Jump to content

openSimEarth airplanes, and camera issues.


Recommended Posts

So hey, remember how I said you couldn't actually fly the airplanes yet? Well it's far from perfect, as will be obvious, but progress is definitely being made. I've been working on a chase cam system but am clearly dropping some positions or failing to interpolate or something, because the camera seems to stay in place for several frames of airplane movement and then catches up suddenly, resulting in very jerky/twitchy camera action.

Also, though I've attempted to force the camera to use full transforms instead of removing the roll axis as per default, I have so far been unsuccessful, no doubt due to my own incompetence - I can get the roll working, but am messing up when it comes to applying the transform to the camera position, so the end result is awkward, to say the least.

But for now, with a chase cam view rather than full cockpit, and with a gentle craft like the Dragonfly ultralight as opposed to a full fighter/aerobatics flier, this could actually be fairly fun to fly...

Website note: any chance of supporting vimeo links here directly, someday?

Oh yeah, also, in case anyone doesn't like ultralights, here is an illustrative subset of all available aircraft in FlightGear, any of which could flown in T3D now using the same system.


There are, of course, loads of issues involved in converting the aircraft models over from FlightGear's ac format into Collada (using Blender) and hence into dts inside Torque. If there happen to be any modelers and/or major airplane geeks out there with some free time on their hands, I could definitely use some help with this one!

First issue: the nodes seem to be coming in almost but not quite all of the time with no parents, meaning all my ailerons/rotors/everything are parented to the world instead of the wing or wherever they belong. When this is fixed I'll be able to record anims on the planes and include aileron, rudder, landing gear etc movements.

Second issue: the textures are almost all wrecked, I got lucky with the dragonfly but there is _much_ work to be done there.

Third issue is not a bug, but the next feature (which will totally seal the deal): to read the flightgear xml setup files for each plane, and use them to place all of the cockpit instrument models and whatever else they define. And animate the instruments and controls - airspeed, altimeter, throttle lever, etc.

I'm planning on calling up flightgear as a slave process at the time the player walks up to a vehicle and decides to use it, that way I can fire it up with the correct starting location and aircraft type, and turn it off when we're done flying. I have much work to do on the flightgear end to make it an efficient and invisible background program, but for now it's actually kind of fun to let it be itself in a very small window, even on my old machine the extra render doesn't really cost too much when it's 320x240.

So anyway, that's the latest greatest. Stay tuned next week, for attack helicopters and people flying out of buildings!

Link to comment
Share on other sites

Thanks Jeff!

Would be interested in any advice you may have re: the camera solution. Right now I'm just stuffing my airplane transform values into globals and reading them back out on the client side of the camera to bypass the networking entirely, since my main problem was the internal lag of trying to tell the server where my plane was and waiting for it to tell the client a tick later, while the plane itself was meanwhile streaming values directly to the client object.

I think I'm going to make a new camera mode that does this, and stop overriding flyMode, but it still seems like a very weird thing to be doing...

Link to comment
Share on other sites

Texture issues mostly resolved (although Torque Materials still confuse and befuddle me to no end):



Next, and much larger, step is to add the supporting models, ie rotors and weaponry, and cockpit...

Link to comment
Share on other sites

  • 2 weeks later...

So, some progress here to report back on. First off, so far so good with the mountObjectEx branch from OTHGMars! I would heartily endorse inclusion of this branch in the main tree, barring some lurking problem that has not shown itself yet.

I'm still working out my system and deciding what should actually mount where, but my first pass involves a new physicsShapeMount table in the database, which allows me to load up any given physicsShape with as many (currently TSStatic) models as necessary. I'm having some trouble mounting physicsShapes onto other physicsShapes at the moment, not sure why, but I don't expect it to be serious.

Anyway, here's my helicopter with the first round of mounts:


The blades still look stupid because they are made up of multiple overlapping meshes, and we're seeing all of them at once. However, the exciting news from yesterday is that I discovered the setMeshForceHidden() function in TSShapeInstance, and exposed it to TSStatic, as per this discussion, and now I can turn any meshes I want on or off at will!

There are three levels of blades on my ka50 model. The general idea is that when they spin faster, they switch to the broader shaped blades, and it makes the blur look better, but when they slow down enough to be seen they need to switch back to the actual blade shape. The three levels are: the actual rotor blade, a larger "propblur" shape, and an even larger "propdisc" shape. The above image was the propdisc, and here's the propblur:


And here's the end goal, the actual blades themselves. Also, I got the tube rockets installed, but I haven't gotten to all the other individual rockets. I'm still trying to figure out the xml files that define all these mount positions for flightgear, so much of the placement here is still manual trial and error.


An attentive eye will note that the center of the blades is not exactly aligned with the rotor. This is because the rotor is tilted forward five degrees, and my next step is to get the blades aligned with that, but first I have to decide whether it makes more sense to attach them to the rotor first, and then get that tilt for free when I mount the rotor, at the cost of making my hierarchy that much more complicated, versus adding some nodes to the helicopter and adding everything separately to those nodes. I'm leaning toward the latter solution.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...