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

P3D v3 Export Issue with 65K Material Limit

Paul Domingue

Resource contributor
Here's an example. I have a bunch of those fasteners that hold down those modular units on a panel on my current project. I started with one, mapped it, then cloned it until I had 30 of them. Now I have a part with 30 elements, and the uvw maps are stacked on top of each other. I make the part an editable mesh and type "getnumtverts$" into the listener window and it reports 3000 texture vertices (total polys are 5460). Now I weld all the common vertices in the uvw editor and when I re-check the number of texture vertices I get 100!
Now that's something I didn't know. So I would select all the cloned objects (for instance my flap ribs you may remember) and add a Unwrap UVW modifier and in the editor weld the overlaid/stacked vertices. Is that correct?
 
The key is that they must be one part. You would take one of the ribs and attach all the others. Then weld the UVW vertices.
 
http://www.fsdeveloper.com/forum/threads/export-issue-with-65k-material-limit.436789/#post-738800

I seem to remember talk of this a longgg time ago and the gist was FSX doesn't support this. Arrimus says some games do, but best to ask Lockheed-Martin if P3D does.

I also remember Mathias of Classics Hangar saying he kept the vertex count per material down around 20K so he could apply all the options – diffuse, specular, bump – without running foul of FSX's 65K texture vertex limit. Might have to do the same for P3D yet.
Hi again:

It took some searching to find these previous threads citing the fact that many (~3-to-4x more per material ?) Texture Vertices (aka "T-Verts") may 'initially' be incurred when applying multiple materials on a 3D model (which IMHO underscores the importance of utilizing "Smoothing" wherever possible to minimize adverse run time rendering performance impact related to "T-Vert" count (sometimes still ascribed to "Poly" count based on IIUC, legacy FS information and concepts):

http://www.fsdeveloper.com/forum/threads/misaligned-textures.434275/

http://www.fsdeveloper.com/forum/threads/triangles-vertices-and-drawcalls.434086/

Of particular note, IMHO, is the explanation posted on the importance of 'welding' T-verts, duplicating Materials, and Drawcall Batching in ACES' Adrian Woods' (aka "torgo 3000") Blog:


NOTE: Because bad things can happen to good information (IMHO, crucial to the FS knowledge base) when MS decides to delete online content incidental to distancing themselves from support of the FS product line while trying to sell other product lines and/or services via existing online storage servers (...as they pursue their seemingly perpetual "Google Envy"), I'm quoting the entire Blog article cited below:


"Performance Art 3: Polygons don't matter.

torgo3000
19 Jun 2007 4:14 PM
As next gen technology came online, people started repeating this mantra: "Polygons don't matter anymore." For the longest time (okay, about a week) I was stuck thinking, "Awesome, we can throw any amount of geometry at the new cards and they'll just handle it. Sweet!" The part that the infamous "they" left off of that Mantra was: "...vertices do!"

So polygons don't matter anymore. That is absolutely true. However vertices do. They matter absolutely. Here's a handy little excercise to see what I mean by this. Open up 3ds Max or Gmax (or follow along in your mind). Create a box. Convert it to an editable mesh and apply a UVW Unwrap modifier. Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener window. In the listener output window, you should see the number 8 appear. That means it has 8 texture vertices. That makes sense, 8 physical vertices and 8 texture vertices, right? Now apply a UVW Map modifier to the box and choose "face" as the mapping type. Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener. You should now see the number 36 appear in the listener output. Huh? 36 texture vertices on a simple box? This is because any texture vertex that is not welded gets duplicated. That happens in the game as well. It also happens for shading groups. We do do some optimization and welding when we convert the geometry to a model, however any hard edge in the UVW Mapping will always cause a split in vertices.

So what this means is that even though your polygon count may be low, your vertex count may be sky high. Like I said, we do optimize pretty heavily on export, but we can't catch every case and if the model is authored poorly from the start (completely unique texture vertices for all the faces for example) you can wind up with four times as many vertices as you intended.

So why does the vertex count matter? Well, because all of the geometry is put onto the graphics card via vertex streams and vertex buffers. A vertex buffer is basically 64k, which translates to ~64,000 vertices stored per buffer. Every buffer is a single draw call. Sometimes we fill the buffer up all the way, sometimes we don't (bad batching). However, let's assume the best case scenario and imagine that we are batching everything perfectly. We create a building that we wan't to appear in a scene 1,000 times. That building has 1000 polygons. Okay, that's a little high, but not bad for a high-detailed model. But due to poor modeling, UVing and smoothing, the building actually has 2400 vertices in it. 64,000 / 2400 = 26 buildings per draw call. 1000 / 26 = 38.4 or 39 draw calls for those buildings. Even though it's a perfect batch and a perfect scenario, we still require 39 draw calls for that single building 1000 times. Let's imagine that the building was well authored and optimized and actually only had 1200 vertices in it (a more reasonable scenario). 64,000 / 1200 = 53 buildings per draw call. 1000 / 53 = 18.8 or 19 draw calls. That's a pretty significant reduction. Especially if you have 200 variations of buildings you want to draw (200 * 39 = 7800 draw calls, 200 * 19 = 3800 draw calls). These are all still excessive numbers, but you get the point (and also can see how creating high-polygon models with bad vertex optimization can kill the framerate quick).

So what can we do about this? The first thing to do is author good models. Yes we have our fair share of bad models. As I said, we've got legacy that we just can't update every release, so we chip away at it release by release. Make sure your smoothing groups are used wisely. If it's a rounded object, 1 smoothing group may do. If it's not, try to create as few smoothing groups as makes sense. Also, weld your texture vertices and align and overlap things as much as possible. If you have two faces overlapping in the UV space, make sure the common verts are welded. Also, try to UV things as contiguously as possible. If you are creating a building, create one seam on it and have all four faces lined consecutively on the texture sheet (like splitting a cylinder and flattening it out). If the front and back and sides are identical, then make sure to weld all of the overlapping vertices. Like I said, we do perform some automatic welding when threshholds are close, but if they aren't close in the first place, then we can't weld them.

The second thing to do is batch up parts of models when possible. If you have several buildings with the same window type, batch up those windows with the same texture and the same material. Since they're small in vertex count, they will all likely fit into a single draw call. So rather than have 1200 vertex buildings that cause 19 draw calls, create smaller groups that can batch up smartly. 1 draw call for windows, 1 draw call for doors, 1 draw call for awnings and then 1 draw call for the simple building geometry that is left. As the material batching comes online, this will be much easier to do. But it's good practice to start thinking about this now."


http://blogs.technet.com/b/torgo3000/archive/2007/06/19/performance-art-3-polygons-don-t-matter.aspx

https://www.linkedin.com/in/adrianwoods



PS
: A somewhat related thread in a Sketchup context on reducing 3D model complexity and texture material mapping mentions that:


* FSX reportedly no longer 'requires' one to weld vertices at 4mm mesh intervals:

http://wing-fell-off.blogspot.com/2006_09_01_archive.html

...and:


* FSX compiler/exporter is able to export without mangling mesh with as small an interval as 0.0005 (1/2 mm)

http://www.fsdeveloper.com/forum/threads/misaligned-textures.434275/page-2#post-712851


Hope this info helps with consideration of work-flow and technique in modeling / texturing 3D models for aircraft (...or scenery) ! :)

GaryGB
 
Last edited:
Nice find Gary.

The Vertices on my models do not need welding. This sometimes occurs with bringing models into a scene via OBJ or other formats. They will sometimes come in as triangles. They look fine, but all the Vertices are apart and need welding.

Then, when you apply a bump map, the part 'doubles' its count of Vertices. Evidently the 'system' uses a double of the model for bump mapping. Why, I do not know. So the 64K limit is now closer or busted.

