Entity/Component System R&D Discussion
by Jeff Raab · in Torque 3D Professional · 07/24/2014 (1:56 pm) · 105 replies
Continued from here: www.garagegames.com/community/blog/view/22794
Per Dan's suggestion, lets move the hardy discussion and specifics into a thread, where the back and forth is more practical
The problem with calling anything directly is for it to correctly type, we'd have to know the specific component's class.
So lets say we want to have a few different colliaion components, to handle various circumstances:
BoxCollider, CapsuleCollider, SphereCollider, MeshCollider.
They have the same basic getCollisionInfo(), hasCollided(), etc calls, but the work they do in them is particular to themselves, right?
So if you wanted your Physics component to correctly call the component's function directly, there's 2 ways to do it.
Either we have an intermediate class 'CollisionComponent' all physics components inherit from, which bulks the heirarchy while still having us use virtual functions anyways, or the Physics component just knowing about every type of collision component we have and checking against them all.
So we have our physics component would have to figure out what component it is to correctly call the function in question. It also means we're adding to the number of headers we have to compile in, increasing compile times. If you wanted to add a new collision component, you'd have to add in the header and typing stuff for the new collider as well.
Then lets say we need to have more than one kind of physics component, such as SimplePhysics, RigidBodyPhysics, SoftBodyPhysics, etc, etc.
We multiply the above considerations for each.
Pretty fast you're going to end up with a ton of excess cross-references just so you can call the functions directly. It'd raise compile times and make adding new components kind of a pain.
With the interfaces as-is, it may be kinda ugly, but none of the above are problems.
You standardize the interface and it's functions, and those virtualize to the component's own interpretation of the interface calls, and does it's work.
This way, the components don't at all care what the other components are, and the same for Entity-Component interactions.
The code may be ugly, but the usage is a lot cleaner and robust.
Unless there's away around the nexus-of-pain of cross-references mentioned above?
Per Dan's suggestion, lets move the hardy discussion and specifics into a thread, where the back and forth is more practical
Quote:
Is there a better place we should discuss this? I was thinking... why are interfaces separate from components? AFAICT, the purpose of an interface is to say 'find me a component on which I can call "getVelocity"'. Could components not do that themselves? Since the whole system relies on dynamic_cast anyway, that is. I guess this would look like components inheriting particular interfaces.
The problem with calling anything directly is for it to correctly type, we'd have to know the specific component's class.
So lets say we want to have a few different colliaion components, to handle various circumstances:
BoxCollider, CapsuleCollider, SphereCollider, MeshCollider.
They have the same basic getCollisionInfo(), hasCollided(), etc calls, but the work they do in them is particular to themselves, right?
So if you wanted your Physics component to correctly call the component's function directly, there's 2 ways to do it.
Either we have an intermediate class 'CollisionComponent' all physics components inherit from, which bulks the heirarchy while still having us use virtual functions anyways, or the Physics component just knowing about every type of collision component we have and checking against them all.
So we have our physics component would have to figure out what component it is to correctly call the function in question. It also means we're adding to the number of headers we have to compile in, increasing compile times. If you wanted to add a new collision component, you'd have to add in the header and typing stuff for the new collider as well.
Then lets say we need to have more than one kind of physics component, such as SimplePhysics, RigidBodyPhysics, SoftBodyPhysics, etc, etc.
We multiply the above considerations for each.
Pretty fast you're going to end up with a ton of excess cross-references just so you can call the functions directly. It'd raise compile times and make adding new components kind of a pain.
With the interfaces as-is, it may be kinda ugly, but none of the above are problems.
You standardize the interface and it's functions, and those virtualize to the component's own interpretation of the interface calls, and does it's work.
This way, the components don't at all care what the other components are, and the same for Entity-Component interactions.
The code may be ugly, but the usage is a lot cleaner and robust.
Unless there's away around the nexus-of-pain of cross-references mentioned above?
#102
Ah, crap, you're right. I was deleting my test materials and it looks like I got carried away and cleared out ones used for UI stuff. I'll get a fixed template uploaded shortly.
01/17/2015 (12:08 am)
@ChrisAh, crap, you're right. I was deleting my test materials and it looks like I got carried away and cleared out ones used for UI stuff. I'll get a fixed template uploaded shortly.
#103
I'm looking at dropping this current build into another up to date T3D project... I know it's a WIP (and I'd be glad to help with stuff like changing all the Behavior class names to Component, etc) but I'd really like to start using it with my physx build.
However I just wanted to double check to see if you can point me at anything I'd have to go to outside the components directory to make it work. I checked both your commit histories but they both started with "big messy upload of entity component stuff" that had 1620 or so files changed. :-) I wonder if that was your stuff plus a merge of some T3D updates?
Anyway, I've got a lot to do for a while just getting my refactor in order, so I'm probably not going to jump on this part right away, but please let me know if you remember anything important.
01/19/2015 (10:14 am)
Hey Jeff,I'm looking at dropping this current build into another up to date T3D project... I know it's a WIP (and I'd be glad to help with stuff like changing all the Behavior class names to Component, etc) but I'd really like to start using it with my physx build.
However I just wanted to double check to see if you can point me at anything I'd have to go to outside the components directory to make it work. I checked both your commit histories but they both started with "big messy upload of entity component stuff" that had 1620 or so files changed. :-) I wonder if that was your stuff plus a merge of some T3D updates?
Anyway, I've got a lot to do for a while just getting my refactor in order, so I'm probably not going to jump on this part right away, but please let me know if you remember anything important.
#104
Should be done tomorrow so that'll make your mergings nice and easy.
I'd say it takes about an hour, hour and a half of concentrated effort. It's actually a good deal easier to merge in than you'd imagine.
The E/C stuff itself is pretty self contained, most of the retooling is in the editor stuffs, along with convenience upgrades I've implemented and just haven't had a chance to PR yet.
Like the RotationF math class. You pass it a Euler, AxisAng, Quat or MatrixF and it converts it internally. You can even tell it if what you're passing in is radian or degrees.
Then later you can request it to return out as any of those above types in either radians/degrees and it does all the conversion work for you so it's super clean.
Entity uses it for it's rotation stuffs. It makes it really easy to do go-betweens with passing the entity's rotation transform to the rest of the engine, or spitting it out as a human-readable euler for scripts.
You can check the Entity's rotation field out if you wanted to look at that in particular.
But yeah, should have the next update tomorrow night. Updated more components to work with the new system, did a bit more touchups on prefabs, fixed the stock art included with the EC template and it'll be updated to devhead.
I'm also brewing some new grass art assets as well, so you can look forward to those ;)
A taste, for your curiosity(fps is for the debug build, unoptimized art):
For full sized:
ghc-games.com/public/gc_test3.png
01/19/2015 (8:57 pm)
I actually started porting it to devhead tonight.Should be done tomorrow so that'll make your mergings nice and easy.
I'd say it takes about an hour, hour and a half of concentrated effort. It's actually a good deal easier to merge in than you'd imagine.
The E/C stuff itself is pretty self contained, most of the retooling is in the editor stuffs, along with convenience upgrades I've implemented and just haven't had a chance to PR yet.
Like the RotationF math class. You pass it a Euler, AxisAng, Quat or MatrixF and it converts it internally. You can even tell it if what you're passing in is radian or degrees.
Then later you can request it to return out as any of those above types in either radians/degrees and it does all the conversion work for you so it's super clean.
Entity uses it for it's rotation stuffs. It makes it really easy to do go-betweens with passing the entity's rotation transform to the rest of the engine, or spitting it out as a human-readable euler for scripts.
You can check the Entity's rotation field out if you wanted to look at that in particular.
But yeah, should have the next update tomorrow night. Updated more components to work with the new system, did a bit more touchups on prefabs, fixed the stock art included with the EC template and it'll be updated to devhead.
I'm also brewing some new grass art assets as well, so you can look forward to those ;)
A taste, for your curiosity(fps is for the debug build, unoptimized art):
For full sized:
ghc-games.com/public/gc_test3.png
Associate Chris Calef
BrokeAss Games
I'm also observing the missing textures in the entry GUIs, I'll poke around here and see if I can copy them forward from your earlier build, but you might want to check to see if you committed everything.
EDIT: found the first issue, missing gui background texture, in missing art/gui directory, but still same crash later. Seeking...
EDIT EDIT: Found it, it was crashing on your new ConvexShape() at the end of the mission, tried a couple attempts at giving it easy textures/materials but let it drop there. Still missing the texture for the grass, but getting an impressive sunset display of huge crowds of orange no material billboards! :-)