• 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.

FSX - Z sorting between objects?

M

martin_ktpa

Messages
40
Sorry if this has been covered already.

The FSX materials have lots of new options regarding Z/Alpha, but they all appear to boil down to sorting the "max scene" itself, meaning the object(s) that are being exported.

These objects by themselves are working fine here, setting "SrcAlpha" according to the Doc when using a diffuse texture with alpha channel... But what about Z sorting between various MDL objects that compose a scenery.

Am I missing something? I tried changing the order of the "SceneryObject calls" within the XML, tried compiling them to separate BGLs and renaming/sorting the files (a la FS2002 Bgls) but still massive Z problems based on the camera viewpoint & object's refpoints.
 
Hi Martin,

I don't think this has changed compared to Fs2004. There it was also that the location of the reference points of the different objects determine their drawing order. I have never found a way to control that. Unless you move them all into one reference point of course, but usually that is not what you want.
 
Thanks for the replies.

From what I can see here it is worse then before. I am noticing that using DXT1 (which used to work fine) makes no difference, causing the same Z problems.

I will see if reverting the objects that use alpha (fences etc) back to standard (non FSX) materials helps (while still exporting & compiling with FSX tools)
 
Hi Martin,

Humm, I have not tried it with DXT1 textures yet. But it would be a pity if that fix no longer works, as it was quite useful to fix drawing order trouble for transparant parts. I'll try to give it a test here as well.
 
Tested it a bit more... No solution in sight & DXT1 or DDS with 1bit alpha doesn't make a difference in my tests. The real cherry is that BGLs compiled with the old MakeMDL 2002 and sorted by filename render with proper Z-Sorting even in FSX.

To me the whole FS9/X concept of wrapping MDLs with XML without control over drawing order, without "V1" max-distance, an LOD system that only works with small objects + the fact that many XML object calls degrade performance is just doomed for scenery design as we knew it. The aircraft guys must be happy, as none of this affects them :(
 
I think that one of the most important lessons I've learned after spending several months working with FSX is this:

In many ways, it is far easier for a "newbie" to come to grips with FSX's "new ways" than it is for an "old-timer," since "newbies" aren't weighed down by preconceptions, nor are they filled with angst about "how things used to work..." :)

Once I decided to cremate my "pity party," I have - somewhat astonishingly - observed that my productivity has nearly regained pre-FSX levels...:cool:

While the new SDKs are much better than previous versions, as always they are but a bare beginning. As in the past, it is "we" who will eventually fill in the blanks through our incessant experimentation and out-of-the-box thinking... :rolleyes:
 
I love this concept that old-jurassic designers are the ones stuck with past-thinking and its time for a fresh generation to produce artistic masterpieces for FSX.

The things we just pointed out in this thread, Z-sorting & control over visibility with a V1 or proper LOD system are not old FS2000 concepts but essential in a modern 3d engine.

Crysis, Nascar, Company of Heroes, Lego SW you name it.... How do you think these games would render if objects weren't Z-sorted? And what fps do you think they would be running at without a proper LOD system? These are 2006 3D rendering essentials that FSX threw overboard. I can also assure you from insider knowledge that no other 3d engine has their objects placed via XML or cryptic GUID values.
 
Last edited:
Very nicely said indeed. I think you are right, we should not try to keep are old way of doing things and port it to the FsX tools. We should start by looking at the new possibilties offered by the new tools and see what nice things we can do with that (and forget how we used to do it).

Of course we will find things that are harder to do now, but we will also find a lot of things that were (extremely) complex in the past and are a lot easier now.

I only hope that in the future some of the standards (like the scenery XML format), will become a little bit more flexible. As I see that a lot of the new stuf is great, unless you want something that is really different from the default scenery. But as FsX is still new, we might also find ways around that.
 
I really appreciate the positive attitude.

If there is a new method for Z-sorting between objects that we just haven't found out yet thats fine with me.

If however there is no Z-sorting method at all that is just bad. I dare someone explain us the advantages of no Z-sorting in a 3D engine.
 
... and some good news... in my limited experiments so far with transparent DXT3 fencing, I have yet to see objects occluded as often happened in FS9.

Jon
 
Paavo said:
Have you checked out the Z-sorting settings of FlightSimX materials?
Click to expand...

Yes, look at the opening post. My issue is that the Z sorting material-options only apply to the MDL that is being compiled.

A scenery however should consist of many MDLs placed more or less close together (overlapping sometimes). Between these MDLs (which by themselves have no Z-sorting issues) is where the problems lie.

The way it would work is if we didn't use many separate MDLs and instead compile large chunks as one MDL. In that case we have less Z sorting problems. This however however not the way it is intended to be done because large-chunck MDLs mean that the LOD system can't be applied anymore (LOD system only works well with relatively small MDLs, as it is made with Aircraft modeling in mind).
 
JonPatch said:
I've enabled Z-Write Alpha
Click to expand...

Yes the Z-Write-Alpha checkbox is a must along with the set-default-transparent button.

In your fence example, do the objects behind the fence have their refpoints also behind the fence and how close to the fence are they? I get problems mainly with objects that are within <10m of the fences or other alpha textured objs.
 
Last edited:
Hi Martin.

Are you exporting many objects from gmax as a single MDL, and then placing that MDL with a single XML placement BGL?

Dick
 
Its no secret I'm going to agree with Martin. I feel many of you guys defending FSX don't know how good you should have it by now. I've worked in the Game Industry over 10 years on a vast varity of GFX engines & tools. All of them have strengths & weaknesses. BUT, nothing & I mean nothing, comes close to the Slopware that is the FSX Engine & SDK. FSX has introduced a totally new level of incompetence beyond even my worst nightmare. I’m coming from the Art camp here. There should be no or very limited need for programming skills while exporting simple static environment scenes.

