FSX:SE General 3ds Workflow

[hairyspin]

Arggg. I don't have the Slate material editor (I have Max 2008), but don't use sub-materials and use the old-fashioned Material Editor to set up your FSX materials to avoid confusion.

 

[DecoFox]

Arggg. I don't have the Slate material editor (I have Max 2008), but don't use sub-materials and use the old-fashioned Material Editor to set up your FSX materials to avoid confusion.

Interesting. The FSX material doesn't show in the viewport but does in renders. Workable, but inconvenient.

 

[hairyspin]

'Twas ever thus!

 

[Heretic]

Sometimes, it takes a reload of Max 2015 to for a material show up in the viewport.



Slate or legacy editor, you only have to assign your texture to the appropriate map slot and that's it. No sub materials, nothing.

 

[DecoFox]

Now with FSX materials and animated control surfaces. Prop, wheels, and gauges have yet to be animated. Probably going to shoot for the first export tomorrow.

Edit: preliminary attempts have failed due to uncooperative textures (failing to load into ModelConverterX) and export tools (the latter program having trouble accessing XtoMDL). I anticipate both problems being fairly solvable, but I figured I'd mention them in case there are easy fixes I'm not aware of.

 

[DecoFox]

Alright, next stupid question

It turns out the materials not coming across is as simple as the .x export not bothering to export them, which is more or less what I figured. Not sure why it's not, but that's easy enough to work around by making DDS exports manually from photoshop. The issue now is the UV maps seem to be getting broken in translation. Not lost entirely, but broken. If you look closely were the upper skin of the fuselage meets the side there is a visible seam there. That is consistent with the actual unwrap, suggesting the UV is intact.
UV map and The same seam in 3ds, for reference:

Spoiler: UV

The fuselage UV is a 2048, though I tried a 1024 version because the problem looks like a scaling issue. I didn't notice a difference though. Note that I am using the most recent dev release of modelconverter, as the most recent stable throws a same-key error when attempting to import the model.

 

[hairyspin]

First question: did you flip the texture vertically before saving as .dds? If you're using PS with the nVidia plugin there's an option to do that automatically. Next thing is does your texture overlap the seam edge by a few pixels? Exact pixel-for-pixel painting at the edges tends to show an unpleasant edge in FS.

Good to see you're getting an export going from Max 2017.

 

[DecoFox]

First question: did you flip the texture vertically before saving as .dds? If you're using PS with the nVidia plugin there's an option to do that automatically. Next thing is does your texture overlap the seam edge by a few pixels? Exact pixel-for-pixel painting at the edges tends to show an unpleasant edge in FS.

Good to see you're getting an export going from Max 2017.

...huh. Yeah I probably never would have figured that out. Glad I started this thread, really would have been an uphill battle without it.
Out of curiosity, why? Seems like a pretty odd formatting detail.

 

[hairyspin]

It's a peculiarity of DirectX, something to do with the rendering engine as it's used in DirectX titles. Oddly, I haven't yet found where in the SDK we are told to flip textures when saving to .DDS – it may be the early FSX developers had a look at the stock models' textures and discovered this to be the case.

 

[DecoFox]

It's a peculiarity of DirectX, something to do with the rendering engine as it's used in DirectX titles. Oddly, I haven't yet found where in the SDK we are told to flip textures when saving to .DDS – it may be the early FSX developers had a look at the stock models' textures and discovered this to be the case.

Yeah, haven't seen it in there anywhere. Speaking of the SDK, my present objective is a good chrome effect on the prop spinner and exhaust. I think I've got a handle on how the spec maps work, hence how I got the nice yellow sheen on the brass prop leading edge, but I haven't figured out reflective chrome (that or it just doesn't do anything outside of FSX because cubemaps)

Both surfaces have taken a shine, but what I'm really after is this

(My current material settings matching the SDK explanations of chrome, and the textures as suitable as I've managed to figure them. I'm using the same example cubemap.)

On the same note, I'm not totally clear on how fresnel ramps work or what they do. What I've gathered from the SDK suggests they're a sort of global bumpmap for reflections, determining how intense they appear based on incident angle. I understand the grayscale gradient provides an alpha value to the reflection and am assuming the distribution of the gradient provides the incident angle part of the equation, but I can't find any explanations as to how the gradient and incident angle actually relate, or why specular color/specular mapping isn't redundant to fresnel mapping.

 

[DecoFox]

Alright, after a few attempts, I've managed some mixed success:

Very mixed.
Problem A: For whatever reason the lighting and normals look terrible in the sim, bearing little relation to their appearance in ModelConverterX and certainly not to 3ds. I find the disruptions towards the aft of the fuselage the strangest, as a study of the MCX render will confirm the normals there are perfectly fine. I suspect the half-shadow has something to do with the fuselage employing the symmetry function, but that was collapsed into the object tree before export so I'm not sure why it would matter now. Though this symptom resembles wonky normals as well, both MCX and 3ds show no such faults.

Problem B: While the model is happy to display in the preview, it still throws a Visual Model Could Not Be Displayed error, and fails to render in the actual simulator. If I had to guess, I'd wager that one or both of these problems has to do with the degenerate polygons reported by the export log. Unfortunately I have no idea what those are or what to do about them. The issue may also arise from my using a dev release of MCX, but given the work is done by the batch file, I doubt it.

Spoiler: XML Header

<FSData version = "10.0">
    <FSModelData version = "9.175">
        <Header>
            <CreationDate>4/25/2017 12:00:00 AM</CreationDate>
            <ModelVersion>10.0</ModelVersion>
            <FriendlyName>isake_vajah</FriendlyName>
            <ModelGuid>{502789af-bd7c-495d-a54a-9cfce2aedf33}</ModelGuid>
        </Header>
        <ShadowMapReady>FALSE</ShadowMapReady>
        <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
        <!-- Exterior model -->
        <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
        <Exterior>
            <CrashTree><BoundingBox X="-5.95785" Y="-2.95334" Z="-4.27993" W="11.9162" H="4.24026" D="8.680429" />
<Nodes Count="149">

Event Log:
https://pastebin.com/embed_js/E6hXNrxp
(text limit)
Note that "eels" is a generic name referring to the gauges. The SketchUp import to 3ds max had some issue with naming for some reason, and I ended up batch renaming the lot of it to solve the problem. Everything has been renamed and grouped appropriately except for the gauges, as they only need to be static props in the 3d model.


Some other notes:

• The model has open edges, namely on the window glass (layered planes as opposed to full boxes), and the export verification tool claims the fuselage has them as well, though there's no reason it should and for the life of me I can't find any. I don't think this is an actual problem because, IIRC, I've seen plenty of models that aren't technically solid in every respect.
• The verification tool throws errors with respect to scale, but the objects it marks all have 1,1,1 scale, even according to the verification tool. I've worked under the assumption that it's either just triggering false positives or the faults are too insignificant to be noticeable. I'm guessing the scale issue has to do with the positioning of rescaled models, as I've run into similar problems exporting for other programs.
• The verification tool throws a lot of errors with respect to insane texture vertices. I believe this is because I left some backfacing polygons that would never be seen out of the UVs they belong to as a method of saving space. I have no idea if this is a problem or otherwise bad habit, just that I've been able to get away with it elsewhere. This is one of my bigger suspects at the moment.
• The verification tool throws a lot of errors regarding co-located verticies, and throws them for every mesh in the model. There is no reason for them to be there, I've never encountered them while working at the vertex level, and running the tool's autofix script results in the welding of verticies that are definitely not co-located. I suspect these are false positives.
• The verification tool also throws errors with respect to repeating object names that aren't repeating as well as some that are, and friendly name/guid directly after generating both. These observations give me some confidence the others may be false positives as well.
• Some repeating object names exist at all, in the form of gauges in cluster hierarchies. I plan to sort out actual animated 3d gauges only in the VC.
• The verification tool hits on a lot of empty objects that once existed in the model (presumably something to do with the SketchUp export. Odd, but not really problematic), that I have long since gone through and systematically deleted. According to the hierarchy, they are no longer there.
• I'm only running one LOD at the moment, which I would think is fine for a non-AI aircraft, at least for the time being.

I suspect this has to do with the inspection script not liking 2017, but it's also possible I've got something wrong in the hierarchy that's making it angry. Just in case, here it is

Spoiler: Hierarchy

 

[ErickC]

