chriscalef

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

http://opensimearth.com/images/screenshots/ka50_textured.jpg

http://opensimearth.com/images/screenshots/ka50_rear.jpg

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

Meanwhile, somebody say something about attack helicopters?

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

Fixed video:

Still some choppiness vs. the terrain, but the major pack/unpackUpdate problem is gone.

And... in case anyone cares, just a quick report back that the twitchy camera is now *fixed*. Although with a really nasty hack... I think a polite fix is going to require a new camera mode. Expect a better video soon, however.

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.

http://www.flightgear.org/download/aircraft-v3-4/

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!

Yes, that sounds much better to me!

I really only want to turn on a few new windows with my editor, and have them hook into my new functionality. Other than that I'd like to leave the world editor functions intact.

Just wondering if anyone out there has a solid understanding of the black magic involved in creating a new editor. I recall having a boatload of issues when I created Ecstasy Motion as its own editor, mostly related to not being able to reliably control windows when switching between editors, and in general just not understanding all the callbacks and things that need to be set up just so in order to play nice with the world editor and menus.

I'm about to get involved in this again for an openSimEarth editor, and I've completely forgotten most of what I had to do for EM, but I came across this old posting of mine from 2012:

http://www.garagegames.com/community/forums/viewthread/132256

Back then @JeffR was sharing my pain, at least. Have you been back to this neck of the woods since, Jeff? Anything gotten easier?

Nothing has really broken for me yet this time around, I'm just barely getting started... but I expect the process to be long and difficult, so figured a preemptive cry for help here probably wouldn't be a bad idea...

In any event, if others are interested I can share whatever I figure out.

Yup, sure enough, I tested it in a place with less height difference, and the problem is much reduced. This is kind of a messy screenshot because of the road interference, but here you can see the trees right in front of the camera only slightly higher than their neighbors, while the trees going off to the left, with a major height difference, are much higher. Bingo.

http://opensimearth.com/images/screenshots/forests_06.jpg

OMG, that looks like an _extremely_ helpful PR, yes, thank you Az. I'll be sure to profile some of those disputed methodologies in there while I'm at it. :-)

Yeah, this has been regular as clockwork for me. It's interesting because the heights go crazy, but only within somewhat reasonable limits, they definitely don't go completely NaN0 on me. I'm also not at all sure that the problem with the decal roads is exactly the same problem as what I'm getting with the mesh roads and trees.

For the forests and mesh roads height values are being set through a server container castRay. I'm suspicious about whether it could be trying to interpolate heights to the other edge of the same terrain tile. (Will have to test it on flat terrain.) I know through earlier help from Andy Wright that a similar problem is what causes the dark shading on many terrain edges - it is more prominent on tiles with a larger height difference between opposite edges.

The decal roads seem a little different. Observed behavior is they pretty much all stick up to the same maximum height when a road goes completely across a terrain border, but a very interesting lesser effect was noted: when you move a road gradually across a terrain border in the road editor, the edge of the road sticks straight up at the terrain edge, and goes higher as you bring it farther over the border. It would seem that the road decals can't figure out how to cross from one terrain to another.

Also interesting was that the decal road behavior is only visible from one side of the border, from the other side it looks fine. :? One sided polygons?

Anyhow, I'll poke around on it but I don't think it's going to be my highest priority at the moment. And who knows, it sounds like @andrewmac has a terrain engine that's running laps around this one, so maybe I'll just have to try dropping all this into there pretty soon...

Hey there, just a quick update on the recent progress...

First off, the next major world building component is now in place: in addition to terrain, forests, and roads, we can now place TSStatic objects with the World Editor, save them to the database, and page back through them at will.

http://opensimearth.com/images/screenshots/statics_01.jpg

As you can see, I didn't do much with this godlike ability yet, because that devolves quickly into countless hours of art time, but in this image the Zero (from flightgear, textures still broken) and the wharf and industrial shacks (many thanks to 3TD Studios for the free art!) are placed using this method. Note that scale also works, as demonstrated by the taller building in the background.

The other big news is, thanks to a most helpful comment from @JeffR on my last blog, we are now able to return to DecalRoads instead of MeshRoads, due to the containsPoint() function. In addition to being much more efficient, in this way we also are able to get rid of the absolutely unusable Z fighting which always seems to follow my MeshRoads around, possibly due to float error from being too far from the origin (running around six or seven thousand meters out here).

However, I'm still having major problems with raycasts at the edge of the terrains. Here is an older image with MeshRoads and trees, demonstrating my problem:

http://opensimearth.com/images/screenshots/road_09.jpg

