View Issue Details

IDProjectCategoryView StatusLast Update
0002642The Dark ModCodingpublic14.12.2020 21:23
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).


02.12.2020 16:48

reporter   ~0013076

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


02.12.2020 16:52

administrator   ~0013077

I don't think there is.
Anyway, the limit only applies to smoke particles, which are used very rarely.


05.12.2020 08:02

administrator   ~0013094

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.


05.12.2020 10:06

reporter   ~0013095

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.


05.12.2020 10:08

reporter   ~0013096

Capture.JPG (84,213 bytes)   
Capture.JPG (84,213 bytes)   


05.12.2020 11:40

administrator   ~0013098

Yes, but I guess you cannot put different models into different positions (aside from editing .prt files)?


05.12.2020 14:36

reporter   ~0013104

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.


14.12.2020 21:23

developer   ~0013135

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

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
02.12.2020 16:48 Bikerdude Note Added: 0013076
02.12.2020 16:52 stgatilov Note Added: 0013077
05.12.2020 08:02 stgatilov Note Added: 0013094
05.12.2020 10:06 Bikerdude Note Added: 0013095
05.12.2020 10:06 Bikerdude File Added: blackheart_2020-12-05_10.05.23.jpg
05.12.2020 10:08 Bikerdude Note Added: 0013096
05.12.2020 10:08 Bikerdude File Added: Capture.JPG
05.12.2020 11:40 stgatilov Note Added: 0013098
05.12.2020 14:36 Bikerdude Note Added: 0013104
14.12.2020 21:23 VanishedOne Note Added: 0013135