It's hard to see from your preview shot, but there's a spot on the aft fuselage that looks less like screwy normals and more like screwy smoothing, as if your model has duplicated, unwelded vertices. I'd weld everything within .001-inch or so before exporting to be certain.

-Could your open edges be where the fuselage halves join, since I presume this is how you used the symmetry modifier? My experience with 3DS is brief, so bear with me, but did you weld your vertices when you collapsed the mesh? Actually, your two fuselage halves are a single, collapsed part, right? I presume that the symmetry modifier mirrors geometry within a part, as opposed to being like a mirrored instance. I swear it looks like the end result of using the mirror button and not attaching the mirrored part.

-You could try solving the scale issue by resetting the scale of every part. You're lucky you're not using FS8 or 9 and makemdl: it would have never exported in the first place.

-If you have polys that can't be seen, why are they there? Optimize, optimize, optimize.

-If my suspicions are correct, you probably have a lot of colocated vertices.

-If the gauge parts all have the same name (as it appears in your log), then those are your duplicate names.

-No clue on the nonexistent objects - you may want to try creating a new scene, and merging your objects into it (this has the secondary benefit of only importing materials that are used, if you have some unused ones lying around). If it doesn't do anything, oh, well. If it does, however, you may want to proceed from there, and, of course, you'll need to re-tag everything...

-LODs on "hero" models are mostly a waste of time, so I wouldn't worry about that. I consider aggressive LODs to be an important part of any AI model, however...

 

[Paul Domingue]

You named your problem when you mentioned the degenerate polys. A degenerate poly is a poly with only two vertices. Select and hide normal polys in the area until you can view and delete the degenerate. It will appear as an edge but highlighted as a poly. That is why they are so hard to see because they hide behind an edge.

 

[DecoFox]

It's hard to see from your preview shot, but there's a spot on the aft fuselage that looks less like screwy normals and more like screwy smoothing, as if your model has duplicated, unwelded vertices. I'd weld everything within .001-inch or so before exporting to be certain.

-Could your open edges be where the fuselage halves join, since I presume this is how you used the symmetry modifier? My experience with 3DS is brief, so bear with me, but did you weld your vertices when you collapsed the mesh? Actually, your two fuselage halves are a single, collapsed part, right? I presume that the symmetry modifier mirrors geometry within a part, as opposed to being like a mirrored instance. I swear it looks like the end result of using the mirror button and not attaching the mirrored part.

-You could try solving the scale issue by resetting the scale of every part. You're lucky you're not using FS8 or 9 and makemdl: it would have never exported in the first place.

-If you have polys that can't be seen, why are they there? Optimize, optimize, optimize.

-If my suspicions are correct, you probably have a lot of colocated vertices.

-If the gauge parts all have the same name (as it appears in your log), then those are your duplicate names.

-No clue on the nonexistent objects - you may want to try creating a new scene, and merging your objects into it (this has the secondary benefit of only importing materials that are used, if you have some unused ones lying around). If it doesn't do anything, oh, well. If it does, however, you may want to proceed from there, and, of course, you'll need to re-tag everything...

-LODs on "hero" models are mostly a waste of time, so I wouldn't worry about that. I consider aggressive LODs to be an important part of any AI model, however...

You were right about the fuselage, but curiously correcting it didn't solve or even noticeably affect the lighting problem. I was eventually able to get it to render in sim and not throw a model display error, however.