I can only hope Microsoft hire a new development team & completely re-write the engine, because the current FSX engine is an obsolete dying relic technology left behind.

Cheers,
George Grimshaw
 
Last edited:
Hi George.

This forum in particular is trying to find design solutions for Flight Simulator, and to share that knowledge.

Most of the posts on the forum are about FSX because we've already taken pre-FSX scenery development to it's limits. Not much new to learn. Go read the wikis and the old posts.

I don't believe anyone is "defending" FSX. If a designer wants to continue development for FS9 and earlier, there's sure a lot of world to design.

I understand the frustration designers may feel towards the new sim. But believe me, it is NOTHING like the frustration we had with FS2002.

This very forum grew from a core of designers that weathered that storm, and unlocked the sim's secrets... some of which even the MS design team were unaware. It involves some creative thinking, and as Bill noted above, sometimes you have just got to let the past go. I think that is valid advice.

Here's why:

The Aces team is now working on a performance patch, and a more comprehensive Vista-related patch is in the future. But I can almost guarantee there will be no patches for design problems, unless they are trivial in nature and can be included with the other 2 patches on the board. Precious little money and time in the budget for fixing all the problems.

( Simconnect is another animal.. there may be a series of improvements as that branch of the team has indicated. I think they are obsessed with it! )

So where are we?

Rather than being a group of "FSX fanboys", I think we're a group of pragmatists that want to solve the problems before us, rather than ranting about what could have, should have, been.

I certainly don't want Microsoft to fire the Aces team, and scrap the sim. And I don't see any other world-sized flight/terrain sim to truly compete with the dying relic. ( Besides, that was the basic thinking behind CFS3, and it was a huge bust... both from a financial and technical viewpoint ).

Most designers want some level of backward compatibility.

Martin's original post was about this lack of compatibility... not about scrapping the sim. So you do not agree with him.

As far as having limited programming skills... most of us suffer from that! What is needed are better tools, with better GUIs to mask the complexity of scenery design. Unfortunately, we poor programmers, that want those tools, are the least likely to create them! So we are at the mercy of those that can program.

But scenery design is a complex problem. Terrain alone requires almost an advanced degree in mapping technology. This isn't the sim's fault, but rather the desire for greater accuracy in the sim.

Scenery objects are also becoming more complex, and more numerous. Admittedly, what we put in the sim is often more than what the Aces team envisioned. Door hinges, rivets, shingle textures, chirping birds, cargo ship container labels... all going a bit beyond what a world-wide scenery engine was designed for ( flight ).

We do have an influence over how the sim evolves. The forums, and the designer's end products are often incorporated in newer FS versions. For example, everyone wanted more ( and more accurate ) roads and water shapes and effects for FS2002. Designers investigated and pushed open the door for what we take for granted in FSX. Constructive and productive solutions will find their way into future versions of flight simulator.

But if the team is fired and the sim scrapped in favor of the entirely new "engine", the sim will dead-end... just like the CFS series died with the unworkable orphan named CFS3.

I'm sorry for hijacking your thread, Martin. I hope you can find some sort of solution, but I suspect you are trying to force FSX into a technical direction it no longer supports. Discreet object MDLs placed in an encompassing XML is the direction the sim has gone, rather than many objects in one single MDL. Does this sound right to you?

Dick
 
Last edited:
FS2002 was the closest they ever got to getting it right. The engine wasn't yet obsolete & they'd introduced GMAX. No decent scenery can be built without an 'off the shelf' 3d modeling package. Unless you want a horrible programmer art default o' rama.

I started with FS2002. I had lots of problems at first.
But, I could build something I was almost happy with in the end.

Now with FSX, everything is a complete disaster. There’s nothing new to learn. It's all broken way beyond even FS9. There obsession with XML exporters & Pointless GUID numbers is the path to poor performance & poor artwork.

Martin Is trying to get a simple card based fence the render correctly with alpha. A simple fundamental 3d graphics features that has worked perfectly outside of FS for 10 years.

Cluster based environment exports ARE the only way to build quality airports.
XML 0,0,0 single object exports quickly leads to pisspoor frame rates.

I know its Taboo to say a bad work about the great guys & gals at ACES, but they have delivered a total piece of crap. Forgive me for insulting a multi billion dollar corporation.
 
rhumbaflappy said:
Are you exporting many objects from gmax as a single MDL, and then placing that MDL with a single XML placement BGL?
Click to expand...

No, I am trying to avoid that and find a balance of (MDL) dimensions that still works with the LOD system.

Basically the LOD system itself is "forcing" me to export many separate MDLs (objects that are never much larger then say a 747 aircraft). The point is that when using many separate MDLs, one encounters these Z-rendering problems between them. On the other hand, these Z-rendering problems could be avoided if the whole "scene" was exported as single MDL... but then of course the LOD system is useless.

PS: Please don't misread or re-read my posts. I'm not aiming for backwards compatibility or alike here. What this is about is how does one create a bunch of scenery objects for FSX using the FSX modelling SDK and materials, compiled with XtoMDL and placed with BGLComp. No pre-FSX code or concepts involved at all. Why would these FSX compiled objects suffer from Z-sorting problems between each other (meaning between each MDL, not the contents of each MDL by itself)?

If this is indeed a problem resulting in designers now being unable to control the MDL drawing order, then it is a flaw and should be pointed out to Aces imo. We cannot just sit back and assume Aces knows what they are doing and whatever they released must be good, while the addon guys just aren't smart enough to figure it out.
 
Last edited:
You must log in or register to reply here.
Back
Top