• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Prepar3d v2 z-bias material

B

BrBlazer

Messages
481
Hello Arno,

Is it possible to add the new "z-bias level" that Prepar3d v2 added specially for ground poly's per the SDK document?

It's explained in the "Using the modeling tools" section where it reads:

"Material Functionality: Z-Bias Level

In order to improve layering materials on the ground for airport ground polygons Prepar3D has implemented a Z-Bias level material setting. "

Maybe this could be something that can also be implemented for the groundpoly converter section... there is FS9 and FSX listed there already, let's say another P3D button and instead of "layer" 4, 8, 12 it would be zbias level -10, -20, -30, etc....

Kindly,

Blazer
 
Hi,

I do have an updated version almost ready that supports reading and writing this new material attribute. Of course it requires the P3D 2.0 SDK. I hope to release the update later tonight.

Later I should also update the ground polygon wizard I guess. It should probably be possible to use MDL files with the zbias setting now, instead of the old FS2002 style code. But that would require a little more testing to make sure it works well.
 
Hi,

I just put the new version in my version control system. So tonight a new development release will be made that includes the P3D v2 support.

The changes to the GPW will take a bit longer. I first need to find some time to experiment with that :).
 
Hi folks,

I hope I am correct in thinking that Arno is talking about the Z - Bias section of the material properties where the info text says 'additional -bias for the material'. Based on my own experience plus reports on the LM forum, flickering or z fighting of transparences in P3D including v2.5 has been a big problem.

I think I have found an easy solution but it does not make sense, so maybe someone has an explanation of why it might work.
According to the P3D SDK,

Material Functionality: Z-Bias Level
In order to improve layering materials on the ground for airport ground polygons, Prepar3D has implemented a Z-Bias level material setting.
This functionality only works with "No Z Write" checked on the material. Using values between 0 and -50, you can set and order the layering of the ground polygon textures above the default airport aprons, taxiways and runways. The more negative the Z-bias, the later in the process it will draw. For example, the runway ground polygon could be -1, the white runway markings could be -2, the yellow runway markings could be -3, etc.

For the heck of it I tried playing around with the additional Z bias in the MCX material editor for some of my problem transparencies, railings in particular. If I check the 'No Z Write' setting, the railings disappear when there is a texture behind.

However if I leave it unchecked (set to FALSE) and use an additional Z Bias of say -1, -2, or -3 the railings display as intended and the flickering is completely gone. And this seems counter to the SDK, so I'm not sure what's going on…. Not that I am complaining!

Any ideas?

Larry
 
Hi Larry:

Although I'm not certain that the numerous inter-related sub-topics and obscure "gotchas" involving SCASM-coded objects will all have a direct bearing on the display issues under discussion here in this same thread, perhaps at least some of the info within the following linked thread (and the linked threads therein) ...might prove helpful ?

http://www.fsdeveloper.com/forum/th...ry-objects-be-called-from-fs9-fsx-xml.431609/


And, at FSDeveloper alone, I see 10 pages of "hits" when I search for "Z-Bias", some of which may also merit review:

http://www.fsdeveloper.com/forum/search/1048849/?q=Z-Bias&t=post&o=date


Additionally, IIRC, there may be some older info regarding how to manually assign "draw order" to sort out transparency attributes within either MDLs or legacy SCASM / ASM object source code, which I might still be able to find; I'll post back here if I can locate it. ;)

[EDITED]

UPDATE #1:

This may only have to do with transparency, but the following thread was one of the earliest inquiries regarding transparency display changes since FSX was released:

http://www.fsdeveloper.com/forum/threads/fsx-sp2-breaks-dxt1-transparent-textures.7124/


Subsequent to that latter thread, Boris Forero reportedly had worked out a system of controlling both transparency and draw order, IIRC, via 'something' to do with his material mapping attributes.


UPDATE #2:

The following thread (coincidentally) describes the method Boris Forero once reported as being involved in his system of controlling both transparency and draw order, which, IIRC, was part of the 'something' to do with his "material mapping attributes".

http://www.fsdeveloper.com/forum/threads/transparecny-and-draw-order-fs2004.19053/


BTW: Boris Forero was working on a FS2004 version, and later a FSX version of his "Quito Ecuador" airport scenery project ...when he was exploring the SDK transparency display changes ACES imposed since FSX was released.


Fr. Bill Leaming later offered this insight (...many thanks, Bill ! :teacher:):

"FS8/9 draw order is sorted alphabetically by material name.

In FSX though, draw order is controlled by Z-bias settings in the material's properties."

