Solved!:Strange black lines on forehead - location varies with pose/expression

paulawp (marahzen)

I'm working on a new character and ran across something I've never seen before. It made itself obvious when I decided to test a new animation on this work-in-progress figure which I happened to have open, and when I rendered it, it had weird black lines on her forehead. The character isn't done, but I had already rendered it several times while testing tweaks and changes and hadn't noticed anything like that. I checked the face mat file - don't see anything obvious there. I then reloaded the character (from a save before I was testing the animation) and rendered it with the same lighting options. With a neutral expression, I now see the marks, but only on the outer edge of the forehead. FWIW, the mat files were created by Face Transfer, but I don't see them on the file, and I haven't seen this yet with other characters created with the same process.

Anyone ever seen anything like this?

I've attached the render with the expression, the render with the neutral expression to compare, and a screenshot of the relevant part of the face mat file. 

hookflash

Try changing Render Settings -> Optimization -> Instancing Optimization from "Auto" (the default) to "Speed"

barbult

There are dozens of forum threads about this problem. You are seeing a geometry collision between the hair skullcap and the character's head. This can often be resolved by applying a morph to the hair to move the forehead forward, but not all hair products include such a morph. You can try the Mesh Grabber product to move the hair geometry if it doesn't have a built in morph. You can try scaling the hair a little larger in the Parameters pane. You can also try hiding the hair cap surface in the Surfaces pane.

paulawp (marahzen)

Thanks barbult, that was the answer. It totally did not occur to me that hair could be the cause of a problem that presented itself variously with different facial expressions. I do software support in real life and had tried accounting for other variables - I never thought to turn off the hair!

This is the 2021-12 Hair and it has several forehead morphs; twiddling with those got rid of this issue. Thanks again for the quick answer to this problem.

margrave

The correct solution is to change your Instance Optimization setting first, and on the very slim chance that doesn't work apply a smoothing modifer. No need to mess around with morphs or Mesh Grabber.

barbult

I don't think there is one "correct" solution for all scenarios. Different techniques work for different products in different scene scenarios. Sometimes Instance Optimization needs to be set to memory rather than speed, if there are a lot of instances in the scene (UltraScenery, for example). Sometimes smoothing does bad things to some hair products that were not designed for it.

margrave

barbult said:

I don't think there is one "correct" solution for all scenarios. Different techniques work for different products in different scene scenarios. Sometimes Instance Optimization needs to be set to memory rather than speed, if there are a lot of instances in the scene (UltraScenery, for example). Sometimes smoothing does bad things to some hair products that were not designed for it.

Even if you say there is no "correct solution", there is a correct hierarchy of solutions which involves using the tools that were designed to fix the problem. Step #1 is to start with setting Instance Optimization to Memory, which is always the best option since it was designed to fix exactly what the OP described. On the slim chance that doesn't fix it, then you use the tool that was specifically designed to make meshes conform to each other, a smoothing modifier. If that still doesn't fix it or doesn't give good results, then you try the other solutions, but I've never had to since--provided the smoothing modifier is low enough--I've never seen these "bad things" you mentioned. Hypothetically, using Mesh Grabber will fix the problem, but why jump straight to deforming your mesh when the Z-fighting can be fixed by other, better methods?

meganappstate

margrave said:

barbult said:

I don't think there is one "correct" solution for all scenarios. Different techniques work for different products in different scene scenarios. Sometimes Instance Optimization needs to be set to memory rather than speed, if there are a lot of instances in the scene (UltraScenery, for example). Sometimes smoothing does bad things to some hair products that were not designed for it.

Even if you say there is no "correct solution", there is a correct hierarchy of solutions which involves using the tools that were designed to fix the problem. Step #1 is to start with setting Instance Optimization to Memory, which is always the best option since it was designed to fix exactly what the OP described. On the slim chance that doesn't fix it, then you use the tool that was specifically designed to make meshes conform to each other, a smoothing modifier. If that still doesn't fix it or doesn't give good results, then you try the other solutions, but I've never had to since--provided the smoothing modifier is low enough--I've never seen these "bad things" you mentioned. Hypothetically, using Mesh Grabber will fix the problem, but why jump straight to deforming your mesh when the Z-fighting can be fixed by other, better methods?

Horsefeathers.

Maybe you can afford to waste time chasing "fixes" that may or may not work, but after 3+ years and hundreds of failed attempts to correct various geometry collisions following your supposedly "correct hierarchy" and finding that inever--and I do mean "NEVER"--fixed the geometry collision with any OOT hair, and discovering along the way that the ONLY100% guaranteed-to-work, one-and-done, solution--regardless of the asset--is to tweak the mesh from the get-go, it an asset doesn't collide correctly out of the box I'm not going to waste the time or put up with the agfravation of going through the "correct hierarchy" when I can tweak the mesh and fix the problem in under 2 minutes.

margrave

meganappstate said:

Horsefeathers.

