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

    • The Black Arrow

      Hey @nbohr1morehow come the zombies in The Dark Mod don't have a "resurrection" mechanic to it, similar to how Thief has it?
      They're quite a weak creature as of right now, it's merely a walking corpse that slashes you, making attacking them to kill them an actual strategy.
      Would be better if they had some cool mechanism to it that truly makes them a danger, such as the resurrection idea itself.
      · 0 replies
    • Ansome

      Query: when was the last time a zombie in a video game was unnerving or scary to you? I'm chipping away at my anniversary submission and I've been trying to gather opinions on the subject. I'm perfectly capable of lighting them well, changing their sfx, and creating effective ambience, but I'm worried that zombies at their core are just too overdone to be an effective payoff to the tension I'm creating.
      · 4 replies
    • nbohr1more

      The Lieutenant 3 is out! Congrats Frost_Salamander! ( raising awareness )
      · 2 replies
    • OrbWeaver

      Has anyone had any luck with textures from Polyhaven? Their OpenEXR normal maps seem too washed out and give incorrect shading in the engine.
      · 5 replies
    • datiswous

      I tried to upscale the TDM logo video. First try:

      briefing_video.mp4 You can test it ingame by making a copy of the core tdm_gui.mtr and place it in your-tdm-root/materials/ , then edit line 249 of that file into the location where you placed the new briefing.mp4 file.
      What I did was I extracted all the image files, then used Upscayl to upscale the images using General photo (Real-Esrgan) upscale setting and then turn it back into a video.
      I might have to crop it a bit, the logo looks smaller on screen (or maybe it's actually better this way?). My video editor turned it into a 16:9 video, which I think overal looks better than 1:1 video of original.
      · 1 reply
×
×
  • Create New...