Page 3 of 3
Re: Time for normal support
Posted: Fri Apr 20, 2012 11:09 am
by Zom-B
Master Ono did it again
seems to be worth nagging you hard about something
Thanks a lot for the effort!
Re: Time for normal support
Posted: Fri Apr 20, 2012 9:27 pm
by StompinTom
OnoSendai wrote: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.
That was fast! Looking sexy.
Re: Time for normal support
Posted: Sat Apr 21, 2012 3:36 am
by galinette
OnoSendai wrote: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.
Hi Ono,
There are several tangent space conventions used. The one used in 3dsmax is quite different from this one, and should be used as a reference I think.
It is explained there:
http://area.autodesk.com/userdata/fckda ... %20Max.pdf
Using the wrong tangent space leads to inconsistencies when rendering normal maps
Etienne
Re: Time for normal support
Posted: Sat Apr 21, 2012 3:49 am
by OnoSendai
Hi Etienne,
Nice link, thanks!
Re: Time for normal support
Posted: Wed Apr 25, 2012 10:14 am
by OnoSendai
Another normal map test.
The model is the 'infinite head'.
Re: Time for normal support
Posted: Wed Apr 25, 2012 10:16 am
by dcm
Re: Time for normal support
Posted: Wed Apr 25, 2012 10:38 am
by CTZn
OnoSendai wrote:Another normal map test.
The model is the 'infinite head'.
Can we see an example on hard surfaces, with other maps put on please ? Normal maps support is a great addition for digital sculptors. Bump is getting quite an old trick by the time I recon.
Don't show this on an implicit surface or I'll bug you till it's into the trunk !!!
Re: Time for normal support
Posted: Wed Apr 25, 2012 9:18 pm
by galinette
OnoSendai wrote:Another normal map test.
The model is the 'infinite head'.
Nice!
I can see some tangent space discrepancy (between the soft generating the map and the renderer) on the upper left I think
Etienne
Re: Time for normal support
Posted: Wed Apr 25, 2012 9:25 pm
by Zom-B
Re: Time for normal support
Posted: Wed Apr 25, 2012 10:46 pm
by galinette
Nope, I don't think so. The image on your link relates to precision issue, whereas this is a typical tangent space convention problem
Re: Time for normal support
Posted: Wed Apr 25, 2012 11:07 pm
by OnoSendai
Hi Etienne,
I think Zom-B is right, it's a terminator artifact.
Re: Time for normal support
Posted: Fri Apr 27, 2012 11:16 am
by OnoSendai
Here's the same scene but with 3 subdivs on the head.
Btw, one thing I really don't like about the approximating subdivision schemes (Loop + Catmull Clark) that Indigo uses is that they soften/distort detail, such as this guy's features. (You can see this by flicking back and forwards between the two renders)
Maybe we need to look into interpolating subdivision schemes.
Re: Time for normal support
Posted: Fri Apr 27, 2012 11:53 am
by CTZn
I think it's alright really. If the maps were baked against the lowpo version then an offset on the smoothed one is expected (those moving volumes might be mapped).
I presume that all sculpting and modeling apps use C-C by default, that's the way for results to remain consistent accross them.
Well I don't know, your call.
Re: Time for normal support
Posted: Fri Apr 27, 2012 9:36 pm
by Zom-B
OnoSendai wrote:Btw, one thing I really don't like about the approximating subdivision schemes (Loop + Catmull Clark) that Indigo uses is that they soften/distort detail, such as this guy's features.
Put a checkerboard texture on him if you want to see the distort better.
If you like to disable the normal smoothing, simply use a Diffuse Transmitter or a Glossy Transparent material
OnoSendai wrote:Maybe we need to look into interpolating subdivision schemes.
I already asked for that back in 2010
Since Indigo v3 you implemented quad based subdiv, what countered the distortion a little, but doesn't have any view dependency working...
Here are some images:
C4D based subdiv with CC @ 2:
Indigos subdiv with quads @ 2:
Indigos subdiv with tris@ 2:
That distortion comes trough having non uniform scaled polygons, here a mesh shot of the model:
Re: Time for normal support
Posted: Fri Apr 27, 2012 10:07 pm
by OnoSendai
Hi Zom-B
It's the smoothing of the vertex positions themselves that I was referring to, not the UVs, although that can be an issue as well.