HugoPKFX
commented
1 year ago Hi, thanks for the detailed explanation
-
This is usually fixed using the
Camera Sort Offsetof renderer nodes. If the O3DE plugin doesn't support it, it's a bug, we'll look into it. How it works is PKFX just offsets draw call bboxes along the camera forward axis (world unit offset) -
This is the main issue with PopcornFX batching sim units. Internally PopcornFX does not simulate these two emitters separately (simplifying it to one one layer in that effect for this example). Particles are evaluated in "waves" of 512/1024/.. particles depending on the platform (wave size can be specified per layer). Because of that, the memory layout of particle storage (positions/sizes/..) needed for rendering isn't location dependent but spawn-order dependent (positions of emitter A and B are stored in the same positions array, depending on particle spawn order).
We built on top of this two systems:
- Localized pages: realtime algorithm splitting waves depending on particles world positions, producing smaller & more localized (as in world location) waves. This helps LOD (built-in particle LOD allowing to reduce execution frequency of pages) of environmental effects or effects with several instances across a world. This algorithm uses an heuristic for splitting waves but it's not a fully satisfying solution
- Draw calls slicing: draw call data is built by (this depends on various parameters, but most of the time that is the case) by direct copies from the source particle data (positions, sizes, ..) into the destination gpu buffers. As the source data isn't stored in a per-emitter fashion, this causes these big bounding boxes. Draw calls slicing determines a maximum number of slices per draw call (let's say, 10). A draw call is then sliced up to 10 times along the view forward axis. This produces smaller draw calls, however the bounding box isn't re-built for these slices (it would require re-walking the index buffer) so we submit to the engine the global draw call bounding box, but PopcornFX SDK provides these draw calls already sorted back to front. We are investigating this in O3DE as a possible solution to this problem, possibly offsetting the draw call bounding boxes somehow
- Is PopcornFX main issue sorting wise, some titles shipping with slicing enabled and in most cases it helped, but it definitely isn't a bulletproof solution. There will always be a case where this won't work properly, where the slicing heuristic would need to be tweaked to the game specifics. We thought about draw calls slicing using the emitter ID, but this can quickly become hardcore performance wise, as two emitters being close to each other, with particles from each overlapping could generate thousands of draw calls. Some other titles using PopcornFX completely removed CPU sorting and used OIT, that can be a solution too but it also has its share of limitations. The other option is to rewrite billboarding code so instead of slicing draw calls downstream, GPU buffers are filled per instance directly, but this will come at a cost obviously as instead of doing memcpy (for the most part) of source particle data, we'll have to iterate on each particle to determine what is the target GPU buffer. Also, one set of GPU buffers will be required per emitter in the level (or this could be a global buffer with different offsets)..
Other solutions to mitigate sorting issues:
- A custom simulation interface could be called in the nodegraph, cull-testing a particle against all views from the game. This would greatly reduce bounding boxes in a level.
- Emitters outside the view can be "SetVisible(false)", also reducing draw call bounding boxes
We'll let you know our findings with slicing in the O3DE plugin
mbalfour-amzn
Short version: In the MultiplayerSample project, we've run into multiple particle sorting issues, and there doesn't seem to be a way to work around or fix it. This is a request to at a minimum provide a way to "unbatch" particle emitters for specific emitters to make it possible to fix sorting issues when problems arise.
Long version: Atom sorts transparent draw calls first by sort key, and then by depth. By default, everything uses a sort key of 0. PopcornFX is also currently hard-coding a sort key of 0 in CPopcornFXFeatureProcessor::Render(). In the case of MultiplayerSample, we need depth sorting since the particles appear in a level that has translucent walls everywhere, so this is OK. It would also be nice if sort key controls were exposed instead of hard-coded, but that wouldn't help for this situation anyways.
The problems show up due to particle batching. The particle effects we're using have multiple layers to them, and each layer has different-sized particles. For simplicity, let's just say there are 2 layers, one with a 1 meter particle and one with a 5 meter particle. We also reuse the effects multiple times around the level, so the same effect can draw hundreds of meters apart. These two factors are affecting the sorting in negative ways:
https://user-images.githubusercontent.com/82224783/232830259-4a82b918-7423-492a-8a93-e46926438b52.mp4