3D support through billboard rendering with instancing #46
Conversation
Add a new drag.rs example
Update example/velocity_modifiers.rs Add PrecalculatedParticleVariables
# Conflicts: # examples/basic.rs # src/components.rs # src/systems.rs
…ic struct CurvePoint. In VelocityModifier, rename ScalarAcceleration to Scalar, and Constant to Vector. Add VectorOverTime and replace Vector(Vec3) by Vector(VectorOverTime) in VelocityModifier. Fix example/shape_emitter.rs lifetime so its nicer and we can see the gradient.
Change the texture atlas example
There was a problem hiding this comment.
@Rayoule Wow! Awesome work. I've taken a cursory look at this and left a few initial comments but this will take me a few days to go through fully. I appreciate the obviously massive effort here and will try to get through it soon.
src/render.rs
Outdated
| extracted_instance_data.instance_data.swap(i, swap_idx); | ||
| indices.swap(i, swap_idx); | ||
| } | ||
| } |
There was a problem hiding this comment.
I think this could be done in linear time by preallocating a vec of the right size and setting the value at the specified index.
Something like this:
let instance_data = Vec::with_capacity(indices.len());
instance_data.resize(indices.len(), ParticleBillboardInstanceData::default());
for (i in 0..indices.len()) {
instance_data[indices[i]] = extracted_instance_data.instance_data[i];
}
And then pass instance_data to the buffer.
We are double allocating, but may still be faster. A lot less swapping and iteration.
| label: Some("instance data buffer"), | ||
| contents: { bytemuck::cast_slice(extracted_instance_data.instance_data.as_slice()) }, | ||
| usage: BufferUsages::VERTEX | BufferUsages::COPY_DST, | ||
| }); |
There was a problem hiding this comment.
I'm not familiar with the bevy specifics so it's very possible I'm missing something here, but with wgpu buffers, we probably don't want to recreate this buffer every frame. We should be able to store the created buffer (maybe wrapped in a Resource?), and instead update its contents every frame, which will be a good bit more efficient.
Sizing the buffer would be complicated though. Not sure how easy it'd be to plumb through but technically the max_particles of all alive 3d particle systems would be the max, and then we can just slice the buffer on the render call, with however many were actually filled that frame.
We'd still have to resize the buffer whenever that number changes though.
| }; | ||
|
|
||
| // Create the bind group for the particle system | ||
| let ps_bind_group = render_device.create_bind_group(&BindGroupDescriptor { |
There was a problem hiding this comment.
Same idea here, I think we can avoid creating these every frame.
|
I don't understand what is wrong with that test |
|
@Rayoule rust-lang/rust#113152 Looks like cargo-udeps is broken/incompatible with the version of proc-macros2 being used by bevy right now. I'll be disabling that particular test as part of the 0.11 upgrade. |
|
I've been thinking about this and wondering if we should gate the extra dependencies and extra pipeline stuff behind a cargo feature like |
Yes this is the right way to do it. No idea how to achieve this however. Also I wonder why there is a performance cost... There should be no entity that requires the 3D pipeline in the basic example. Maybe I should have used the standard render graph pipeline setup. |
Hello! 3D update!
That was quite a piece of work but here it is !
This PR adds many many things, all related to 3D compatibility:
With this update comes a few problems:
It does make things work better (try disabling it), but if you pay attention, the arrow particles of the 3d example will start to get messy after a few seconds, and I have no idea why.
If someone could check it out it could be really cool, as I am out of ideas for this.
Well I hope you'll like it !