Tips and tricks from an idiot savant

[ErickC]

Part I

All right, you've got a bunch of numbers and some drawings of dubious trustworthiness (i.e. no two match). Let's build a wing. Here's the data I came up with:

Root chord 200 inches
Tip chord 50 inches
Semi-span 500 inches

Root incidence +2°
Tip incidence -1°

Root t/c 14%
Tip t/c 13%

Sweep at 25% chord line 25°
Dihedral at trailing edge 2°

Flap leading edge at 75% chord line
Aileron leading edge at 70% chord line
Fuselage at STA 85.000
Flap ends at STA 350.000
Aileron starts at STA 352.500
Aileron ends at STA 480.000

Wing apex at fuselage STA 550.352 and WL 14.000

I started by opening a GMax file called "default" that rests in my main GMax projects folder. It's set up the way I like it: no annoying selection brackets, blue background in the port I use for 3D views, and no distracting grid in the same. I've created a plane:

I apply a 2 x 2 FFD to do all of the percent-related work. I put the leading edge at 100.000", and the trailing edge at 0.000". I moved the root to 0.000", and the tip to -500.000":

Then I collapsed everything and used the slice plane at 70% of chord (30.000" from STA 0.000):

Let's set the taper. I apply another 2 x 2 FFD, but this time I move the apex to 200.000" and the leading edge of the tip to 50.000":

Hey! It's starting to look like a wing! Here, I've created another plane, substantially larger than the wing, and rotated it 25°. This is the sweep at the 25% chord line.

Now I've sliced this plane at wing STA 0.000 and 500.000, and moved the result back to a more convenient location:

Select the vertices at the root. Snap the vertex at the 25% chord line to the leading edge of the other plane. Repeat for the tip.

I did something similar for the dihedral, but snapped the root of the reference plane to the apex of the wing, because all I really want is the Z position of the tip:

Now, we can copy this number to the vertices at the tip, and we have our theoretical wing.

Now I make slices at STA 85.000, 350.000, 352.500, and 480.000:

This defines the boundaries for our control surfaces. I then name the part "z theoretical wing" (I start all reference part names with z, so that, regardless of what method you prefer to group or select parts, they still appear at the very end of the parts list). The last thing I did was to place the pivot at the apex. Because I build exclusively in the first quadrant of the x/y plane until I have no need for numbers from station diagrams and whatnot, I then moved the whole theoretical wing to fuselage STA 550.352 and WL 14.000. Remember that stations run from the origin back, so STA 550.352 is going to be at y = -550.352".

 

[ErickC]

Part II

I have created a simple airfoil for us to work with. In an ideal world, you'd have the coordinates for whatever airfoils you might need (most airplanes will use multiple airfoils, splined together to form a smooth surface), but most of the time you'll have to use photographs to guess. At any rate, I've specified this fictitious 14% airfoil as the basis of our project, with a 13% version of it at the tip. This means that we only care about the airfoils at 0% of the span and 100% of the span. Real-world applications will probably require some intermediate airfoils. At any rate, here's my airfoil:

First, I apply an FFD and copy all X and Y data from the theoretical wing:

This, of course, gives us an ugly, fat wing. I set the bottom FFD points at WL 0. Now I can calculate Z values for the top points based on numbers I already have. The root is 200 inches, with a 14% airfoil. This means that the top FFD points at the root should be at WL 28.000:

With a tip chord of 50 inches, and a 13% airfoil, the thickness should be 6.5". So I move the top FFD points at the tip to WL 6.500:

I should have probably modified the incidence before I set the chord and thickness, but at angles this small it's probably not going to make a huge difference. Either way, I rotated the tip to an incidence of -1° and the root to an incidence of +2°:

Finally, since our dihedral is at the trailing edge (in my experience, this is generally where it is specified), I snap the trailing edge to the theoretical wing:

The basic wing is done. We could now detach the areas defining the ailerons and flaps from the theoretical wing, extrude them, and use these parts to cut these areas from our wing. We could also compare the place where the wing joins the fuselage to the nominal point at wing STA 85.000 to ensure we have our spacial relationships between parts correct. You'll notice, based on my computer's clock, that this was a grand total of 20 minutes of work. No backdrops, just numbers and results.

 

[ErickC]

Oh, yeah, and a question from me for people who know better: can we change the default weld threshold from a decimeter to something, you know, practical?

 

[tgibson]

You can probably write a script to do it, but to run the script takes just about as long as to type in a new threshold value...

 

[antaris]

Dear Mr. Cantu
Thanks for this wonderful tutorials; this should be a "sticky one"

All the best,
Sergio Kauffman.

 

[ErickC]

Moral of the story: SAVE OFTEN! Even if you end up with hundreds of files in one folder, you can always either compress them, archive them somewhere else, or do what I do and just highlight/delete 2 of the 4 rows of .max files (just not the row containing your current save of course.) Although I AM lazy when it comes to organizing files and my folder was approaching 12gb at one point...

I ought to mention that upon completion of major subassemblies that are a royal pain in the arse, I do often copy all 26 of the current files and place them in a backup folder. I figure I can clean it all out when the project is done.

I just finished this little prick today (just needs animation, hoses, and a ground spoiler cable on the starboard side), and you can bet that's precisely what I did:

I do not want to have to do any portion of this assembly ever again. Mirroring it will be bad enough.

 

[ErickC]

Edges count, everything else is fungible!

I made a simple model of an MXR-type stompbox for you all.

The knobs are different. Let's look at them more closely.

What do you see? Well, the knob on the right is a more complex part, and probably has a much higher number of triangles/vertices/et c.

You'd be wrong.

Aha - we get to the point. I used fewer sides for the knob on the left, but I smoothed out a bunch of things in some areas that I knew wouldn't make a huge difference. There are more differences, though. The knobs would, in real life, be attached to potentiometers, obviously, so I made pot shafts, because even with the small gap between the body and the knobs, the shafts will be visible.

Notice also that a small sliver of the inside of the knob will be visible from some angles.

There is more:

I modelled the inside of the knob on the left knob. Would you notice the difference with the body in the way? No. Similarly:

Nobody's going to notice the detailing of the pot shaft buried under the knob.

The difference between the two was noticeable at a close distance when viewed from the side, because I chamfered the edges where the angle of the knob changes. Did you see? This is another example of how and where edges count. I expend a lot of triangles on noses, because just about everything on them forms a visible edge from just about every angle. On concave, curved objects, such as wheel rims, and certain parts of tires, I will actually greatly reduce the resolution of the mesh, because with the proper application of smoothing, you will never notice the difference. It will eventually add up.

We must also consider the purpose of this stompbox. Is it for an application where the knobs might be removable? Then it would make sense to model the interior of the knob and the top of the pot shaft. What distance do you intend to view it from? Let's explore the angle transitions when viewed from the side again.

At this distance, the difference is much harder to see. How close are people really going to get to the knobs in your VC during every-day gameplay? Is your target audience people who use FS to fly, or is it screenshot commandos who pose the airplane, take a bunch of shots, then quit FS and do something else? Form follows function. If you're building for pilots - optimize, optimize, optimize. They'll thank you for the smoother flying experience.

 

[ErickC]

Also: I could have probably gotten away with as a few as 8 sides on the pot shafts, because the places where the shaft meets either the body or the knob would never be visible. I could have probably made the convex top of the knob a simple cone, because, with smoothing, it would probably look more or less the same. Polygon counts still matter - but indirectly through UV coordinates and vertex counts.

Let me drill that through your head.

Polygon counts still matter, because more polys still means more vertices, and vertices matter a whole lot.

Optimize, optimize, optimize. Nobody is going to care that your polygon count is impressively "bigly yuge" when your model runs like crap. And remember that the boundary of two smooth groups effectively means extra vertices. For parts where the funky shading won't be terribly visible, I'll actually put things in one smooth group that might otherwise be in different ones if the part were a standalone object. I flatten UV coordinates where possible and weld them where possible. It all adds up. Form follows function.

 

[ozzman1997]

Erick, I'm not sure how much experience you have with VC modeling, but it would be interesting to see what your approach is to getting dimensions/proportions right when little reference is available. You seem to be incredibly systematic in your design techniques, which is a trait that I really envy. I know that there isn't one single way to design a VC, but I imagine that most people aren't lucky enough to have all of their aircraft's instrument panels arranged in poster format within the manual.

 

[ErickC]

Let's start with an excellent post from another thread:

I'm one of those (sometimes) excessively anal-retentive folks who insist on giving meaningful names to every stinking object in the scene. I also like to Link objects into relevant sub-groups so that I don't have to go crazy trying to track down some part that's named "Object15329" or some other silly auto-generated part name!

Oh dear! I just noticed that there's one of those pesky things still left in my APU_Panel tree! Argh! Where's the Raid?

Bill's post is from another thread, but within it is a very important general idea: organization. I happen to know, from conversations with Bill, that his highly-organized system extends to all major facets of the job: part names, part groups, the configuration of the modeldef.xml file, and so on. His workflow appears, to me, to be a railroad classification yard of branches, sub-branches, all leading to a common output. The railroad always knows where the cars are.

That's an exceptionally good way of doing things. Having a consistent, standardized system in place will tend towards consistent results and easy diagnosis of issues. Imagine you were, for example, a starship captain exploring the unknown regions of the Ford galaxy. Suddenly, a Klingon bird-of-prey de-cloaks and begins firing photon torpedoes laced with Milli Vanilli records at you. How do you raise shields? If defensive systems are organized into a single control panel, and each sub-panel is somehow connected in a logical way (for example, weapons and associated sub-functions in one panel, shields and associated sub-functions in another), even an inexperienced operator could quickly navigate to the button that raises the shields. What if a model were a group effort? It does often happen.

For what it's worth, here's a sample of what one of my hierarchies for triple-slotted trailing-edge flaps might look like. The flap rails are, in turn, directly linked to the left wing. I treat all sub-assemblies as sub-hierarchies. A logo light lens, for example, would be linked to its housing, which would in turn be linked to the wing, which is in turn linked to the fuselage, which is in turn linked to the base node (since this is an FS9 model, that would be a dummy called "exterior"). I would never, for example, link both the lens and the housing to the wing separately. Note that I still use the old FS8/9 part names out of habit, but treat them as a text version of an animation tag (which is what they are):

Those of you who have downloaded my source files in the past might have also noticed that I colour code all parts. In general, I tend to use blue shades for major parts, such as fuselages, wings, and stabilizers, and red and orange shades for control surfaces. I also use lighter and darker shades of the same colour in sub-assemblies, and off-colours when I run out of shades (since I tend to keep my parts counts to the bare minimum required per sub-assembly, this doesn't happen often). It's just a simple visual cue that simultaneously differentiates and groups parts. I find it useful on a subconscious level.

 

[ErickC]

Erick, I'm not sure how much experience you have with VC modeling, but it would be interesting to see what your approach is to getting dimensions/proportions right when little reference is available. You seem to be incredibly systematic in your design techniques, which is a trait that I really envy. I know that there isn't one single way to design a VC, but I imagine that most people aren't lucky enough to have all of their aircraft's instrument panels arranged in poster format within the manual.

I've only built two (and never really finished them - the B737 and L1329-25), but since I've started playing with model airplanes again, I've started to be more thorough about all specifications, including the cockpit visible from the exterior (which is really just a simplified virtual cockpit). The basic procedure, for me, is the same. Work from generalities to specifics.

If accuracy is a primary concern, for example, I would not begin anything until I had the basics of the cockpit area on the external model in a final form. The surfaces of the aircraft define the limits of everything beneath them. They also, occasionally, contain clues to the placement of things within the cockpit (window frames, for example). Note that station diagrams can also provide basic information for the extremes of the cockpit area. The lobe crease on the B70237 is at WL 208.1. This is, conveniently, also the location of the floor of the aircraft. You have one less dimension to guess - the floor will be 208.1 inches above the reference datum. Assuming that the rest of the model were built with fuselage contours at the correct locations relative to this point, the floor cannot be misplaced.

If I were to start on a VC right now, I think the general process would be thus:

1.) Gather all available references off the internet
a.) Look online for PDF versions of manuals (many can be had for free or cheap - I found an F-104G FCOM with some careful searching)
b.) Scour the internet for photographs or diagrams from the kinds of sources I've named before, with a particular emphasis on odd angles and 3D panoramic views
c.) Scour the internet for measurements. With the advent of home cockpit-building, measurements may not be very hard to find!

