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

FS2004 Canopy fun

Messages
349
Country
unitedkingdom
Okay, next model, the RV4. Time to experiment with cockpit transparencies.

I managed to get the cockpit glazing to work with the fuselage (not allowing us to see right through the aircraft), so that's not the problem. However when I look at the canopy in-sim I see what look like "glass floors in a glass building", a strange effect. It's almost as though there are polygons between nodes on opposite sides of the canopy. Look down through the canopy and they disappear, but as the angle decreases towards looking sideways through the canopy (edge-on to these "floors") they become more obvious?

I've not found mention of this on the forums, so I assume I've done something fundamentally stupid here!

I created the canopy from a cylinder that I massaged using the "non-uniform scale" tools, and when creating it I also made a slice to lose lower polygons, but that's all.

So, if anybody knows how to get rid of these glass floors, please sing out!

 
Last edited:
Anyone that stood up can stand down now!

I'd been using double-sided textures for the canopy. Renaming the material brought the canopy back to be floor-less, if not flawless. Never seen that one before.
 
Spoke too soon. Although that fix works, I spotted another error rendering in-sim. The left flap is masked out through the canopy, it becomes invisible, whereas the right flap is okay all the time; in fact everything shows through the canopy except the left flap ...

Ugh, its late, I quit!
 
Make sure that your canopy material is a little less than 100% opacity, that sometimes helps.
 
Make sure that your canopy material is a little less than 100% opacity, that sometimes helps.

Thanks, Tom. It may come to that after I've explored the naming options. For some strange reason the right flap is okay but the left one isn't. I just now cloned the right flap and made a new left flap from it, and it was still masked out. The alpha transparency of the canopy is causing the effect, but only on parts with particular names (!) but I even renamed the left flap as r_flap_01 and it still plays up. I might bring up one of my incremental saves and see what it was like "way back when" - it could be that it was there all the time and I didn't notice it, but I certainly seem to remember it being there previously. Project's been nibbled at for 2 weeks now, and I'm up to 76 incremental saves, so there must be a good one in there somewhere...

I'm reticent on a new material for the canopy because this is an AI plane.

Edit: Tried the opacity setting to no avail. Still can't figure out why one flap is okay and the other isn't. They are clones, so the only difference is the name and that fact that one is mirrored (4 degree dihedral).
 
Last edited:
Make sure you use the Mirror modifier on the stack and not the Mirror button at the top of the screen.
 
I always use the stack version of mirror, so the mirroring in this case isn't the source of the problem so far as I know, although the fact that one behaves normally and the other doesn't does lead me to wonder.

I made some images, although they don't really say much more than the words I've written so far. In the first, the left flap displays fine, and in the second the right flap doesn't (you can see the shadow of the wing (& flap) on the ground).




I've tried many things to get around this problem now, renaming materials to try to influence drawing order, attaching various parts to various other parts. Grouping the conflicting parts and separating them by their names to try drawing them separately that way (although Arno posted a while ago that drawcalls that are exactly the same settings and texture are aggregated).

