Jump to content
Sign in to follow this  
n4gix

FSX model display problems

Recommended Posts

Guest paulmack

I have created a highly detailed model of the Concorde for FSX using MAX7. The interior is about 72,000 polys and the exterior is 70,000.The model compiles without any serious errors and loads into the sim. The problem is it does not display correctly and most of the animations do not work. Textures are missing and don't display correctly, and many pieces are invisible yet their shadows actually display! Wheels don't rotate, doors don't open and nothing in the interior animates. The problem does not lie in assigning animations or textures. I have concluded it must be a size thing. The only possible related message I get during compilation is 'index buffer exceeds maximum size'.So my question is - how big can the model be (exterior and interior) before things like this happen? It seems that texturing affects it also. If I remove almost all the textures, most of the missing parts appear, but the animations are still incomplete. Thanks for any knowledgeable help.

Share this post


Link to post
Share on other sites

OK I'll try to shed some light here, but first I'm curious as to how you created a 140,000+ polygon model and are just now wondering why things don't work. Let me rephrase: Had you only just now tried to compile your model for the first time? If so, how can you create a model, especially one that large, without first having done dozens of compiles to see how things were progressing?What I'm trying to get at here, is why this issue just now cropping up for you. Unless you're using the term "create" loosely, and are really just having trouble getting an imported mesh to compile? Nothing wrong with that of course, but it just boggles my mind that you'd be asking these things now, having just "created" a 140,000 polygon model:) It's been a long time, but I personally wanted to see how things looked at LEAST after the first lowly 10,000 polygons or so...Generally when you're over budget on verticies, you'll get a log entry just as you described - index buffer too large. Why the model actually finished compiling I cannot say.Invisible faces aren't actually invisible if they're casting shadows. Their normals are likely inverted even though they may look perfectly normal in 3DS. This is (or at least was with makeMDL) a bug related to using the mirror tool (from the toolbar). How could this bug have existed for so long when clearly aircraft are so perfectly suited to mirroring? Ask MS. The solution is to use a mirror modifier instead, and apply at the sub-object level.Animations will also be destroyed by mirroring. Animations need to be done independently for each half, and there was no solution for that (at least in FS9 compiles).Cheers,--Jon

Share this post


Link to post
Share on other sites
Guest paulmack

Thanks for the reply Jon. Let me shed some more light on my situation. The model was created entirely by me from scratch. The external model was done, without any concern for size, for other purposes long before I purchased FSX. Upon purchasing FSX, I observed that the B747 .mdl files total 10.7 MB. Assuming that was probably not the maximum size allowed, I decided to build a detailed interior and convert them into an FSX model. My model, as it now stands, totals 13.9 MB and compiles without any size warnings. There where lots of other problems for me to fix before getting to the missing parts and animation stuff so I continued on. Without any size limits in the SDK documentation and without any serious compilation errors, why not? I now realize the missing animations and invisible parts, are at least in part due to mistakenly thinking that the FSX compiler, unlike the FS9 compiler, could correctly handle mirrored objects. (Are you reading this MS?). However, it would sure be helpful to have some definite limits posted.As a point of interest, I have successfully created about a dozen FS9 models, the largest of which is a 2.8MB mdl file(64,000 polys).

Share this post


Link to post
Share on other sites

Hi Jon,Not to "hijack the thread," but there are two points I'd like to mention that might lead some to erroneous conclusions...>Invisible faces aren't actually invisible if they're casting>shadows. Their normals are likely inverted even though they>may look perfectly normal in 3DS. This is (or at least was>with makeMDL) a bug related to using the mirror tool (from the>toolbar). How could this bug have existed for so long when>clearly aircraft are so perfectly suited to mirroring? Ask MS.>The solution is to use a mirror modifier instead, and apply at>the sub-object level.The solution you've mentioned is absolutely correct. What is less correct is the assumption that the "Mirror Tool" is somehow a "bug" in either Max/GMax or MakeMDL.exe {FS2k2/FS9) or X2MDL.exe (FSX).The key to understanding the difference is really much simpler. The "Mirror Tool" actually mirrors both the object and the object's properties, including normals and animations. The result is precisely what you'd see if you held the object in front of a physical mirror.The "Mirror Modifier" on the other hand, mirrors only the object itself, and does not mirror the other properties of the object. Hence, the normals and animations are not affected.>Animations will also be destroyed by mirroring. Animations>need to be done independently for each half, and there was no>solution for that (at least in FS9 compiles).That is not entirely accurate either. Perhaps you've not seen my latest "mini-tutorial" posted at FFDS: "Mirroring Parts in Max/GMax Perfectly!"http://www.aerodynamika.com/cgi-bin/yabb/Y...?num=1183676822In this document, I describe the process with illustrations, including how to easily mirror the animations precisely by simply changing the sign of the appropriate coordinate(s) x, y, z for both Position and Rotation data.This technique will work for both FS9 "stock" animations as well as FS9/FSX "keyframe animation tracks." ;)Aside from these two points, I fully agree with the remainder of what you've written. :-beerchug


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites

Since you mentioned "texture issues," allow me to point out that in FSX, unlike previous sim versions, a "texture issue" can and does prevent parts from displaying entirely (although the shadow appears)......and also can cause parts to be displaced from their modeled positions, such as having the ailerons and flaps rotated 90


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites
Guest paulmack

Thank you Bill. Now I am convinced it is the textures that are causing most of my display problems. I never came accross anything like this in compiling for FS9 and figured Xtomdl would work the same. I have all the symptoms you mentioned - displaced parts, rotated parts, invisible parts and even a large hole in one part. The question now is, what could be wrong with my textures that would cause things like this? Any ideas? I have a lot of materials, like 70 or 80 and many of them are multi/sub-object. I get warnings like 'at least 1 sub material slot is unused' but of course it doesn't tell me what material that is and I don't know how to find it.

Share this post


Link to post
Share on other sites

>Thank you Bill. Now I am convinced it is the textures that>are causing most of my display problems. I never came accross>anything like this in compiling for FS9 and figured Xtomdl>would work the same. I have all the symptoms you mentioned ->displaced parts, rotated parts, invisible parts and even a>large hole in one part. The question now is, what could be>wrong with my textures that would cause things like this? Any >ideas? > I have a lot of materials, like 70 or 80 and many of them are>multi/sub-object. I get warnings like 'at least 1 sub material>slot is unused' but of course it doesn't tell me what material>that is and I don't know how to find it. UGH! There's a large part of your problem already...RULE OF THUMB #1Never "drag-and-drop" textures on a part in the Viewport! Instead, select the part and the FSX Material in the Material Editor, and then click the "Apply" button. That is what it is for.When anyone does the "drag-n-drop shuffle," Max/GMax will cheerfully create an entirely new Material, or worse a new Multi-Material. In short order, your Material Library will begin to take on the appearance of a Library of Congress card catalog! :-erks RULE OF THUMB #2There should only be one FSX Material for each texture bitmap, unless there's a compelling need for more than one. Period.Obviously there will be some exceptions, but this is a good starting point for a well-organized model.All of the "parts" that appear on one texture bitmap should ideally be assigned to one FSX Material. The only real exception to this might be if a part (or group of parts) really needs to have different FSX Material Properties, such as "no fresnel ramp," or a different emissive source (for lighting).RULE OF THUMB #3Avoid Multi-Materials as far as possible.The only objects that require a Multi-Material as those few (such as a fuselage) that might span two or more bitmaps.Use Multi-Materials only if absolutely necessary. I've found that while Multi-Materials are terrific to use as "tools" while UVW Mapping, once that is done I try to eliminate the M-M if at all possible.RULE OF THUMB #4As far as possible, after you've finished UVW Mapping objects that required a Multi-Material, try to optimize the object to the fewest number of unique sub-materials.What I mean by this is, I've actually seen models where the Multi-Material had as many as 80 sub-materials......and only four unique bitmaps, that seemed to be endlessly repeated. :-eek For example, if you have more than one sub-material that uses "fuseA.dds," then all MatIDs that use that use that same texture should be consolidated. Let's say MatID 3, 15, 18, 22 and 55 all are assigned to "fuseA.dds..."Then all of the polys with MatIDs 15, 18, 22 and 55 should be re-assigned to MatID 3.RULE OF THUMB #5Export selected parts of the model frequently!This will ensure several things; first that there's no colocated or colinear vertices in the part (you can check the log file), there are no mis-aligned or flipped normals, and finally, there are no errors that will present a compiling problem.RULE OF THUMB #6UVW Map objects and create the "Master Mesh Bitmaps" as you are modeling!Frequently the modeler will find and fix errors before they become a problem. Completely aside from which, there's a real "kick" to seeing your model textured in Max/GMax as you work. It may well be that you will find that you can use texture for detail rather than having to actually create a 3d mesh for a part.------------------I hate to say this my friend, but you've got a LOT of extra work ahead of you to get this model optimized and compiled successfully.Well, at least something positive will come from this! I can post these six "RULES OF THUMB" at Freeflight Design in the "Tips" forum! :)


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites

Hey Bill,>The "Mirror Tool" actually mirrors both the object and>the object's properties, including normals and animations. The>result is precisely what you'd see if you held the object in>front of a physical mirror.I understand what you're saying about the mirror tool "mirroring" the normals. But it's not "flipping" the normals (at least not in the viewport). Why then do they appear "flipped" (inverted) as well as mirrored once exported. For example if I were to take that same mirrored object and export it to pretty much any other 3D app, it would have correctly aligned normals. It just seems like a bug to me that they're exporting with their faces inverted when clearly they are not inverted in the scene. The animations I can completely understand, since, as you say, the axis is mirrored as well.>>Animations will also be destroyed by mirroring. Animations>>need to be done independently for each half, and there was>no>>solution for that (at least in FS9 compiles).>>That is not entirely accurate either. Perhaps you've not seen>my latest "mini-tutorial" posted at FFDS: All I can say is, I wish I'd seen it about 3 years ago when I was painstakingly doing it by hand:) I can remember scouring the internet for days wondering how this could possibly so...Anyway great tip, and I stand corrected (as usual).Cheers,Jon

Share this post


