Default Amethyst Processors and Components for ECS

[LucioFranco]

This issue is to keep track of all the systems that will need to be implemented for amethyst engine.

Systems

• Transform | Issue: (#53), PR: (#113)
• Rendering | PR: (#85)
• Scripting
• Audio

Components

• Transform
• Velocity?
• Renderable

Feel free to leave a comment and/or create a PR. Let us know if you are working on one by leaving a comment.

[JohnDoneth]

Should networking be a target?

For example: Some sort of automatic serialization and transmission of structs over the std library networking functions.

[JohnDoneth]

Should networking be a target?

For example: Some sort of automatic serialization and transmission of structs over the std library networking functions.

[ebkalderon]

@JDoneth That is correct, but off-topic. Networking is an engine-level feature and not an ECS (entity-component-system) feature. This issue deals with implementing systems in the ECS sense. Personally, I prefer the term "processors" to eliminate confusion.

[ebkalderon]

@JDoneth That is correct, but off-topic. Networking is an engine-level feature and not an ECS (entity-component-system) feature. This issue deals with implementing systems in the ECS sense. Personally, I prefer the term "processors" to eliminate confusion.

[JohnDoneth]

Ah sorry, my bad, I saw systems and thought engine modules. I understand ECS, but this topic doesn't mention ECS.

[JohnDoneth]

Ah sorry, my bad, I saw systems and thought engine modules. I understand ECS, but this topic doesn't mention ECS.

[ahmedaliadeel]

Position and velocity shouldnt be separate components. If u use 3rd party physics like nphysics or bullet bindings u get rigidbody access. We need to provide a rigidbody component.

[ahmedaliadeel]

Position and velocity shouldnt be separate components. If u use 3rd party physics like nphysics or bullet bindings u get rigidbody access. We need to provide a rigidbody component.

[Emilgardis]

I think that they should be separated, I don't see any reason why they shouldn't. Having them together means more work for the engine, i.e computing if a object is static (not moving) or dynamic (moving).

::Update:: Now when looking at the nphysics repo which seems the most mature lib for this kind of stuff, it seems that it inside nalgebra, there is support for PositionXd with Points. However, how much should amethyst integrate nphysics?

[Emilgardis]

I think that they should be separated, I don't see any reason why they shouldn't. Having them together means more work for the engine, i.e computing if a object is static (not moving) or dynamic (moving).

::Update:: Now when looking at the nphysics repo which seems the most mature lib for this kind of stuff, it seems that it inside nalgebra, there is support for PositionXd with Points. However, how much should amethyst integrate nphysics?

[ahmedaliadeel]

I haven't explorered the nphysics yet but based on my experience on unity 3d i was suggesting this idea.
Look, its not just velocity or angular velocity there is much more about a physical body. Like i want to know velocity at certain point?
Let me explain in detail for a different perspective. I think we should have separate components and respective subsytem for both 2d and 3d.
Talking about the granulity of components incase of 3d physics we should provide components the way most physics engine api is natural to map. Physix, bullet both have to concept of rigidbodies, colliders etc
For kinemetic physics we can just add a property to rigidbody component that this object is not dynamic. (As of know nphysics doest support kinemetic bodies) or if its an unmovable static body etc.
Now that i have discovered this project i will also try to implement a reference set of components and subsystem.
Thanks for consideration.

[ahmedaliadeel]

I haven't explorered the nphysics yet but based on my experience on unity 3d i was suggesting this idea.
Look, its not just velocity or angular velocity there is much more about a physical body. Like i want to know velocity at certain point?
Let me explain in detail for a different perspective. I think we should have separate components and respective subsytem for both 2d and 3d.
Talking about the granulity of components incase of 3d physics we should provide components the way most physics engine api is natural to map. Physix, bullet both have to concept of rigidbodies, colliders etc
For kinemetic physics we can just add a property to rigidbody component that this object is not dynamic. (As of know nphysics doest support kinemetic bodies) or if its an unmovable static body etc.
Now that i have discovered this project i will also try to implement a reference set of components and subsystem.
Thanks for consideration.

[kvark]

@ahmedaliadeel yes, while rendering 2D/3D is mostly uniform, physics gets definitely much more complicated, so it kinda makes sense to separate 2D and 3D components for it. Looking forward to see what you'll come up with!

[kvark]

@ahmedaliadeel yes, while rendering 2D/3D is mostly uniform, physics gets definitely much more complicated, so it kinda makes sense to separate 2D and 3D components for it. Looking forward to see what you'll come up with!

[Aceeri]

I think a networking system might definitely be a goal for this. For instance, automatic sync between a server (or maybe P2P?) for specified components.

[Aceeri]

I think a networking system might definitely be a goal for this. For instance, automatic sync between a server (or maybe P2P?) for specified components.

[Aceeri]

Outdated, kind of handled in separate issues like scripting and physics.

[Aceeri]

Outdated, kind of handled in separate issues like scripting and physics.