2.) Create a basic cockpit shell. Work from the outside in. What if we have to guesstimate the basic dimensions? This is where photos from odd angles come in. We'll cover that in a bit.

3.) In a separate file, I would next create the instrument panels. If your aircraft is a relatively popular one with home builders, the dimensions might be easy to find. But how often is that the case? Well... it depends on what you're building. 737 and DC-9 builders need not worry.

So how do I guesstimate the size of things? The same way I determined the DC-9 theoretical wing was correct. I take a photo, make a copy of it, and start drawing lines. In an ideal world, we would take a Kinect with an attached laptop into the real cockpit and generate a mesh to use for reference. For now, we can create a low-res hand-drawn simulation of a mesh that will be a visual guide. I'm going to draw some pictures to demonstrate how I would come to basic conclusions, which I would then write down in a text file that would be a running tally of notes (guesstimates of panel angles and so on). To be continued.

 

[ErickC]

Here's a CV-880 cockpit:

This kind of photograph is pure gold, and I took it from this angle for two reasons:

1.) There is a glass fence keeping one from stepping in (but it ends at waist height, so I was able to use the camera to extend my "eyes" a bit)

2.) This angle gives you so much basic dimensional information, it's not even funny!

I did a very quick job of drawing some lines that can be used to gauge the positions of things in all three dimensions:

I could have drawn more, but I chose to concentrate on determining the basic dimensions of the consoles to the left of the captain's seat. Remember drawing cubes in elementary school? This is what we've done here. We've estimated the edges of parts based on where other parts begin and end. We have drawn the edges of the cube. Remember the comment about photos from odd angles? If we can view that first console from ahead of the seats, we could guess at how wide it is. For our purposes here, I guessed that it was as wide as the little hollow console behind and aft of it.

How could we get the y-axis position of the aft edge of the forward console? We followed the contours of the walls and made a couple of educated guesses. I continued the line defining the outboard joint of the console to the cockpit wall, and extended the line defining the aft edge of the console to it. We now know the y-axis position of the aft edge at the cockpit wall. Notice how I next drew a line consistent with vertical indentations on the sidewall to arrive at the point where the sidewall has a protrusion that defines the window sill. The top edge of the wall changes colours, almost like the darker grey is part of the structure, and the lighter grey is the plastic covering. Aha! We move our line right by about the same amount, then continue upward, again along the estimated contour of the sill (red line, from a vertical crack), and we now know the position of this line at the top of the window sill. Trace inwards along the estimated angle of the top of the sill (blue line, from window roller). I have extended a green line along the predicted edge of the sill behind the movable clear-air window. We now know where this line is along the inner edge of the sill. Trace up and around the window and we now have a definite reference point - the general vicinity of the boundary between the two side windows. Since we built an accurate external cockpit area first, we can position things accordingly.

