Jump to content
The Dark Mod Forums

particle request: candle smoke


Springheel

Recommended Posts

Found it. The second system (which we don't use in any maps) is idSmokeParticles, which is implemented in SmokeParticles.cpp. It looks like it was added as an afterthought. The main particle code (that we do use) sits in the engine, in Model_prt.cpp and DeclParticle.cpp. SmokeParticles.cpp is in the game code, so that game devs could have amended it before the game was open-source. It replicates code freely from Model_prt.cpp, which is why I say it looks like it was added as an afterthought. No-one would plan to replicate code like that in two completely independent parts of the codebase.

 

Unlike the main particle code, it maintains a list of emitted quads that have independent origins, so once emitted they won't move to follow the emitter. It has a performance concern because the emitted particles get rendered no matter where they are in the map, however many visleafs away, whether they are visible or not. But it could be used sparingly, or be turned off when the player leaves a location, and it would be nice to have trailing or drifting smoke. We could probably hook it up with the location system so that we could have a spawnarg that turns it off when the player leaves the area, rather than require players mappers to set up something manually to turn it off.

 

Edit: I take back my bitching about code replication. It's actually quite a cool design. The internal machinery for particles is in DeclParticle.cpp, and the Model_prt code in the engine is one possible way to use that machinery, the "easy" route that requires less setup. SmokeParticles.cpp is another way to use the machinery, one that got exposed to game designers so they could do what they liked with it.

Edited by SteveL
Link to comment
Share on other sites

Cool! I read an interview where he did say there were bigger performance concerns for it. Shouldn't matter for extinguishing candles though. How can I try it out?

Link to comment
Share on other sites

AHA! it never occured to me that smoke emitters use a different system (which really doesn't make much sense, it would be much better to have a system for both and optimize common sub-cases).

 

So, the firearrow trail probably uses the smoke emitter, like chimney stacks.

 

One problem with the smoke is that it cannot be turned on/off when the player leaves the visleaf, because that would mean when you return, suddenly the chimneys start to smoke and that looks bad. Probably that is why they use "draw it always".

 

For candles, that wouldn't matter much, tho.

 

@Springheel: I don't think it will be that easy. Only entities of the type "idSmokeEmitter" will create such particles, and the candle does not have such a thing. Technically, one could spawn such an emitter during extinguish, then remove it again afterwards. But sounds like a kinda heavy solution for such a small problem.

 

Would be much better that each particle could just specifiy which way it wants to work.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

@Steve: What I meant to say in the last post is that it would be better if the SmokeEmitter quads where merged into the other code, and idSmokeEmitter just sets a flag and proceeds normally. If that is easy and possible, tho.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Cool! I read an interview where he did say there were bigger performance concerns for it. Shouldn't matter for extinguishing candles though. How can I try it out?

 

I'll figure it out shortly... I'm working through the 7 (!) different ways of drawing shadows that are in the renderer right now but I could do with a break to look at something with a quicker reward :)

 

One problem with the smoke is that it cannot be turned on/off when the player leaves the visleaf, because that would mean when you return, suddenly the chimneys start to smoke and that looks bad. Probably that is why they use "draw it always".

My guess is it's to do with bounds checks. The normal way a particle effect gets hidden from the renderer is by checking whether it can be seen, using the emitter's origin and the maximum distace of the quads from the emitter. That logic can't be applied where particles are independent of the emitter once released.

 

No need to be pessimistic! We will get it working, and nicely. As I mentioned a day or two ago in another thread, I'm planning to read up on particle systems from other games and propose something new for TDM this dev cycle anyway. It's a huge bonus to discover there's already an example of a completely customized particle system using the existing particle engine right here in our own code :)

  • Like 1
Link to comment
Share on other sites

I'll figure it out shortly... I'm working through the 7 (!) different ways of drawing shadows that are in the renderer right now but I could do with a break to look at something with a quicker reward :)

 

 

My guess is it's to do with bounds checks. The normal way a particle effect gets hidden from the renderer is by checking whether it can be seen, using the emitter's origin and the maximum distace of the quads from the emitter. That logic can't be applied where particles are independent of the emitter once released.

 

Yeah, but then you could put the quads into a quad-tree and cull them based on distance to the player. Using the emitter for the check is cheap, but not quite correct...

 

There is also the question on how much performance does it actually cost? A few thousand quads more or less is nothing for a GPU nowadays. Unless you compute the quads on the CPU as idtech4 does, then it becomes a CPU bottleneck. Maybe putting the particles to the GPU and compute them right there would help.

 

No need to be pessimistic! We will get it working, and nicely. As I mentioned a day or two ago in another thread, I'm planning to read up on particle systems from other games and propose something new for TDM this dev cycle anyway. It's a huge bonus to discover there's already an example of a completely customized particle system using the existing particle engine right here in our own code :)

 