As you can see, reported heights become wildly inaccurate at the terrain edges. Which actually makes for some pretty amusing bugs on the mesh roads, but hardly desirable. Lacking the time to really dig into this, I've been simply avoiding putting trees close to the terrain edges, and I fear I will have to do the same thing with roads, for now. While mesh roads show the problem as seen above, with decal roads the symptoms are different - from one side, but not the other side, of the divide, any decal road crossing from one terrain to another will shoot vertically up in the air, not infinitely but for quite a distance:

http://opensimearth.com/images/screenshots/road_14.jpg

Since this whole world is meant to be more for fun and experimentation than for a perfect simulation at this point, I think I'm just going to work with what I have and create a little DMZ style "no man's land" between each terrain tile. Eventually I plan to move this to T6, and/or fix the problem here, but other parts of the project are calling my time harder than this. If anyone has any ideas, I'd love to hear them though!

As a final note, this might be a good time to mention: openSimEarth needs art! If anyone out there in Torque world has public domain artwork, or private models they'd be willing to share, including trees and other vegetation, animals, houses, industrial buildings, and/or anything else you think would fit in, please consider contacting me, I'd love to give you credit and include some of your work!

So anyway, that's where we are for now...

Ah, that's good to hear, @MangoFusion! Keep them as floats the whole time, what a thought! :)

Wow, didn't know about Marvelous Designer yet, that's pretty impressive...

Thanks for the info!

Cool, thanks!

Does MakeHuman deal with clothing very well? Or is it mainly just for making the naked human mesh?

Awesome, thanks for clarifying. I like where you're going with it!

@saindd: My interest in the generic models is because I want to make videos showing off motion and AI, without the distraction of particular character details.

I am also _very_ interested in MakeHuman, however. I haven't taken the time yet to research the full pipeline from makehuman/blender into a rigged and finished character in Torque, have you used it a lot and found that to be a no brainer process? Any tips?

Very noice!

Hey @Janders, is that dummy you're making going to be shared? I'd love to have something like that to use when I want to get attention away from the art assets and onto the motion, or whatever else I'm trying to emphasize.

@Mango: sounds good, I can wait but I'm excited that you're working on it!

While we're on the subject of Torque Script though, you wouldn't happen to have done anything re: the floating point precision, would you? I just lost half a day on a bug in my code that turned out to be because of the six digit limit on float values passed from the engine to the console, and while I understand it's for efficiency, I sure would appreciate that value being set somewhere under the control of the user so the tradeoff of efficiency versus precision could be more transparent.

My particular case involved use of lat/long coordinates, where -123.076 is simply nowhere near enough precision. I resolved it for my own case by moving that part of the logic into the engine, where it probably should have been anyway for performance, but all the same, that's a pretty painful data truncation to have just built in to the engine with no easy way to modify it. IMHO.

Thanks again for your efforts!

Yay, thank you Mango! Just to clarify though, this is in T2D? Is it easy to drop into T3D?

No problem, really glad to see somebody taking on the GUI layer! In particular I really like your customizable toolbars, and the window docking, etc, these are things that I've wished Torque had FOREVER. If there aren't any major problems with it I see no reason not to switch right over and never look back. Thanks again for all the hard work!

Wow, yeah, I'm sorry to say I hadn't really followed this thread before even though I saw it come up, but great work on this! Very impressed. Looking forward to using it.

Ah, thanks Jeff, that sounds helpful. Although with Meshroads, it seems like my current solution is probably fastest, since we're already doing a raycast to find the ground anyway and the same cast is capable of excluding everything except terrain. But for decal roads that sounds like a great solution!

Awesome, yeah please do. The other question I still have is whether there's any efficient way to do the same with groundCover objects. Just now I tracked down where you'd look for that - groundCover.cpp line 1226 or so, looks like this:

PROFILE_START( GroundCover_TerrainRayCast );
         // Transform billboard point into terrain's frame of reference.
         Point3F pp = Point3F(cp.x, cp.y, 0);
         terrainBlock->getWorldTransform().mulP(pp);
         hit = terrainBlock->getNormalHeightMaterial( Point2F ( pp.x, pp.y ),
                                                      &normal, &h, matName );
         PROFILE_END(); // GroundCover_TerrainRayCast

But it calls getNormalHeightMaterial instead of using castRay(), and I suspect that is because it's probably a whole lot faster. I'm out of time for now but I guess I'll try testing that later. If anybody has any ideas on the subject I'd love to hear them though!

http://opensimearth.com/images/screenshots/roads_header.jpg

Well, it's been a busy October for OpenSimEarth!

We're still totally under construction and not ready for business yet, of course, but this seemed like a pretty good time to report back. If you're interested in checking out the repos, see my last post on the subject for URLs.

