Time for normal support
Re: Time for normal support
Normal map support?
We will definitely have a look at it after the 3.2 release.
We will definitely have a look at it after the 3.2 release.
Re: Time for normal support
Normal Maps: one of my "Top 5 Features I like to see in Indigo"
Please make us happy Ono
Please make us happy Ono
polygonmanufaktur.de
-
- Posts: 1828
- Joined: Mon Sep 04, 2006 3:33 pm
Re: Time for normal support
As long as orthographic rendering and camera clipping gets in there too
Re: Time for normal support
orthographic rendering, clip planes, and normal mapping support are all on the 'immediate post-3.2 todo list'.
Re: Time for normal support
hide-able emmiters too ?
Re: Time for normal support
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
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
polygonmanufaktur.de
Re: Time for normal support
Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.
Re: Time for normal support
you are wrong, masterOnoSendai wrote:Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.
Re: Time for normal support
Oh? Please elaborate.dcm wrote:you are wrong, masterOnoSendai wrote:Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.
Re: Time for normal support
"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!
polygonmanufaktur.de
Re: Time for normal support
Theoritically, yesOnoSendai wrote:Quality wise, I don't think there is a fundamental improvement of normal maps over bump maps.
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
Last edited by galinette on Thu Apr 19, 2012 11:29 pm, edited 2 times in total.
Eclat-Digital Research
http://www.eclat-digital.com
http://www.eclat-digital.com
Re: Time for normal support
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)
Your ad here!
Re: Time for normal support
Etienne:
I guess you will be wanting to write normal map shaders then?
I guess you will be wanting to write normal map shaders then?
Who is online
Users browsing this forum: No registered users and 38 guests