Does terragen read Normal Maps in Y+ or Y-?
Terragen 4.5 doesn't read normal maps. That's on the 2021 roadmap.
So only bump? But similarly, bump can be read positive or negative? I've been noticing a lot of directx exported stuff have inverted normal maps, and weirdly vertically flipped textures which don't align with object UV in TG (gotta flip horizontally) so just trying to figure out tbe quirks with these unreal/unity assets.
Also most PBR generators are outputting normal maps, not bump maps and they appear to work. They aren't read properly?
TG probably reads the hues as greyscale and makes higher values into bump.
Quote from: Matt on February 23, 2021, 01:37:26 AMTerragen 4.5 doesn't read normal maps. That's on the 2021 roadmap.
Can't wait!!!!! :D
QuoteTerragen 4.5 doesn't read normal maps. That's on the 2021 roadmap.
Terrific news!
Quote from: Dune on February 24, 2021, 02:12:59 AMTG probably reads the hues as greyscale and makes higher values into bump.
Must be. I don't even have software that outputs bumps. Everything I use is Normal Maps. Honestly haven't seen a bump fo years except few days ago ripping some Unreal assets. Heck even CrazyBump doesn't even export bump maps, and exports normal maps. Good thing Materialize reads Normal as 3D and then can create a heightmap from it. Kinda like it's AO feature you can see it firing shadows from 360 degrees to "formulate" a heightmap.
I use Pixplant, but to be honest, a bumpmap is some kind of derivative of the color map, and not really representing real bumps. Just recoloring and fading the whites and blacks. Some areas clearly being higher than others but having a darker hue, will end up having a low bump. Like in birch bark.
Handwork is often needed.
Okay, but is compatibility planned in the future? I think I already have got the basics of Terragen covered, and now, I'm thinking of how it could become even better....
Sorry to dig this thread up again, but are there any news on when we can expect support for normal maps? I have to rebuild my library and most of my assets are automatically loaded with normal maps so it's very time consuming to manually go in and change all of them to bump map.
- Terje
Oh yes!!!! Normal map support would be fantastic!! Converting them into bump maps is nothing but a very inaccurate compromise. If TG would read normal maps correctly it would be a very big improvement in displaying models.
Actually I think it's a must have nowadays, if TG tries to compete with other apps.
I agree, normal map inclusion would be great!
It's almost 2023 now, hopefully that can sneak in.
Patiently waiting here as well. It would make the ZBrush -> Terragen pipeline oh so much better.
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.
Wouldn't there be a workaround (for the time being) converting the RGB channels into vector displacement (vector bump)?
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 :P .
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.
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).
Quote from: Dune on December 23, 2022, 03:34:40 AMThe 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. :(
Yes, I agree, normal map readability would be the most efficient way. But it's nice to get the brain working now and again ;D
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.
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/ (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.
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!!
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.
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.
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).
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?
Why is Displacement shader 01 output not hooked to anything?
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.
So now that we have a solution for this, wouldn't it be a good idea for the creators to make an extra slot (with an inbuilt vector displacement shader) in the default shader or the surface layer? Just for convenience and maybe for beginners who want to know, where to put the normal map.
I guess so, but Matt would know if this vdisping really works like it should, and not only looks as if it works ;)
Quote from: Hannes on January 01, 2023, 05:49:32 AMSo now that we have a solution for this, wouldn't it be a good idea for the creators to make an extra slot (with an inbuilt vector displacement shader) in the default shader or the surface layer? Just for convenience and maybe for beginners who want to know, where to put the normal map.
I'm not against this, but if we'll get real support for normal maps, I promise I'll give something back to this community that is using normal maps ;)
Quote from: Hannes on December 23, 2022, 06:01:42 PMHard 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.
It's pretty easy to tell, though, all this roughness breaking lighting is the mesh breaking because it's pinching.
Screenshot_6.png
If things look like they are super sharpened and creating had grain with bright lighting and super dark lighting, it's safe to assume it's not working correctly.
I still find the converting normal to a grayscale displacement, and using that as VDISP is 100x better. Pay attention to grout, and mesh angles
VDISP Normal Map - Notice all the rough noise, creating bad lighting: that's mesh errors from bad disp
PavingStones_VDisp_Normal.jpg
Converted VDISP Normal Map - NO rough noise and bad lighting (besides the base displacement issues with the mossy areas)
PavingStones_Converted_Normal_as_VDISP.jpg
No, Terragen still needs proper support, and there is no good alternative that doesn't require some manual work if you care about the fidelity of your work.
Not only is converted map less noisy and choppy, but it produces stronger amplitude *without* those effects. All while still being vdisp, allowing your to target each direction independently.One of the biggest issues with just using a normal map into vdisp is it breaks the lighting model heavily. For example, here the Fresnel is already 0.01, with vdisp normal map, it starts creating hard lighting points where the noise is, creating almost a specular spot like look that we do for sand. Additionally, angles of the mesh aren't rounded, and retain their angles.
Also if you take any average normal map, and convert it to greyscale, you get all the overlaying which should be different axis, unified into similar gray, so you get a simulated banding effects and around small details, noise from pixels representing different angles in different tones of grey, not properly interpreted for grayscale.
Using something like Materialize which will create 3D bump and fire off shadows from all angles is going to be more accurate then just using a normal map, inherently. Granted, you do have to spend some time understanding displacement maps and how a micro displacement like normal map would need to look (for example no heavy whites for super tall peaks)
PS, I'd have done larger resolution, but my key doesn't appear to be in my email anymore (probably deleted it for security being in my main email). So only key is on my other computer I don't have access to currently.
It's hard to see the actual differences in the examples, though I do see differences. But if you would have shown me the first only, I would have been satisfied with the looks. Perhaps a more defined (no-DOF) example would be more 'definitive' to rule out this method. Or proof its merit.
So what if you slighly blur the normal map (0,5 or so) for the time being? Perhaps that would mix the overlaps so it wouldn't breakup the lighting in those edges.
I figured a "final scene" would actually be best, so you can see how it ruins a artistic inspection, actually.
Here is some zooms without DOF.
Notice the classic lean because it's not interpreted right to begin with. Inversion doesn't help.
Additionally, I'd say converting normal maps has a lot more control to actually match any reference you may have, which leads to better "detail". Furthermore, because it's not doing stuff erroneously on X/Z, you can probably default low resolution limitations of maps by adding some fractal warping/noise in the displacement without extraneous tearing.
Edit, I did notice VDisp mode without Y displacement does look a bit better though, I think the added Y displacement on top of base displacement map messes up the look. I didn't do that in this example.
These all are no real substitute for proper normal maps in appearance or workflow.
PS If you also aren't computing your object after it's initial displacement map, with a low scale compute normal, you won't really be benefiting from normal maps through displacement anyway, even if they did work (because the displacement map through default shader isn't computed), as it will just lean entire displacement and not really apply anything to X/Z as far as detail, only Y + lean shift offset.
Interesting. Still, I find the differences quite small. Hard to fathom how it would really work. You say you need a compute normal in the object. I thought so too at first, but wouldn't it just use the normals provided with the object?
I did a little experiment on a polysphere (not generating UV's seems necessary). Found a comparison normal/bump image on the web. I don't really know how to interpret the findings, but it seems vdisping doesn't really do any good here.
And here are some renders. Again, vdisp doesn't really look good after all. But this may not be the right way to check.
By the way, this is showing the backside of the polysphere, so normal map is on left.
Quote from: Dune on January 02, 2023, 03:54:22 AMI thought so too at first, but wouldn't it just use the normals provided with the object?
Yeah, from the base mesh, not with the displacement map you have added in the default shader, which would be necessary to not destroy the mesh oddly, as you have two displacements, occupying the same general space, using the same normals, but applying on top of each other in chain.
Since VDISP requires computed normals to apply to displacement that isn't computed, you'd need it. It's no different then needing one for lateral displacement, which this would need to apply to your added displacement map at all angles which is altering the mesh (as it isn't fake bump/normal mapping)
If you use a displacement shader (as bump) and a vdisp. If it's only a normal map used for bumpmapping, it would have enough from the normals in the object, I'd say.
Edit: 2 more tests.
This is really a very interesting thread. If only one of the staff would chime in to tell us their opinions and future plans.
This is a great thread, keep it going.
I learn a lot out here.
One thing i do as an Artist is to mix PBR's.
I use the displacement from one PBR in another PBR.
I know they don't match up, but i can get something i like that way sometimes.
Well, I just had to see this for myself. Here is a comparison using an imported uv-mapped cylinder. The maps are nice quality. Source: https://www.textures.com/download/PBR0071/133106.
There is no comparison between the vdisp and a good-quality height map. Using the height map with a low-amplitude vdisp on top adds a little more detail, but it's not really worth the trouble.
Quote from: Dune on January 02, 2023, 04:18:54 AMIf you use a displacement shader (as bump) and a vdisp. If it's only a normal map used for bumpmapping, it would have enough from the normals in the object, I'd say.
Edit: 2 more tests.
If you aren't using a compute normal
after regular displacement (displacement function/image of default shader), that isn't really possible programmatically with what's going on. As you've added displacement, and are adding
more displacement based on the underlying mesh UV/Normals. So you got two displacements sharing the same space, trying to do two different displacements. But the second is applied over the original, confusing it's space.
Quote from: sboerner on January 02, 2023, 01:13:44 PMWell, I just had to see this for myself. Here is a comparison using an imported uv-mapped cylinder. The maps are nice quality. Source: https://www.textures.com/download/PBR0071/133106.
There is no comparison between the vdisp and a good-quality height map. Using the height map with a low-amplitude vdisp on top adds a little more detail, but it's not really worth the trouble.
Now actually convert that VDISP to regular displacement using a good converter, create a edge map, and overlay it at 10%, and you have a muuuch higher quality displacement then vdisp for microdisp. Additionally, because it isn't pushing on X/Z pinching the mesh, you could even add fractal warping or w/e to give it more fidelity than a image map would ever allow without being absolutely ridiculously huge.
Try using a compute normal with 0.001 scale, or 0.01 scale and very light VDISP or regular disp. You'll get much better X/Z displacement for a VDISP inherently anyway, even before trying to simulate normal mapping.
Overall I think the main issue is Terragen's coordinate system. It's non-standard euler with rest of DCC apps, like DX and OpenGL Normal output. So we would need to figure out how to rearrange R, G, B inputs, and flip/rotate according to TGs Euler.
If you inspect your normal maps by channel, you will notice B is what we would use for Y or G. At least with DirectX normal maps.
This would also likely mean the other maps would probably end up needing rotating (maybe also flipped) on Y with resulting final of flipped up normal map. Come to think of it looking at Ulcos ball example it seems clear the pinching type effect is cause that displacement should be applying in the opposite direction. So it's giving it a tin foil type look.
@Matt I honestly think TG needs to change it's Euler coordinate system to align with major DCC, so that it's more appealing, especially with workflows, and future exporting/importing systems. Especially with Python API released. I feel it'd make things a lot easier for developers and teams to utilize TG for what they need if they weren't worrying about weird compatibilities with maps and importing stuff via scripting. I don't think such a change would impact end-users, or even be noticeable, besides maybe allowing more standard approaches to things going forward. That probably entails some major overhaul though, huh?
There is no "standard" coordinate system:
(https://miro.medium.com/max/4800/1*IWv0KVHPnf_xxL05Vh7oVQ.webp)
Can you tell which one Terragen 4 uses?
We'll implement normal maps this year. Object rendering was put on the backburner while we prioritized Terragen Sky Early Access, but normal mapping was (and still is) near the top of the Terragen 4 to-do list.
Quote from: Matt on January 02, 2023, 08:11:25 PMWe'll implement normal maps this year. Object rendering was put on the backburner while we prioritized Terragen Sky Early Access, but normal mapping was (and still is) near the top of the Terragen 4 to-do list.
Great! That's good to hear. :)
Quote from: Matt on January 02, 2023, 08:11:25 PMWe'll implement normal maps this year. Object rendering was put on the backburner while we prioritized Terragen Sky Early Access, but normal mapping was (and still is) near the top of the Terragen 4 to-do list.
This makes me really happy! ;D
In the meantime, I'll start creating some awesome photogrammetry models for everybody here.
- Terje
Great! That finishes the experimentation...
Great news! Looking forward to it!
Quote from: Matt on January 02, 2023, 08:05:50 PMThere is no "standard" coordinate system:
(https://miro.medium.com/max/4800/1*IWv0KVHPnf_xxL05Vh7oVQ.webp)
Can you tell which one Terragen 4 uses?
Yeah, sorta right, except all these respect each other, and handle each others Euler systems with ease. It's like when I was doing the FBX importer. No one could help, and was pointing out that Terragen is using a weird system. On Autodesk, Three.JS, and on Stack Overflow. Everyone had issues with TGs Euler and gave up. Lol So many unanswered questions I had to get that system working.
I think I even asked you, and you couldn't explain how to flip the Blender standard Euler to TG. And using TGs Euler selected in Blender, isn't respected in TG like it's not actually that Euler.