The quick summary, as hinted in the title: I now have a somewhat functional system for paging streets (mesh roads) and forests as you travel around the world.

The streets are a further development from this post, and they follow directly from the work I did with the forests.

Torque has a very nice forest rendering system, capable of rendering impressive numbers of trees at very low cost... but at some point, even it will become unusable if you just keep stuffing trees into it forever. Since my goal is an open and virtually infinite world, I needed to have a way to control the forested area and keep it centered on the player.

My (somewhat predictable) solution was to subdivide my terrain tiles into a grid of forest cells, and load and drop them as the player moves around the map.

I needed to paint the forest procedurally, of course, so I copied the random forest painting technique from the forest brush tool into a function designed to fill a single cell, and then worked up a little logic to keep track of which cells around the player had been filled already and keep filling and dropping them as we move.

http://opensimearth.com/images/screenshots/road_05.jpg

Oh, before I forget, I did some things that could be of general interest here. First, if you ever get tired of painting forest with brushes arbitrarily limited to 150m in radius, the fix for that is in forestBrushTool.cpp, line 307:

void ForestBrushTool::setSize( F32 val )
{
   mSize = mClampF( val, 0.0f, 15000.0f );//150.0f
   Con::executef( this, "syncBrushToolbar" );
}

I'm not using the brush tool anymore, but that really annoyed me for a while, thought it might help somebody.

Second, I added a couple of functions that I think really ought to be included in stringFunctions.h. I'll be glad to submit it as a PR, but if anyone on the steering committee just wants to copy and paste them from here, that would be fine too, they're quite trivial. But unless I missed something there didn't seem to be a "Torque way" to convert char strings to long or double values:

inline long dAtol(const char *str)
{
   return strtol(str, NULL, 10);
}
 
inline double dAtod(const char *str)
{
   return strtod(str, NULL);
}

Anyway, once I got my forests paging around the map with me, I moved on to the next step, which was filling different areas with different types of forest. So far I've only accomplished the first part of this process, which was differentiating forest cover based on terrain texture. For my ultimate solution I intend to do this in addition to having arbitrary landcover polygons that I can place anywhere, but... one thing at a time.

Since I was already scheming about how to incrementally load both street nodes and other placed objects, this forest cell system led me right on to other things. However, the first thing I had to figure out was how to make sure the forest didn't get placed in the roads. (I was actually a little surprised Torque didn't do this already.) I'm still unsure about the best way to handle decal roads, but with meshroads it was possible to get a different object type from a castray function, so I added the following line to my getGroundAt function stolen from forestBrushTool:

if ( !hit || strcmp(rinfo.object->getClassName(),"TerrainBlock"))
      return false;

If you want the same behavior with your forestBrushTool, you can go there (forestBrushTool.cpp, line 673) and do the same thing. (Does this want to be pulled into the main trunk as well?) In addition to roads, it also keeps forests from growing on rocks or houses or any other static object. Not sure if a lot of people need contradictory behavior or not, for me this seems to work pretty well.

http://opensimearth.com/images/screenshots/road_07.jpg

Along the way here I lost a couple of days getting very excited about something called SpatiaLite, which is an add-on for SQLite to support GIS logic. I'm still hoping I get to move there sooner or later, because it sounds like THE way to do what I'm trying to do on my own here, but I found a large number of obstacles involved in compiling and using it with Visual Studio and ended up backing away in defeat with my tail between my legs. :-P My primary goal was to be able to do efficient regional searches of a potentially very large geographic database, and what I ended up doing was inventing a lat/long based cell tag for all of my street nodes (looking like "123d0834W_44d0566N"), and then creating an index on that tag to make it search faster. It wastes a little memory, and it's still too slow, but it definitely helped.

There's still a lot of work to do, of course, in many different directions. I'm setting road widths and (to the extent I have textures available, which is very little) road textures based on the highway type specified in the OpenStreetMap data. I hope to extend the same logic to rivers and streams, but I'll need to do terrain modification for them, and of course that would also help a lot with roads, to flatten the terrain underneath them.

Finally, as mentioned above, I'd love to find an easy way to detect decal roads with a raycast, anybody got any ideas on that? I'm using all mesh roads right now just because they're the only ones I can detect to keep the forests out of them.

Oh, also, I don't expect any magic help here for this one, but I'm running into a really annoying render glitch with my forests... at times, they seem to just not work at all, but when I raise my camera up a bit in free camera mode, they pop back in. You can see an example around the 0:21 point in this video, which demonstrates the current system:

I have nothing helpful to add, but nice model btw!