Ignore the propstrike (it's backwards), and the godawful resolution (FSX rigged for VR).

I've noticed a few things, namely that, in sim, the seam responds very little to changes in lighting or viewing angle. That right half is always darker and seems to have a strangely aliased bumpmap on the main fuselage, but this reverses on the face of the cowling (with the light, correct side now on the side that's otherwise broken and aliased) and towards the empenage with the same pattern. According to the verification tool the co-located vertices have been corrected and the fuselage is no longer open-edge. Any latent problems with either of those effects have also been fixed on all objects except the gauges. Export no longer throws degenerate poly errors (though import does refer to deleting zero-area triangles. Not sure what that's about). It also seems that the fuselage (on both sides) displays without smoothing groups, which I find strange given the wings don't have this problem. The behavior may be related to specular mapping though; I have to experiment with that some more.

What's strangest to me is that this is all with a mirrored fuselage. Both sides use exactly the same single-side texture map. When I discovered the seam I was certain that was the problem, but it doesn't appear to have changed anything. I have some ideas yet though. Might this have something to do with running 2048 dds files? I recall seeing something about a 1024 limit in the SDK, but the wings are also 2048 and display fine.


Edit: I've confirmed the lighting problem is with the spec map specularity of the model in general. I have only been able to do away with the issue by exporting the model with specular maps and then deleting the specular maps. Running the specular modifier without maps still produces the issue. I am using specular materials with the same settings on the wings, so my current theory is that the interaction is between the specularity and the bumpmap.

 

[Heretic]

Bump maps have to be produced by ImageTool to work well in FSX. See here:

http://fsdeveloper.com/forum/threads/beware-the-bump-maps.56595/

Even if it won't fix problems, it'll at least narrow down the list of suspects.

 

[DecoFox]

Bump maps have to be produced by ImageTool to work well in FSX. See here:

http://fsdeveloper.com/forum/threads/beware-the-bump-maps.56595/

Even if it won't fix problems, it'll at least narrow down the list of suspects.

Thank you so much, you nailed it. I really should have caught that issue but to be honest I glossed over the bumpmap section because they were coming out okay in MCX. The problem isn't completely solved, but the straight up broken lighting is gone and everything looks ten times better, considerably closer to its appearance in 3ds max. The last problem seems to be split lighting across the cowling taper and front, as if the depth mapping is being reversed on one side. I suspect this has to do with my using the wrong neutral color; I'll update if I figure it out.

Edit: I've traced the issue to the polygonal seam between the halves. Though the two halves are no longer technically halves, since they were mirrored there are still two coplanar polygons where theoretically there could be one. I modeled with the mirror in interest of UV symmetry and am not particularly keen on rebuilding the UVs more or less from the ground up anyway, so I just yanked the bumpmap off the front of the cowling and edited the cowling lip bumpmap to end just before the seam in a manner that resembles a flat tab affixed with screws. It actually looks slightly better that way anyway. I've also down-scaled the model slightly, special thanks to ErickC for his post in another thread about how to cheat a little on that. Shifting attention to getting the contact points right, then I'll either jump to VC or performance.


Edit 2:
Wheel contact points in, she's now made her first flight between Miami NAS and somewhere adjacent I didn't bother to identify.

Spoiler: Vanity Shots

 

[Heretic]

Congratulations. All you need now is two Kerbals in the cockpit (bonus points for names straight out of KSP's Kerbal generator on the flight suit). Or some kind of stereotypical ace pilot figures.

 

[DecoFox]

Congratulations. All you need now is two Kerbals in the cockpit (bonus points for names straight out of KSP's Kerbal generator on the flight suit). Or some kind of stereotypical ace pilot figures.

Thanks. Diving into airwrench; any advice on dual lifting surfaces that aren't technically biplane? I'm guessing I can just rig it as a biplane and offset the lower wing to the aft, though I'm not certain that would cooperate with the elevator setup. Any general tips?

Edit: This is what I've come up with so far

Decent approximation of the shape, and true to the dimensions (according to 3ds max and some square meter to square foot math. Only problem:

DRAG.

Don't get me wrong, this would definitely be a draggy airframe, but I have a lot of trouble believing it would be THIS draggy. Right now it flies more like an obscenely maneuverable airship with the glide performance of a parachute. I've found that the drag is at least somewhat tied up in the efficiency factor, but as it stands I'm just emulating the efficiency factor of real aircraft from that general era and style. It seems very odd to me that induced drag would be quite this cruel, especially given my surface area and span quantities aren't nearly, say, Jenny surface area and span quantities. I know aspect ratio is important, but while my numbers there aren't great, they aren't that absurd either.

It might be worth noting that the files I used as the basis for this were originally from the cub

 

[Heretic]

While having an interest in flight dynamics, I my knowledge is too limited to help you with that, so it might be best to ask the experts in the FDE forum:
http://fsdeveloper.com/forum/forums/flight-dynamics.65/

You can try to use OpenVSP to create model of your aircraft for aerodynamic analysis and it will spit out values for use in .air files.

But beware: FDEs and OpenVSP are their own brands of science. Bring your reading glasses and time!

 

[hairyspin]

Read the manual for AirWrench thoroughly. Thoroughly.