There are some caveats:

-I did my best to guesstimate the amount of perspective distortion and reproduce it "inside" and "behind" parts, but these guesses will be imperfect

-Distance estimates will be most reliable within the x/y plane defined by the photograph, not the virtual plane through it. This photograph, for example, is the most useful in determining the width and height of objects. Our guess of the position of the console aft edge, for example, is bound to be off by a few inches. Because I'm nobody's fool, I took photos through the open cockpit windows for data along the y-axis:

Our general location was right, but we ended up a few inches too far aft. This is why photos from odd angles are useful - you never know what part might be positioned according to them. Using the photos from behind and through the window, I could place the aft edge of that part of the console, assuming my shell were accurate, within fractions of an inch of where it ought to be.

Let's say that we've already built this forward console, but want to know how wide the narrow console that continues aft of it along the cockpit wall is. We can measure, in pixels, the total width of the line that defines the first console's aft edge, and divide the width of the narrower console to get a percentage, which we can then multiply into the measured width of our modelled forward console to get a guess of the width of the aft one when we build it. I'd round it to the nearest quarter inch based on the idea that most major dimensions in a CV-880 cockpit are probably pretty close to the quarter-inch mark. Metric cockpits will probably be close to the 5mm mark.

While I'm working here, I'd use some basic trigonometry to guess the angles of all of the panels. I'd write them down in my running tally of notes, and when it came time to build the panels, I'd build them flat, because it would be easier that way, and then rotate them to the right angle when fitting them to the shell later. If we know the angles already, we can undo any rotation should the need for rework arise.

If I lacked a reliable diagram of the panels themselves, I would make the basic panel from a photo from as far back in the cockpit as possible to reduce perspective distortion, and map the photo to it for later. I would then guess the height and depth that form the angle, write them down, and use an FFD to skew the panel to fit. I'd then rotate this part until it was more or less flat, then squash it with a non-uniform scale (in vertex mode) until it was actually flat, and then continue as before. Because I previously threw the photo on it, I'd have a rough idea of where the gauges ought to be.

It's not going to be as precise as working from a 3D scan or an accurate set of plans, but the results ought to be reasonably close. How many 737-200 models available for MSFS have the correct inlet lip skew of 4 degrees inboard? If you don't know, it's because most people would never notice. Sometimes, "reasonably close" is all that we can do, and I accept that few are going to notice some of the more anal-retentive things that I do these days (such as moving an airliner wing two inches forward because I calculated the width of a couple of frames wrong).

 

