Terragen Normal Maps

[Hannes]

Hopefully there will be a statement from the staff. It's tedious work to convert all the normal maps, and in the end it doesn't look really good.

[Dune]

Wouldn't there be a workaround (for the time being) converting the RGB channels into vector displacement (vector bump)?

[sboerner]

How do you mean? Wouldn't that be an actual displacement (as opposed to a bump)?

I've been using ZBrush to create displacement maps, then using those as bump maps in Terragen. This works OK. I don't use third-party models but I understand that they often include only normal maps. Whenever I've tried using normal maps as bump maps, filtering out various channels, the results are usually .

IMHO Terragen's conflation of bump and displacement functionality in the default shader is confusing. I sometimes wish the default shader had separate slots for bump and displacement -- and normals -- like the surface shaders in other applications.

[Dune]

No, that's not what I mean. Actual displacement only works if you use it as mesh displacer or the inadvisable non-Raytraced object rendering (in the render tab), or changing the default render method in the object itself. By default any 'displacement' fed into a default shader or whatever displacement shader (surface shader, PF, displacement shader vector displacement...) is treated as bump in Raytraced objects. By default.
So, a separate slot for displacement wouldn't really add anything unless that would override the earlier mentioned settings. And the mesh would have to be extremely fine to get real displacement by a map that usually does the finer detail.

The thing I was thinking of is treating the different channels as vector displacement, so R would yield a different bump direction than B, or G. But maybe that's too far-fetched (if that's the right expression).

[Hannes]

The thing I was thinking of is treating the different channels as vector displacement, so R would yield a different bump direction than B, or G. But maybe that's too far-fetched (if that's the right expression).

Sounds interesting. It's been a long time, since I've used vector displacement. However a native normal bump workflow would be the most accurate I think, and probably the most convenient way. I have no idea how complicated this would be to incorporate into TG.
If I look at other apps normal map support is quite usual by now. PBR workflow is possible in TG for some time now, which is fantastic, but this essential feature is still missing.

[Dune]

Yes, I agree, normal map readability would be the most efficient way. But it's nice to get the brain working now and again

[Dune]

Here's what I would do. Vector displacement looks better than bump from a displacement shader. I don't know if it really works to bump in different directions, that would need a more thorough test I presume.

[sboerner]

This is turning into a great thread! Great first test. Vector displacement does indeed look much better.

Ulco, Thanks for the explanation but I understand the difference between displacement and bump in TG. I just wasn't being clear. I should have asked whether you were proposing to use high-poly meshes with real displacement. That vector values would be converted to scalar by default makes sense and you are right about there being no need for separate bump/displacement slots.

Poked around a bit and came across this: https://charles.hollemeersch.net/njob/. Looks like it might be useful. Downloaded but haven't tested it yet.

Edit: The download link appears to be broken. No updates since 2016. Oh, well.

[Hannes]

Wow, wow, wow!!!!!
I tested it as well, and I'm blown away! As you can see the image with the converted map (upper) looks worst. Using the normal map for regular displacement seems to be somehow better, but plugging the normal map into the vector displacement shader looks fantastic. Look at the bolts for example!
Thanks a lot, Ulco!! It's a few steps more than just loading the normal map into the shader, but it's worth it!!

[WAS]

The vector map version is pinching edges though, and that looks really bad, as it is actual displacement. Looking at the hexagon pattern, perhaps your displacement is actually inverted.

[Hannes]

Hard to tell what was intended. I don't think, it's inverted, because the rest looks correct. However, of course it depends on the quality of the normal maps. All in all Ulco's method looks best I'd say.

[Dune]

I'd say VDISP looks really better, despite some small faults. Maybe smoothing a normal map in PS just a tiny tad may work even better (for the time being).

[sboerner]

I've been testing Ulco's setup with maps generated from my models in ZBrush. With the displacement map attached to the displacement slot, and the normal map attached with a vector displacement node, both work entirely as expected. The disp map handles the heavy lifting, with the normal map adding detail and accents.

Just brilliant. Kudos to Ulco. Why has no one ever tried this before?

[Doug]

Why is Displacement shader 01 output not hooked to anything?

[Dune]

Because this was a test, so I could switch between hooking the displacement shader on, or the vector displacement shader. So in the shown situation it could also have been deleted, as it has no use.