Material Preview V-Ray Issues (with Abbe)

[JonasNöll]

Hi,

I have following problems:
- When enabling the abbe for refractive shaders in the compact material editor stuff gets extremely slow. Up to that Max freezes for like 20 seconds before can continue.
- The problem gets worse when there are a couple of slots in the compact material editor populated with refractive shaders and abbe enabled
- When you save a scene and reopen it and open the material editor it takes minutes to load all the preview slots back if there are refractive shaders with abbe enabled
- I don't have this issue with Max 2018 and V-Ray 3.6

My quesions:
- Am I right to assume that this has to do with the new (admittingly much more beautiful) material previews?
- Is it really necessary to calculate the abbe for the material previews? You anyway can't see the effect in the tiny previews...
- Is there a way to get the old previews back?

Running the latest nightly build

[kosso_olli]

- Is there a way to get the old previews back?

In the render settings window, under Settings->System->Native 3dsMax material swatches.

[JonasNöll]

Oh great, thx a lot!

[^Lele^]

*) The new material preview renders with multiple AA samples, the old one a single one (i.e. v-ray before v5). Further, Abbe is a spectral effect, in itself requiring a lot of secondary samples per camera ray, which compounds the render time.
*) The behavior is expected, as the max material editor doesn't allow for caching of the sample images on load: it will force a recalculation on scene open (out of our hands.). So, more samples, more render time.
*) See previous.
*) See first.
---
*) See above.
*) If we started to arbitrarily drop whichever feature was deemed too long to compute, we might as well render gray balls. There is no difference between the small preview and a double clicked one: the material is exactly the same. So dropping features for the small one would drop them for the big one too. And then it would be problematic, as features people's tweak would not show up at all.
*) Olli explained.

If it is what you work with the most, and this is unacceptable on your hardware, feel free to revert as Olli explained.

Better still, clear the mateditor when you close the file, so to save yourself the wait: you won't be editing 24 samples at once, anyway, on file open.
In nigh any of the productions i TDed, this was a hard requirement.
We had shaders which loaded tens of GB of textures off the network, and would take an hour each time one such shader was to be rendered, on file open or mateditor open.
Cleaning after one's self, even between lookdev sessions (i.e. a scene closes. you have no caching for it left in RAM.), is generally a very good practice.

[JonasNöll]

Hi,

thanks for the explanation! In this case I think the best way for me would be to just use the original material swatches if I need to enable abbe as they don't come with those inconveniences.
I get what you are saying about that the swatches should be a 1:1 representation of the original shader. It makes sense, but in terms of the abbe you literally can't see any difference in the swatches with bare eyes and without it renders 4 seconds and with it takes 40 seconds to update the preview in my case, so I'm not sure how anyone would benefit from that in this instance
Anyway thanks for leaving the option for the original swatches available!

[kosso_olli]

We had shaders which loaded tens of GB of textures off the network, and would take an hour each time one such shader was to be rendered, on file open or mateditor open.

Really? How did operators cope with this?

[^Lele^]

We were simply at our wits' end.
That person was left unsupervised, and decided for an approach to shading revolving entirely on a single multisub material, "for easier updates", he said, of a *very* complex asset, present in a very high percentage of the shots.
By the time we (other TDs. I was warned by the Comp Sup, which waited two weeks for a simple shot, go figure the trouble it got us into.) realised, it was too late to change approach.
Opening the shader was akin to launching a full render, and it'd load a metric ton of PNGs that it then proceeded to colorcorrect to hell and back, and so on.
It would literally have people from all departments turn around looking for someone working on the thing, so slow the whole file serving became.
Rendering sequences on the farm was utterly out of the question.

I ended up converting all textures to 16bit (double the bitness of most originals, ugh), but to convert them to tiled EXRs.
VRayHDRI loaders took care of loading the minimum amount of viable data (as opposed to the max bitmaps) from those hundreds of textures, making the load a matter of a few seconds, believe it or not.
The multisub material sample only shows so many IDs, and the VRayHDRI would stop loading bitmaps that weren't needed very quickly, while the max bitmap loader would load the *whole* of the dozens of shaders at play, with all the bitmaps at their 4/8/16k original sizes.
It wasn't uncommon to have max quit as it finished loading.
In that case, we had to change video drivers and load again, so that it wouldn't support huge textures, to then proceed to save it as bounding boxes or wireframe, instead of shaded with textures. (...)

Stuff that happens when you jump a company too many, in too short a time, perhaps.
Life of a mercenary, i'm sure it's common enough an occurrence for many.

[Joelaff]

The more experienced you get the higher percentage of your time is spent fighting stupid issues like this. If everything just “worked properly” as Dyson says an experienced artist could go home at noon every day.

[PIXELBOX_SRO]

I found out that standard max color correct node does somecrazy shit with the swiftness of mtl editor. Some mats where color correct is used take 10-30 secs to update.
any chance of getting vrays own color correct node please?

[Joelaff]

I found out that standard max color correct node does somecrazy shit with the swiftness of mtl editor. Some mats where color correct is used take 10-30 secs to update.
any chance of getting vrays own color correct node please?

I would love to see a VRay Color Correct. There is also this Color Correct. Though I haven't tested it recently, I know back around 2014 or so it was MUCH faster than the built in one. I think some of that speed difference went away around Max 2016 or so, though.

https://cuneytozdas.com/3ds-max-plugins/

I would trust a VRay CC node to still be around in a few years. To be fair, Cuneyt Ozdashas done a nice job keeping his plugin up to date.

[kosso_olli]

I found out that standard max color correct node does somecrazy shit with the swiftness of mtl editor.

This has been the case since it's introduction. The standard Max color correction is extremely slow. As is the standard composite.

[Moriah]

Is there any substitute for the composite node? Any plugin paid or free? Vraycomptex is very limited since it doesn't support multiple layers.

[^Lele^]

Have a look inside the vrayPluginTex node.

TexLayeredMax (any *Layered* really, as you please), ColorCorrect/ColorCorrection should provide you with the functionalities you're looking for.
You'll have to forego the PS-like ui of the max's composite, though, in favour of nesting of nodes, when the layers are many.
Their functionalities should be fine, however.
You should really notice my use of conditionals: the stuff in that texture node isn't exactly meant to be used directly, but rather as a tool for us to translate across apps.

So, feel free to try it out, but be wary of potential issues as you do so.