chriscalef

It is not currently built into the engine, because the stock physics plugins do not include joints. There's nothing going on in that direction in bullet yet, to the best of my knowledge, but I took over Timmy's Physx3 project a while ago and added joints and ragdolls (though my ragdolls still need more work in terms of fine tuning joints, they are currently very unstable. That build can be found here (engine code): https://github.com/ChrisCalef/Torque3D/tree/physx3_advanced_WIP And the game directory for it with a precompiled binary is here, if you just want to play with it: https://github.com/ChrisCalef/physx3_advanced_game If you're attached to using bullet instead of physx, it should not be all that difficult to get the joints working in bullet, since the only work you should have to do is in the bullet plugin itself, and the rest of my work in the PhysicsShape and PhysicsJoint classes should be plugin-agnostic.

Three cheers for the ECS rewrite! Hip hip hooray! etc

Ah, yeah, it's never that easy. :-). You'd probably have to write your own clientside damage logic based on physx collisions, which would be less hack proof, but...

By default you're running a physics sim on the server as well as on each client, so if you want objects to run on the client and not get networked you would theoretically just say "simType=0" in the physicsShape datablock. I say "theoretically" because this actually hasn't worked for me, it seems they don't perform at all unless they are simType=2, which is client & server. For my current ragdoll build, I ended up running my shapes as client+server, but put all my bodyparts on the client, and only put a placeholder physics object on the server - I haven't decided yet what to do with the server side, will probably change that to a player controller or a capsule and use it for collision detection. Re: your crashing into a wall scenario, though, would it not work just as well to pass the event (driver crashed into wall at location xyz) and then spawn the actual physics blocks separately on each client? The game experience would be the same, the only thing different is each block wouldn't be exactly where it is on everybody else's machine. The lead driver probably won't even see the blocks because he's already speeding away though, so it shouldn't result in any noticeable artifacts. If the players were actively throwing blocks at each other or something like that, then you would definitely have to network them, but for the case you describe it doesn't sound necessary.

Paul, you're probably all over this aspect of it but if not, make sure you take a good hard look at whether you really need to network all the physics objects you're trying to network, ie are they all gameplay critical and interactive between different players? Because if there's anything that can be assumed to be only providing eye candy for one client at a time, you can simulate it and render it on that client and remove it from the network bandwidth. You probably already knew that though.

Hell of a nice wiki page! Buckmaster +1

+1 for this thread. I've always hated Torque's behavior but never enough to look into alternatives.

Ha ha, you got me. It's gotten to the point where I'll believe anything about Emacs. I've used it for years and years, by now I mostly only use it for writing notes to myself and for editing any text file that doesn't already have its own dedicated IDE, but yeah, damn I love it. The one thing I think I love above all else is the way I can effortlessly split and split and split the screen into as many frames as I need. I've had times where I was designing whole class hierarchies and had fourteen frames open. Get so tired of clicking on tabs and not being able to see everything at once in literally every single other IDE I've ever tried. :-P

WAAAT?? There's a TorqueScript package for Emacs??? But of course there is. Will be trying that out, thanks for the tip!

Just a quick note to say Hi, I LOVE YOU GUYS! Hugs and kisses all around.

Speaking of Awesomium, is it still an active thing? I thought I heard it had dropped off the map or diminished in importance. I'm still using it, but would love to switch to something more mainstream and especially open source, which brings to mind, has anyone tried or know anyone who has tried WebKit?

Ah, there it is, Quick Links! Even has an Active Topics right in there as well, unless you just added that. ;-) Request withdrawn.

Just wondering if anyone's considered doing this here, it's a handy feature for not incredibly active sites, to drop in every few days and be able to hit one link to get a list of every recent post from every forum, sorted by date/time. Low priority I'm sure, but thought I'd throw it on the list.

