I have now my new missile models in action including the new obstacle avoidance behaviour…
as well added the possibility to pick any weapon including the initially default twin miniguns
And the scene is the first trial of a training ground, not yet satisfied with it, needs another couple of iterations, but to try out the weapons it is just perfect
The bullet integration is the whole point of this code. Other physics libraries would follow a similar pattern but it’s all bullet-specific glue code.
Really only the handful of components are possible reusable (like Mass, Impulse, etc.)… but since bullet is float-based, I made these float based. I have similar components in my own mphys boiler plate glue code but they are all double-based.
Got a basic debug app state working… and ghost objects… but I don’t publish contacts yet so it’s not like that matters much:
Also actually checked some source code in. Still very much a work in progress.
Bullet/SiO2 integration:
Demo:
It takes some finagling to get it to compile and you have to work against snapshot versions of some other simsilica stuff… that will all be resolved when it’s done.
I don’t know if its a great idea to mix 2D and 3D stuff like that though. I know its just a dimension off, but it sounds really lazy. One dimension is a third of the work. I’d probably go for a separate 2d implementation tbh.
great work @pspeed. I have a similar approach on using Zay-ES in combination with Bullet. I keep a concurrent map of EntityId and PhysicsRigidBodys, and update the position of the model (set Position component) after the physicstick.
Really looking forward to how you will handle PhysicsCharacters.
Got some little dudes randomly wandering around to show my approach to controlling mobs. I’ve never really used PhysicsCharacters so I don’t know what advantage they provide. My other physics engines never had them so I got used to doing things a different way.
Here are a few little mobs randomly wandering around:
With debug view and some debris:
Next step is to hook up contact detection so that the wanderers can also do some simple object avoidance.
Maybe the answer will be in your next step, but how will you handle a combination of steering behaviours? Now you have a wanderdriver controlling an entity. But what if you want an entity to , for example seek a target but also flee from another target?
I am just wondering how you would fit this steering behaviour in an ECS. You could have a SteeringComponent with a type, like Seek or Arrival. But then you couldn’t combine these, since you can only have 1 component of a specific type. You could ofcourse have a SeekComponent and ArrivalComponent but then your system will get very complicated and messy since you would have to combine the forces of both goals.
As I understand and how I will probably implement it, is using the suggestion of @pspeed of having a control driver with the desired behaviour contained. You have for example a LocationDriver that would go to a location (seek and arrival behaviour combined) and in the meantime would also avoid objects or entities (evade behaviour). The list of entities to avoid can be set on the location driver component, but then again I don’t know if this is bad practice (I don’t like the idea of having list of entities somewhere)… still figuring stuff out
This is a whole other topic probably not relevant to a WIP thread.
…I personally use a “Goal” object. The steering driver uses that goal to figure out which steering primitives to configure.
Edit: though to be honest there is a steering type as well that is what controlled adding the steering driver in the first place. And this steering type generally implies a specific stack of steering primitives… whether arriving or seeking or whatever.