Best way to make rigging wires?

[ConradB 0]

Having added the struts, I've been messing with the rigging, but it isn't working too well. So I was just curious of the methods others use for them.

 

Here's a couple more pics with struts added.

 

 

[Bullethead 12]

Looks nice!

 

I've been stewing over struts on my MS AI. My my Bristol, I just extruded them from the fuselage and that was OK because they didn't connnect the fuselage to any other parts. But on biplanes and the MS AI, the struts connect wing and fuselage. So what's the best approach?

 

See, the wing and fuselage have to be separate objects and named as such. Thus, if the strut is part of fuselage and you actually connect it to the wing, the whole plane becomes 1 object. So it seems the struts have to be separate objects. But how do you manage the joints? I've heard that overlapping polys is a bad thing, but I also don't want to leave any gaps between parts.

 

On top of that, what about damage? At least some of the struts have to go away when parts of the wings are shot off. Do you just arbitrarily make some struts part of 1 wing, some part of anyother, and some part of the fuselage? Or will the parts hierarchy take care of them as separate objects with non-CFS3 names? By that I mean, is the following OK or not?

 

L_Wing

+ L_Interplanestrut_Inner_Forward

+ L_Interplanestrut_Inner_Aft

+ L_Wingtip

++ L_Interplanestrut_Outer_Forward

++ L_Interplanestrut_Outer_Aft

++ L_Aileron

As to bracing wires, that's also something I'm quite curious about. Do you make a 3-sided cylinder or should you use a 2-sided poly with partially transparent textures. Also, is it OK to stick the ends of the wires into the wings and struts, or do you need to stop them just an RCH short. And, of course, how to they fit into the parts hierarchy?

 

 

 

 

 

[ConradB 0]

Good points BH! I was also curious about that point of the matter. Thankyou for the compliments! But pat yourself on the back, as your help, especially the moral support helped trmendously.

 

I wasn't sure if extruding them (the rigging) was the best policy. The struts I have, I meticulously stopped them just ever so shy of touching any wing or fuselage surface, but I also have to work very carefully to shape the strut ends to surface they are supposed to be attached to, and from zooming in, I can't find any real nasty gaps that would look obvious, at least from the angles in the cockpit. That may be the order of business for the rigging, using a veryfine 3 or 4 sided object.

 

The one thing I wasn't watching was the size of things with the wing struts and those odd looking rods that go from the fuselage up through the wing, those are aileron control rods, and bellcrancks. But the struts are too small, and the control rods are too fat.

[ConradB 0]

See, the wing and fuselage have to be separate objects and named as such. Thus, if the strut is part of fuselage and you actually connect it to the wing, the whole plane becomes 1 object. So it seems the struts have to be separate objects. But how do you manage the As to bracing wires, that's also something I'm quite curious about. Do you make a 3-sided cylinder or should you use a 2-sided poly with partially transparent textures. Also, is it OK to stick the ends of the wires into the wings and struts, or do you need to stop them just an RCH short. And, of course, how to they fit into the parts hierarchy?

 

Not sure if I would go that route. That was I think the way the rigging wires were done in RB3D, and there were some odd artifacts that would be seen at different angles while looking around from left to right, or if you had a plane padlocked. In otherwords, if you looked at the rigging wires on end they looked like a "+", or an "X". The use of an alpha though left a few oddities that had to be lived with.

 

I think I will try a very thin 3 or four sided cylinder and comepare it to what is seen in the game when you fly.

[ConradB 0]

Here's the latest of the Halberstadt CLII with bracing wires, thanks to stumpjumper.

 

 

I also have been doing work to revise some inaccuracies in the basic design. The aileron system is rather interesting. It used control rods connected to belcranks in the top wing right above the fuselage. A sturdier design than cables for the controls and they wouldn't get damaged as quickly by small arms fire or the light machinegun fire from other planes. This is really a neat experience building this model.

[hairyspin 1]

Gentlemen, it’s time to read the SDK!

 

But seriously… There are more ways to build a model than there are tutorials, so these are but a few random thoughts.

 

You could build the entire model as a single fuselage object and then select elements or groups of polys such as ailerons etc and Detach them, giving them appropriate names as you go. You could also build your model from separate objects, taking great care where one part butts up to the next to avoid overlapping polys. I think most of us use a combination of both approaches.

 

Overlapping polys:-

 

For major components of the model, overlaps are indeed a no-no; but for small details like wires it matters little. A common small object in WW2 aircraft, which I model, is a pitot tube. I just make it and sink the end ever-so-slightly into the wing. No big deal.

 

Unless you’re extruding wings directly from the fuselage, bigger objects like wings are built partly sunk into the fuselage, then two Boolean operations between wing and fuselage will cut both and allow you to remove the overlapping polys from each with a perfect joint between the two. See Milton Shupe’s C162 tut for the details of this.

 

That’s also what I’d do with the struts between upper and lower wings, and the struts between fuselage and upper wing in this model.

 

 