So... if the video's still processing then come back in a few minutes, but... I successfully addressed the most entertaining point on the above list: Yes, you can shoot them now! Although I haven't committed the script side yet because it's part of a new project, which as you can see merges my terrain pager and physx3 projects into one game build... master plan coming together... all it took on the script side is the following addition to WeaponImage::onFire (put it right after the "create the projectile object" block) ... //Add this for physics raycasting //TEMP! Hard coding it for basic pistol and rifle for first pass, but this // should be maybe a projectile property(?) if ((%this.getName() $= "RyderWeaponImage")||(%this.getName() $= "LurkerWeaponImage")) { %start = %obj.getEyePoint(); %start = VectorAdd(%start,VectorScale(%muzzleVector,2)); %vec = VectorScale(%muzzleVector,100); //TEMP! Define this in the (weapon or the projectile datablock)? if (%this.getName() $= "RyderWeaponImage") %weaponForce = 70.0; else %weaponForce = 95.0; //echo("casting ray from: " @ %start @ " in direction of " @ %vec); %id = physx3CastRay(%start,%vec,1);//0=static,1=dynamic,2=player,3=all if ((%id)&&(%id.getClassName() $= "PhysicsShape")) { %id.setDynamic(1); %id.aitp(%id.getContactBody(),VectorScale(%muzzleVector,%weaponForce)); } //end physics raycasting (Sorry if that is too confusing, here is the full function for reference) // ---------------------------------------------------------------------------- // A "generic" weaponimage onFire handler for most weapons. Can be overridden // with an appropriate namespace method for any weapon that requires a custom // firing solution. // projectileSpread is a dynamic property declared in the weaponImage datablock // for those weapons in which bullet skew is desired. Must be greater than 0, // otherwise the projectile goes straight ahead as normal. lower values give // greater accuracy, higher values increase the spread pattern. // ---------------------------------------------------------------------------- function WeaponImage::onFire(%this, %obj, %slot) { //echo("\c4WeaponImage::onFire( "@%this.getName()@", "@%obj.client.nameBase@", "@%slot@" )"); // Make sure we have valid data if (!isObject(%this.projectile)) { error("WeaponImage::onFire() - Invalid projectile datablock"); return; } // Decrement inventory ammo. The image's ammo state is updated // automatically by the ammo inventory hooks. if ( !%this.infiniteAmmo ) %obj.decInventory(%this.ammo, 1); // Get the player's velocity, we'll then add it to that of the projectile %objectVelocity = %obj.getVelocity(); %numProjectiles = %this.projectileNum; if (%numProjectiles == 0) %numProjectiles = 1; for (%i = 0; %i < %numProjectiles; %i++) { if (%this.projectileSpread) { // We'll need to "skew" this projectile a little bit. We start by // getting the straight ahead aiming point of the gun %vec = %obj.getMuzzleVector(%slot); // Then we'll create a spread matrix by randomly generating x, y, and z // points in a circle %matrix = ""; for(%j = 0; %j < 3; %j++) %matrix = %matrix @ (getRandom() - 0.5) * 2 * 3.1415926 * %this.projectileSpread @ " "; %mat = MatrixCreateFromEuler(%matrix); // Which we'll use to alter the projectile's initial vector with %muzzleVector = MatrixMulVector(%mat, %vec); } else { // Weapon projectile doesn't have a spread factor so we fire it using // the straight ahead aiming point of the gun %muzzleVector = %obj.getMuzzleVector(%slot); } // Add player's velocity %muzzleVelocity = VectorAdd( VectorScale(%muzzleVector, %this.projectile.muzzleVelocity), VectorScale(%objectVelocity, %this.projectile.velInheritFactor)); // Create the projectile object %p = new (%this.projectileType)() { dataBlock = %this.projectile; initialVelocity = %muzzleVelocity; initialPosition = %obj.getMuzzlePoint(%slot); sourceObject = %obj; sourceSlot = %slot; client = %obj.client; sourceClass = %obj.getClassName(); }; MissionCleanup.add(%p); //Physics: do a castRay, IF this is a weapon which should do this. //TEMP! Hard coding it for basic pistol and rifle for first pass, but this // should be maybe a projectile property(?) if ((%this.getName() $= "RyderWeaponImage")||(%this.getName() $= "LurkerWeaponImage")) { %start = %obj.getEyePoint(); %start = VectorAdd(%start,VectorScale(%muzzleVector,2)); %vec = VectorScale(%muzzleVector,100); //TEMP! Define this in the (weapon or the projectile datablock)? if (%this.getName() $= "RyderWeaponImage") %weaponForce = 70.0; else %weaponForce = 95.0; //echo("casting ray from: " @ %start @ " in direction of " @ %vec); %id = physx3CastRay(%start,%vec,1);//0=static,1=dynamic,2=player,3=all if ((%id)&&(%id.getClassName() $= "PhysicsShape")) { %id.setDynamic(1); %id.aitp(%id.getContactBody(),VectorScale(%muzzleVector,%weaponForce)); } } } } Obviously it's still in its raw and cluttered state of "just barely got it working this morning", but it seems to be on the right track anyway.

