Indigo Renderer Forum

http://quixel.se/

http://www.youtube.com/watch?v=Cql81lsr ... tu.be&hd=1

Normal map support?
We will definitely have a look at it after the 3.2 release.

Normal Maps: one of my "Top 5 Features I like to see in Indigo"

Please make us happy Ono

As long as orthographic rendering and camera clipping gets in there too

And freeform fisheyes.. erm yes something like that !

orthographic rendering, clip planes, and normal mapping support are all on the 'immediate post-3.2 todo list'.

hide-able emmiters too ?

I learned to work around missing clip planes and Ortho-Cam (Move cam way back and zoooooom back in!),
also not option to hide emitters emitters is something I live with and learned to do so...

But normal maps should bring a bit more quality to my work, and that is what I am looking for

Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.

OnoSendai wrote:Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.

you are wrong, master

dcm wrote:

OnoSendai wrote:Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.

you are wrong, master

Oh? Please elaborate.

"fundamental" is a hard word here, but referring our experience with other render engines NMs tend to create way better illusion of depth, also well suited for animations since bump maps only have inner2outer changes of the normals, while NMs have here also a "angle" they define!

OnoSendai wrote:Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.

Theoritically, yes

Practically, and especially when working with shaders, writing normal maps is much easier, this means much more powerful.

Example : I want to give every window in a building a random tilt angle.
In normal map syntax, this means a shader with uniform value over each window. Very simple
In bump map syntax, you need to define a gradient, which means you need to cope over a coordinate system (world xyz or uv). xyz will give you orientation headaches, uv will set scaling issues (the tilt amount will depend on uv scaling), and finally, I gave up finding a universal and clean solution.

On the other hand, normal mapping and having access to an instance/model ID in ISL (another long time request, for randomizing between instances) would have allowed solving this in a beautiful way with a few lines of code, and this could be applied to a standard glass building material reproducing façade imperfections (tilt, tempering wavelets and thermal deformation)

Also, bump maps/shaders suffer from numerical errors liked to numerical derivation: stepping with bump maps(partially solved with smoothening) and arctifacting with high frequency features (which means you cannot define very small roughness for faking a kind of microfacet model) which is more a problem with shaders for making things like velvet

Etienne

Isn't it basically just a "one vs. three channels" precision issue? (eg 1 b/w-channel vs. 3 rgb-channels storing information, assuming same bit-depth)

Etienne:
I guess you will be wanting to write normal map shaders then?