Is it possible to sync a particle emitter to a light shader?

[Kiln]

Well, it looks like you guys are finally getting a map out of me. Pretty much 100% done on base architecture/layout, 100% on story, but only about ~25% on detailing and here is where I've got an issue that is over my head.

 

I've got a sputtering torch-like object that uses a modified tdm_biground_fastpulse light texture and a custom flame particle that flares every 0.5 seconds. I'd like the surge in the flame to coincide with the light pulse. Before I brute force it I'd like to see if there is an easier way.

 

At the very least I'd like tdm_biground_fastpulse to cycle exactly 0.5 seconds. Is this even possible?

 

(from tdm_light_textures.mtr)

// Light-Textures

table torchtable { { .3, .2, .8, .1, .2, .3, .1, .5, .1, 1, .2, .3, .3, .2, .1, .1, .7 } }
//    fire flickering shader
//    shaderparm3 - speed modifier
//    shaderparm4 - offset (set to different value for adjacent lights to prevent lockstep flickering)

table pulsetable { { 1, 1, 1, 1, .9, .8, .7, .6, .5, .5, .6, .7, .8, .9 } }

table flickertable_hi    { { 0.91, 0.95, 0.92, 0.98, 0.85 } }
table flickertable_low    { { 0.04, 0.2, 0.1, 0.16, 0.09 } }
table firelightrot { { 13, 16, 123, 256, 90, 12, 190, 160, 1, 59, 280, 150, 15, 280 } }

.
.
.


lights/tdm_biground_fastpulse
{    
    {
        forceHighQuality
        map    lights/biground1
        colored
       zeroClamp
        red     ((.1 * sintable [(time * ( 0.3 + Parm3 ) ) ]) +.90) * Parm0
        green   ((.1 * sintable [(time * ( 0.3 + Parm3 ) ) ]) +.90) * Parm1
        blue    ((.1 * sintable [(time * ( 0.3 + Parm3 ) ) ]) +.90) * Parm2
    }
}

All I can grok here is sintable = sin function to make everything cycle. Unfortunately, scripting is mostly voodoo to me, so keep that in mind if anyone has an explanation/solution.

 

Thanks in advance.

 

[nbohr1more]

