When I use a bumpmap in the default shader, there's no problem, but as soon as I add very shallow extra bump, the polys are hard edged. It's only a fraction of a millimeter. The model is quite highpoly, and normals are calculated on a smooth basis. Even when I negatively offset by half the bump height, it doesn't work properly. So I wonder what can be done about this (by me... or in TG).
I don't know what the cause is, but it seems to me that in the image without hard polys those edges are also visible (to a lesser extent), and that the bump there as a whole is fuzzier. Maybe it's because the bumps are multiplied.
Indeed! The less fine bump makes the edges a bit less obvious, but if you look close, the edges are there.
Yes, you may be right, but still; without any bump it's smooth.
The displ amplitude is negative in your example, which leads me to the following
question: have you tried a positve value and an inverted bump fractal?
I don't think I did, but displacement in the displacement tab (and not by clamped color) is positive and negative anyway, so some parts of the perlin will be above 'skinlevel', others parts under it.
From the latest changelog:
Quote from: Matt on October 23, 2019, 01:56:55 PMBuild 4.4.40 (Frontier Build)
Changed how bump mapping affects the shading position. Bump mapping doesn't affect shading position anymore because this was causing incorrect rendering of transparency. However, this also means we can't use the positive bump trick to avoid sharp terminators on low-poly geometry. We'll need another solution for this in future builds.
I am facing similar issues, though unfortunately you have the worst-case scenario :/
Cool model btw. Did you make it? How do you find working with geometry for the hairs? It may not be as heavy as one might think!
Matt has mentioned in the past high poly objects don't work well with displacement, and to use low poly objects for TG to utilize those larger faces for displacement. I assume too small a face and TG can't calculate correctly or the displacement is being cut off, exaggerating seams.
Ah, that's not so good, I have to rely on subtle bumpmapping. If that is really what Matt means. I didn't use any glass shader, btw, just the default, etc.
I's a ZBrush transformed DAZ Genesis model; just divided the head a few times extra and added some wrinkles.
It's not displacement, WAS, it's bump, as the object is raytraced. But maybe you do mean that.
Quote from: Dune on October 27, 2019, 12:58:05 PMAh, that's not so good, I have to rely on subtle bumpmapping. If that is really what Matt means. I didn't use any glass shader, btw, just the default, etc.
I's a ZBrush transformed DAZ Genesis model; just divided the head a few times extra and added some wrinkles.
It's not displacement, WAS, it's bump, as the object is raytraced. But maybe you do mean that.
TG supports Normal Maps now? I don't know how it would without it being faked as that's what it's inherent goal is. I assumed we meant displacement. I'd imagine bump would inherently have issues with any realistic rendering honestly.
Normal/Bump isn't actually displacement it's faked lighting if there was displacement, so why I may be confused.
Quote from: WAS on October 27, 2019, 12:42:35 PMMatt has mentioned in the past high poly objects don't work well with displacement, and to use low poly objects for TG to utilize those larger faces for displacement. I assume too small a face and TG can't calculate correctly or the displacement is being cut off, exaggerating seams.
For objects with "Force displacement" enabled, that's true. But for ray traced objects there is no true displacement (yet), it's only bump, so this advice doesn't apply.
Regardless of whether you have bump or not, curved surfaces need lots of polygons to render smoothly along the lighting terminator. But bump mapping can make the problem more apparent as it can increase the brightness of surfaces close to the terminator. Subdividing the object before importing into Terragen is the best solution to this problem.
Quote from: Matt on October 27, 2019, 05:39:56 PMQuote from: WAS on October 27, 2019, 12:42:35 PMMatt has mentioned in the past high poly objects don't work well with displacement, and to use low poly objects for TG to utilize those larger faces for displacement. I assume too small a face and TG can't calculate correctly or the displacement is being cut off, exaggerating seams.
For objects with "Force displacement" enabled, that's true. But for ray traced objects there is no true displacement (yet), it's only bump, so this advice doesn't apply.
Oh strange. I was never using force displacement on the shader balls or orb object for that to even be advise then in my instances. And subdividing is what I was doing. Speaking of that does force displacement still only work on individual objects or can it be used on instances in a pop?
I think there might be something else going on here. Here is a little test I did, using the same object and same texture files, both in Terragen and Maya.
terragen.jpgarnold.jpg
Even if I push the bump in Arnold to the extremes, I never noticed anything wrong. But even with the slightess amount of bump in Terragen, the terminator is faceted.
I actually even shows on the mesh itself with a default shader:
tgout-001 00m21s v4.4.40.1.jpg
:-\
...Doing a bit more digging on that, I might be onto something. It looks like the "Use smooth normals" checkbox in the object's tab is not affecting the shadows.
This illustrates the problem:
smooth_shadows.jpghard_shadows.jpghard_noShadows.jpgsmooth_noShadows.jpg
Different renders have different ways of handling this. There isn't one "correct" way to do it, but there are ways, and I plan to implement one of these soon.
I did a bit of research on the subject and I realized I wasn't aware of how common this problem is in rendering. I found a paper explaining the reason and implementation for a fix and it all makes sense now.
For the curious out here: http://www.aconty.com/pdf/bump-terminator-nvidia2019.pdf (http://www.aconty.com/pdf/bump-terminator-nvidia2019.pdf)
Yeah, that's one of the papers I have in my notes. The other one is this: https://www.yiningkarlli.com/projects/shadowterminator.html
I plan to try out both of these. But I think the faceted appearance is a separate issue.
Interesting find, KyL, thanks for that! And thanks for diving into this, Matt. I hope you can resolve the issue (and not only in PT). As said the model was quite dense in polys, even more so than my usual models, and I have to rely on bumping them.
Why do we keep saying bump mapping? Terragen has no Bump Mapping / Normal Mapping. It's only displacement. Real dispalcement. Bump / Normals is simulating displacement through normal shadows / and normal highlights.
Quote from: WAS on October 28, 2019, 12:45:27 PMWhy do we keep saying bump mapping? Terragen has no Bump Mapping / Normal Mapping. It's only displacement. Real dispalcement. Bump / Normals is simulating displacement through normal shadows / and normal highlights.
Uh, not true...TG, on imported objects, only Bump Maps not displaces Jordan.
Quote from: bobbystahr on October 28, 2019, 02:28:34 PMQuote from: WAS on October 28, 2019, 12:45:27 PMWhy do we keep saying bump mapping? Terragen has no Bump Mapping / Normal Mapping. It's only displacement. Real dispalcement. Bump / Normals is simulating displacement through normal shadows / and normal highlights.
Uh, not true...TG, on imported objects, only Bump Maps not displaces Jordan.
Bump Mapping / Normal Mapping is a way to
simulate displacement via lighting. It doesn't modify the shape in any way. There is no displacement.
This is clearly displacement, and just that.
With that said, Terragen has never been able to read Normal Maps to even achieve this, Bobby.
This is why I showed the technique to convert bump maps
to displacement via software that does read the normal mapping.
No, Jordan. By default TG uses bump for imported objects (although you plug a shader into the "displacement" slot). If you want real displacement on objects, you have to set the render method to "force displacement".
But maybe you mean the displacement on the terrain?
Ugly example. The first image uses bump mapping, the second one displacement. Absolutely the same settings, except the render method.
Ugh. Come on, Hannes...
You can clearly see the geometry is altered because it's not actually normal mapping / bump mapping...
This has been a looooooong asked for feature of Terragen and hasn't been implemented as far as I know. Providing TG a normal map will not give you accurate bump results, it's not RGB channels. They need to be converted from 360 lighting.
https://planetside.co.uk/forums/index.php/topic,17559.msg170385.html#msg170385
Again, bump / normal mapping is trick of light. It's very fake. Which may be why Matt hasn't implemented it.
And a Bump Map is a Normal Map, so if there is no normal mapping, there is no bump mapping. There is displacement. And if you're trying to use a Normal for displacement, it should inherently be converted to Depth / Displacement Mapping.
Which brings us back to
Quote from: WASWhy do we keep saying bump mapping?
Here's an example of using a normal/bump as displacement vs using the same normal converted to displacement. We're using Fabric31 from cc0textures: https://cc0textures.com/view.php?tex=Fabric31
I probably should have increased size but I wanted you to see what happens with a normal map repeating and trying to be read by Terragen with ray tracing.
Not only is the result simply wrong, we get artifacting because channels read on the seams of the normal are not read correctly.
Not only this, but the normal map renders twice as long as the converted map which finishes rendering before the first, normal mapped one.
Another example with the texture zoomed... which one is jagged, and trying to interpret the bump from mixed channeled colours, and which is smooth and carpety....
Jordan,
From the Wikipedia page on bump mapping: "There are two primary methods to perform bump mapping. The first uses a height map for simulating the surface displacement yielding the modified normal. This is the method invented by Blinn[2] and is usually what is referred to as bump mapping unless specified."
Terragen uses the kind of bump mapping described above in situations where it can't use displacement. Hannes was demonstrating that the left sphere uses bump mapping by showing that it is different from the right sphere which uses displacement. He did this to show that Terragen does bump mapping.
Also from the Wikipedia page: "The other method is to specify a normal map which contains the modified normal for each point on the surface directly. Since the normal is specified directly instead of derived from a height map this method usually leads to more predictable results. This makes it easier for artists to work with, making it the most common method of bump mapping today.[3]"
This second method (normal mapping) is not supported by Terragen 4.4 but will be in future.
Both methods very clearly describe the same end results, not effecting geometry, by simulating the lighting via normals. Both results yield the same non-edited geometry (the sphere is still smooth as well as the casted shadow)
In TG it's creating displacement, which is seen along the object, and in the shadows.
Which results in weird looking objects it seems, especially with light interaction. At which point does this become displacement, and not simulated bumpiness of light? The height map method says it's used to get the normals, for the lighting. Not using it for actual physical displacement.
You can clearly see in my examples, one has a hard time with TG's lighitng, and one is smooth more correct. I imagine because instead of simulating lighting, it's just displacement with actual object lighting. The other is proper displacement for TG to handle (smooth one). It's a ray traced TGO sphere.
Quote from: WAS on October 29, 2019, 05:00:31 PMBoth methods very clearly describe the same end results, not effecting geometry, by simulating the lighting via normals. Both results yield the same non-edited geometry (the sphere is still smooth as well as the casted shadow)
Yes.
QuoteIn TG it's creating displacement, which is seen along the object, and in the shadows.
If you see the silhouette of the object change, this is displacement. In Terragen that will happen with displaceable objects. That was Hannes's sphere on the
right. But Hannes's sphere on the
left was just bump mapping.
QuoteWhich results in weird looking objects it seems, especially with light interaction.
Yeah, that is the main problem with bump mapping.
QuoteAt which point does this become displacement, and not simulated bumpiness of light? The height map method says it's used to get the normals, for the lighting. Not using it for actual physical displacement.
Correct, bump mapping just changes the normals for lighting. This is what Hannes's left sphere shows.
Quote from: Matt on October 29, 2019, 05:18:49 PMQuote from: WAS on October 29, 2019, 05:00:31 PMBoth methods very clearly describe the same end results, not effecting geometry, by simulating the lighting via normals. Both results yield the same non-edited geometry (the sphere is still smooth as well as the casted shadow)
Yes.
Quote from: undefinedIn TG it's creating displacement, which is seen along the object, and in the shadows.
If you see the silhouette of the object change, this is displacement. In Terragen that will happen with displaceable objects. That was Hannes's sphere on the right. But Hannes's sphere on the left was just bump mapping.
Quote from: undefinedWhich results in weird looking objects it seems, especially with light interaction.
Yeah, that is the main problem with bump mapping.
Quote from: undefinedAt which point does this become displacement, and not simulated bumpiness of light? The height map method says it's used to get the normals, for the lighting. Not using it for actual physical displacement.
Correct, bump mapping just changes the normals for lighting. This is what Hannes's left sphere shows.
Hannes's sphere on the left very clearly has displacement... you can see in on the sides of the sphere and shadow, though. So I don't understand. This isn't "Bump" mapping, which is simulating bumpiness of lighting only.
Even in my
ray traced example, it's very clearly creating displacement, very weirdly, I might add, over the same normal map simply converted to depth.
The way it is now, seems like it's own thing, trying to create displacement from a bump map, rather than lighting. For example, some materials of objects that use displacement and bump. You'd get strange results with the added displacement playing with light on top of the simulating lighting effect it should be doing, as the displacement is suppose to be the actual geometry/mesh adjustment, not the bump.
---
When I zoom into the Normal Map version, it creates near back depression shadows where it should be fairly subtle, over the actual diffuse of the object (Fabric31). Is this because it's simulating lighting
on top of creating displacement? Cause it looks bad.
Re. Screenshot_19.png:
Shadow on the ground: If the sphere is ray traced, any roughness you see in the shadow on the ground is caused by aliasing, not displacement, because there is no displacement on ray traced objects in Terragen 4.4. If we want to displace the shadow at all we need to use a displaceable object or the use the mesh displacement feature (deformation) on a high-poly model.
Silhouette: If the sphere is ray traced, any roughness you see on the silhouette is caused by aliasing, not displacement, because there is no displacement on ray traced objects in Terragen 4.4. However, if the render method is set to "force displacement" then it will displace the surface and the silhouette, but not the shadow.
Re. HardBlackShadowArtifacts.png:
This depends on the version of Terragen because its behaviour has changed a few times over the years. In some Terragen builds there may be some shadows appearing in the dips of the bump map on the surface of the object itself, and in the raises it can adjust the position of the terminator. This was an attempt to try to make it slightly better than traditional bump mapping. It was removed in v4.0 but added again in v4.1 because it can be used to work around certain terminator faceting issues. But it leads to other problems (including incorrect transparency) so it's been disabled again in build 4.4.40 frontier.
Again. Displacement is very clear, his, and mine... That's not just AA Matt. Ray tracing objects is applying displacement...
TG Frontier 4.4.40
And the shadow effect is too hard and fake and entirely changes material I'd say. A checkbox may be in order instead of arbitrarily adding/removing features at whims of complaints or what not. Seems more logical and easier to manage in the development path.
Sigh
Quote from: WAS on October 30, 2019, 03:51:04 AMAgain. Displacement is very clear, his, and mine... That's not just AA Matt. Ray tracing objects is applying displacement...
If you're talking about the cloth render then I will look into what's causing the black spots if you send us a TGD where this happens. But if you are talking about Hannes's sphere (the one on the left) then you are entitled to your opinion on whether it's doing displacement but I seem to have run out of ways to help you with that one.
Although I initally didn't want to discuss this anymore, here is one last try.
Once again I used exactly the same settings for both images except the render method. The first one shows BUMP (Render method "Default"), the second one DISPLACEMENT (Render method "Force Displacement"). As you can see in the first image there's a perfectly round silhouette of the imported sphere, since it's only faking displacement. The second image shows a really displaced sphere.
Thanks Hannes.