Creating aggregate objects.

#1 I cordially dislike bumping, but this is a work-stoppage issue. You mean to tell me that nobody, not even Melv, has any idea how to build aggregate objects under T2D?

#2 As far as I can tell, you mean something similar to what David did in his demo, with the main boss robot made up of multiple shapes that can be "shot off"?

I'm not sure what he did, but the code may be around in some form somewhere here in the forums, or maybe he can give a brief synopsis!

If that's not what you mean, then sorry, hehe.

#3 I believe he just mounted the differing parts of the boss to create the entire big boss. As a certain area was damaged enough, it was unmounted.

#4 Specifically, what I'm trying to do is create a bare scene object with no collision, attach some scene objects to it that are purely collision objects (no sprites/etc), and then attach a sprite object to it (no collision). This doesn't seem to be working. If you need me to post code, I can.

#5 I think it's always safe to assume that code is needed. Post a stipped down version of what you have and perhaps we can provide input based off of that.

#6 In Melv's defense, he might be too busy or too tired to reply to every request to explain the engine's inner workings. Let's not lean on him too much. The poor guy's already killing himself just to finish the engine. :)

There's no way he can reply to the increasing flood of posts in these forums. And we're better off if he doesn't, since he should use the free time he has to work on the engine. Remember, he's got a separate fulltime job and a family (which is also a fulltime job).

But anyway....

#7 Sorry, I seem to have missed this post.

Just to be clear on what you're trying to achieve; you want to use fxSceneObject2Ds that are mounted together in hierarchy or hierarchies, all of which will ultimately be linked to a larger object that will serve as the base rotation point? The problem is that you're just not seeing the collision volumes?

If you want the collision volumes to show-up, you need to activate the collisions themselves on the objects. I made a minor mod so that they only show if they are active. This is easy to change and I was even toying with showing the lines up stippled in they are inactive.

If you want to change this, you'll can change the debug rendering code here...

void fxSceneObject2D::renderObject( const RectF& viewPort, const RectF& viewIntersection )

... specifically ...

if ( (getCollisionActiveSend() || getCollisionActiveReceive()) && (debugMask & fxSceneGraph2D::FX_SCENEGRAPH_DEBUG_COLLISION_POLYS) )

... by removing the "getCollisionActiveSend()" and "getCollisionActiveReceive()".

Does this help at all or is there some other aspect you're interested in?

- Melv.

#8 For the record, yes, the boss in CB is made up of a central invisible object (ie: never gets an image block assigned to it) with disabled collision, and the various arms and such are children. When they get destroyed, as Stephen said, they are indeed unmounted and then given a random velocity. After a short time, they generate a particle effect and are deleted.

The actual body of the boss has collisions disabled and is just there as a visible reference. If you want to see it, press CTRL-D during the game to get Melv's debug stats. :)

Since collision geometry has nothing to do with the image, you can have invisible objects that send/receive collisions. I see no reason why what you are attempting wouldn't work, but then again I have never tried to set a collision object with no image.

#9 Oh, um, never mind. Apparently, I spelled fxSceneObject2D without the 2D in my code. As I went to copy it in, I found the error. Thanks anyway ;)

#10 Now that I have the mounted stuff working, I'm running into some other issues. The problem is that forces and such do not appear to be transmitted from a mounted child to its parent. Without that transmission, there's no way to make this work. After all, what good is it to set the collision response to be active for the child if the object it is mounted to doesn't change direction? Right now, the collidable object gets to push through the world limits that should bounce it off.

#11 Smaug,

The mounts don't act like particles with a constraint between them or anything like that at the moment. The reaction is only unidirectional from parent to child at this point; the whole body doesn't react as one. This system still provides alot of functionality and is very useful. Lots of work still to be done, oh so much work!

I'm sorry that this doesn't enable you to do what you want.

Work to be done is to integrate a check in the fxSceneObject2D collision code that, upon encountering a collision, checks to see if the object is part of a rigid-mount and then propogates that force up the chain. We also want to add some kind of basic hinge/pivot constraints as well.

The mounting code was written in the early days before I was going to publish T2D so it has yet to 'catch-up' feature-wise but will get done in the near future.

- Melv.

#12 Smaug,

On another note and regarding an object having multiple collision volumes; have you looked at how the fxTileLayer2D handles collisions? It has essentially a parent collision object by default but also has child collision objects (tiles) that are created dynamically.

The reason I mention this is because this is an abstracted process and any custom object can use this feature.

The collision detection process uses a call to "fxSceneObject2D::getCollisionAreaPhysicsModels()". By default the fxSceneObject2D pushes the default parent physics model (single one that all objects use by default) into this vector and that would normally be the end of it. It does this in its "onAdd" like so...

// Default to Global Physics Mode.
// NOTE:- This list can be overriden by custom objects.
mCollisionPhysicsModelsList.push_back( &getParentPhysicsModel() );

If you derive another object and you want multiple volumes, simply push your physics models (each having its own position, size, orientation, collision-poly etc) into this vector and the system will monitor the collisions for you. If you want to do some custom work when they collide (in C++), simply override the virtual member...

void fxSceneObject2D::onCollision( const fxPhysics2D::tCollisionStatus* pCollisionStatus )

... and decide what you want to do.

After the next bug-fix update, I'll be adding custom responses to include things like "none, clamp, sticky, bounce, rigid etc" so "setCollisionPhysics()" will become "setCollisionResponse("bounce", "none")" and this will be detailed in the "tCollisionStatus" as well so that you can either call the appropriate stock function (to get your response) or ignore if and want to do your own. Any extension to the enumeration for responses will be ignored by stock T2D and you can do the response in your object alone without confusing T2D. The advantage here being that you can use the same interface calls to setup the object.

I'm not sure if this will be useful in your endeavours but I thought I'd point this out as there seems to be some overlap with the work you're doing that I didn't point out before.

- Melv.

#13 Most interesting. So the relationship between the fxSceneObject2D and the collision/physics stuff really is a "has a" relationship rather than "is a". It also seems that things like position, orientation, and so forth of fxSceneObject2D really comes from fxPhysics2D.

So, from a C++ perspective, it seems like it would be possible to bypass fxSceneObject2D and use fxPhysics2D objects directly. Not that I'm suggesting such a thing, mind you.

Also, from looking at more fxSceneObject2D code, it seems that, in order to allow for a scene object with multiple collision volumes along with all of the other expected scene object stuff, the sizes of each fxPhysics2D object will need to be constant.

#14 Yes, "has a". The idea for the future was have this "has a" also being a module that was late-bound rather embedded as it is now. Different "models" for different collision/physics parties.

The fact that fxPhysics2D "contained" the physical attributes of position/size etc was deemed not the best way to go. We want to be able to bind the collision/physics module at runtime so that they become objects that hook into the fxSceneObject2D and its attributes such as position but can vary from physics model to model and also keeps them as light as possible. This would make generating new collision/physics models much cleaner and abstract. In the same way though, manipulating the fxPhysic2D object would result in altering the hooked fxSceneObject2D indirectly. As you've obviously seen, the calls such as "setPosition()" are simple pass-throughs to the respective fxPhysics2D object. Accessors such as "getPosition()" do the same.

Whether this will happen soon (or at all) is one of the many things Josh and I will be discussing when he gets back for plans for the months ahead. Lots of work, little time.

With respect to multiple collision "volumes"; there is no expectation that the sizes of each fxPhysics object need to be constant (if I'm understanding your reference to "sizes" correctly). The tile-layer has a physics model for each collidable tile (one of the reasons why we're going to work on making this more lightweight). When an object decides to "send" a collision, this area (expanded with the objects velocity) is used to interrogate which relevant physics models (from the object itself) need to be checked. They are checked sequentially (at the moment) and responses made. The responses can (or will soon) be totally customisable (but you can override in C++ anyway). This is the worst case where everything is dynamic, including the physics models. I don't think you need this?

If your object is comprised of several fxPhysics2D objects that each have their own position, size, orientation, collision-poly, you can simply post these into the vector (mentioned above) and the system will get you to the point where you can decide what to do. In this case you may want to apply torque to the main object or just make it go bang, whatever. Presumably these positions will need to be managed with something similar to the mounting system. You can, of course, update their positions/orientations each-frame using whatever system you like as T2D wouldn't touch them by default unless you wanted an autonomous response.

I think I've covered everything here but it is early and I've yet to have my morning coffee (so essential to brain activity for me) so if you've got any futher questions or if I've missed anything vital then fire away.

- Melv.

#15 Melv, that's an excellent write-up. I hope it becomes clearer and clearer to everyone how much time we spent considering how to do these systems, and deciding carefully on the designs we used. Not that we did everything perfect, but we always kept in mind "this seems the best way to do it for the general engine, and let's be very careful to make things as easy to replace, change, or extend as possible". The physics system is a good example of that. It's not totally done yet, but the basis for a very nice extension system is there.