View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002642||The Dark Mod||Coding||public||20.02.2011 18:04||30.11.2020 12:34|
|Product Version||TDM 1.04|
|Summary||0002642: Add multiple particles to func_emitter|
|Description||We have StaticMulti to present multiple func statics as one model to the rendered, but we lack a way to do the same for particles. |
Particle emitters cannot be "combined" into a rendermodel, but we should at least be able to store all models and their offset in one entity, then present them all to the renderer, instead of having to have multiple entities with one particle for each.
This would help in cases like fog (multiple floating fog particles), leaves or foliage (hundreds of trees with particle leaves, or flower patches), or f.i. a grand city view with dozend of chimney smoke stacks.
|Tags||No tags attached.|
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:
* emitterAddModels(modelName, modeloffset)
Things to do:
* 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).
|20.02.2011 18:04||tels||New Issue|
|20.02.2011 18:04||tels||Status||new => assigned|
|20.02.2011 18:04||tels||Assigned To||=> tels|
|20.02.2011 18:36||tels||Note Added: 0003618|
|20.02.2011 18:36||tels||Target Version||=> TDM 1.05|
|23.02.2011 17:16||tels||Note Added: 0003646|
|23.02.2011 17:18||tels||Relationship added||parent of 0002576|
|23.02.2011 17:19||tels||Relationship added||parent of 0002575|
|23.02.2011 17:19||tels||Description Updated||View Revisions|
|14.03.2011 11:09||greebo||Target Version||TDM 1.05 =>|
|15.05.2013 15:28||tels||Assigned To||tels =>|
|20.11.2020 16:11||nbohr1more||Assigned To||=> stgatilov|
|22.11.2020 12:49||nbohr1more||Relationship added||child of 0005138|
|30.11.2020 12:33||stgatilov||Note Added: 0013057|
|30.11.2020 12:34||stgatilov||Note Added: 0013058|
|30.11.2020 12:34||stgatilov||Relationship deleted||child of 0005138|
|30.11.2020 12:34||stgatilov||Relationship added||related to 0005138|