http://www.fsdeveloper.com/forum/threads/transparecny-and-draw-order-fs2004.19053/

[END_EDIT]

...More to follow, if I can find it. :idea:


Hope this helps ! :)

GaryGB
 
Last edited:
To me it does not seem to contradict the SDK. The act of selecting "no z-write" invokes a new algorithm, not part of the original SDK, that layers textures for proper presentation of GP's - which your railing is not and there is little wonder it is transparent in front of a texture that probably has a higher drawing order, I don't know. This from the P3D forums:
"This is a new system that doesn’t require old FSX sdk tools. The Z-bias material flag has a new section in the SDK"
However, in my interpretation, when you do not select no z-write, effectively "allowing z-write," the legacy z-bias adjustments affect your texture with desired results, upon experimentation.
 
Thanks Gary, and Rick,

OK Rick, I take your point about no conflict with the SDK. In that case, what is the range of acceptable values for the additional Z Bias? Do the numbers in the P3D SDK -1 to -50 refer specifically to ground polys? I did not double check this, but one time I tried 0.10 for the additional Z Bias, and that seemed to work too! In any case, so far I've had success in solving a very annoying problem.

In that the flickering does not happen on every model where I use essentially the same material (in Sketchup) I wonder if the following might explain it: unlike painting with an opaque material, you can paint only one side of a poly in SU and the opaque part of the transparency will show through to the opposite side. So if one is very careful, you only need to paint one side of a transparent texture. But in a complex model with frequent revisions, often the reverse side will end up painted with something inappropriate. I have not found an easy way to remove the unwanted texture on the reverse (initially light gray) side *and* let the desired side show through, so I usually use the dropper tool on the good side and paint the bad side. Perhaps the sim then interprets this as two different transparent textures on the same plane, thus the flickering. Perhaps the Z Bias then offsets on material one way and the opposite face the other. Just a guess!

By the way, a few of the default P3D objects have the flickering problem too.
 
L_Rob said:
I wonder if the following might explain it: unlike painting with an opaque material, you can paint only one side of a poly in SU and the opaque part of the transparency will show through to the opposite side. So if one is very careful, you only need to paint one side of a transparent texture. But in a complex model with frequent revisions, often the reverse side will end up painted with something inappropriate. I have not found an easy way to remove the unwanted texture on the reverse (initially light gray) side *and* let the desired side show through, so I usually use the dropper tool on the good side and paint the bad side. Perhaps the sim then interprets this as two different transparent textures on the same plane, thus the flickering. Perhaps the Z Bias then offsets on material one way and the opposite face the other. Just a guess!
Click to expand...
It should not be difficult to set up a test model at all. Say an octahedron upon which you could apply different material settings, and then "sight" through pairs. You could put numbers on each pane to help maintain track of them.
 
Hi Larry:

I also agree with Rick's observations and suggestions as posted above. ;)


Regarding Sketchup, IIRC, the developer's documentation states that a certain script function is used to effectively cut through the wall when applying a "translucent" material on a window sub-face, which is intended to penetrate through the entire (1/200th of an inch thick) depth of a (default 'single-thickness') double-sided wall face on a 'solid' / 'manifold' ex: extruded box model, so that edge lines of a window 'sub-face' drawn and textured onto a 'wall' face are visible and accessible for modification ...from both the front and reverse sides of that same 'wall' face.

This may or may not allow one to see through those windows from the inside of the building to the outside of the building, so that nearby objects can be displayed properly (if at all).

In such scenarios, within Sketchup I always apply the same transparent / translucent material for the window 'pane' on the inside of the building ...as was used for the window pane on the outside of the building. :idea:

When I do that, I get transparent / translucent windows with the ability to see through those windows from either side of the wall on which they are located.

Furthermore, I can also still see through those windows when looking at them through other nearby windows, which suggests a rather comprehensively sorted transparency and draw order has been achieved. :wizard:



Although I don't yet have P3D to test with, I believe some of the same criteria for successfully implementing transparency and draw order applies to P3D, as applies in 'some' FSX modeling and texturing material scenarios.

There may be, however, some additional parameters we might need to consider when (literally) sorting out transparency and draw order test scenarios such as you describe.


If one reviews Arno's wiki: "Drawing order problems with transparent textures"

http://www.fsdeveloper.com/wiki/index.php?title=Drawing_order_problems_with_transparent_textures


...using the "Boxes" model made by rhumbaflappy for Arno's tutorial above:

https://onedrive.live.com/?id=F3950C5BBD2BCFA1!393&cid=F3950C5BBD2BCFA1&group=0


