Func_emitters visible outside their leaf

[grayman]

This might have already been discussed, but a forum search didn't turn up anything.

 

I'm using a func_emitter set for tdm_moon_rays_med.prt.

 

I have two rooms sitting over each other, but separated by the void. The f_e is tucked against the ceiling of the upper room. Using DR's new particle animation, I can watch the particle quads drift down from the f_e, through the floor, into the void, and dissipate before they get anywhere near the ceiling of the room below.

 

However, in TDM, if I stand in the room below and look up, 'r_showtris 2' shows the quads being painted.

 

Anyone know why this is?

 

I might have to add triggers to turn these things on and off if they insist on being painted like this.

 

Thanks.

[stumpy]

is there a visportal separating the lower room from the upper room, cos if there's a visportal in between the rooms, ie in doorways, then the emitters particle effect should not be drawn when using r_showTris 2. If there's no visportal then it will draw.

[Fidcal]

Wild guess: maybe it's to do with the void. If the quads extend into the void perhaps they render in any room that is adjacent to the void. As a test, insert a shallow room between with an opening to the room above so they are the same leaf and all the quads remain within the leaf. If that works then seal the opening with a func_static brush matching the floor if it's visible.

[Bikerdude]

yeah i would also like this fixed, its always annoyed me when P_E extend beyond the leaf they are in, so I have had to on occasion created a custom version etc to fit with the confines of the room. Could this be fixed so this doesn't happen..?

[grayman]

is there a visportal separating the lower room from the upper room, cos if there's a visportal in between the rooms, ie in doorways, then the emitters particle effect should not be drawn when using r_showTris 2. If there's no visportal then it will draw.

 

If I walk from where I'm seeing the f_e to the f_e's room, I walk through 13 visportals.

[grayman]

Wild guess: maybe it's to do with the void. If the quads extend into the void perhaps they render in any room that is adjacent to the void. As a test, insert a shallow room between with an opening to the room above so they are the same leaf and all the quads remain within the leaf. If that works then seal the opening with a func_static brush matching the floor if it's visible.

 

 

I'll try your suggestion and report back. Thanks.

 

 

[grayman]

I dropped the floor of the room the emitter is in so that none of its quads could make it out of the leaf. I verified the quad movement using DR's new particle animator (or whatever it's called).

 

The problem still occurs: I can see the quads from the room below.

 

I guess there's no architectural solution to this, so I'm going to add triggers to turn them on and off as the player moves around.

 

Thanks for the suggestion.

[Fidcal]

My second guess would be that the range of the quads extends down into the room below but they time out before they reach there. So it looks like the range does not reach the room below but in fact it does. I'm fairly certain this was how it worked in Dromed so I assume similar in Doom3. So this would need a mod to the particle def.

 

Also keep in mind there needs to be a significant, detectable, performance hit for any of this to matter because the particles are not visible in-game. Setting up triggers has a small performance hit too.

[grayman]

Also keep in mind there needs to be a significant, detectable, performance hit for any of this to matter because the particles are not visible in-game. Setting up triggers has a small performance hit too.

 

Wouldn't the performance hit of a trigger that's thinking every 0.5 or 1.0 secs be much less than the performance hit of having to calculate the quad positions and orientations every frame?

 

My emitters are all on one side of the map, and the player spends most of his time away from them, so the emitters spend way more time off than they do on. And they're toggled in groups, so I need fewer triggers to handle them.

[Tels]

I would have to look into the engine code, but particles and smoke are based on two different, but similiar systems. The "emitted" particles are injected into the system, advanced/animated/morphed and then rendered in one (or some small number) of passes.

 

That means all particles, all smoke etc are always rendered as one, regardless on in which leaf they are in.

 

(One interesting thing to check would be to see if torch particles are also rendered always, but I guess so).

 