But.... That explains why the 64K limit is there. I didnt know that. Buffers in the Graphics Card system are the culprit and that is why it cannot be broken/surpassed. Dang draw calls and buffer limits.... sigh...
 
Hi Bill:

Can 3DSMAX "bake" a visual equivalent of what a bump map does ...into a Diffuse texture image, then remove the 'source' bump map ? :scratchch

GaryGB
 

hairyspin

Resource contributor
when you apply a bump map, the part 'doubles' its count of Vertices. Evidently the 'system' uses a double of the model for bump mapping. Why, I do not know.
It's easily explained Bill, each mapped vertex needs its mapping information. Add a bump map and each mapped vertex needs the bump mapping information too. And again for specular.

If there are 20K vertices to an object, adding specular and bump as well as diffuse texture means 60K of mapping info – 60K of texture vertices. Robert's UVW vertex welding tip will chop the texture vertex count down by loads – I've tried it...
 

hairyspin

Resource contributor
Can 3DSMAX "bake" a visual equivalent of what a bump map does ...into a Diffuse texture image, then remove the 'source' bump map ? :scratchch
Yes, but it doesn't work quite as well as FSX or P3D's bump map rendering: you get a fixed appearance instead of one which changes with lighting angle etc.
 
Ah, yes ...those dynamic changes certainly would look good for realism with FSX DX-10 / P3D DX-11 cockpit shadows. :cool:

So, IIUC, a subtle Ambient Occlusion (aka "AO") skylight shadow may look OK if baked into a FS Diffuse texture image, but not a bump map. :scratchch
 
Last edited:
So, IIUC, a subtle Ambient Occlusion (aka "AO") skylight shadow may look OK if baked into a FS Diffuse texture image, but not a bump map. :scratchch
Correct. Shading and bump mapping are two different things. Shading versus a 'textured' 3d surface that casts tons of various shadows via a false appearence of raised details, such as a lambs wool seat cover on a 737 seat, or bricks in a wall, fuel cap on a wing, etc.
 

Paul Domingue

Resource contributor
Gary, I meant weighted vertex normals aren't supported in FSX. Sorry for any confusion.
Does this mean that hand manipulation of normals will not have any affect in FSX? I thought weighted normals was using an algorithm to automate what you could tediously do by hand.
 

hairyspin

Resource contributor
Does this mean that hand manipulation of normals will not have any affect in FSX?
I don't think so Paul. I've searched for any mention in the sdk too, but nada.

edit: weighted vertex normals are too modern for FSX. The only game engine of similar age I know of which does use them is Doom 3. Talk of scripting in Max to support this surfaces around 2012 and other game titles which use it also date from thereabouts.
 
Last edited:

Paul Domingue

Resource contributor
I don't think so Paul. I've searched for any mention in the sdk too, but nada.

edit: weighted vertex normals are too modern for FSX. The only game engine of similar age I know of which does use them is Doom 3. Talk of scripting in Max to support this surfaces around 2012 and other game titles which use it also date from thereabouts.
Ok, and from testing I can say that P3D up to v2.5 doesn't support it. I don't have v3 so if someone could test it and report it would certainly be of interest.
 
Gary, I meant weighted vertex normals aren't supported in FSX. Sorry for any confusion.

Thanks for that reply; I believe it is very helpful to achieving a better understanding of the related sub-topics on shading and smoothing groups that, IMHO, necessarily have arisen in this thread, when our discussions include terminology commonly used in the 3D modeling community knowledge base, discussion forums, FS SDK documentation etc. ;)


FYI: Info I believe might further relate to the issues and work-flow under discussion in this thread: :idea:

Weighted Vertex Normals

"weighted vertex normals also allow for faux-rounded edges (smooth shaded beveled edges) without significantly increasing the polygon count, and can greatly reduce distortions of specular reflection highlights and environment mapped reflective/refractive surfaces."

