[Genma Saotome]

I think the proper title for this thread is Z Bias question, but not being sure of the correct terminology apologies in advance if I've goofed.

My question: Does specifying don't apply shadows interfere with apply hi shine?

The problem I'm trying to solve can be seen in these images:

From any close distance, the model looks like this:


Pull back a bit and I see this:



What I understand is going on is a merger of parallel faces when viewed at a distance, in this case a highly reflective glass face (using the hi shine shader) which I run behind the whole wall (in an attempt to minimize the poly count) and the foreground face of the wall.

I'm assuming there isn't any way to control what's going on here with something as simple as setting a flag somewhere in the mesh file.

I'm considering using LOD's and multiple planes of glass with those closest to the wall having the shortest LOD value and another plane placed further inside the building. I think the short LOD will make the first plae of glass disappear before faces are merged and the second will be far enough back to avoid the issue. That should work, right?

In addition I feel its also necessary to turn off shadow processing on these interior surfaces. Since I also want to apply night texture processing on the glass -- only the glass -- I figure my usual technique of moving the glass into its own model and then assigning its Position() and QDirection() values to match the building shell will be used.

Which leaves me with a simple model set for no shadow processing with a hi shine shader. Will that solve this problem?

[captain_bazza]

Make sure there is a gap between the building part and the glass part. Gap distance is trial and error.

Cheers Bazza.

[Genma Saotome]

I use a gap already, anywhere from 2-3cm to 12. The larger gap works from afar but not as well close up, which is why I'm considering multiple view blocks with unique LOD values.

Minimizing how many screen pixels take or give shadows does, cumulatively across the entire scene, make for slight a performance improvement.

[superheatedsteam]

The term is “Z-fighting or stiching”. I found the Wikipedia link sums explains it quite well https://en.wikipedia...wiki/Z-fighting and https://learnopengl....L/Depth-testing goes into more detail.

In fact your post made me look back at some of my models that use this technique and see they also suffer from it when I looked closely. As the areas involved are smaller and viewed at a greater distance the effect is less pronounced to the point that I either didn't notice or just accepted it, I don't recall. I have also observed that Shape File Viewer is more sensitive to displaying Z-fighting than both the MSTS and OR 3D renders. This for me is a good thing as SFV highlights these areas to the model creator for closer examination.

Your idea of using multiple LOD's with the greater offset of the windows for long distance and closer offset for shorter distance sounds like a good one.

Though I doubt it will make any difference, you could experiment with making changes in the viewing distance in OR to see how that impacts. There is also a vol_sphere parameter in the .S file that can impact on drawing. Again I doubt it will have any impact but just throwing it out there.

Cheers,

Marek.

[Jovet]

"Z-fighting" is a specific instance when two meshes are coplanar. For example, in MSTS, if you overlap two Transfers in the Route Editor, they will "fight" each other, with random results every frame, because they're trying to be drawn in the exact same position.

In this case, it's more about draw order. You want the window pane mesh drawn before the outer surface is drawn. I'm not sure there's an explicit way to control that short of manually editing the .s file. If it were me, I'd just be increasing that gap.

[Genma Saotome]

Jovet, on 20 March 2018 - 02:06 PM, said:

In this case, it's more about draw order. You want the window pane mesh drawn before the outer surface is drawn. I'm not sure there's an explicit way to control that short of manually editing the .s file. If it were me, I'd just be increasing that gap.

I had not considered that possibility. If that's the case why then does the problem appear at a specific distance and not randomly at all view distances?

What in the .s file controls draw order? I've seen the term mentioned WRT multiple semi-transparent alpha faces, such as looking thru front and side cab windows to see both the partially obscured tree in the distance and the crew member in the foreground but was led to understand you get that in $$ tools like 3dmax only.

[Jovet]

Genma Saotome, on 20 March 2018 - 03:43 PM, said:

If that's the case why then does the problem appear at a specific distance and not randomly at all view distances?

Occlusion seems to work differently in every rending engine. A 1mm "gap" could be sufficient in one rendering engine (e.g. MSTS) and be wholly inadequate in something else (e.g. Shape Viewer). It's probably something silly like rounding errors. I am not technically in the know enough to really answer this question properly.

Genma Saotome, on 20 March 2018 - 03:43 PM, said:

What in the .s file controls draw order?

I can't say for absolute certain but I suspect that mesh earlier in the file is drawn first. But the Matrix list matters too. When setting up a LOD part hierarchy, you can control which parts "follow" other parts, and controlling this to your advantage has solved some alpha blending issues for me before.

[Hamza97]

As a workaround, try moving the glass plane backward on subsequent lods so that when the lod kick in the glass plane also moved a bit thus reducing Z :aggressive: ...

[jared2982]

Genma Saotome, on 20 March 2018 - 03:43 PM, said:

What in the .s file controls draw order? I've seen the term mentioned WRT multiple semi-transparent alpha faces, such as looking thru front and side cab windows to see both the partially obscured tree in the distance and the crew member in the foreground but was led to understand you get that in $ tools like 3dmax only.

Gmax is also capable of sorting the draw order. It takes a bit to wrap your head around it but worth the effort if done correctly with alpha channels. I don't know if it would do anything for this particular issue but might be worth a try.