I am not sure they create a big performance impact, but you should be able to add LOD settings to them to simply hide them by distance. Alternatively, add the location zoning system and add a trigger "on_enter" and another "on_enter" in two zone where the player cannot see them, but must pass through, and make the on_enter turn them off in the far zone, and the on_enter in the near zone turn them on.

 

 

[ particles  ] <==> [ corridor (on enter turn them on) ] <==> [ hallway (on enter turn them off) ] <==> [room with no particles]

 

Abd by on/off I mean Hide() and Show().

 

Does this help?

[grayman]

Abd by on/off I mean Hide() and Show().

 

I can't rely on LOD for this. There are many spots where I want to see the emitter that are farther away than the spot where I don't want to see it.

 

I'm testing the location solution. I already have locations for ambient sound changes. I need to add a few more to cover the emitter problem, and make sure the sound settings still make sense.

 

In reading the code, On/Off is the same as Show/Hide for emitters.

[Fidcal]

Try a lever in the room below to switch the particles on and off. If you cannot humanly detect any difference in performance then is it worth the bother of triggers?

[grayman]

Try a lever in the room below to switch the particles on and off. If you cannot humanly detect any difference in performance then is it worth the bother of triggers?

 

The frame rate drops from 45 to 35 on my older system.

[nbohr1more]

AFAIK, Sotha used Hide-Distance for his rain particles in a couple of his missions. Yes, an occlusion based approach would be better but you get what you can... for now.

[grayman]

Using the location entities to toggle the emitters works fine. I dumped the triggers I'd added earlier (and which also worked fine).

 

Thanks for the suggestion.

[nbohr1more]

Delete post please...

Edited September 6, 2011 by nbohr1more

[grayman]

Can you add the script example for particles to this wiki?

 

There's already a "turn entity on/off" example script at the end of that wiki.

 

What I did was--by necessity--more complex than that, but if I boil it down for the wiki, it's going to look similar to what's already there.

 

Edit: I see you deleted your question. Maybe you found the existing example.

[nbohr1more]

Yes, it looked too generalized at first but then I re-read the description and realized that it was all there.

 

I added a section on Entity Management to the performance wiki with a link to that section, along with an overdue nod to LOD and SEED which I was having trouble finding the right place to fit in.

[Bikerdude]

yeah i would also like this fixed, its always annoyed me when P_E extend beyond the leaf they are in, so I have had to on occasion created a custom version etc to fit with the confines of the room. Could this be fixed so this doesn't happen..?

 

ANyone got any ideas on how to get around the above..?

[nbohr1more]

ANyone got any ideas on how to get around the above..?

 

I think it would be too expensive to have a particle entity detect it's bounds withing a room (etc) and automatically resize itself. That's probably also tougher than the challenges that Tels is working with to setup 3D entity distribution for SEED.

 

Maybe Stgatilov can cook something up?

 

(I think this is something that might be more practical with renderer access because you would have object coordinates rather than having to "detect" them.)

 

Maybe more prefab sizes for particle entities?

 

[Tels]

I think it would be too expensive to have a particle entity detect it's bounds withing a room (etc) and automatically resize itself. That's probably also tougher than the challenges that Tels is working with to setup 3D entity distribution for SEED.

 

Maybe Stgatilov can cook something up?

 

(I think this is something that might be more practical with renderer access because you would have object coordinates rather than having to "detect" them.)

 

Maybe more prefab sizes for particle entities?

 

 

The "more prefab sizes" is quite cumbersome. The "detect if the origin of the particle left the leav and disable it" should be possible when the renderer goes opensource.

 

OTOH, the slowdown (which is the only reason we want to switch particls on/off) will very likely be gone with OS Doom3 anyway, because the only reason the particles are so slow is that they are processed on the CPU. If we'd process the on the GPU, you could have a few ten thousand more of them, and the system wouldn't slow down a tick. Even if the GPU isn't capable, preparing them on the second CPU core would already help.

 

That would also fix the performance problems with the rain particles.

 

@grayman: glad that the location system could be of help, Deemagogue will be pleased to hear this