PDA

View Full Version : Normal Map not respecting self shadow



GimbalLock
03-22-2018, 06:34 AM
Hi Forum,

Sorry for all my spam. Having some difficulties these days ;)

I'm testing out a set of textures with displacement from Real Displacement Textures.
I cannot get the Normal Map to respect self shadows, as seen below. Normal Map is set to Linear color space.
Test render with no GI to make it clearly visible:
140823

Even when reducing the strength of the map to a point where it starts to lose its purpose:
140824

GimbalLock
03-22-2018, 06:37 AM
Here's a sample image of how it renders out in Cinema4D. All the displacements are razor sharp.

140825

lertola2
03-22-2018, 06:46 AM
Its hard to tell what is going on without seeing you scene. It looks like you might be seeing the backside of some polygons. Have you tried making your surface double sided?

GimbalLock
03-22-2018, 07:20 AM
Thank you, that did it. :)

140826

Though I wonder why it's necessary - the mesh is a closed sphere very simple just subPatched and displaced so my guess is that Normal Maps will do this in many cases. Should I always double side normal mapped objects?

Another thing is that I can't seem to get things very sharp. Not compared to the sample C4D render. Displacement map is 16k x 8k and Normal Map likewise, and subPatch level is 30 on a tess 4 sphere, so everything's ludicrously high res.

GimbalLock
03-22-2018, 07:24 AM
I can boost the bump and normal maps to get it sharper on top, but the underside lit by GI remains a lump of putty.

Here's another render with all maps applied.
AO map can fake the missing definition on the underside, but things are still a bit putty overall.

140827

03-22-2018, 08:07 AM
Have you flipped the normal map about the axi?
In a note early on, or in the docs, they say that this may be necessary now.

If it only works double-sided, your sphere is flipped inside out or you need to do the above in the normal map panel. Double-sided shouldn't be needed.
Robert

GimbalLock
03-22-2018, 08:31 AM
Hi Robert,

Changing the normal map axi makes indents pop out or in case of Z, reverse lighting for the entire object, so the default settings are correct in this case.
The sphere has its normals out, if not it would render as a hollow bowl, so it's only the surface modifiers that don't respect the self shadows unless double sided.

GimbalLock
03-22-2018, 08:35 AM
As for the butty-like underside, I've noticed in other cases that things affecting normal rendering doesn't get picked up by GI diffuse lighting. For example, DP Edge only rounds edges that are hit by a light or are reflective. If you use GI only, and object has zero reflection, all the edges render sharply.

03-22-2018, 12:37 PM
Are you on 2018?

MarcusM
03-22-2018, 01:32 PM
When I reported my problems with normal maps during testing LW 2018 I got this reply from customer support :)

"The diffuse shading model in PBSDF is different from the standard Lambertian in 2015. The shading model in PBSDF is angle dependent, and will have "issues" because of the normal map. When using normal maps, the normal can point away from the viewer, because it is not real geometry, it is a cheat to make it look like there is."

If you are on 2015.3 then it is different story. Be sure mesh is triangulated before render.

GimbalLock
03-23-2018, 03:36 AM
I'm on LW 2015. The normal map issue I can fudge around by clicking double sided, it doesn't seem to really give any render hit.
As for the putty-like displacement, I've done some research and it seems to be because LW doesn't have sub-poly displacement like some other render engines, neither in 2018. This is a bit of a blow, because what I basically wish to do is create models in general and apply real 3d bump maps (displacement) to surfaces regardless of how the mesh is shaped or how low-poly it is. Say, make a basic 6-poly cube, apply a brick wall heightmap and have it render as a complex model with real grooves. All being mesh-independent so I can have such materials as surface presets and apply to any type of mesh. Normal maps alone just doesn't cut it for the complexity in real world surfaces, and modelling all the bricks manually is silly.

What I'm thinking is I might come closer to the desired workflow getting Octane, possibly with the LW plugin, rather than getting 2018. Any Octane plugin users who can confirm this?

GimbalLock
03-23-2018, 12:09 PM
Fiddled with the Octane for Lightwave demo and without watching any tutorials I got the stuff working that I've banged my head against for days in native.

This is my first test with the displacement map and it does exactly what I want. The entire floor is just one poly, no subdivisions.
140843

The way the renderer handles volumes and light in general is just insane. Had a hard time getting my arms down in order to type! And it's easy to use because it uses LW's workflow logics.