Model hierarchies:-

 

Before getting tied up with this, consider what happened when a biplane lost a top wing: did the a/c carry on with just one wing or was the structural integrity so compromised that the lower folded up almost immediately? I don’t know, but I’m sure there are those here who do. The structure is clearly dependant on the cross-bracing and struts between the two to form a structural whole.

 

If the a/c could carry on for a bit, you need to ask the bi/triplane modellers here about naming upper and lower wings, because the SDK is silent on the subject and names are everything in getting the CFS3 sim engine to do what you want. Then you can work out which objects are parents and which children relative to each other. In BH’s example, the aileron and outer inter-plane struts will be carried away when the wingtip is destroyed, but it will take the destruction of the wing itself to remove the inner inter-plane struts.

 

The purpose of the hierarchy is to govern how the sim handles damage, amongst other things. If you add objects to the model without organising them in the proper hierarchy, they will display in the sim but not behave properly as you crash/get shot down/zoom external views in and out. The only objects which should be added in this way are the boxes for the damage model. The SDK is especially terse here, the best way to learn is to study the P-47 and Ju88 models supplied. If you find it helpful, I have the hierarchies of both models in bitmap format for viewing. This includes all the LOD (Level Of Detail) sections so you can see what that’s about.

 

 

Aileron mechanisms:-

 

I don’t think you’re going to get the bellcrank mechanisms animated in external views; the CFS3 aileron animations are limited to standard rotations, this is not FSX. However, it should be possible to animate the mechanism in the VC, which uses keyframes, and would be really cool.

 

 

 

[ConradB 0]

Oh man, if you have those in bmp form, it would be a great help! Evert little deatail makes a difference!

 

And I have been reading the SDK, and was thinking how to annimate some parts, and your mentioning the VC is what I think I may be looking for. If they wouldn't annimate, it wasn't that big an issue, as they don't have a large field of travel. Maybe 15 degrees maximum. So their movement wouldn't be as critical as the main parts of the plane that are needed and recognised by the game engine. So the if there is need of a tradeoff, that's fine.

 

Most important thing is I don't feel like I'm doing this anymore.

[hairyspin 1]

It takes time, but it does come. And the more you learn and practice, the more you understand gibbering old modeller's drivel, like mine!

[Bullethead 12]

Gentlemen, it’s time to read the SDK!

 

I have, and do, but it makes very little sense to me. Gradual I understand a bit more of it, but only because I ask you and Stump quetions.

 

Before getting tied up with this, consider what happened when a biplane lost a top wing: did the a/c carry on with just one wing or was the structural integrity so compromised that the lower folded up almost immediately? I don’t know, but I’m sure there are those here who do. The structure is clearly dependant on the cross-bracing and struts between the two to form a structural whole.

 

For most planes, I'd say you're right here and OFF is wrong. I don't think the upper left wing could survive on most planes without the lower left wing, at least not for any length of time. I'm pretty sure this would have been possible in a Fokker D.VII, which really had cantilever wings--the interplane struts were just there to make the staff happy. Also, the Dr.I could lose it's whole upper wing but leave the lower 2 OK. That happened to MvR once.

 

If the a/c could carry on for a bit, you need to ask the bi/triplane modellers here about naming upper and lower wings, because the SDK is silent on the subject and names are everything in getting the CFS3 sim engine to do what you want.

 

I think the SDK implies, as do some tutorials, that you can put a number after CFS3's favorite name and the game will treat that part the same as if it had the regular name. IOW, you can have L_Wing, L_Wing01, and L_Wing02, which might be your names for the upper, middle, and lower left wings of a triplane. It's basically the same thing as having Rudder and Rudder01 for twin-tailed planes. Or at least that's the impression I got. But as you know, I have just enough knowledge on this subject to shoot myself in the foot.

 

But that's just for the wings themselves. That still leaves the question of what to name the wires and struts. I don't want to spend a lot of time experimenting and reinventing the wheel if the answer's already out there. Much as the experience would do me good, I just don't have the time for that.

 

So can you tell me if you've ever given your own made-up names to parts of planes and just linked them in the hierarchy? If so, has that worked? If not, in what ways did it fail? If it fails, probably the only answer is to make the wires and struts part of the objects with CFS3-approved names, but it would make things a lot easier if they could have nonstandard names.

 

The SDK is especially terse here, the best way to learn is to study the P-47 and Ju88 models supplied. If you find it helpful, I have the hierarchies of both models in bitmap format for viewing. This includes all the LOD (Level Of Detail) sections so you can see what that’s about.

 

I would dearly love to have this. As the models come in the SDK, they're not linked at all, so I find them essentially useless for instructional purpose. About all you can do is try to steal the pilot figure out of it.

 

BTW, do you have the hierarchy for the ship and vehicle models, too?

 

Damn, I hit submit too soon in my last, forgetting my manners.

 

Hairyspin, thanks for the help!

 

 

[hairyspin 1]

