Particle engine

I’ve been thinking of that too, and the answer right now is - pull meep, and use particle engine either by itself, or as part of meep (via ECS system). Both options will work, using the particle engine without ECS is more work, but not too much more, and you can always just check ParticleSystem class to see what needs to be done.

Size matters

I think most people wouldn’t want to use meep as a whole thing, the culture in web-dev these days is to use a bunch of smaller "middleware` components, and as such, having particle engine as a separate library would be more useful for majority of users I think. Doing that packaging for me is a bit of a pain, but I think I should do it at some point, even if as a snapshot of current state.

Pain

To clarify, why I say it’s a pain, the particle engine is made possible thanks to a large number of smaller powerful components that meep is built out of, such as packing algorithm that the atlas system uses, the automatic atlas, binary utilities, sorting algorithms, material management tools, and spatial index, to name a few. I work on the engine as a whole, it’s imported into my projects as a git module, and ripping out the particle engine would require either making a snapshot that would need to be manually updated every time, or doing some major refactoring in the meep engine to break it into a number of git modules.

Why

The “Particular” (working name) engine has a number of neat things, and it’s most pragmatic engine I know of, feel free to take it with a grain of salt - since I’m the author. But it does have a bunch of limitations currently, chief among them is accessibility and ease of use for new users. I made a handy diagram in another thread, here it is, I suspect it will prove useful to many people who are curious about the engine:

2 Likes