I don't want to be begging here, but maybe we can create particles that use the physics system. Having smoke not pass through the ceiling, or other solids would be huge. It doesn't have to run on the GPU, tho :)

 

But maybe not re-inventingf the wheel and using an existing, open, particle system would be the way forward? (It is amazing that there isn't a usable lib for these things?)

Edited by Tels

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Yeah, but then you could put the quads into a quad-tree and cull them based on distance to the player. Using the emitter for the check is cheap, but not quite correct...

 

There is also the question on how much performance does it actually cost? A few thousand quads more or less is nothing for a GPU nowadays. Unless you compute the quads on the CPU as idtech4 does, then it becomes a CPU bottleneck. Maybe putting the particles to the GPU and compute them right there would help.

 

Yes, they could have new logic to cull them. We'd want to spend some time thinking about how it fits in to the bigger picture. Right now the task of deciding which bits of the map get drawn in the current frame is handled by a single routine in the renderer front-end, FindViewLightsAndEntities, and it's a lovely, clean and simple bit of code that operates on entity origins and bounds and visportals. The entire task is implemented in about 100 lines. We wouldn't want to spoil it by splitting the task between it and the game code. And as you say, there are other solutions.

 

Agreed, it's mostly about the amount of data we pass to the GPU every frame. Computing the verts is nothing, drawing them is nothing.

 

I don't want to be begging here, but maybe we can create particles that use the physics system. Having smoke not pass through the ceiling, or other solids would be huge. It doesn't have to run on the GPU, tho :)

 

We can develop that thought... Smoke that could spread over ceilings would be cool. Maybe do a set of upward traces from around the emitter origin when the emitter starts up, to work out a set of spline paths for particle quads that could be passed to the particle system (doesn't matter whether it's running on the gpu or the cpu). I'm going to look what other games have done first, but we're not limited by existing achievements of course. :)

Link to comment
Share on other sites

I haven't quite got an answer to testing it on a candle yet, but I've done some research.

 

There's a single "emitter" for the entire map, so that's why it's always considered to be in view. The emitter isn't an entity at all.

 

You can't stop individual particle effects once you;ve started one, so it's probably best used with ones that time out naturally like the candle smoke.

 

It's supported in a few places in the game:

AnimatedEntities can spawn damage effects that are independent particles.

Projectiles can use it via their "smoke_fly" and "smoke_detonate" spawnargs.

Weapons have a "smoke_strike" spawnarg.

AI have a sophisticated particle system of their own that uses the SmokeParticle setup. You can give them one or more particle effects at spawn time using spawnarg smokeParticleSystem, smokeParticleSystem_1, smokeParticleSystem_2 etc with a value of particle_name-joint_name. I'll put an example below.

You can also trigger particles from AI on demand using their Burn() script event. That activates any particles named in spawnargs smoke_burnParticleSystem, using the same particle_name-joint_name setup.

 

The first AI has spawnarg "smokeParticleSystem" "tdm_smoke_torchout-LeftHand" (which is why the smoke is coming from his hand not the torch).

The second AI has "smokeParticleSystem" "gas_cloud-head"

 

Both are a bit hard to see in the vid, especially the smoke. But we can thicken it up.

 

http://youtu.be/MOauMuXTfB4

  • Like 4
Link to comment
Share on other sites

I haven't quite got an answer to testing it on a candle yet, but I've done some research.

 

Steve, this is just fantastic research. Could you do me a favor and put these things on the wiki? The forums are a place where such things are easily lost (and not googable).

 

Edit: I think the smoke for the AI is used for the breath puff, and for the imp.

Edited by Tels

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Steve, this is just fantastic research. Could you do me a favor and put these things on the wiki?

 

Will do. I put in a new script event for 2.03 that'll let mappers use it, although it'll be 2.04 before we use it on any core assets.

 

The performance issue turned out not to be that bad. If you have 100 guards trailing smoke spread through the map, yes all the quads get drawn all the time but it'll be a single draw call for all those quads across the map, no matter how many there are. It wouldn't be worth trying to filter out individual quads just because they can't be seen. It'd cost more effort to block them than to let them be drawn.

 

I also figured out how to use it. There's only one function, but it's flexible enough to let you have a candle or torch trailing smoke using the particle def to decide when and how to emit quads, or to let you emit individual quads exactly when and where you want.

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

As someone oblivious to deeper coding, this thread is still an intriguing read! It makes me glad to see you guys being so competent and thorough, and I'm absolutely amazed by the fact that you can put so much time and effort into TDM. Just some motivational praise, hehe. Keep up the great work! :)

  • Like 1

"My milkshake bringeth all ye gentlefolk to the yard. Verily 'tis better than thine, I would teach thee, but I must levy a fee."

"When Kleiner showed me the sky-line of New York I told him that man is like the coral insect—designed to build vast, beautiful, mineral things for the moon to delight in after he is dead."

https://soundcloud.com/paralytik

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...