I have, and do, but it makes very little sense to me. Gradual I understand a bit more of it, but only because I ask you and Stump questions.

 

I think the SDK implies, as do some tutorials, that you can put a number after CFS3's favorite name and the game will treat that part the same as if it had the regular name. IOW, you can have L_Wing, L_Wing01, and L_Wing02, which might be your names for the upper, middle, and lower left wings of a triplane. It's basically the same thing as having Rudder and Rudder01 for twin-tailed planes. Or at least that's the impression I got. But as you know, I have just enough knowledge on this subject to shoot myself in the foot.

 

But that's just for the wings themselves. That still leaves the question of what to name the wires and struts. I don't want to spend a lot of time experimenting and reinventing the wheel if the answer's already out there. Much as the experience would do me good, I just don't have the time for that.

 

So can you tell me if you've ever given your own made-up names to parts of planes and just linked them in the hierarchy? If so, has that worked? If not, in what ways did it fail? If it fails, probably the only answer is to make the wires and struts part of the objects with CFS3-approved names, but it would make things a lot easier if they could have nonstandard names.

 

 

The SDK is really designed for people who already know what to do. If it’s any consolation, all the FS SDKs are the same that way; I’ve just got FSX and it’s no better!

 

 

Names, eh? If you read the Modeling Aircraft and Vehicles document from the SDK you’ll get a section on External Aircraft Naming Conventions. Jumping around a bit, look first at Visibility Test Names. These are the all-important names used in the model’s structure and control how the model behaves in crashes, when shot at or flying into something else. For example, if the model is one object named fuselage and crashes you’ll see the model, still complete, half-sunk in the ground and burning. If the model had a number of different parts – fuselage, l_wing, r_wing, tail, vertical, nose organised in a hierarchy like this:-

 

fuselage

 

l_wing

r_wing

nose

tail

vertical

 

 

 

then the next time you try flying through the scenery, you'll see the fuselage sink into the ground and burn while some or all of the rest scatter to the four winds. If the model were not an organised hierarchy, this breaking behaviour just doesn't appear. You can add all sorts of other objects to the hierarchy to make up the details, but these must be linked to one of the Visibility Test Names to behave properly in the sim.

 

Next the Rotation Animation Names. These are for objects which the sim animates all by itself, all you have to do is make sure the pivot is properly aligned and the rotation range is specified in the aircraft’s config file. Obvious candidates here are rudder, l_aileron, r_aileron etc. Then Keyframe Animation Names which are applied to parts you have to do the animations for in gmax (lots of fun and yet more headbanging, you’ll find!). Again you can link more objects to these animated parts, but any object which moves independently of another in an animation must be named with a valid Animation name.

 

Then there are the Weapon Names and Damage Endcaps. If the node (a gmax Dummy object) is not properly named, your Parabellum will be a dud, a replica, a piece of uselessly heavy scrap metal. I once read of someone giving up when the guns on his model fired backwards, so make sure the pivot points the right way.

 

 

This all sounds like the SDK respouted, so here’s one I made earlier:-

 

 

 

 

 

 

 

 

which highlights your other problem. Hierarchy? What hierarchy? You’ll like this…

 

 

 

 

 

Padaaaa! You can now see just how ‘tis organised: the node l_wheelwell perched at the top of the undercarriage hierarchy as a typical visibility test name. l_wheelwell will disappear when the gear is fully retracted, so the sim doesn’t waste processor time rendering the gear behind doors which fully hide it anyway. When it does disappear, so will all the child objects linked to it.

 

 

Farther down the hierarchy are various l_gear_x objects which have all been animated with keyframes. Amongst them are CrankDummy, OleoRodL etc which move with the animated objects they are linked to, but do not move independently. They can have any name you like, other than the pre-defined ones in the SDK.

 

 

Also in the hierarchy are Rotation Animation Names l_tire_still and l_tire_blurred which both are the wheel. When the pivot is aligned correctly, the sim will rotate these for you as the aircraft starts to roll for takeoff. Once the speed on the ground builds up, l_tire_still is hidden and l_tire_blurred is shown instead. Once in the air, the wheel stops turning and l_tire_still reappears.

 

 

So the naming problem with wires and struts is easily solved: call ‘em whatever you like, just link them to the wing, fuselage, whatever visibility test name you want them to break off/disappear with when shot away or similar.

 

 

And you should now find the (fully linked) Ju88 and P47 models more understandable! I’ll send the bitmaps tonight. HTH

Edited January 26, 2010 by hairyspin

[Bullethead 12]

So the naming problem with wires and struts is easily solved: call ‘em whatever you like, just link them to the wing, fuselage, whatever visibility test name you want them to break off/disappear with when shot away or similar.

 

And you should now find the (fully linked) Ju88 and P47 models more understandable! I’ll send the bitmaps tonight.

 

Thanks for all the help! That solves all my problems. I had not idea that "display subtree" thing was there.

 

Guess I'll get back to work on the Type AI. I'd put it aside due to not knowing how to proceed.