chriscalef

Indeed, totally with you on the full weather simulation goal... another thing worth mentioning though is the METAR system, which FlightGear uses to model real life weather coming in from the network of METAR sources at airports, etc. Even if you didn't want to use them in realtime, the codes and a stored history of some of them could let you fake an awful lot of weather simulation, without ever having to deal with the barometric pressure and temperature stuff yourself.

But of course that's nowhere near as much fun. Personally I'm hoping to plug in a full on weather simulator at some point, I seem to have lost the link but I had an open source fire/local weather simulator on tap a while back. It might be overkill for game purposes, but I'm slowly learning the advantages of letting other people do the heavy lifting whenever possible. :-)

Ha, well, I thought I'd try it myself, but so far I can't exactly report epic results. Much of the problem I think is my own ineptitude and general confusion when it comes to dealing with the Material Editor and Torque materials in general, but I wouldn't be surprised if we're having some translation difficulties in our little import pipeline here. This is what I got after messing with it for half an hour or so and trying a handful of different models at random. I still haven't found the little puffy white cloud blobs in the above screenshot, most of these are more planar, and obviously I'm completely wrecking the materials and losing the transparency. Some help from an actual artist here would be awesome. :-)

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

The smaller blob in the foreground is a 1% scaled down nimbus1, the higher farther away pair of planes is altocumulus1. The others I tried were all more or less planar, the nimbus has been the most interesting mesh so far. Flightgear also does all kinds of animations and other work on these in the engine, so there's no guarantee the models on their own are ever going to look perfect... but the FG side is open source too, and also has a fairly large and helpful community, so sooner or later I'm sure it can all be figured out.

Heh, I couldn't find an easy way to copy out a list of filenames, but here's a screenshot of the top part of my FGDATA models/weather directory just to give you an idea of how many models we're talking about.

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

The total count is 124. You can browse and download the .ac models from here:

https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Models/Weather/

I don't remember if I had to download a plugin for Blender or not, if it doesn't work for you let me know and I'll find it on the FlightGear site. If it works you can just go to Import->ac model, and then export as DAE, and you're up to where I am so far. As mentioned in this other thread I'm still having trouble importing some textures, and all of the textures have needed to have materials written for them by hand in Torque script.

Well this won't get you all the way there, but if you really want a complex, diverse and realistic sky model with all kinds of clouds, you might consider joining me in my little "borrow as much useful content as possible from FlightGear" campaign. The cloud models are in .ac format and need to be converted to dts (my method has been going through blender to get models into collada, and then importing them into Torque.) They also have flat texture layers in addition to the 3D clouds. Here's just one screenshot, if you look around on flightgear.org and their forums you'll find many more:

http://www.flightgear.org/wp-content/gallery/gallery-v2-8/6oxqb.jpg

I would personally love to see everything FlightGear can do re: clouds and weather imported wholesale into Torque, and I don't think their community would have any problem with it as long as we were open about where the content came from. It's all released under an open license anyway. There is still work to be done on the T3D side, of course, to make sure the sky layers are capable of everything necessary and to work in the 3d models where appropriate. I'm not familiar at all with the sky system so can't help you much at this point, but it is on my list for sure.

OMFG... not a T3D bug, nothing to see here, everything's going just fine...

It turns out if you happen to be in a hurry with your copying and pasting, and for some inexplicable reason neglect to assign unique InternalNames to each of your TSForestItemData datablocks... then you will get all the same datablock when you reload, because that's what it uses.

On to the next one...

Ah there we go, starting to look a little better. The DAE importer, at least for my files coming in from blender, appears to have a hard time making materials for textures, as opposed to solid color materials which seem to work fine. Had to make the material entry myself, but after that the UV coords seemed to be hooked up and working fine.

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

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

So, I got to a relatively stable spot with my recent binge on the network layer, and jumped off in a different direction. One item on my long list of goals for the project involves sharing models between flightgear and T3D, and since flightgear is exclusively based on a model format called .ac, (AC3D) the tools options are somewhat limited. However, Blender works for .ac files (possibly with a plugin?), and I saved them out as collada from Blender and imported those into Torque.

Aside from some slight issues with the textures :-P, the shapes appear to be working, so far. Expect future updates.

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

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

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

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

Don't get too excited though, you can't fly them... yet.

