View Issue Details

IDProjectCategoryView StatusLast Update
0002642The Dark ModCodingpublic30.11.2020 12:34
Reportertels Assigned Tostgatilov  
Status assignedResolutionopen 
Product VersionTDM 1.04 
Summary0002642: Add multiple particles to func_emitter
DescriptionWe 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.
TagsNo tags attached.


related to 0005138 resolvedstgatilov Refactor particle systems code 
parent of 0002576 assigned SEED: Handling of entities with bound children 
parent of 0002575 assigned SEED: Handling of entities with attachments 
Not all the children of this issue are yet resolved or closed.




20.02.2011 18:36

developer   ~0003618

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.


23.02.2011 17:16

developer   ~0003646

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


30.11.2020 12:33

administrator   ~0013057

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.


30.11.2020 12:34

administrator   ~0013058

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).

Issue History

Date Modified Username Field Change
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