 |
A first stab of this has been implemented with revision 0004618. Multiple particle models can be set with "modelSUFFIX" like "model_2" and positioned with the corrosponding offset spawnarg (relative to entity origin). LOD changes only happen for the first model, and there are some issues with Save()/Restore() which need sorting out. But otherwise it works. |
|
|
The code has been restructured to not use so much memory if there are no additional models (keep only 1 instead of 3 lists, only put additional models into it, not the base model etc.). Also each model has a flags field (so we later can selectively hide them), and the Save/Restore code is much more complete now. The code can now also distinguish between "is the same as the original model" (which should get full LOD treatment) and "is not the same", which should only pay attention to the hide_distance. Also two script events have been added: * emitterGetNumModels() * emitterAddModels(modelName, modeloffset) Things to do: * removeModel() * script events for removeModel() and getModelOffset(), getModelAtOffset()? * LOD thinking for the individual involved models |
 |
I would say most of the cases listed in issue description can be implemented using "particle deform" system: fog (multiple floating fog particles) leaves or foliage (hundreds of trees with particle leaves, or flower patches) Things like this cannot, since exact emit positions are important: a grand city view with dozens of chimney smoke stacks Although it is dangerous to combine particle systems across large distance into one entity, since they will loose individual bounding box checks and will always be rendered. One way to achieve it is using smoke particles + script, but: 1) There is only one global smoke particle system in game (no idea why). 2) The limit: <= 10000 particle at any time. 3) Is stateful, so not very good for performance. Plus same problem about one bounding box for all. In principle, it is possible to add something like idSmokeParticles, but with following differences: 1) can exist in many instances 2) particles are stateless like in particle models, emission is tied to some fixed array of locations/orientations (aka static entities). 3) each emission location should have many particles, not just one. I think the best idea would be taking idRenderModelPrt. It can be extended to store array of origin+axis locations. Then in idRenderModelPrt::InstantiateDynamicModel: if this array exists, then treat each of its elements as individual particle system. If the array does not exist, assume that it has one element with identity location (which would work as usual). No idea how to fill the array though. I guess it should be some code in SEED.cpp or near that. |
|
|
Anyway, it is not part of refactoring, so removing child-parent relation. The refactoring should have made it easy to write yet-another particle system use case if needed (adding to the three that we already have). |
 |
@stgatilov, on this subject, is there a way to show how particles are being rendered on-screen (so we can see how close to the 10000 limit we are etc) |
|
|
I don't think there is. Anyway, the limit only applies to smoke particles, which are used very rarely. |
|
|
It seems that there is idFuncEmitter entity class, which can store several particle models in it. Every model has its own renderEntity, so the vertex data are processed separately, not combined into one buffer. However, they are all in one entity. The multiple models can be added by having multiple "model_*" spawnargs. Also they can be added in script via "emitterAddModel" event. So in terms of reducing entity count, it is sort of "done". In terms of reducing overhead for nearby particles, it is not done. Perhaps it can be based on the same emitter, which would create its own individual particle model, and expect particle models to have several particle declarations with different origin/axis inside. In terms of ease of such combining for mappers, I think nothing is ready. Perhaps it can be integrated into SEED framework in a way similar to how it combines static entities. |
|
|
Well I can confirm the model_1, model_2, works with the existing func_emitter entity, below there are 4 particles on a single func_emitter. |
|
|
Capture.JPG (84,213 bytes) |
|
|
Yes, but I guess you cannot put different models into different positions (aside from editing .prt files)? |
|
|
that I dont know, as it is I would I would measure where I wanted the place a given particle and then adjust said particle in the editor. That how I did those four bulb glare you see in the first shot. |
 |
func_emitters support offset_N spawnargs. 'leaves or foliage (hundreds of trees with particle leaves, or flower patches)' -- I experimented with 'deform particle' surfaces for those in the past, and as far as I could discover there's no way for the particles to have light interactions if spawned from surfaces. (Possibly relevant comment from Carmack at https://www.gamedev.net/forums/topic/266373-so-i-finally-took-all-of-carmacks-quakecon-speech-and-put-it-to-text-format/ -- '...internally there are a number of things I consider flaws with the Doom engine, for instance, surface deforms, where you have something that's an auto-sprite or uses some other deform, that happens in the wrong place in the pipeline to get lit.') I would have liked to be able to drape particle-based ivy over a building just by curving a patch around it, but no dice. The garden trellises in ITB use emitters (and the size of the particle models is still constrained by the fact that func_emitters' particle models are only lit if the emitter's origin is within the light volume). At a large distance, for something like a background forest, it's probably possible to use fullbright particles with dark colours (particle foliage can look bad up close anyway, due to billboarding), but for something like a flower bed it's possible the player will come over and introduce a light source. |
- Anonymous
