Well a lot has been written about bitmap blur and its effect on rendertimes and sharpness and whatnot. A lot of people have incorporated a workflow where they use the input of one bitmap with different color corrections to create a shader. Now I was thinking, say I have a diffuse map with blur set to 0.5, but I want to use that same map for the VrayColor2Bump map to generate some bump, but when using that same VrayHDRI node with the blur set to 0.5 it will be too sharp for bump (or when using it for reflections or whatever…) so I have to duplicate that VrayHDRI node and raise the blur.
Question: wouldn’t there be a better way to manage this, so I don’t have to go and duplicate the same HDRI map 3-4 times because I want different blur values? I know I can export some parameters with some floating spinners and whatnot if I want to change tiling or other parameters and link them all to the other maps but this wouldn’t be necessary if we would have a different way of managing the blur values per map type.
Maybe a special node that receives the map and outputs multiple different blurred maps?
I think the vrayhdri takes care of avoiding duplicate images already, whether the map is instanced or copied (something not quite working for the standard max bitmap loader), provided the image path is identical.
That is, if memory occupation is your issue, rather than outright UI/workflow.
Personally, i’d love more atomic nodes, but i can hear the screams in the distance coming closer and closer if i think of splitting UVs from map loading in max (it’s never been the case. people will resist it if history’s any teacher.).
It’s also unclear if it could be done at all (it couldn’t a decade back, due to intrinsic Max code) without serious side-effects.
Alas, it’s a +1 with reservation from me.
I for my self like it the way the osl in 2019 works where uv is splitted from map loading. It’s nice to be able to distort the uv’s with noises. I don’t think people will complain If that’d be an optional thing.
