froggy VS three

What I found in practice is that many people start using the ECS for speed, and then draw themselves into a corner of the design space. Now they have to weight every step on "how would it work in ECS?", and dedicate effort to fight the ECS paradigm.

For example, a mesh may contain multiple materials. Is each material chunk a separate entity? Or maybe each bone in a skeleton is a separate entity with its own "parent" and "transform" plus other component.

One of the different approaches is component graph systems [1]. It lacks the ability to mix and match components, but provides a more natural (and simpler) model to program for.

[1] https://github.com/kvark/froggy/wiki/Component-Graph-System

I had similar motivation back in the day for CGS in https://github.com/kvark/froggy, which was also powering https://github.com/three-rs/three. It's nice to see Rust ecosystem not locking itself on ECS, even if they are so cool :)

Rust has ways to deal with mutability. Three-rs [1] uses a classic scene graph tree, like ThreeJS. It's based on Froggy [2], which is a general low level primitive for building a "traditional" topology of the classes.

[1] https://github.com/three-rs/three

I had similar motivation back in the day for CGS in https://github.com/kvark/froggy, which was also powering https://github.com/three-rs/three. It's nice to see Rust ecosystem not locking itself on ECS, even if they are so cool :)