Ah, there we go... Now we can drive kinematic bodyparts around as expected. Remaining goals: 1) start moving actors around the world in realtime, making sure above still works 2) build a game with a player in it and hook up the rifle to effectively shoot them 3) fix all the single-player-game assumptions 4) eventually figure out what's up with the knee/elbow joint orientations. Possibly move on up to latest greatest physx, currently still on version 3.3.1.

Thanks! Oh btw, meant to post it earlier, but that transform problem is gone now and changes pushed to github, was due to a minor oversight.

Like. Nice work! I always loved that Mayan Temple pack.

Minor improvements: got setDynamic(bool) and setHasGravity(bool) functioning, as well as setPartDynamic and setPartHasGravity. Still WIP status, remaining most immediate issues are: 1) we still have an offset problem, when actors start out kinematic and later change to dynamic, they are rendering the shape mesh out at double the main body transform 2) knee/elbow joints reveal an apparent bug in physx3 (?), or else some fundamental misunderstanding on my part, because: I have succeeded in rotating the physx view of my joint limit cone to exactly where I want it, judging by the debug render view anyway, but in practice the limit cone is always right down the center, and the knees and elbows bend backward exactly as much as they bend forward. Will probably try limit planes next. 3) finally, I also haven't set up the kinematic side yet to drive the physx bodyparts with the nodeTransforms.

I definitely agree. When you forget the big leagues and consider "the competition" to be only the other open source engines, Torque is a hell of a contender still, esp with things like openGL/linux finally part of the main trunk, and then the full set of editors and being able to just click on "host game" or dedicated server right out of the box. I was one foot into Ogre once, but that was a hell of an impediment when I realized how much other work had to be done that was just sitting there in Torque. If we could really focus on backing away from shapebase and all the other tribes-oriented code and get the entity component thing and assimp hooked up so people didn't have to deal with our DTS/DSQ toolchain, we could still be a force to be reckoned with.

