Time for normal support
Re: Time for normal support
Master Ono did it again
seems to be worth nagging you hard about something
Thanks a lot for the effort!
seems to be worth nagging you hard about something
Thanks a lot for the effort!
polygonmanufaktur.de
-
- Posts: 1828
- Joined: Mon Sep 04, 2006 3:33 pm
Re: Time for normal support
That was fast! Looking sexy.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.
Re: Time for normal support
Hi Ono,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.
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
Eclat-Digital Research
http://www.eclat-digital.com
http://www.eclat-digital.com
Re: Time for normal support
Hi Etienne,
Nice link, thanks!
Nice link, thanks!
Re: Time for normal support
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.OnoSendai wrote:Another normal map test.
The model is the 'infinite head'.
Don't show this on an implicit surface or I'll bug you till it's into the trunk !!!
obsolete asset
Re: Time for normal support
Nice!OnoSendai wrote:Another normal map test.
The model is the 'infinite head'.
I can see some tangent space discrepancy (between the soft generating the map and the renderer) on the upper left I think
Etienne
Eclat-Digital Research
http://www.eclat-digital.com
http://www.eclat-digital.com
Re: Time for normal support
I think its a general issue: http://www.indigorenderer.com/forum/vie ... 29#p113329
polygonmanufaktur.de
Re: Time for normal support
Nope, I don't think so. The image on your link relates to precision issue, whereas this is a typical tangent space convention problemZom-B wrote:I think its a general issue: http://www.indigorenderer.com/forum/vie ... 29#p113329
Eclat-Digital Research
http://www.eclat-digital.com
http://www.eclat-digital.com
Re: Time for normal support
Hi Etienne,
I think Zom-B is right, it's a terminator artifact.
I think Zom-B is right, it's a terminator artifact.
Re: Time for normal support
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.
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
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.
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.
obsolete asset
Re: Time for normal support
Put a checkerboard texture on him if you want to see the distort better.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.
If you like to disable the normal smoothing, simply use a Diffuse Transmitter or a Glossy Transparent material
I already asked for that back in 2010OnoSendai wrote:Maybe we need to look into interpolating subdivision schemes.
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:
polygonmanufaktur.de
Re: Time for normal support
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.
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.
Who is online
Users browsing this forum: No registered users and 42 guests