[KurtS]

But doesn't that suggest that the bump effect is capable of accounting for it's own shape for direct light, but not indirect light? In other words: it self-shadows and reflects properly for emitters, but not the reflected light off the floor, or the actual reflection of the floor?

That can't be right, can it? Am I missing something obvious? (wouldn't be the first time.... )

b

You can have a "dark side" of a bump, but that bump wil not throw a shadow on another part of the same surface unless its physicaly modeled.

[JTB]

Is this discussion justified when we already have 3 final releases of the product? (I wonder...)
Anyway, where is the official NL opinion on this?

[KurtS]

I don't see any problem with this. AFAIK this is the way bumpmaps work in all rendering engines, unless it supports displacement. (except the problem that WillMartin shows - it's more Maxwell specific)

[dilbert]

I've had problems with this also. Check out the following link. It's a material I uploaded, and no matter what I did to the bump map, it seemed like the parts that were meant to "bump" outwards, i.e. the white parts, bumped out on one side of the lightsource, and bumped in on the other. I don't know if there's a fix.


http://www.maxwellrender.com/forum/view ... hp?t=22599

[iandavis]

the only thing I can think of is that maxwell is getting confused. bump maps depend on the changes of value to indicate normals changes in the smoothing. If there is no transition and it goes from white to black there is very little (zero) change to read and the engine assumes/guesses.

If the maxwell bumpmap engine is working you should be able to get the right result as long as any transition between values happens over a few pixels. Also, I've had issues with using black and white... It seems better (results-wise) to use 128 as the mid and 220/20 as the high/low values.

If your bump map is:
1. 8 bit greyscale ( I don't know if maxwell supports 16 bit maps )
2. slightly blurred (gaussian @ 2 pixels )
3. contains a sensible range of values and isn't all one tone or another.
then.. it should work. If it doesn't... I blame Maxwell.

[WillMartin]

As for the format of the map being valid enough for M~R or not, while what's posted above is a gif (for quick thread viewing) the tests were all done with a .png (out of Photoshop). Maxwell seems to like it fine enough in general.

Note that I only use LW, so perhaps I have a scewed perspective in my expectations as to what bumpmaps do in any 3D app. I would assume that all would give me close to what LW gave me above, but maybe Max or Rhino would give results more like the M~R above? Or does Maxwell have special conditions for a bumpmap working from other apps that I've somehow not come across? Feel free to enlighten me a bit on any of this; I admit I'm no 3D app master.

If there is no transition and it goes from white to black there is very little (zero) change to read and the engine assumes/guesses.

I understand about the huge leaps from black to white, but the airbrush spots aren't in the same league as that, are they? (applying blur to airbrushing? ... edit: just tried it and Photoshop isn't showing any change when I try to blur those airbrush spots. They are as blurred as can be expected from what I can tell)

[iandavis]

you blur the entire image to take care of areas like those squares. The areas already at least 2 pixels blurry will not be impacted much at all. From your tests it looks like a lot of areas are ok, but some are in error. There is no denying that it's a little wacky with maxwell.

I use LW exclusively as well. That shouldn't mean anything tho, since it's true that bump mapping works pretty much the same way with all apps.

Though, I would try making a 'greyscale' in photoshop and save it as a bmp. Next Limit, if you want to jump in here and tell us what format maxwell is designed to like best?

If it gives you problems after making it greyscale, no black and white touching eachother (gaussian blurred) and saved as bmp... well then, you can be pretty sure it's the software and not your bump map having the issue.

[WillMartin]

Another piece of the puzzle, and I think this solves it?...

In LW, it is not uncommon to take bump map values pretty high. Apparently M~R starts acting strangely to this if you don't have a monstrous resolution map (with lots of grayscale). Here is exactly the same image I've been rendering (no blur applied to the map or anything), the only difference being that I set the Maxwell surface bump map value down to 5 from 90...



The previous images I posted, despite the value being nearly maxed-out (90) by M~R standards the beveled stuff looked good and fine as you saw but the rectangles were a mess. Here as you can see, the beveled stuff is barely visible, but the white-black rectangle stuff looks fine. (Note1: Raising the setting from 5 to even 15 starts these rectangle bumps to lose their cohesion. Note2: in all my tests the "airbrush dot "stuff was pretty bad; is too flat at low setting and starts "clipping" right away up raising the bump map value.)

So it indeed seems M~R does bump maps differently than at least LW. It seems that for a single bump map of this design to give the same output in M~R as in LW, the resolution would have to be increased many, many fold and near invsible blur (unless zoomed way in) applied to the rectangles so that the map value could be set high and not clip anything -- at least that's my present conclusion. Maybe I'm wrong on that, though, so feel free to keep experimenting and correct me.

[lebbeus]

here's a crazy thought:

can you split up your bump maps to different layers (and set up some weight maps) and use the "appropriate" bump value for each element (low values for the rectangle and nearly maxed-out ones for the bevels, etc)???

EDIT:
actually, I guess you could use the same bump map, just set up different layers (using the same map) and knock-out the portions you don't want for that layer with a weight map. Will do some tests to see if this works (slow day here at the office )

[iandavis]

One problem I run into is the limits of the bump itself... you only have 256 levels to play with. (unless you have 16 bit bumps)

For vastly different levels you need to think numerically. Your low rise areas need to occupy from black to say 50/256 where the higher areas will go all the way to white. If everything is a bump rather then a depression, you can have the base value at near 0, but if there are depressions as well as high areas the base needs to start somewhere in the middle. Use the situation as a guide; if there are tall mountains with a shallow river the base value can be lower, where conversely if there is a canyon with a slightly bumpy plateau then the base value should be set higher, closer to white.

the latest render looks like all the values are within only a small portion of the usable bump space...? If you don't use every bit of the bump range possible you will get the dreaded 'stairstep' problem... though you may end up with it regardless, since 256 really isnt that many steps for some situations.

cheers

[lebbeus]

here's my quick test: 1 bump map, 2 layers (bump values of 5 and 90 respectively) and weight maps. Still some weirdness…

[ivox3]

It would help if we can see the map used .......

[lebbeus]

sorry--its the same one as posted earlier in this thread
http://www.freeimagehosting.net/image.p ... 0c14ac.gif

[ivox3]

Gotcha .....

[lebbeus]

here are the weightmaps in case anyone is interested:

for the beveled areas:


for the non-beveled areas: