FSX triangles, vertices and drawcalls

[robystar]

Hi Arno,
You must be very busy with your family or with your work because I can not imagine that you are enjoying the nice weather that we have here in the Netherlands?
Hope you find some time to clarify the inconsistency that exists between the number of triangles, vertices and draw calls that exist between what MCX tells you and what FSDS tells you.
I explain: I made a very simple object (a taxi sign) with SketchUp and made it exactly the same as one made with FSDS and textured it with the same materials.
I check what the draw calls, the triangles and the number of vertices are in FSDS and compare them with what MCX tells me and funnily enough MCX gives me more than double the figures that the same one made in FSDS gives me!
Could you give me an explanation for that and/or convince the ones that think SketchUp is doing it the wrong way so that the latter weighs more on the FPS in FS than when it is done with Gmax or FSDS?
Tks,

 

[arno]

Hi,

It's a bit hard to tell without seeing some numbers or images. The triangle count should be the same. MCX shows texture vertices, which is an unique combination of position, normal and texture coordinates. So that explains why you can see more vertices than in other tools. But this is how FS sees the vertices when rendering as well.

 

[=rk=]

I can suggest that SU does not count triangles within polygons. I am pretty sure that is the discrepancy. In the strictest sense, individual faces always only have three sides. SU, I believe, allows four and multiple sided polygons to have a single face. So a square in SU would be two triangles in MCX. My previous version of SU had an option to "triangulate faces in selection" and it would make triangles from all the edges in a polygon, it would add the corresponding faces as well. So a single polygon SU hexagon would become 4 triangular polygons in MCX:

 

[arno]

A polygon is not the same as a triangle of course. Some programs give polygon counts, others give triangle counts. That should not be confused.

 

[=rk=]

Yes and I did confirm that SU provides a count of faces, which would probably be polygons. My suggestion above does not account for SU creating more than double, so it only confuses the issue, apologies.

 

[robystar]

Thanks but basically what is the answer to the following question:
Are two identical objects, one made in FSDS and another one in SketchUp, although showing different numbers, boil down to the same number of vertices and triangles and their impact on the FPS in FSX irrespective of the data provided by the program used to show the amount of triangles, drawcalls, polygons and such?

 

[tgibson]

If they are truly identical in FS then yes. But that it almost never true once the source objects are compiled into FS objects, due to differing conversion processes.

 

[=rk=]

Ok two things: in my experience, SU tends to add polygons and components I didn't expect. Perhaps it is part of the editing process or my own clumsiness; whichever the case, my solution is to use this plugin: https://extensions.sketchup.com/en/content/cleanup³ and when I do, yes my SU models are very compact in relation to their FSDS counterparts. I did a reasonably large project using FSDS to animate my and other authors' models I had a chance to compare identical components from each software. I will say that FSDS always triangulates every polygon while SU does not automatically do so. You see it when you import an FSDS model into SU.
The other thing is that you can convert to common format and run models from both versions through MCX and into each editing software to try to nail down where the extra complexity is coming from.

 

[GaryGB]

Hi Arno:

IIRC, you had once posted that texture vertices were approximately 3 times more numerous than base geometry vertices of the "3D wire frame" for an object... could you clarify that for us ?


Also, Sketchup by default makes all objects as double-sided faces (even when they are 'manifold' solids), and upon export from Sketchup, one must manually disable the default export of 2-sided faces in the [Options] dialog when they are not needed (which is the case for most MSFS "solid" scenery objects).

Additionally, both sides of each Sketchup model face are always textured with a Material "Color": whether the Front (White) or Reverse (Light Blue); thus, IIUC, there will be UVW texture Material mapping for each vertex (aka "T-Verts")


Wouldn't this suggest that a Sketchup model may be initially more complex than 3D models from certain other 3D modeling apps by virtue of their geometry, texture vertex count, and "Edge line" statistics alone, until it is processed by MCX to "optimize" the model Hierarchy of its overall structure ?

Thanks,

GaryGB

http://en.wikipedia.org/wiki/Solid_modeling

 

[arno]

Hi Gary,

IIRC, you had once posted that texture vertices were approximately 3 times more numerous than base geometry vertices of the "3D wire frame" for an object... could you clarify that for us ?

Yes, that is quite likely. Take a cube, it's easy to see that the geometry has 8 unique vertices. But the texture vertices also take the normal and texture coordinates into account. So, since each side has a different normal, there are at least 6 x 4 = 24 vertices for that cube when counting the texture vertices. If the texture mapping of the two triangles of each side are not continuous this can increase to a maximum of 3 x 2 x 6 = 36 texture vertices for the entire cube.

 

[GaryGB]

Thanks for that clarification, Arno !


BTW: This brings up another related question I have been wondering about for some time, which is alluded to in this post:

http://www.fsdeveloper.com/forum/threads/decrease-polygon-edges-lines.434139/#post-711527


When Sketchup "component instancing" and/or "mirroring by 'reversed geometry' instancing" is used, upon import to MCX, is all that geometry actually kept intact as true instances when exports to MSFS MDLs are performed in MCX ?

Or does MCX instead convert all component "instancing" of a Sketchup 3D model into multiple copies of the actual original component geometry so that the polygon / triangle / vertex limits are what they otherwise would have been if instancing was not used ?


Do we instead always have to use the 'instancing' feature of placing MSFS scenery library objects multiple times when working with 3D scenery objects ?