Yeah, it's definitely a lot of work, and it's probably out of reach at this point to try to assemble and maintain full starter kits for all the different game types, that would only work if each had their own community of interested volunteers working on that type of game. However for myself, I'm already engaged in my multiple branch strategy and plan to continue with everything I can componentize out of my current code. The problem with _not_ doing it this way is the problem I've experience so many times before and am currently in the midst of with Ecstasy Motion - you end up with such a massive pile of "everything but the kitchen sink" code piled into one project that it becomes useless to anyone else and very hard to maintain in its own right. For me this got so bad that I pretty much gave up on maintaining EM as is, and instead I'm grabbing everything useful, bit by bit, and dragging each bit into the future with current T3D and physx3. I plan to open source most of the bits, maintaining only enough closed source code to make the actual end product not be something any idiot can just download for free, but still allowing torque devs to have access to 90% of it. (My real target customers are indie film makers, so I don't think I'll lose a lot of sales with this strategy, and hope to gain some positive feedback and maybe road testing of various features etc by doing it this way.) Meanwhile re: the game I'm also putting together, I do hope to be able to share code and resources with your project, but even though Uebergame is very flexible, I think what I have in mind is different enough that combining the two projects would not be feasible. Hopefully anything useful from mine will be trivial to import into yours via git merge though, if my multi branching scheme is successful. While I'm at it I guess I'm spilling some beans here so I might as well spill more - and life is busy of course so don't hold me to a deadline - but the game I want to build is going to be an open world sandbox game, sort of Rust combined with Second Life but placed on the actual Earth using my FlightGear world server project, anywhere the player wants to play it. Re: the competition between engines, definitely open source is our power - it is actually the only reason I'm back here again, I almost totally gave up on Torque back in the day. In the process I got so burned out on having my core business plan completely under the thumb of a private company that I vowed a solemn oath to _never_ again put my work on top of a code base over which I did not have complete ownership. For this current game I want to make, having it be fully open source is a key component of the plan. Which reminds me of a question I've had for a while: has there been a thread on this site or GG.com that extensively lays out the current competition in terms of open source engines? I'd like to know where we stand there, is there anything yet that is as game ready as Torque, with editors and efficient networking code out of the box? Not looking to switch, mind you, just wondering.

I can't say for sure it isn't a local issue, but to replicate the bug, if you have it, simply create a new mission, add a forest, create some trees, save it, and see if the trees are still there when you reload it next time.

On the subject of an open source game... I've been thinking about this a lot, because I have my own plan in the fairly near future to combine the work I've been sharing into my own open source game. The thing with open source games, as Dan pointed out and Duion has been noticing, is that it's really really hard to get any substantial number of people to work on them, because there are as many visions for the final result as there are people involved. While the team may have a lot of agreement on features and components, in my experience when it comes down to final content, story, etc it is nearly impossible to get agreement because everyone has their own vision. As a solution, I'd like to propose that instead of putting all of our eggs into a single game project, we instead take an approach of putting as much work as possible into modularized components that can be released as separate git branches or resource libraries. We've always wanted solid starter kits for different game types, but with everything going to MIT and git it seems like this might start to be achievable. What if we had branches for commonly used features in FPS, RTS, MMO, etc, and as much as possible broke out independent features in sub branches in as granular a way as possible, and then built our open source game(s) by merging the branches we needed? That way we could share as much of our work as possible without getting stuck on whether we're going to support X's game or Y's game as "the" open source game for the community. It would take a little more work to keep all these branches up to date with the main engine progress, but it would seem worth it if it allowed the work to be useful to and draw input from a lot more community members than just the team working on one game, and maybe we could get some contributions from some of the non-open-source projects out there as well once the ball started rolling.

And, WHEW. Was an all weekend project, but they are now working from any direction. Still the same joint limits, iterations, etc. issues, but the key transform problems appear to all be solved at this point. EDIT: Oh yeah, also I moved gravity out to a pref in scripts/client/prefs.cs, but I took that file out of the repo so you'll have to add this yourself if you want a non default gravity: $pref::Physics::gravity = "0 0 -1.0"; The above is very light gravity, handy for fine tuning joints, but normal is more like -9.8.

Ah, hehe, whoops! Spoke too soon. Currently they work fine unless you happen to want to start them rotated in any way other than identity. :-P Working on it...

Okay, no further progress to report except code cleaned up and committed, so grab updates if you're interested. @Mango, not sure what you mean, were you bringing in models with animations or was physics involved? I shouldn't have to worry about constraints (until we get to the next phase, that is) since all I'm looking at is driving kinematic rigid bodies with the animation data. The really fun part (I've done this already in Ecstasy Motion, just not here in stock Torque physx) is when you start driving joint forces with animation data. It looks pretty weird and is definitely a very different product from the original animation, but if you're planning for that it can be really cool.