[Coming Soon] PBRTK - PBR Viewport Shader for 3DS Max
Traditionally, 3DS Max has not been very good at previewing what game art will look like in the final game, particularly with the standardization of PBR shading in next-gen engines.
PBRTK is a viewport shader for 3DS Max which solves just that! This viewport shader gives you a physically-based shader based on the metalness workflow in line with next-generation game engines, allowing you to have a much better idea of what your model will look like in the final game.
Some screenshots of the shader are below:
Get it here: http://www.mophogames.com/pbrtk-3ds-max-viewport-shader/
Replies
Also...potential issue here. I see you are working in max 2010. Are you preparing this to work post max 2013 when autodesk decided to screw up the way normals work?
How did max screw up the way normals work? >.>
I'm calculating my own tangent basis from the normal, tangent, and binormals.
Glad to know there's interest in this
But I can't seems to see the screenshot posted on your first post?
im loading it like i would Xioulin shader so if this is a error on my part my apologies, i know at least one of my buddies would love this kind of option in max aswell.
best of luck i will be following the development of this closely.
Eh? The example I provided?
Are you talking about the viewport shader template?
Try changing line 213 to this:
Actually, I just changed that yesterday. Now it takes separate images for metalness, ambient occlusion, and roughness. Also, non-metal surfaces are now assumed to be 4% reflective - this was mentioned over on the PBR in Practice page on the Marmoset website, and I went with it as it allows me to drop a full extra texture. It also seems to work just fine in practice.
I had a question regarding the 4% (0.04) base reflectivity. Is this the linear value? or the gamma space value? (Same for 30 -50 minimum value on the diffuse, is it 30-50 before or after gamma correction?)
Thanks.
Don't know about the diffuse one. I think it's safe to assume that it's pre-gamma-correction, since generally PBR works/looks best in a linear color space.
Get it here: http://www.mophogames.com/pbrtk-3ds-max-viewport-shader/
- And the cubamep is wrapping strange. I mean it looks ok from the default view, but its coordinates looks buggy when im rotating the camera.
Not necessarily
It's easy enough to change of course. I may add an option to change how roughness works. Until then an easy workaround is just to import your roughness map into Photoshop and hit CTRL+I.
Screenshots?
Look at the top of the sphere, notice you can see the ground.
It's actually common to capture an environment for image-based lighting by taking a photograph of a highly reflective ball as seen above.
All I'm doing is reflecting view direction along surface normal using the built-in reflect function. The result is also realistically plausible as evidenced by many photographs I can find on Google Images, so I don't think it's an issue.
EDIT
Seems UE4 also has results closer to what I have: https://d1wzu4qct23er4.cloudfront.net/files/78349185fe86484abe39f70b3666db92/original/banner2.jpg
So I'm assuming it's probably some optimization or approximation in UDK.
What issue are you encountering? Material doesn't show up in material browser, invisible in viewport, files not installed to correct locations, errors...?
If the MZP file runs at all it should pop up a message box telling you to restart 3DS Max. If it doesn't, then something is definitely wrong.
EDIT
Still, you CAN manually install the files yourself. It's just more of a pain.
To do this, rename the .MZP extension to .ZIP, then extract it. Take the files under res/PBRTK/ and put them into Maps/fx/PBRTK/. Then, take the PBRTKMaterial.ms script under script/ and move that to Scripts/Startup/PBRTK/
Oof, sorry for responding late...I was referring to how Nitrous spits out wierd values for tangents/binormals. I really don't know much about it, other than it crippling the xoliul2 shader.
That pretty much killed me ever attempting to use viewport shaders in max ever again, so I haven't bothered messing with any new shaders since.
Sounds like its working fine for other people though, so ignore me
Switching to DirectX mode fixes that. Same is true for Max 2015 and nitrous
I'm not sure wether the things your scripts does are not supported in Nitrous at all or only some small checks would be sufficient to make it work in Nitrous. But would be great to have it work in Nitrous
Anyways great initiative, and thanks for posting this
What BRDF do you use in your shader ?
Hadn't heard of GGX before for some reason, will take a look. Seems to have much nicer/softer highlights than Cook-Torrance.
i know from experience.
I originally developed it for someone else, but they can't seem to run it in 2011 (invisible in viewport). I forged ahead and released it anyway as I have no means of actually testing or debugging this, but hopefully somebody out there may be able to help.
I actually really like the falloff of the highlight. Much less of a severe falloff than Blinn-Phong or Cook-Torrance.
Interesting, my understanding is based on what I've heard from various programmers, thanks for the correction.
This new version's got some changes:
1.) Now using GGX instead of normalized blinn-phong, bringing specular results closer to that of UE4.
2.) Changed the specular cube mip factor to more closely match specular highlight results.
3.) New specular cube texture included. Apparently I forgot to check "Save mipchain" in CubeMapGen. Oops. New specular cube does not suffer sharp edges, yay!
Be sure to uninstall old version first before installing new version.
Just tried - works perfectly fine with Max 2011....
Hm. Well, it must be something strange with his particular setup.
He also has Xoliul installed, maybe that would make a difference?
for pbr you don't use emission for either the diffuse or specular IBL, they both get added to the diffuse/specular response as applicable.
also, you're not doing any kind of importance sampling for your IBL, you're just scrolling through the mip levels based on roughness * mip total, which is "wrong" for a couple of reasons. the first reason is that it doesn't match the actual roughness curve that GGX has (just use the specular distribution factor for this). the second being that you're always going to have a "stepping" effect with the IBL, you'll never have true variance in IBL based on your roughness input... you could have a well defined material that looks incorrect because the IBL is returning a block value rather than a true one.
I would suggest studying resources like these:
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch20.html
if the albedo is black then metalness will try to use black as the reflective value.
2.) Wat. I thought mip selection was the standard way of doing blurry reflections?
Nope. In that case your albedo should be the color of the metal, as per standard metalness workflow. You're probably thinking of the specular color workflow
EDIT: I'll take a look at importance sampling when I have time (probably next weekend)
Emissive pixels are considered to pass without lighting/shadowing. They can also give off illumination based on their brightness, depending on the engine (and usually they're great in combination with bloom, even if they don't give off illumination, due to their high contrast with shaded pixels around them).
Because emissive pixels don't receive lighting or shadow, they're physically incorrect, which is one of the cornerstones of PBR.
2.) Yes, mip selection is used, but it's used in conjunction with importance sampling. the simple reason being that if your cubemap has for example, 8 mip levels. Then without importance sampling your material can only haver have 8 "bands" of roughness in the IBL contribution.
For example:
Without importance sampling, you may have a material that's closer to the pen tip than the chrome sphere in terms of the value you've handed to the shader, but because it's not quite rough enough to be in the bracket with the pen tip, it has a chrome reflection.
What importance sampling does is help break up each band so you get a more true representation of a roughness curve.
Quote from Andrew Maximov's blog;