[Melo965]

Excellent thread. Thank you very much!

 

[ozzman1997]

Very informative as always, Erick. We really appreciate you coming to share your knowledge here! It's always interesting to have a window into other people's mental processes, not in an attempt to "be" someone else, but rather to plant the seeds of wisdom in our own minds and see what they grow into.

 

[Ronald]

Great material and nice visually supported too ErickC, thanks for sharing!

 

[ErickC]

More about optimization

What's the difference between a 60,000-triangle model and a 100,000-triangle model? Level of detail? Sometimes, but not necessarily. Here's a little gadget whose primary function is to simulate the sound of sucking the last little bit of a vanilla shake through a straw when the nose gear retracts (a secondary feature is to stop the wheels from spinning):

I'm not done with it. Let's shave some fat:

I deleted the polygon that would otherwise be hidden by the roof of the wheel well, and welded a couple of unnecessary vertices at the very front. As Mr. Igami says: "value of a vertex." Why did these two have no value? They held no value because they did not define a change in contour, and were thus target-welded into a couple of vertices that did. I also eliminated some vertices by putting the back side of that little block at the nose (the rubber part that does the actual work) in the same smooth group as the bottom of the bracket, and I put the front of the block in the same group as the sides of the whole assembly. This is because any time you have two polygons in different smooth groups, the "hard edge" is created by "splitting" the vertices, even though you may have welded them! Sure, this creates some strange shading, but for this part, it doesn't matter. First, it's a part that few are going to notice, because it's fairly well-hidden. Second, the texture is going to be pretty dark anyway. The cost was worth the benefit.

There's some more optimization going on on the nose wheel that I bet you can't see. What did I do?

See it now? The overall reduction here is fairly small, but over an entire model, these savings are huge. The little changes I just made save 572 triangles per wheel. I did the same thing to the main wheels, which have a similar savings in overall triangle count. That's nearly 3500 triangles across all six wheels. That's enough to do a simple AI model of this entire aircraft! The end-user's system could be rendering both your airplane and an AI version of your airplane and doing the same work as rendering just the un-optimized version of your airplane.

(For what it's worth, Jorge's FS98 model of the same airplane only had about 1500 triangles)

Now I can use those 60,000 or 100,000 or whatever triangles to their fullest extent. I only use resources that carry actual value. You should, too. It takes more effort, but it yields better performance. Nobody is going to care about a bunch of hidden polygons when the model is a slide show.

What I do these days is pick an optimum zoom level for viewing the whole aircraft, and make everything look good to that point (I mentioned this earlier with the Falcon windows). If I'm rounding the edges on a pushrod, I'll zoom to that optimal place, and then use just enough sides to make it look round. If there's a bolt holding a door to a pushrod, and that bolt has a nut, I'll skip the nut if you can't tell the difference at that particular viewing distance. The user might not notice, but they'll thank you if your model is just as detailed as the other guy's but runs better. Trust me.

The keyboard command in G/3DS Max to collapse a pair of vertices in E-poly is CTRL+ALT+C. Remember it, and use it well.

 

[ErickC]

More about key commands

Here's a list of keyboard shortcuts for 3DS. They largely apply to GMax as well. The more of these you know, the faster you will arrive at the intended results, leaving more time for optimization and other "time wasting" tasks.

 

[hairyspin]

Don't forget you can customise G/3dsMax to suit your way of working. They also have a default keyboard template but Gmax has alternatives bundled with it which will make it function like Max with W for move, E for rotate etc. Explore the Customize menu for these.

There's a lot going for cleaning up your mesh and deleting polys which simply aren't seen. Just be aware some users go exploring trying to find holes and although you would never fly the aircraft with your head between your ankles looking up behind the throttle quadrant, if they can they will and moan at great length about the 6mm hole they've found...

 

[ErickC]

The solution to those guys is to charge 'em. The second they have to pay for it, every flaw becomes "the right way to do it."

On the other point... I just added a few shortcuts for things I frequently do today, as a matter of fact!

Here's a good question that brings up another topic (when to not take things at face value): every single 737 has a gauge that always lies. It never tells the truth, in fact, it's rarely even close! Which gauge is it?

 

[hairyspin]

Not in that list from Wikipedia is Select And Do Nothin' in Max - Q
I assigned a key in Gmax for that since it's not on the default assignments. I also have hotkeys for the various Reference Coordinate Systems which I use a lot.