The way I handled this is adding the following function to px3Body (it should probably get more generalized and moved up to physicsBody, so as to more easily implement the same thing in bullet, but I'm physx3 focused and it was faster to put it here:

In px3Body.h:

  virtual void setDynamic( bool isDynamic );

In px3Body.cpp:

void Px3Body::setDynamic( bool isDynam )
{ 
bool isKinematic = mBodyFlags & BF_KINEMATIC;
if (isDynam==isKinematic)
{ //ie we're switching states, we were kinematic and now we want to be dynamic, or vice versa.
	physx::PxRigidDynamic *kBody = static_cast<physx::PxRigidDynamic*>(mActor);
	if (isDynam)
	{
		kBody->setRigidDynamicFlag(physx::PxRigidDynamicFlag::eKINEMATIC, false);
		mBodyFlags &= ~PhysicsBody::BF_KINEMATIC;
	} else {
		kBody->setRigidDynamicFlag(physx::PxRigidDynamicFlag::eKINEMATIC, true);
		mBodyFlags |= PhysicsBody::BF_KINEMATIC;
	}
}  
}

You can then call that like mPhysicsRep->setDynamic(true) from a PhysicsShape when you want a live object, and send it false to put it to sleep.

Demonstration videos... sure, someday... Got a lot of nuts and bolts work to do before that becomes relevant though. :-)

Re: T3D main line, yes and no. The project itself, no, because it is going to involve a lot of logic and dependencies that go far beyond Torque's general purpose game engine mission. However, my intent as I go is to make as many subcomponents as possible be PRed back to the main line, ie things like my animation tools, etc.

In addition, I'm trying to separate out useful lines of work that are still too specific to include in the main engine into their own repos to be shared separately on github (for instance, any physics work I do that doesn't make it into the engine) so that people could make use of it without fully adopting OpenSimEarth.

But anyway, still fixing the terrain pager at the moment, and many other little things to do after that...

JeffR wrote:

That's why I'd mentioned a mesh segment with the bones at the end. You'd rig the mesh to the bones, and you'd rotate the bones to align to the segment breaks.

Ah, brilliant! Yeah, sorry, I missed that little detail. That would be perfect. Used with a set of models to encompass stages of the curves etc., picking the closest one, and then stretching as necessary. For things like bridges you could also have standard start and end models that don't scale, and then fill in the middle as necessary to get the length. More complex structures like suspension bridges might have to stay in as one unit, to capture the arc of the cables, but simpler bridges could have two ends and a variable length middle section.

It seems like it would be pretty hard to make the mesh road system just automatically substitute in a 3D model, because what are you going to do when the road is not perfectly straight and level? It would have to stretch one side or the other to make curves, unless you also made models to use at all the possible turning angles, and stretching one side of a straight section could easily come out less than perfect looking, I'd imagine.

Very cool. Thanks for sharing it!

AAAAHHHHH....

Thanks, Timmy! Yup, memcpy works fine. :-P

Pardon me, but do you have a moment to talk about reinterpret_cast...?

I am currently working on a networking layer item that requires converting a set of values of various data types into an array of bytes (char *), and then back into int, float, double etc. values. I've been doing this for some time through a shortcut of converting all numeric values into floats, and simply ignoring strings because I didn't need any at the moment. (Sorry, I was in a hurry.) But recently I revisited this code and decided to make an earnest attempt at generalizing it.

However, right after I worked out a nice systematic way to transfer a series of bytes through a socket and break it back out into whatever data type it came from, for some odd reason my float values started coming up zero every time. Ints and shorts and doubles are working fine, but when I run the following code, my floatValue reports zero, every time.

It's doubly weird because up until now I've been using nothing _but_ floats for everything... but now that I started introducing short, int, and double, everything works great _except_ floats. #fml

	
char bytes[8];
char *buf;
buf = new char[1024];

short shortValue = 25;
int intValue = 36793;
float floatValue = 4.5;
double doubleValue = 7.89;

int byteCounter = 0;
strncpy(&buf[byteCounter], reinterpret_cast<char*>(&shortValue),sizeof(short));
byteCounter += sizeof(short);	
strncpy(&buf[byteCounter], reinterpret_cast<char*>(&intValue),sizeof(int));
byteCounter += sizeof(int);
strncpy(&buf[byteCounter], reinterpret_cast<char*>(&floatValue),sizeof(float));
byteCounter += sizeof(float);	
strncpy(&buf[byteCounter], reinterpret_cast<char*>(&doubleValue),sizeof(double));


byteCounter = 0;
for (int i=0;i<sizeof(short);i++) bytes[i] = buf[byteCounter+i];
short *shortPtr = reinterpret_cast<short*>(bytes);
shortValue = *shortPtr;	
byteCounter += sizeof(short);

for (int i=0;i<sizeof(int);i++) bytes[i] = buf[byteCounter+i];
int *intPtr = reinterpret_cast<int*>(bytes);
intValue = *intPtr;
byteCounter += sizeof(int);

for (int i=0;i<sizeof(float);i++) bytes[i] = buf[byteCounter+i];
float *floatPtr = reinterpret_cast<float*>(bytes);
floatValue = *floatPtr;
byteCounter += sizeof(float);

for (int i=0;i<sizeof(double);i++) bytes[i] = buf[byteCounter+i];
double *doublePtr = reinterpret_cast<double*>(bytes);
doubleValue = *doublePtr;
byteCounter += sizeof(double);

