Support non-sprite rendering?

[johanhelsing]

Maybe this is out of scope, but Bevy doesn't currently support additive rendering of sprites. There are ways to use your own shaders (Mesh2dMaterial) for 2d, though.

Just wondering if you'd like to try to support other types of 2d materials?

[abnormalbrain]

This is an interesting thought. I've not looked at Bevy's Mesh2dMaterial previously, but that would be something nice to support. I don't think it'd be super difficult.

Instead of just having a Handle<Image> for default_sprite, we could introduce an enum that would have a Sprite(Handle<Image>) and a Material2d(Mesh2dMaterial) member. What do you think @johanhelsing?

Probably would be good to change default_sprite to something like renderable or similar. This would open up the avenue to 3d support as well.

[johanhelsing]

It would definitely be cool if it was possible to implement your own renderer. Perhaps through a ParticleRenderer trait or somesuch?

I would at least like to add one for bevy_smud to render sdf shapes if possible.

[abnormalbrain]

Looking at bevy_smud, it seems like an entity just has to have the right set of components for the extractor and such to find it, right?

Maybe a particle system can take an optional spawn callback which takes in a Commands and Entity so you can add whatever you want to the particle. This gives greater flexibility as well for letting particles be interactable or have other logic outside of this library applied to them, as you can add any custom component, and keeps the library from directly being concerned with the rendering. Then the default sprite could just be optional.

I'm not as familiar with the renderer parts though, would that work for being able to use bevy_smud shapes for the particles, or am I missing some details?

[Rayoule]

Currently trying to implement 3D.

The main issue with this is the rendering pipeline:
For now I can spawn particles that have a MaterialMeshBundle to which I give a shape::Plane and a custom material that has a custom billboard shader.
But the trouble is when I try to update the material per-particles. They all share the same plane and the same material. So they cannot have their own color.
If I modify the material, it changes the color for all particles and we're not making a material for each particle.
If I modify the mesh (its vertex color for example), its the same issue as they all share the same mesh and we're not making a mesh for each particle either.

I can only see 2 options:

• We use instancing, which allows to draw all particles with a single drawcall AND per instance data. The issue could be that we won't be able to spawn different meshes within the same particle system.
• We write our own rendering pipeline that allows everything we may need, but im concerned about the fact that it will be heavy work, and will also be harder to maintain as Bevy Engine move forward.

I will try instancing for now. And it seems to be quite close to writing our own custom pipeline and its described very nicely in the instancing bevy example. What could go wrong ?

About bevy_smud, Its a nice feature but it comes after the standard billboard particles in my opinion.

Do you have any other solutions ? Or advice ?

[theanti9]

I think your first option, instancing a single mesh, is the best option and a reasonable limitation for the moment. Plus, doing everything in a single draw call would be excellent as it'll be substantially more efficient, which is great.

I agree that implementing a custom pipeline here would not be ideal as it would make the upgrade path significantly more challenging, so I'd like to avoid that. I think it's potentially less easy for others to integrate that way as well.

If you're worried about limiting to a single mesh, one thing we could consider is doing something similar to Unity and making it a bit easier to have a sub-emitter or child-emitter which can have its own set of parameters but follows the state of the parent with regards to playing/pausing, etc.