Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a set of dynamic particles are spread across multiple sub-meshes, Away gets their indices wrong. If the sub-meshes are created at different times, Away also generates redundant data for the earlier sub-meshes.
To see this in action, create the "Particles" sample project, and make the following changes to
Main
:Changed lines
Entire Main.hx file
This version starts out with fewer particles, but adds 500 new particles each time you double-click. It then prints out how many
animationParticles
are allocated per batch (it only needs 500, but ends up creating far more).Each batch is meant to be offset by 100 units from the last, but since I used dynamic positions, it's impossible to set the position of anything after the first batch, so everything else appears at (0, 0, 0). If you apply this pull request, you can then uncomment the offset code, and it will appear correctly.
I'm submitting this as a draft because there's another use case I haven't tested.
Sub-meshes don't have to represent different sets of particles, they can add more geometry to existing particles. And each sub-mesh can have its own material. So for instance, your particles could have a "solid" part stored in sub-mesh 0, with a basic color shader, plus a glowing trail with an alpha texture stored in sub-mesh 1. Then sub-mesh 0 and sub-mesh 1 would both include the same range of particle indices, starting from 0.
Given how everything was implemented, this appears to be the intended use case. However,
ParticleGeometryHelper
will create sub-meshes that don't start from 0 if there's too much data, and I guess that simply never got tested.