You should be able to make attributes in the particle def (prt) accept sintable:

 
//Author: SneaksieDave
particle tdm_fire_torch {
    {
        count               80 *  ((.1 * sintable [(time * ( 0.3 + Parm3 ) ) ]) +.90)
        material            textures/particles/pfiresmall2
        time                1.000
        cycles                0.000
        bunching            0.950
        distribution        rect 0.000 0.000 0.000
        direction            cone "50.000"
        orientation            view
        speed                "4.000"  to "0.000"
        size                5.500 * ((.1 * sintable [(time * ( 0.3 + Parm3 ) ) ]) +.90)
        aspect                "1.000"  to "2.000"
        randomDistribution    1
        boundsExpansion        0.000
        fadeIn                0.000
        fadeOut                1.000
        fadeIndex                0.000
        color                 1.000 1.000 1.000 1.000
        fadeColor             0.000 0.000 0.000 0.000
        offset                 0.000 0.000 0.000
        gravity             world -20.000
    }
 

You'll probably need to adjust the math but that's roughly what you'd use.

[Kiln]

Okay - that's an approach I hadn't thought of. I'd assume that particles can't be dynamically altered at runtime like that. My working theory is all the generated prt's look like rigid parameters fed into a black box at level load, and it's the black box that creates the dynamics. Likely wrong on my part, but I guess that's why I asked. This approach looks as if it will alter my complex prt though, which is a shame since it really looks good at the moment - so much so that I thought to myself "Ya know what would look cool here is if it where synched with the light..."

 

 

Thanks for the suggestion.

Edited May 29, 2017 by Kiln

[teh_saccade]

There is no spawnarg for flickering lights (parm 3-4)..?

 

http://wiki.thedarkmod.com/index.php?title=List_of_shaderParm_variables

 

idk if can be set to the particle emitter, but - since the particle is likely only visible when lit... even thought it "exists" when not seen, it's not a big hit to run-time to keep constant and control the particle's appearance through light (similar to misty room lit by, eg, broken electric light / shalebridge-effect).

Edited May 29, 2017 by teh_saccade

[Kiln]

There is no spawnarg for flickering lights (parm 3-4)..?

 

 

From what I've seen flickering is either time based and regular (sin function) or sound based - multiplying the sound level by a factor and using that to dim the light synchronously - for the "shorting out lights".

 

If someone more savvy with mtr and scripting could point me to how I can very accurately measure the cycle time, I'd be in business.

 

...control the particle's appearance through light...

 

An interesting idea. Part of the issue is the prt is the flame itself and it dynamically flares. A lot of the magic in it (to me anyway) is the motion, but I'll look into that approach.

 

 

 

Doom 3's particle system is really powerful - a shame more people don't noodle around with it.

[Bikerdude]

Once we get this working I would like to add this to the core mod, as we have a number of flickering lights where the func_emitter is static etc.

[teh_saccade]

 

From what I've seen flickering is either time based and regular (sin function) or sound based - multiplying the sound level by a factor and using that to dim the light synchronously - for the "shorting out lights".

 

If someone more savvy with mtr and scripting could point me to how I can very accurately measure the cycle time, I'd be in business.

 

An interesting idea. Part of the issue is the prt is the flame itself and it dynamically flares. A lot of the magic in it (to me anyway) is the motion, but I'll look into that approach.

 

 

 

Doom 3's particle system is really powerful - a shame more people don't noodle around with it.

 

Ah, so the flame is the particle..? Well, in that case - it may be more simple to time it to the light flicker...

 

 

The main issue with this system is that appearance appears related to the speed at which it is observed (fku einstein).

Lights flickering, for example - the frequency will change depending on the player's FPS, no matter what it is told to do (potato vs hamster-powered rendering):

 

This video, the effect was set @~55-60fps (my monitor's refresh) and worked perfectly. However, upon testing at anything lower than this - the effect (that relies on the time of light and motion remaining exact and constant) was destroyed and looked too messy to ever use except for my own amusement. The illusion was destroyed and looked crap to everyone else but me on my monitor, as you can see.

 

 

 

 

 

 

I cannot figure a way to pull the player's FPS and tie the mover's revolutions and light's strobe timing to this, so the effect is constant for all players (other than those @~60fps). I don't think it is possible.

Even setting the stage so that it would be like a gig, where the "smoke" carries the strobe (like setting VFX for a gig) doesn't make a difference - so I tried using "func_smoke" instead of "func_emitter".

Still didn't work - ain't no-one got time to write that many scripts for so many differently named objects... (shoulda woulda coulda named them all the same).

 

This is where it might be relevant to what you are trying to achieve:

http://wiki.thedarkmod.com/index.php?title=World_Particle_System

 

(see section "natural timing")

 

Maybe the script on the WPS page would be fine to use if substituting the particle for the one you are using..?

 

In the instance of a regular, 1/2 second emission, matching the light to sys.getTime(500) [idk if that is correct, nbohr1more / biker?], to get the starttime correct and set random=0 as well as (perhaps) the origin and n,n,n direction - for me it'd be trial and error...

 

But since your light is a particle itself - I can't see why this wouldn't work with a simple copy-pasta of the example on this page with the vectors and $object_names changed (unless it's bound to a mover or md5, in which case it is more complicated - idk, it's been over a year since I looked at this stuff and my memory tends to fade out after a few umm... uhhh... minutes?).

 

The behaviour of the particle can then be further edited using DR's dialogue, to fine tune.

 

http://wiki.thedarkmod.com/index.php?title=Particle_Editor

 

Perhaps a fade in / fade out is enough to get the particle "looking" as if it is fudged in with the lighting effect behind your flame particle..?

Since the light can be more accurately timed using simple DR parms - the WPS might help sync the particle and light togehter without the need to mess with shaders and materials.

 

 

I'm not good at scripting and writing materials or definitions, so if there's an opportunity to take a shortcut by using something "forgotten" like this and a DR dialogue - I'll take it.

Edited May 30, 2017 by teh_saccade

[teh_saccade]

maybe its sys.waitframe(500)... idk, icr...

 

// oh, maybe adding "show", "wait" and/or "delay" as spawnargs (in miliseconds) might do it... idk. I just hit stuff til it works.

Edited May 30, 2017 by teh_saccade

[Kiln]

Yeah, I figured FPS and other system variables will muck up the situation, which is why I'd like to run everything off "game-time" (is that the term for it?) I'm liking the potential here, but we're getting into scripting country so we may have the heat death of the universe before I comprehend what's going on. Won't stop me from taking a swing at it.

 

Another approach I've thought of is using a sound effect that oscillates. It would fit in very well with this whole system, and we already know that light can be synced to that. If the emitter can be tied to the sound function too somehow, we're golden (well until the next roadblock comes up.)

 

Got some IRL stuff to deal with today so I gotta run but thanks for the links. I should be back at it tonight.

[teh_saccade]

idk if TDM uses "ping" like Thief did, but if you can set it so an emitter "hears" noise then that would be a great basis for some stim/response alarm device and traps - many possibilities and a more elegant, less complex, AI-based stim-response system than I use, for sure...

 

If the player is detected because of their noise and this causes an emitter to release a gas or gush some water - it would make for a very tense escape from a rapidly flooding room / cavern with only simple script... and lower the entity count a fair deal.

Hope you get it figured (so I can steal it).

[HMart]

I don't know if this was already suggested but what about a FX declaration file? This is what id software says about them https://www.iddevnet.com/doom3/fx.php

[Epifire]

What if you did something a bit crazy and had a particle system always running (when the light source is active) but modulate the light material and the ones used in the particle based off a sound file? You could then tie both into a single sound file playing. I guess the problem with that might be particles already spawned would light up outta nowhere. Unless there's a way to enable a particle cull on spawn based out of a transparency check. The theory behind that is if the particle is invisible > remove. So it would be killing the particles off until the opacity kicked back in. Talkin like some screwy UE4 kid here though, cause I'd imagine something like that would be pretty costly.

 

So the limitations would be directional particles, like smoke or sparks with a long trail would look strange. Particles that could benefit from this would have a contained bounding and center (such as electricity or beams) without the noticeable spawn snapping. Best I could come up with, hope it helps.

[Kiln]

Thanks for the leads guys. I haven't abandoned this, but I've kicked it to the "nice to have, but not essential" list. If it ever works out, it looks like some kind of scripting will have to be involved, and I'm not going to let this project bog down. Almost done with the first pass detailing and I'll revisit it when the spit-and-polish phase comes around.

 

BTW - Epi, any chance we can get a shadowmesh for your awesome leather chair? I use it quite a bit but it looks funky around light sources as I'm not seeing a shadow.

[HMart]

If a model has no shadow mesh it should still show shadows, so if you can't see shadows on a model perhaps you have shadow casting turned of for it, see the entity options in DR or the model material for the "noshadows" keyword.

 

 

btw a lowpoly shadow mesh is not a requirement is just a way to optimize shadow casting for models with plenty of polys.

Edited June 11, 2017 by HMart

[NeonsStyle]

Don't know about your problem, but when you're detailing. When you think you're finished. Don't publish yet. Hang on to it and keep it, and guaranteed in

you'll find lots more detail to do. Hold on to it till you can't stand it anymore, and it'll be a better map. I thought mine was finished in November, I'm still

finding things to fiddle with an improve lol.