I went back to an earlier version and re-did the canopy clone/extrude/invert normals procedure (and got that to work without having to attach the inner surface to the fuselage as I'd needed to previously).

I thought about other AI models that have decent transparencies and no occluded parts such as flaps, an AI Chipmunk and Tucano, but discovered that they all use extra textures (which I know would work but which'd also add a drawcall). An option I could use (since I create an extra drawcall for the prop anyway) is to somehow combine the prop and canopy into a single BMP - but after that effort I'd probably end up with the prop occluding the canopy instead.

What makes it so horribly frustrating is that one flap is perfectly okay! I want to ask it "what's your secret, then?"

I have to admit this whole process is getting me down now. I'm trying hard to keep the load on the sim as light as I can, and every solution really just degrades what efficiencies there may be. Still, ultimately it has to look right, so it may come to the combined prop and canopy approach, which is also a compromise but at least doesn't hit performance.
 
Last edited:
End of the "developing" day, and the canopy problem seems to be fixed. The trouble is I don't know how. I was awake a 3am thinking about the canopy, finally got up at 5 to start pecking away at the problem, took breaks throughout the day to do house decorating (power sanding is normally a horrible chore, and today it was a welcome release from Gmax-drudgery), gardening, local errands, the trivia of life away from the computer. Went back to Gmax and rejigged the model for the umpteenth time and suddenly, "two flaps and a canopy", starring Huge Grant. No holes in the fuselage, no missing crew, just an RV-4 that wasn't looking moth-eaten. Gawd knows how that happened, but I'm glad it did. Now onto the disappearing crew trick - shazzam.

FYI, the inner canopy is attached to the fuselage and the outer one left separate, and it seems to be fine. The worry is that I'm sure I've already done this, meaning that it might just decide to undo itself on the next compile.
 
I figured out what I did to fix this, the trouble is that the answer won't really help anybody because it almost certainly varies per-project.

I was gathering together a bunch of small objects that will be part of LOD100 and I grouped them into an umbrella group, so instead of about 8-10 small objects I could just select one thing and remove it when working on lower LODs. The act of making that group and recompiling fixed the problem with the invisible flap. :confused:

And I thought women were inscrutable.
 
Groups? Ack, baad! Use Named Selection Sets instead. Well, I do - see sticky at top of Modeling forum; avoids a number of group-related problems
 
Well, the problem is that it solved my problem!

If it did that by gathering all the names together under one name, and a selection set doesn't do that, then it might actually be the best option. Does a named selection set make the items in the set disappear under one name in the objects list?

Presently I'm considering giving groups a great big sloppy kiss.
 
Does a named selection set make the items in the set disappear under one name in the objects list?

No, selecting a Named Selection Set will simply select all the objects in the set. Any of these objects which are hidden or frozen will be unhidden or unfrozen at that time. What you do with them after that is up to you!

I have a number of these sets on my model's VC: I might select the joystick set, invert the selection and Hide Selected - result only the joystick set is left visible. Or I might have everything hidden and selecting the throttle quadrant set will select - and unhide - all the objects in that set. Hugely useful when mapping or just reviewing sections of the model.

This pays huge dividends when making LODs: each LOD's objects are part of a named set and a full LOD's parts can be called up from a simple selection of the particular set.

And no OBED scaling errors on export - a known problem when messing with groups.
 
I believe it is the disappearance of the objects into the group that saves my situation, so selection sets wouldn't have worked for me in this instance.

Since I work only on very simple AI models I think grouping subsets of the model would be overkill for me, so selection sets aren't a natural choice when you have only a couple of dozen parts in total, perhaps up to 40-50 on a complex model (!).

I grouped the top LOD minutiae really just to clear out the list of objects by taking away from sight the names of all those parts that had been completed to my satisfaction (things like aerials, pitots, seat backs, gear-body fairings etc) so it is just an admin exercise, or was, until I realised that my occluded flap problem goes away when this group is set up and reappears when it isn't. After that it became mandatory. Goodness knows why it fixes the problem, I'm just glad that it does because this tiny project has been jinxed a few times where more complex ones have been problem free.

I get the occasional scaling error if I group-ungroup often enough, but they are very rare and easy to correct.

Once I'm happy with a particular LOD of an aircraft I again group it as something like RV4_LOD_100, RV4_LOD_085 or whatever and leave it alone, selecting all these LOD groups to export my LODed aircraft. Its pretty rudimentary but it works.

By the way, any particular reason you select a selection set, invert and "hide selected" rather than picking a selection set and "hide unselected"?
 
By the way, any particular reason you select a selection set, invert and "hide selected" rather than picking a selection set and "hide unselected"?

If you happen to have some objects "pseudo-hidden" in the Freeze area, "hide unselected" will also move those frozen objects to the "Hide" area...

...which may not be what you want!

BTW, you can avoid any OBED scaling issues once objects are Grouped simply by never again Ungrouping them!

Use Group Open/Close instead... :D
 
Ah, freeze. The only thing I freeze are the 3-view panels.

I use a very limited repertiore of Gmaxisms, only picking up new ones when absolutely necessary. Consequently I don't explore the options much.
 
I use the "Freeze" area (with objects invisible) as a type of second "hidden area". Sometimes I'll have everything but one family of objects "hidden" and can then use the "Freeze" area to temporarily make all but one single object become invisible...

When I've finished working on that one object, "Unfreeze All" will bring the rest of that family's objects back into view.
 
Yes, I use freeze as an organisational thing too. The 3 views are handy for a while but become less useful, so I hide frozen objects for a while until I'm texturing, when I'll bring them back to check that I'm getting panel lines in the textures at the right places - because AI have animated flaps/slats but traditionally ailerons, elevators and rudders are just drawn on, hence the reference lines becoming useful again for a short time.

Once the drawing side is done the 3-views are dropped entirely (since I do many incremental saves there's always a version somewhere that I can use to merge them back in should it become necessary - it never has so far).

For making models with comparatively few parts, such as AI, there quickly comes a point where I could become over-organised. I also tend to branch development if I need to experiment, working on a steadily incrementing version number for the source file until I need to learn something new that might not necessarily be used in the final model, then I'll use filenames to indicate a branch that either comes back into the main development sequence if the experiment works, or results in a jump back a few stages to the last version saved in the main sequence if it doesn't. In my software dev life, I used to work within configuration control systems a great deal (I even wrote one many years ago), so although my approach is pretty informal, it does have rules.
 
I use a very limited repertiore of Gmaxisms, only picking up new ones when absolutely necessary. Consequently I don't explore the options much.

I'm most of the way through a VC and the more Gmaxisms I can learn the more I can do! :rotfl: That's why I 'invest' so much time hanging out here... :o

The select-invert-hide selected is more to do with my set of keyboard shortcuts: we all have our ways of working. :)
 
Last edited:
:) For the things I make, I could really just use a spanner and a screwdriver. Instead developers have this whizzy multifunction tool with myriad addons and flashing lights (lots of those), not to mention a bell and whistle.

If there was something that could accept a series of text inputs where to make a wing you say "NACAxxxx aerofoil, span 11.5 metres, dihedral 4 degrees, flaps (chord80%;span10-45%), ailerons (chord80%;span45-90%);wingtipmitre(lead:30, trail:0)" and some way of achieving mapping through a simple visual interface once the model pops out as expected, I'd jump on it. Unfortunately I was given a workbench for Christmas (thanks, gran) with a thousand arcane widgets to achieve things I will never need to do, some of which compromise goals by complicating the path leading to them, and I accept that's the option with (well, more or less, with some whining and pouting) equanimity.

I have no ambitions for modelling. It's a necessary but painful process that leads to variety in my GA setup.
 
Back
Top