Color and Bump are two different channels in Max (hence the Bump amount parameter in the output rollout which handles bump specifically) and some maps produce different or no bump at all. With this map, you can ‘force’ bump to render based on color output even if the map doesn’t provide any bump channel information (such as AO, for example). Another really useful side effect is that you can use all blending modes of the composite map and color correction on bumps.
No, it takes whatever is plugged into it and treats it like regular black and white RGB information, just as if you plugged a bitmap into the bump slot.
Another example is using the color correction node - it just does not work with bump. If you use the bump converter, it will magically start working as you would expect.
i am not sure why we need to use color correction node for bump if we can use output rollout in the same texture and it work with color correction just don’t give result for bump
@maru - have you tried to use it with the tiles-map? I can’t make it work. Just like it doesn’t work very well with greyscale bitmaps. …or maybe I’m overlooking something?
Hi, I have a question about using noise map in BumpConverter.
In the attached examples you can see that BumpConverter does something to mapping of noise map.
If I change object XYZ to explicit mapping in noise map coordinates, and map objects with same UVW modifier it works as expected.
Is this normal behavior?
Should we avoid using some procedural maps in bump converter for any reason?
Good catch. But shouldn’t the noise look different anyway? If it was mapped in Object Space I’d expect it too look like what the BumpConverter looks like… If you used World Space then BumpConverter doesn’t seem to pick it up properly.
Odd thought, but why couldn’t “Bump Converter” be hard-coded into the Corona shader ? Basically every time you would put shader network into bump slot, Corona would act like there was ‘BumpConverter’ node on top of it.
I am still confused why Corona shader replicates 3dsMax limitations if it’s property of Corona. I mean the bump slot could simply be called “CoronaRelief” or something random whatever, why does it need to share some property of 3dsMax ? Or is there some deeper reason due to integration ?
(And did anyone ever use the ‘bump amount’ inside 3dsMax bitmap ? I didn’t even know what that crap was for, and now when it’s explained, it just seems like some stupidity from DOS era that can be safely ignored)
Dunno if that’s good idea. I rarely use bump converter, because more often than not, i like max’s native bump result more, even if it’s not correct. Of course there are instances where bump without converter simply won’t work and then it is like gift from gods :]
It can be useful when bitmap is instanced into several materials’ bump slots and you want to adjust bump strength for all affected materials at once.
If one produces incorrect result than that’s not very good argument for keeping it :- ).
One of reasons I stick almost 100perc. to normal maps these days.
The other argument is quite weird solution too to be honest :- ). Seems like out-of-the box way to do something that can be done much easier with more commonly accepted workflow. Even though that’s currently CoronaNormal map loader.
But I am not negating the need for a useful node…I love nodes, options are options, flexibility is good.
Just not sure why “problematic” scenarios cannot be solved through hard-coding inside shader and instead introducing band-aid stemming from adhering too close to every quirkiness of host app. I would definitely ignore some outdated concepts from 3dsMax.
I was thinking the same thing. If Bump Converter function is to adjust any map to be used as an input to the bump map channel why not just integrate it into bump channel.
Maybe I’m getting something wrong here. Is there a reason why some maps shouldn’t be used through Bump Converter but only through regular bump channel?
it might make sense to use it internally to replace known problematic shaders, but generally it is bad idea to use this as blanket solution, because bump convertor for example interferes with normal maps (normal map plugged in bump convertor should not work normally), is inefficient for bitmaps (regular bitmap should have better performance there), and generally it is violating conventions of 3ds max. 3dsmax offers every shader to do its own bump mapping, and some do it correctly, those should not be overriden automatically. Overriding those that are deemed to do bump incorrectly is fair game though.