...when one examines Material properties for each texture in such example models within the right pane of the Material Editor in Arno's ModelConverterX (aka "MCX"), one might discern what factors play a role in successfully implementing transparency and draw order, by comparing appearance of the model in MCX' OpenGL 3D preview with its actual FSX / P3D run time rendering via the Windows DirectX sub-system.



These additional considerations may also apply when successfully implementing transparency and draw order:

http://www.fsdeveloper.com/forum/threads/transparent-building-issue.1608/

http://www.fsdeveloper.com/forum/threads/transparency-dxt3-drawing-order-issue.4521/

http://www.scenerydesign.org/2008/02/transparent-textures/

http://www.fsdeveloper.com/forum/threads/transparency-drawing-order-of-glass-terminal.20433/

https://www.google.com/#q=Arno FS Alpha transparency


Also of note is Andrew's solution to successfully implementing transparency and draw order on a double-sided window:

http://www.fsdeveloper.com/forum/threads/transparency-dxt3-drawing-order-issue.4521/#post-30376

< NOTE: I haven't found Andrew's 'tutorial' yet ...anyone know where it is located ? :scratchch >



PS: I added some updates to my post above:

http://www.fsdeveloper.com/forum/threads/prepar3d-v2-z-bias-material.428218/#post-718090


Hope this additional info helps ! :)

GaryGB
 
Last edited:
Thanks for all of this Gary,
The one thing I couldn't find in a quick scan of the links is a rough history of the Z-Bias setting as used in the MCX material editor, and in particular, the range of values that are acceptable other than the -1 to -50 for P3D above. Does this setting go back a long ways?

I suspect that this was originally tied in some way to material options in GMax. Sketchup does not have similar material options, so I gather MCX assigns any needed material options which can then be adjusted. The question is then, where to start, what Z Bias values are appropriate as a first try to eliminate the z fighting of certain transparencies in P3D? (I figured -1 was a nice round number!) :)

Larry
 
Last edited:
Hi,

The material attribute in MCX goes back to the old API macro format where we had a zbias command as well. It's range was typically a positive integer number. This was used to determine the order in which overlapping polygons are rendered.

For ground polygons the layer of the ground polygons is also stored in the zbias attribute.

For FSX mdl files there is no zbias, so actually it's a good thing it was added back in P3D since it is a useful technique. When exporting to the FSX mdl format MCX moves the polygons a tiny bit along the normal to mimic the zbias behavior.
 
Hi Arno,

Your comments above are really helpful! To maintain consistency with FSX, I'm exporting all my models in FSX format so your comments apply.

For the sake of those perusing this tread in the future, perhaps I can summarize my tentative conclusions ... as of this moment:

Problem in P3D: flickering or z-fighting of some but not all transparencies applied to model surfaces

Likely cause: if there is a transparent texture applied to both sides of a surface, the sim will try to display both in the same plane, thus flickering.