(I'm referring to objects in a context of BGLComp xml placement and not Autogen placement ...for purposes of this discussion).


Thanks in advance for your further clarification.

GaryGB

 

[arno]

MDL objects don't have the concept of instancing, so if a SketchUp object contains multiple instances of the same component, they will each become separate geometry and will thus add up to the total triangle/vertex count.

If they are placed as seperate objects with BGLComp you can have the drawcall batching, but in the end there is no "free" geometry, it always has to be rendered somehow.

 

[GaryGB]

So, IIUC, currently, if one wishes to use "instancing" in MSFS to reduce 3D model complexity in each MDL, and its associated demand on the FS rendering engine, one must export ex: Sketchup components as separate objects and place them as MSFS scenery library objects, so that the visual display of a complex 3D scenery object that uses many copies of the same "component" sub-object is essentially made up of many individually-placed MSFS scenery library objects.


That begs this question...

Can MCX be adapted to tag Sketchup "components" in a KMZ file upon import, so that part of the existing MCX feature set could be used to later "place" those sub-object geometry entities in the correct position (relative to their original XYZ coordinate location in 3D model Cartesian coordinate space within the overall object) ...except instead that they are placed as separate MDLs ...via a BGLComp placement BGL at Geographic Lon, Lat, Alt "XYZ" coordinates ?

Since MCX already has a feature for creating a BGLComp placement BGL from a KMZ import of a Sketchup model, could MCX be further coded to utilize that data in a Sketchup-generated KMZ containing "components", so that MCX can output the KMZ model as multiple MDLs, with each "component" having its own precise Geographic Lon, Lat, Alt coordinate 'placement' code ...in the same BGL as MDLs themselves (understanding of course this would provide geo-locked placement for those MDLs) ?


IIRC, you have previously implemented a way for MCX to sequentially import a Sketchup project file (KMZ ?) containing multiple objects for Dean Mountford (aka "=Hollywood="), and IIUC, to also "place them" as separate MDLs.

Could the code for that above method perhaps be adapted to do what I suggest above for other FS developers, and specifically to expedite processing of ex: Sketchup KMZ models using many instances of "components" ...while potentially also optimizing MSFS run time performance when displaying such complex 3D scenery objects ?


Thanks for your further consideration of this possibility; I believe it could prove very helpful to both scenery developers and end user FS run time performance with scenery containing complex 3D scenery objects that utilize many instances of identical sub-objects.


GaryGB

 

[arno]

Hi Gary,

I would pose that adding the extra triangles to the mdl file, is probably more efficient performance wise than placing multiple instances with bglcomp.

IMHO the overhead of the additional placement is more than what you save. In the end the total amount of triangles that has to be drawn is the same. I don't believe that the FS engine has a real instancing logic in it.

 

[robystar]

Hi,

I noticed the difference between an FSDS made object and a SU made one is the fact that on the intersections of the SU made ones extra triangles are formed while in the FSDS one they are not.
In wireframe mode you can see what I mean:

FSDS:

Sketchup:

Notice the difference in triangles and vertices.

 

[GaryGB]

Hi Gary,

I would pose that adding the extra triangles to the mdl file, is probably more efficient performance wise than placing multiple instances with bglcomp.

IMHO the overhead of the additional placement is more than what you save. In the end the total amount of triangles that has to be drawn is the same. I don't believe that the FS engine has a real instancing logic in it.

Hi Arno:

IIRC, it was reading a Blog post by ACES' Phil Taylor years ago which gave me the impression FSX SP2 had implemented "instancing":

http://blogs.msdn.com/b/ptaylor/archive/2008/04/17/back-of-the-envelope.aspx

"Part of our performance work is to turn the engine from a batching engine to an instancing engine to help bridge this gap. When using instancing and assuming 10% of the bus bandwidth is available for non-animated instance data (0.10 * 34MB / 48 bytes per instance) = 74, 274 instances per frame at 60 Hz can be sent across a PCIe 16x bus."


IIUC, when "draw call batching" is used on non-animated objects, such non-autogen objects may also utilize "instancing"; or was ACES' work on this not finished in SP2 ?

http://en.wikipedia.org/wiki/Geometry_instancing

https://msdn.microsoft.com/en-us/library/bb173349(VS.85).aspx


BTW: An incidental find regarding LM's work with 'instancing' in P3D:

http://www.prepar3d.com/forum-5/topic/fade-in-of-autogen-and-lod/


Thanks for sharing your insights on this (sub-topic).

GaryGB

 

[Lane Street]

I noticed the difference between an FSDS made object and a SU made one is the fact that on the intersections of the SU made ones extra triangles are formed while in the FSDS one they are not.
In wireframe mode you can see what I mean:

You can easily replicate the FSDS statistics in the SU model by understanding how SU works and it's "sticky" technology.

If you make the posts separate from the sign, so they don't actually touch, the poly count would be the same. Even a space of a few mm would work and be hard to notice in the sim.

Or you could make the sign a group. Doing so would prevent the posts from "sticking" to the sign. If you then delete the surface of the bottom of the posts the SU poly count would match the FSDS poly count.

Another method would be to make a post first, then make it a component. You would then make 2 copies of the component and they would not stick to the sign.

One advantage to making to posts components is you only have to map one, which could save a few minutes in your workflow.

cheers,
Lane

 

[robystar]

Hi again,

Small update: making a separate component of the taxi sign posts eliminates these extra triangles (see screenshot) !!!

Thanks, Lane.

I wrote the above reply around 4 pm (14:00 UTC) but forgot to post the reply. So, yes, I already found out what you said just now.
Though I am not sure whether the advantage outweighs the difficulty I have in placing the components where they belong. That is something that I still do not grasp 100%.
Point is that this component or group making is not necessary in FSDS to reach the same result.
Of course, I still do prefer SU when it comes to making static and simple models as SU is simply faster and easier to do and involves less 'operations'.

 

[Lane Street]

the difficulty I have in placing the components where they belong.

Maybe I can help with that- http://www.fsdeveloper.com/forum/threads/moving-and-duplicating-elements-in-sketchup.434157/

cheers,
Lane

 

[robystar]

That helps, thanks Lane.