Link to post
Share on other sites

>I understand what you're saying about the mirror tool>"mirroring" the normals. But it's not "flipping" the normals>(at least not in the viewport). Why then do they appear>"flipped" (inverted) as well as mirrored once exported. For>example if I were to take that same mirrored object and export>it to pretty much any other 3D app, it would have correctly>aligned normals. It just seems like a bug to me that they're>exporting with their faces inverted when clearly they are not>inverted in the scene. What is happening is that the normals of the "Mirror Tool(ed)" faces have their origins shifted to the opposite side of the faces, but their directionality is inverted as well (it appears as a negative number in exported mesh file). In the Max/GMax Viewport the normals appear - well "normal" - but as I said their origin has been shifted to the opposite side of the face.The FS graphics engine however, will take the 'negative sign' on the normal literally, and hence the object will appear "inside out" in the sim when drawn.>All I can say is, I wish I'd seen it about 3 years ago when I>was painstakingly doing it by hand:) I can remember scouring>the internet for days wondering how this could possibly so...Jon, I wish I had taken the time to develop the technique about three years ago! It would have saved me a lot of headaches as well! ;)Every once in awhile, I will set aside a day of "paying work" and devote it to working out some particular problem to develop a simple solution that may be applied consistently and uniformly be anyone.


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites
Guest paulmack

Thanks Bill for the 6 rules of thumb for texturing FSX models. I am guilty of not following all but 1 & 2. Unfortunately, my original texture maps where not done with FSX in mind. All my models are imported from an older 3D app as textureless .3ds files and GMAX/3DSMax 'thoughtfully' assigns a material to every single part!In GMAX there is a way of actually deleting materials, but for some unknown reason, you can't in 3DSMax 7. It would make things much easier if you could.You are right, I have a lot of work to do to get my Concorde model working and displaying right. Live and learn!

Share this post


Link to post
Share on other sites
Guest Patrick_Waugh

You can delete (remove) materials from parts in Max. Click on the tab for scripts and then More... and it's in there.

Share this post


Link to post
Share on other sites

>Thanks Bill for the 6 rules of thumb for texturing FSX>models. I am guilty of not following all but 1 & 2.>Unfortunately, my original texture maps where not done with>FSX in mind. All my models are imported from an older 3D app>as textureless .3ds files and GMAX/3DSMax 'thoughtfully'>assigns a material to every single part!Ah, Max/GMax "trys" to be helpful, but typically ends up creating a mess...>In GMAX there is a way of actually deleting materials, but for>some unknown reason, you can't in 3DSMax 7. It would make>things much easier if you could.As Patrick points out, there is a script in Max that will do that for you.BTW, as a useful "tip" for cleaning up a project from deleted and unused Materials...Save your scene to an incremented file (use the "+" button unless you have "Autoincrement" enabled), then click the "New" button to revert to an empty scene. "Merge" your saved scene file into the empty scene, and only the "active & used" Materials will be present... ;)>You are right, I have a lot of work to do to get my Concorde>model working and displaying right. Live and learn!>


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites
Guest paulmack

>You can delete (remove) materials from parts in Max. Click>on the tab for scripts and then More... and it's in there.>So it is, thanks! Don't know how I missed that (maybe because it's not mentioned in the user reference.) :)

Share this post


Link to post
Share on other sites
Guest Patrick_Waugh

Bill,Can you expound on your rule of thumb #3? What is the rational for avoiding them? I'm also not sure at all why one would need a mult-material for a part like a fuselage, even if you had it span more than one texture. Only thing I can think of is that you used the mult-material in that instance to "divide" up the fuselage with material ID's to make it easy to UVW map.Great post.Patrick

Share this post


Link to post
Share on other sites

>Bill,>>Can you expound on your rule of thumb #3? What is the>rational for avoiding them? I'm also not sure at all why one>would need a mult-material for a part like a fuselage, even if>you had it span more than one texture. Only thing I can think>of is that you used the mult-material in that instance to>"divide" up the fuselage with material ID's to make it easy to>UVW map.That's quite simple, actually. You simply can not have more that one bitmap assigned to any single mesh object, except by using a Multi-Material......and, you cannot use a Multi-Material without also using Material ID numbers to "sub-divide" the mesh into two or more discrete areas of coverage.All of the enumerated "Rules of Thumb" are interrelated; none of them stand in isolation.The overall goal of any project should be to use only the absolute minimum number of bitmaps, as well as the absolute minimum number of discrete Materials/sub-Materials.Also, bear in mind that with FSX, there has been a slight - but profound - paradigm shift in priorities. Where in the past the most emphasis has been on "poly count" or more accurately "triangle count," beginning with FSX the total number of "vertices," which includes both the mesh itself and UVW vertices is actually the critical point of consideration.Quite obviously then, the greater the number of Materials used (and corresponding UVW vertices), the higher the total vertex count for any given project climbs.Adrian Woods publish a paper on this some months ago, but I'm afraid that it has largely gone unnoticed by the vast majority of FS modelers... :-hmmm :-hmmm :-hmmm http://blogs.technet.com/torgo3000/archive...n-t-matter.aspx


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...