Solution: add a Z Bias to the material in question using MCX. Per Arno, when saving for FSX, The Z Bias value causes MCX to move the poly that the texture is applied to a little bit along the normal to the surface. By usual convention this should be the outward facing normal vector, where the vector for the two sides point in opposite directions. (I'm just assuming the sim follows this convention.) The result is a slight separation of the z fighting textures.

How: (this works for models originally compiled with MCX; it may or may not work for other models -- have not tried it.) Open the model .mdl or .bgl in MCX, then open the material editor. In the Properties tab, find the problem texture and change the Z Bias value from 0 to a small positive integer. Save the model and test in P3D.
 
Hi Rob,

That sounds quite OK.

Only, I don't think that a two sided transparent polygon will give flickering. Since they are not rendering in the same direction (one is the front and the other is the back). So either there are two front polygons or another polygon is conflicting.
 
,"Only, I don't think that a two sided transparent polygon will give flickering"

Hi Arno,

This remains puzzling -- the cause that is. In SU if there are two polys in exactly the same plane flickering will be obvious. And as a check in SU, I selected a few of the surfaces I knew caused problems-- one at a time-- and hit 'delete'. No surface remains. I do know that at least in some cases where the flickering has been a real problem that both sides of the surface were painted with matching textures, the second copied from the first with the dropper tool. The first option you suggest would seem then to be ruled out. Can you think of a way for another identical poly to conflict, one that is not visible even with 'unhide all'? Could it be something hidden in the .dae code?
 
Last edited:
Did you maybe enable the two sided option in the material settings as well? That could conflict with having two polygons already.
 
Hi Arno:

After considering the (additional) info in these threads:

[EDITED]

http://www.fsdeveloper.com/forum/threads/draw-order.63370/

http://www.fsdeveloper.com/forum/threads/z-test-value-and-transparencies-im-lost.214849/

http://www.fsdeveloper.com/forum/threads/fsx-property-layer-on-fs2002-gpolys.22930/

http://www.fsdeveloper.com/forum/threads/fsx-transparency.240259/

[END_EDIT]


...and:

The FSX SDK documentation on the option of setting "double sided" for materials:

https://msdn.microsoft.com/en-us/library/cc526973.aspx#DoubleSidedMaterial


...and:

The MCX documentation that only says this regarding setting "double sided" for materials:

http://www.fsdeveloper.com/wiki/index.php?title=ModelConverterX#Material_editor


...I'm compelled to ask:

* In MCX, exactly where (and when) would one set- (or not set-) the "double sided" option if one is also using Sketchup's native exporter option ...to either allow- or dis-allow- 2-sided faces within the file to be imported by MCX ? o_O


* And in what situations would one specify for use or (non-use) of Alpha with- (or without) "Z-testing" ...when seeking to eliminate the above described display artifacts in MSFS / P3D at run time ? :scratchch


PS: UPDATED 08-11-2015 ...I also found these pertinent threads:

http://www.fsdeveloper.com/forum/threads/z-test-alpha.65982/

https://msdn.microsoft.com/en-us/library/cc526973.aspx#AlphaData

http://blogs.msdn.com/b/shawnhar/archive/2009/02/18/depth-sorting-alpha-blended-objects.aspx


Thanks for helping us to sort out use of these parameters and the other related sub-topics in this thread ! :)

GaryGB
 
Last edited:
Hi Arno,
And thanks from me too in helping us understand how this works.

I have confirmed that I do not have the double sided option set in the MCX material editor, and I do not use the 'export two sided faces' option when exporting from Sketchup. As far as the flickering problem in P3D, it seems to be an intermittent problem with a number of scenery objects, both addon and in a couple of cases I think, generic objects. I'm just guessing about one possible cause based on my own models. There is another issue too that has been related to flickering in P3D; an inappropriate Clip Mode setting for the camera used, but that's another subject.

And now to check out the links Gary has provided; the FSX SDK link regarding double sided materials has me even more confused than normal. :-)
 
Hi Larry:

Can you list 1 or more specific 'default' scenery object(s) from FSX and/or P3D (by name or GUID) ...which Arno could examine on his own FS installation to see if he can replicate the above described run time display artifacts in MSFS / P3D, and hopefully identify what MDL or other ASM code is both required and to be avoided ... to allow proper display ? :scratchch

If you don't yet have a conclusively identified 'default' scenery object from FSX and/or P3D (by name or GUID) that has the above described run time display artifacts in MSFS / P3D, could you instead please provide Arno with one of your own scenery objects that does definitely have the above described run time display artifacts in MSFS / P3D ...so he can examine it on his own FS installation ? ;)


PS:

L_Rob said:
...the FSX SDK link regarding double sided materials has me even more confused than normal. :)
Click to expand...

FYI: See this 3ds Max Help: Double Sided Material tech document:

http://knowledge.autodesk.com/suppo...2EA132CE-B506-4840-920F-33D220E898A7-htm.html


Sketchup, of course, already allows double sided materials by default, just as it already creates 2-sided faces by default (AFAIK, all other 'mainstream' 3D modeling programs require one to manually allow and create a 'reverse' face which can be textured). :pushpin:



BTW: Interestingly, the above 3ds Max Help: Double Sided Material tech document also mentions this as an associated parameter:

"Translucency

Sets the amount that one material shows through the other. This is a percentage that can range from 0.0 to 100.0. At 100 percent, the outer material is visible on inner faces and the inner material is visible on outer faces. At intermediate values, the specified percentage of the inner material "bleeds through" and is visible on outer faces. Default=0.0.

You can animate this parameter"


One might wonder whether Sketchup use of texture materials {ex: PSD / TGA / BMP/ TIF with Alpha, or PNG with other "keyed color" transparency, might be implemented and display-able as 'double sided materials' in FSX / P3D by virtue of this parameter being applied (ex: in Sketchup's default "Translucent" materials ...accessible via the Paint Bucket Tool) ? :idea:

GaryGB
 
Last edited:
Gary, I have one model in mind, and I think another was mentioned on the LM forum; I'll see if I can find the model names and GUIDs
 
Last edited:
You must log in or register to reply here.
Back
Top