Con::printf("shortValue %d intValue %d floatValue %f doubleValue %g byteCounter %d",
				shortValue,intValue,floatValue,doubleValue,byteCounter);

If anyone has a moment to cut and paste the code and report the results, I'd be most appreciative. :|

Oh, absolutely! I'm just waiting for Andrew to call it ready. :-)

Okay just as a quick update, the other low hanging fruit is accomplished. You can now load scenes by running around the world and getting within (currently) 5.0 meters of the scene's origin. When you get up to (currently) 20x the load threshold, so 100.0 meters, the scene unloads.

Nice, yeah that sounds like a much larger version of something I did with a door once:

I'm also envisioning my stuff here as being useful for baking out AI behaviors, for ambient background anims, eg a field full of rabbits foraging and occasionally hiding or running away or something - you could design a fairly intensive behavior tree for a lot of agents, and then bake out a good one and turn all that off at game time.

Re: what features are there and how to test them... my apologies but the most important feature of OpenSimEarth - the flightgear-based terrain paging system - isn't really packaged up and ready to distribute at the moment, I've had it packaged up before but I'm back into a bit of a mess with it at the moment. Hope to have it ready to go in the next couple of weeks though.

In the meantime, what you can do is download the game directory repo, and run the executable (OpenSimEarthGame.exe), and then pick Empty Room for your mission. You should get a flat plane with a little tower thing on it with a messed up texture (orange no material). :-P

Once there, you should be able to open the world editor and in the library tab, find a new dropdown box, with my two scenes named PRTL_BLDG and PRTL_TEST. Both of them simply create a handful of my Michael4 actors (dude in black underwear), with a very simple BadBehavior behavior tree attached that has them run back and forth between the one health object and their starting position, sort of.

Not too exciting at this point, but if you go into openSimEarth.cs, line 300 or so, and uncomment the following:

//schedule(40, 0, "startRecording");

Then you will start recording everything that your actors do. At this point you can shoot them in realtime, or go into the behavior trees and add setDynamic(1) somewhere to make them ragdoll, or add forces to them, or add more complicated behaviors, and all will be recorded.

When you are ready, then you can hit "alt g" or type stopRecording() into the console, and then after that hit "alt b" or type makeSequences(), and then you will get a dump of scene sequences into the folder art/shapes/m4_optimized/scenes/ and then a number representing the database id of your current scene.

Also, you can make more scenes and sceneShapes in the database itself, best way to do that is to open the sqlitestudio executable I included with the build in the main game directory.

Finally, I also created a handy little system called actionSequences, wherein I make it possible to assign a particular sequence name at the shape instance level to a generic category, ie you can say %shape.setActionSeq("run","my_particular_run"), and then later on in the code or in behavior tree scripts you can call actionSeq("run") without having to know or care which particular run anim this shape is currently using. I find it makes a lot of things easier, and you can expand the system infinitely with as many actions as you like.

I fixed the scene unload button now as well (the "-" button by the dropdown) so be sure you do a fresh update before you try anything. I also added a global position per scene, which gets added to the local position of each scene shape, with intent that I can start making "scene templates" where you could reproduce a common scene with it's common shapes many times over on a map. (i.e., fill in a single family dwelling with a typical family doing their typical things, in whichever house you walk into.)

My next easy low hanging fruit trick is going to be loading/unloading scenes based on proximity, so you can cross a landscape and instantiate/deinstantiate little active scenes as you travel.

Many apologies if you can't get it to work at all, this stuff is beyond bleeding edge at the moment, but do let me know and I'll try to figure it out for you!

Ah cool, I didn't know they did that in HL2. But yeah, that's the idea!

OpenSimEarth Approaches!

TL;DR: I have a T3D build on github that incorporates the animation recording and saving functionality from Ecstasy Motion, so you can blow up ragdolls and save them out to dsqs.

So, this hardly qualifies as a proper "Show-off" yet, it's not anywhere near done or anything, but since it's been pretty quiet around here, and I did just commit up some code that could be potentially useful to somebody, I thought I'd share a bit about what I'm doing anyway.

Before I forget, the repos in question are here (for the engine):

https://github.com/ChrisCalef/Torque3D/tree/open_sim_earth

and here (for the game directory):

https://github.com/ChrisCalef/OpenSimEarth_game

Don't get too excited yet, like I said they're in no state for distribution... but bookmark those babies, I have a LOT of plans for them!

http://opensimearth.org/images/ose_001.jpg

(Sorry for the most boring screenshot ever, but I'll explain the one interesting feature in a minute.)

Sooo.... what am I doing, anyway?

Basically, if you've been around these parts for any length of time, you must have heard me go on and on about Ecstasy Motion. (If you're a newcomer, go check out my blogs at garagegames.com, if you have all day.) Long story short, the idea has always been to make a T3D build enabled with ragdoll physics, animation editing capability, and a bunch of AI tools like navmeshes and behavior trees, and aim it at the independent filmmaker market, to generate animations for export to Maya or other movie making software. My projected price point has always been in the $99 to $199 range.

This has appeared to be a viable plan for some number of years, even though I knew it was taking me way too long to finish, but recent research has convinced me that at least in terms of Maya, I may have less of a niche than I previously thought. (Hint: google Miarmy).

No final decisions have been made, but at the same time, I've also been finding myself very powerfully drawn to my OpenSimEarth project idea, starting with this blog from a couple of years ago:

http://www.garagegames.com/community/blogs/view/22269

And then more recently this one:

http://www.garagegames.com/community/blogs/view/22953

Meanwhile, however, I'm still working on the movie project that has gone hand in hand with EM from the beginning:

https://www.facebook.com/Portlingrad

This film still needs the logic from EM in order to be completed, and I'm still convinced that there is a lot I could offer to other indie film producers. However, I've decided to go ahead and merge as much of my EM functionality as possible with my OpenSimEarth branch, making it fit in more properly into the engine, and make as much as possible available to Torque developers. Wherever relevant and desirable, I'd love to PR specific items into the T3D trunk.

So anyway, back to that boring screenshot above. The one new thing you can see there is a "Scenes" dropdown menu, with "+" and "-" buttons next to it. What's going on there is the ability to load and unload (unload isn't plugged in yet) physicsShape actors into a scene, from my sqlite database. Once there, the new and exciting bit as mentioned above is the ability to record sequences. A call to my script function "startRecording()" will cause all actors to start saving their current node rotations and base node translation to internal arrays. Then a call to "makeSequences()" will cause them all to save these rotations into dsqs, named after their database sceneShape id.

This ability is not limited to physics ragdoll effects, you can also use it to record an actor running around the world and performing various actions, such that you could play back a whole scene from only canned anims and not have to run the physics and AI on those characters anymore.

It may seem crazy for me to be giving away the crown jewels of EM like this, but I'd rather have the participation and help of the Torque community than whatever money I could make off of this code around here. I am considering adding something along the lines of "Pro Tools" for OpenSimEarth, however, where I will enable export to FBX and/or BVH, and that could be where I get to charge my hundred bucks or so from the indie filmmakers.

Anyway, that's basically it for the moment. Expect more functionality and some working web presence at opensimearth.org/.com sooner or later.

And, because you made it this far, here's another screenshot, this time with some violence in it. I did shoot those guys, and I'm not even sorry.

http://opensimearth.org/images/ose_002.jpg

Right, networking is the other thing I'd like some community review on, I've just basically skipped it in my build, in favor of saying "ragdolls only happen on the client" and ignoring the rest.

Re: the joints as SimObjects, I would argue against that, personally. My goal is as many active ragdolls as I can get, and if I can run a ragdoll via a simple array of joints and bodyparts on the physicsShape, such that only physx needs to know about the details and physicsShape only needs to know where to put the nodes, then that seems like a win to me. Getting a bunch of Torque overhead tracking SimObjects for every active joint (and bodypart?) seems like a waste of game resources IMHO.

It does sound potentially worth it to just pack the physics descriptions into an XML file, however. I actually had that working at one point in EM, right before I took the red pill and went full SQL. It's a pretty trivial job, really.

The editor is another story... I did have a whole physics editor section in EM, but it was definitely awkward and imperfect. I'm in the midst of trying to stuff as much of my Ecstasy Motion logic as possible into the Shape Editor and Mission Editor right now as part of where I'm going with OpenSimEarth, so I'll see where that takes me.

Awesome, good to hear from you on this! I've actually finally been able to carve out a little time on my own here recently to push my stuff forward (look for near future OpenSimEarth updates) but I've been very much wanting to set out the whole physics project up for an in depth critique by the steering committee. I'd like to set it up for a pull request, but I agree, an sqlite database is not a good general solution. I initially used datablocks for all the joints, and for most practical applications that would probably work, but for my own (Ecstasy Motion) use case I wanted to provide too many potential joints at the same time and the load of having them all be datablocks became excessive. For my current work I've gotten so used to having a db handy that anything else is just a PITA and I don't have time :-) but it would be great if an optimal solution could be agreed upon at least, and then potentially could be picked up by a volunteer if I don't ever get around to setting it up.

.

Wow, thanks for digging up that docs page, that's really thorough!

Happens for me too, in Win 7, 32 bit build (I think). 64 bit box.

Nice!

Well, I haven't had much dev time recently, but just wanted to chime in and make this all ever so slighly less of a thankless job: THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU!!!!!!!!

Three cheers for the busy worker bees! =-)