http://www.bytehazard.com/articles/vertnorm.html


Key 3D Modeling Terminology

http://blog.digitaltutors.com/basic-3d-modeling-terminology/


Key 3D Texturing Terminology

http://blog.digitaltutors.com/cover-bases-common-3d-texturing-terminology/


Computing Vertex Normals by Weighting

"This next section discusses two additional techniques that may be used in computing vertex normals. The first technique weights the normals by the vertex angle on each face. The second weights the normal using the area of each face."

"Weighting by area gives an interesting result, but perhaps not as satisfactory as weighting by face angle."

https://knowledge.autodesk.com/sear...0FCB4578-77F8-4F05-99CD-349E85F13639-htm.html


Adjusting Normals and Smoothing


https://knowledge.autodesk.com/supp...FF29D920-7338-4614-8A72-B5C94D47889B-htm.html


TurboSmooth Modifier (3DS MAX)

https://knowledge.autodesk.com/supp...EA8FF838-B197-4565-9A85-71CE93DA4F68-htm.html
  • "TurboSmooth is considerably faster and more memory-efficient than MeshSmooth. TurboSmooth also has an option for Explicit Normals, unavailable in MeshSmooth. See Explicit Normals.
  • TurboSmooth provides a limited subset of MeshSmooth functionality. In particular, TurboSmooth uses a single smoothing method (NURMS), can be applied only to an entire object, has no sub-object levels, and outputs a triangle-mesh object."
"Explicit Normals

Lets the TurboSmooth modifier compute normals for its output, which is faster than the standard method 3ds Max uses to compute normals from the mesh object's smoothing groups. Default=off.

Consequently, if the TurboSmooth result is used directly for display or rendering, it will generally be faster with this option turned on. Also, the quality of the normals will be slightly higher. However, if you apply any topology-affecting modifiers, such as Edit Mesh, above the TurboSmooth modifier, these normals will be lost and new ones computed, potentially affecting performance adversely. So it's important to remember to turn on Explicit Normals only if no modifiers change the object topology after TurboSmooth takes effect."

"Surface Parameters group

Lets you apply smoothing groups to the object and restrict the smoothing effect by surface properties.

Smooth Result

Applies the same smoothing group to all faces.

Separate by Materials

Prevents the creation of new faces for edges between faces that do not share Material IDs.

Separate by Smoothing Groups

Prevents the creation of new faces at edges between faces that don't share at least one smoothing group.

Update Options group

Sets manual or render-time update options, for situations where the complexity of the smoothed object is too high for automatic updates. Note that you can also set a greater degree of smoothing to be applied only at render time, in the Main group.

  • Always - Updates the object automatically whenever you change any TurboSmooth settings.
  • When Rendering - Updates the viewport display of the object only at render time.
  • Manually - Updates the object only when you click Update.
Update
Updates the object in the viewport to match the current TurboSmooth settings. Works only when you choose When Rendering or Manually."


Softening, Smoothing, and Hiding Geometry (Sketchup)

http://help.sketchup.com/en/article/3000097


...And other related info:

http://polycount.com/discussion/85809/face-weighted-normals


Face and Vertex Normal Vectors (Direct3D-9)

https://msdn.microsoft.com/en-us/library/windows/desktop/bb173380(v=vs.85).aspx


ShaderFX Displacement and Tessellation, and Offset Bump Map (Maya; DirectX-11)

https://knowledge.autodesk.com/supp...4B6156D2-C013-487A-83D0-BA14B484845C-htm.html



https://knowledge.autodesk.com/search?search=weighted vertex normal#?sort=score

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


"For scenery welding vertices will in general not reduce your texture vertex count. This is because vertices can only be shared if the position, normal and texture mapping is the same. In many cases the normal is not the same on different polygons for example. In general only if you have smooth objects vertex sharing will really help."

http://www.fsdeveloper.com/forum/threads/draw-calls.23263/


GaryGB
 
Last edited:
Top