Time for normal support

Zom-B · Fri Apr 20, 2012 11:09 am

Master Ono did it again

seems to be worth nagging you hard about something :lol:

Thanks a lot for the effort!

StompinTom · Fri Apr 20, 2012 9:27 pm

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.

galinette · Sat Apr 21, 2012 3:36 am

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

OnoSendai · Sat Apr 21, 2012 3:49 am

Hi Etienne,
Nice link, thanks!

OnoSendai · Wed Apr 25, 2012 10:14 am

Another normal map test.

The model is the 'infinite head'.

dcm · Wed Apr 25, 2012 10:16 am

CTZn · Wed Apr 25, 2012 10:38 am

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 !!!

galinette · Wed Apr 25, 2012 9:18 pm

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

Zom-B · Wed Apr 25, 2012 9:25 pm

I think its a general issue: viewtopic.php?p=113329#p113329

galinette · Wed Apr 25, 2012 10:46 pm

Zom-B wrote:

I think its a general issue: viewtopic.php?p=113329#p113329

Nope, I don't think so. The image on your link relates to precision issue, whereas this is a typical tangent space convention problem

OnoSendai · Wed Apr 25, 2012 11:07 pm

Hi Etienne,
I think Zom-B is right, it's a terminator artifact.

OnoSendai · Fri Apr 27, 2012 11:16 am

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.

CTZn · Fri Apr 27, 2012 11:53 am

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.

Zom-B · Fri Apr 27, 2012 9:36 pm

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 :roll:

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:

Attachment:

subdiv_c4d_CC.jpg [ 78.63 KiB | Viewed 1728 times ]

Indigos subdiv with quads @ 2:

Attachment:

subdiv_indigo_quads.jpg [ 83.93 KiB | Viewed 1728 times ]

Indigos subdiv with tris@ 2:

Attachment:

subdiv_indigo_tris.jpg [ 94.38 KiB | Viewed 1728 times ]

That distortion comes trough having non uniform scaled polygons, here a mesh shot of the model:

Attachment:

subdiv_indigo_color.jpg [ 89.62 KiB | Viewed 1728 times ]

OnoSendai · Fri Apr 27, 2012 10:07 pm

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.

Time for normal support

Who is online