Maybe you can afford to waste time chasing "fixes" that may or may not work, but after 3+ years and hundreds of failed attempts to correct various geometry collisions following your supposedly "correct hierarchy" and finding that inever--and I do mean "NEVER"--fixed the geometry collision with any OOT hair, and discovering along the way that the ONLY100% guaranteed-to-work, one-and-done, solution--regardless of the asset--is to tweak the mesh from the get-go, it an asset doesn't collide correctly out of the box I'm not going to waste the time or put up with the agfravation of going through the "correct hierarchy" when I can tweak the mesh and fix the problem in under 2 minutes.

This isn't a matter of debate. It's what the Iray documentation says to do:

When instancing mode is set to “on”, “auto” or “user”, the scene is automatically shifted in space. This increases the precision and accuracy of rendering computations and reduces precision artifacts that originate from self-intersection.

The OP showed a picture of precision artifacts that originate from self-intersection. The people who made the rendering engine programmed that feature to fix that problem.

Due to Daz's spotty documentation, new users are going to Google their problems and find threads like this, which is why it's important to provide the factually correct answer: first change Instance Optimization to Memory.

meganappstate

margrave said:

meganappstate said:

Horsefeathers.

Maybe you can afford to waste time chasing "fixes" that may or may not work, but after 3+ years and hundreds of failed attempts to correct various geometry collisions following your supposedly "correct hierarchy" and finding that inever--and I do mean "NEVER"--fixed the geometry collision with any OOT hair, and discovering along the way that the ONLY100% guaranteed-to-work, one-and-done, solution--regardless of the asset--is to tweak the mesh from the get-go, it an asset doesn't collide correctly out of the box I'm not going to waste the time or put up with the agfravation of going through the "correct hierarchy" when I can tweak the mesh and fix the problem in under 2 minutes.

This isn't a matter of debate. It's what the Iray documentation says to do:

When instancing mode is set to “on”, “auto” or “user”, the scene is automatically shifted in space. This increases the precision and accuracy of rendering computations and reduces precision artifacts that originate from self-intersection.

The OP showed a picture of precision artifacts that originate from self-intersection. The people who made the rendering engine programmed that feature to fix that problem.

Due to Daz's spotty documentation, new users are going to Google their problems and find threads like this, which is why it's important to provide the factually correct answer: first change Instance Optimization to Memory.

That may well be the method PRESCRIBED in the documentation, but the fact that it's PRESCRIBED doesn't automatically make it "the correct answer," as there may well be other, more efficient, methods.

margrave

meganappstate said:

That may well be the method PRESCRIBED in the documentation, but the fact that it's PRESCRIBED doesn't automatically make it "the correct answer," as there may well be other, more efficient, methods.

To anybody who finds this thread through Google:

The most efficient way to fix the problem is to change your Instance Optimization to Memory. By changing one dropdown box, you fix 99% of self-intersection errors.

Visual proof is here:

https://www.daz3d.com/forums/discussion/537851/fixing-black-forehead-lines-black-eyes-and-red-skin-correctly

Ostadan

When you document a bug, it becomes a feature.

marble

meganappstate said:

margrave said:

barbult said:

I don't think there is one "correct" solution for all scenarios. Different techniques work for different products in different scene scenarios. Sometimes Instance Optimization needs to be set to memory rather than speed, if there are a lot of instances in the scene (UltraScenery, for example). Sometimes smoothing does bad things to some hair products that were not designed for it.

Even if you say there is no "correct solution", there is a correct hierarchy of solutions which involves using the tools that were designed to fix the problem. Step #1 is to start with setting Instance Optimization to Memory, which is always the best option since it was designed to fix exactly what the OP described. On the slim chance that doesn't fix it, then you use the tool that was specifically designed to make meshes conform to each other, a smoothing modifier. If that still doesn't fix it or doesn't give good results, then you try the other solutions, but I've never had to since--provided the smoothing modifier is low enough--I've never seen these "bad things" you mentioned. Hypothetically, using Mesh Grabber will fix the problem, but why jump straight to deforming your mesh when the Z-fighting can be fixed by other, better methods?

Horsefeathers.

Maybe you can afford to waste time chasing "fixes" that may or may not work, but after 3+ years and hundreds of failed attempts to correct various geometry collisions following your supposedly "correct hierarchy" and finding that inever--and I do mean "NEVER"--fixed the geometry collision with any OOT hair, and discovering along the way that the ONLY100% guaranteed-to-work, one-and-done, solution--regardless of the asset--is to tweak the mesh from the get-go, it an asset doesn't collide correctly out of the box I'm not going to waste the time or put up with the agfravation of going through the "correct hierarchy" when I can tweak the mesh and fix the problem in under 2 minutes.

 

I tend to agree based on the fact that all of my OOT black line problems have been fixed very quickly by adjusting the scaling of the skull cap or tweaking the forehead parameters. I can't speak to the IRay documentation and I have no idea what effect changing Instancing Optimization to memory might have other than what's described here. I know that it helps to be set to memory when there are a large number of instances in the scene and I will check out the proposed solution for another problem I have just mentioned in another thread here (objects far from World Centre).