Time for normal support

Discuss stuff not about Indigo.
User avatar
galinette
1st Place Winner
Posts: 923
Joined: Sat Jan 09, 2010 1:39 am
Location: Nantes, France
Contact:

Re: Time for normal support

Post by galinette » Thu Apr 19, 2012 11:30 pm

OnoSendai wrote:Etienne:
I guess you will be wanting to write normal map shaders then? :)
Definitely. I hate textures :)

I added some details to my previous post since you replied.

I'm open to discussions regarding the ISL interface for normal maps (especially the conventions for the tangent space)
Eclat-Digital Research
http://www.eclat-digital.com

User avatar
dcm
Posts: 663
Joined: Sun Jan 03, 2010 1:55 am

Re: Time for normal support

Post by dcm » Thu Apr 19, 2012 11:53 pm

SaphireS wrote: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)
Yes

A bump map stores the simulated height of each pixel in the map. The renderer has to then convert these heights into slopes when it renders. It does this by comparing the current pixel with allneighbors to find it`s slope. Normal map stores the slope/tilt of each pixel in the texture.

Normal maps are better becuase, the renderer wants the normal (slope/tilt) of the pixel for lighting. In a normal map, thats exactly what the data represents. In the bump map it has to calculated on the fly.
They are more accurate. A greyscale bump map can only hold 256 levels of height. Sharp edges are easier in normal maps. Each pixel in a bump map is a little block of a certain height. Lay down a sheet of rubber on top of this to see the shaded, sloping surface. There's a loss of detail in there.
They are better for representing something which is difficult to paint manually (ie high rez geo).
Its not just storing the curvature of the high resolution model but the difference in curvature of the high resolution model and the low reolution model.

User avatar
galinette
1st Place Winner
Posts: 923
Joined: Sat Jan 09, 2010 1:39 am
Location: Nantes, France
Contact:

Re: Time for normal support

Post by galinette » Fri Apr 20, 2012 12:07 am

dcm wrote:They are more accurate. A greyscale bump map can only hold 256 levels of height. Sharp edges are easier in normal maps. Each pixel in a bump map is a little block of a certain height. Lay down a sheet of rubber on top of this to see the shaded, sloping surface. There's a loss of detail in there.
Indigo supports EXR bump maps, that's already a good workaround to bump maps precision issues if you have photoshop. 8bit bump maps is clearly an awful thing.
Eclat-Digital Research
http://www.eclat-digital.com

User avatar
dcm
Posts: 663
Joined: Sun Jan 03, 2010 1:55 am

Re: Time for normal support

Post by dcm » Fri Apr 20, 2012 12:15 am

True, but with other advantages which normal maps carries, i`d prefer to use normal maps. A lot of softwares for creating normal maps supports some additional features which could be applied to normal maps (details, noise)
On other side, using EXR bump maps is overkill (meaning in file size and converting/creating)

If i want to make wood with nice bump for closeup,i prefer to make normal map. I like complex materials and details which add realism and using bump maps is sometimes disturbing.

User avatar
Zom-B
1st Place 100
Posts: 4700
Joined: Tue Jul 04, 2006 4:18 pm
Location: ´'`\_(ò_Ó)_/´'`
Contact:

Re: Time for normal support

Post by Zom-B » Fri Apr 20, 2012 12:29 am

Support for 16bit TIF and PNG in Indigo would help here too... just to push that topic too ;)
polygonmanufaktur.de

User avatar
dcm
Posts: 663
Joined: Sun Jan 03, 2010 1:55 am

Re: Time for normal support

Post by dcm » Fri Apr 20, 2012 12:29 am

yeah, 16bit is gold middle way

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Time for normal support

Post by OnoSendai » Fri Apr 20, 2012 12:31 am

Zom-B wrote:Support for 16bit TIF and PNG in Indigo would help here too... just to push that topic too ;)
They are supported already :)

User avatar
galinette
1st Place Winner
Posts: 923
Joined: Sat Jan 09, 2010 1:39 am
Location: Nantes, France
Contact:

Re: Time for normal support

Post by galinette » Fri Apr 20, 2012 12:40 am

Is some grayscale image format supported without conversion to RGB for saving memory ?

In that case, 32bit grayscale bump map could compete with RGB normal map from a memory point of view.
Eclat-Digital Research
http://www.eclat-digital.com

User avatar
Zom-B
1st Place 100
Posts: 4700
Joined: Tue Jul 04, 2006 4:18 pm
Location: ´'`\_(ò_Ó)_/´'`
Contact:

Re: Time for normal support

Post by Zom-B » Fri Apr 20, 2012 12:44 am

OnoSendai wrote:They are supported already :)
You sneaky something... ^^
why not drop such information in public and make people happy!!?
galinette wrote:Is some grayscale image format supported without conversion to RGB for saving memory ?
It is supported for 8Bit images at least... I'll test that whole topic at some point and see if everything works out nicely ;)
polygonmanufaktur.de

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Time for normal support

Post by OnoSendai » Fri Apr 20, 2012 12:45 am

Zom-B wrote:
OnoSendai wrote:They are supported already :)
You sneaky something... ^^
why not drop such information in public and make people happy!!?
I think it was at some point. (online) Manual has only been updated with that info recently tho.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Time for normal support

Post by OnoSendai » Fri Apr 20, 2012 2:12 am

galinette wrote:Is some grayscale image format supported without conversion to RGB for saving memory ?

In that case, 32bit grayscale bump map could compete with RGB normal map from a memory point of view.
Yup, loading of grayscale formats is supported without conversion to RGB.

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Time for normal support

Post by OnoSendai » Fri Apr 20, 2012 2:17 am

It's true that bump maps and normal maps may have somewhat different performance characteristics, and may have differences in their susceptibilities to quantisation errors (e.g. problems when storing as 8 bit/channel).
However, on a fundamental/theoretical level, the only thing normals maps can do that bump maps can't, is to have 'non-conservative' normals - for example, you could have a normal map that described a circular ramp such that you are always heading 'downhill' as you complete successive paths around the circle. Bump maps can't do this as they are based on the derivative of a scalar function. However these non-conservative normals make absolutely no sense in the real world, so it's not really an advantage in practice.

User avatar
galinette
1st Place Winner
Posts: 923
Joined: Sat Jan 09, 2010 1:39 am
Location: Nantes, France
Contact:

Re: Time for normal support

Post by galinette » Fri Apr 20, 2012 7:18 am

OnoSendai wrote:It's true that bump maps and normal maps may have somewhat different performance characteristics, and may have differences in their susceptibilities to quantisation errors (e.g. problems when storing as 8 bit/channel).
However, on a fundamental/theoretical level, the only thing normals maps can do that bump maps can't, is to have 'non-conservative' normals - for example, you could have a normal map that described a circular ramp such that you are always heading 'downhill' as you complete successive paths around the circle. Bump maps can't do this as they are based on the derivative of a scalar function. However these non-conservative normals make absolutely no sense in the real world, so it's not really an advantage in practice.
If you really want to avoid this on textures, you can pre-remove the rotationnal part.

When I make nice algebric bump microfacet shaders, I would prefer derivating myself instead literally of letting the ugly numerical derivation.
And in many cases, the normal can be expressed simply. To convert it to bump, you need to integrate literally, which sometimes is not possible, sometimes possible but ugly. And finally, Indigo derivates numerically... That's too bad.

Also, normal map shaders allow making height discontinuities, which are ugly with bump shaders.
Eclat-Digital Research
http://www.eclat-digital.com

User avatar
OnoSendai
Developer
Posts: 6241
Joined: Sat May 20, 2006 6:16 pm
Location: Wellington, NZ
Contact:

Re: Time for normal support

Post by OnoSendai » Fri Apr 20, 2012 10:44 am

Here you go dcm, just for you :)

Preliminary normal map support has been implemented (see image)

Etienne:
The standard basis for normal mapping seems to be something like:
* Take dp/ds (where p is the surface position, and s is the first texture coordinate)
* remove components in the direction of the shading normal N_s
* normalise. This forms the i vector of the basis.
Likewise for dp/dt to form j
N_s is used for k.
Note that this is not necessarily an orthogonal basis, if dp/ds and dp/dt are not orthogonal.
Attachments
normal_map_test.jpg

User avatar
pixie
Indigo 100
Posts: 2332
Joined: Sat Dec 29, 2007 4:54 am
Location: Away from paradise
3D Software: Cinema 4D
Contact:

Re: Time for normal support

Post by pixie » Fri Apr 20, 2012 11:07 am

OnoSendai wrote:Preliminary normal map support has been implemented (see image)
:twisted:

Post Reply
45 posts

Who is online

Users browsing this forum: No registered users and 26 guests