roq effects

[OrbWeaver]

I was wondering what it was about particles that keep them looking good from odd angles--we could make a much better flame if we could combine the aesthetics of a sprite with the orientation of a particle.

 

In this case the sprite option would be a single quad with an animated flame texture applied to it, correct?

 

The problem is that a flame is actually a 3D volumetric effect, which you will never be able to simulate entirely from a 2D animation, since the flame does not look the same from all angles (such as from above, as you have noticed).

 

A particle system, while made up of individual 2D sprites, works as a whole to produce a 3D volumetric effect, so is better for simulating a flame in this instance.

[Springheel]

Ok then. Our particle flames are fine, so it's not a big deal. I was just hoping to find a way to add a little more life to the flame itself.

 

Yep; the waver was instead done to the particle emitter itself to prevent that. Not perfect, but it works decently.

 

Really? How did you do that? I didn't see anything that would modify the position of the actual emitter.

[OrbWeaver]

Ok then. Our particle flames are fine, so it's not a big deal. I was just hoping to find a way to add a little more life to the flame itself.

 

Well the Doom 3 particles are pretty powerful, so there are probably some things you can do. For example, you could add extra particle stages representing sparks or creating a variation in brightness or flame shape; there is also the "bunching" option which controls how smoothly particles are emitted, which could be used to create a flickering flame effect.

[SneaksieDave]

Really? How did you do that? I didn't see anything that would modify the position of the actual emitter.

IIRC, it's these, from tdm_lights.def, that control the particle wavering as a whole:

 

"scriptobject" "rand_osc_light"

 

"editor_usage" "Moving light source that oscillates randomly about the origin."

 

"editor_float f_min_x" "Minimum frequency of the x oscillator [Hz]"

"editor_float f_min_y" "Minimum frequency of the y oscillator [Hz]"

"editor_float f_min_z" "Minimum frequency of the z oscillator [Hz]"

 

"editor_float f_max_x" "Maximum frequency of the x oscillator [Hz]"

"editor_float f_max_y" "Maximum frequency of the y oscillator [Hz]"

"editor_float f_max_z" "Maximum frequency of the z oscillator [Hz]"

 

"editor_float phase_x" "Relative phase of the x oscillator (in degrees)"

"editor_float phase_y" "Relative phase of the y oscillator (in degrees)"

"editor_float phase_z" "Relative phase of the z oscillator (in degrees)"

 

"editor_float d_x" "Max displacement in x"

"editor_float d_y" "Max displacement in y"

"editor_float d_z" "Max displacement in z"

 

 

Or wait... is that the light movement, or the particle movement, or both? I think Ishtvan developed this so he would know for sure. I think it controls both, so they're linked... maybe. Crud, if that's the case then, how would we separate particle movement from light movement (in case we didn't want the latter, for optimization). Now I'm getting all confused... Ishtvan, help!

[Springheel]

I'm pretty sure that's just for the moving light, though it's worth testing to make sure. I'm not using the moving light for the candle entities for performance reasons, so perhaps the candle flame would move if I did?

[Tels]

I'm pretty sure that's just for the moving light, though it's worth testing to make sure. I'm not using the moving light for the candle entities for performance reasons, so perhaps the candle flame would move if I did?

 

The offsets etc are for moving the light source. For performance, we wan't to avoid that.

 

Moving the particle emitter could be done, but I think it would look wrong. Changing the way the particles are emitted would be better, but that can also get complicated (you need basically multi-stage emitters, possible more than one (we actually have two, IIRC, one for the glow (which has I think way too many particles) and one for the flame.

[SneaksieDave]

To clarify, this already works. I made a test room long ago with a candle and a jittering rand_osc particle (not necessarily the light*), and remember shooting a video of it for the forum, and removing any vertical movement because it looked wrong. At some point these candles were in test/torch.map, but it looks like that map is gone at this point.

 

*The only question I'm wondering about this is: can rand_osc apply to a particle or light separately as well as to a particle and light together?

[Springheel]

I don't know much about particles but as the particle and light are two entirely separate entities I would imagine they could each have whatever oscillation values we wanted.

 

If some kind of oscillation could be used to move the particle emitter back and forth that might be an aesthetic improvement. I have no idea where the emitter is actually referenced, however. I also don't want to spend TOO much time on this, as it's a fairly minor cosmetic issue, and there are still lots of characters I want to rig.

 

If you'd like to experiment with it Sneaksie, that would be great, but for the time being I think I'm just going to get the entities set up using the existing particle as is.

[Tels]

I don't know much about particles but as the particle and light are two entirely separate entities I would imagine they could each have whatever oscillation values we wanted.

 

They are actually NOT two seperate entities. (at least in the current setup).

 

The tdm_candleflame entity is:

 

* light emitting

* has a visible "model" of the particle, which emits the particles when it is on.

* has a visible "model" of the particle, which emits the particles when it goes out

* has a script object which lights/extinguishes the entity (aka swap the emitter, toggle light off/on etc)

 

The only way you get the emitter to oscillate w/o the light to oscillate is to:

 

* build a light def with no visible particle model

* then attach an oscillating emitter to it

* upon lighting/extuingishing of the light object, trigger a script that changes the emitter from "lit" version to "unlit" (the unlit version does simply play the smoke going up so you see the candle going out smoothly, it then stops emitting).

 

Look for instance at tdm_lights.def:

 

entitydef light_candleflame
{
	"inherit"							   "light_extinguishable"

	"editor_usage"				  "Static extinguishable candle flame. (Light origin does not move to simulate flickering)"

	"mins" "-1 -1 -2"
	"maxs" "1 1 2"

// tels: does not work
	//"clipmodel_contents" "131088" // CONTENTS_RESPONSE|CONTENTS_MOVEABLECLIP
	"clipmodel_contents" "131072" // CONTENTS_RESPONSE
	// CONTENTS_MOVEABLECLIP BIT(5)

	"model_lit"					 "tdm_fire_candle_glare.prt"
	"model_extinguished"	"tdm_smoke_candleout.prt"
...

 

The "model_lit" and "model_extinguished" lines need to be empty, so make it like so:

 

entityDef tdm_candleflame_no_particle
 {
 "inherit" "tdm_candleflame"
 "model_lit" ""
 "model_extinguished" ""
 "scriptobject"  "light_ext_extra_particle"
 }

 

You would also need to write the script object "light_ext_extra_particle" and make it inherit from "light_ext" and code in the extra functionality. Also, you need a new object for an oscilating emitter.

 

(I probably won't have time until the 11.6 to look at it I am afraid

 

Still, I hope that helps!

[Springheel]

Hmm. I definitely don't want to start mucking around with scritps at the moment. I think I'll just mark the flickering as a post-1.0 feature and look at it later.

[Tels]

Hmm. I definitely don't want to start mucking around with scritps at the moment. I think I'll just mark the flickering as a post-1.0 feature and look at it later.

 

After a bit of thinking I *believe* we could just re-use the "light_ext" script object for the emitter, andmake a light which no light emitting: there are a "noshadow", "nospecular" and "nodiffuse" spawnrargs (or like so) and setting them all to "1" might create a light object that doesn't actually emit light. So you would need:

 

* one candleflame light object with "model_lit" and "model_extingusihed" set to ""

* another one, where "model_lit" and "model_extingushed" are set, but "nodiffuse", "noshadow" and "nospecular" are set to 1, and the rand oscillator stuff is set appropriately.

 

Then you just attach both of the at the same position to the candle and the light emitting one should stay still while the particle emitting one will bounce around.

 

You could try that if you are adventourus

 

However, it still uses one extra entity per candle flame, and I am not sure if Doom will understand that the light won't emit light and thus optimize it away and just have the particle emitter bouncing around.

 

IMHO it might be better for performance if we can make a script (or better C++) code that modifies the particle emitting center point. (But that is certainly more complicated)

[greebo]

Ok, here we are right before release packaging time, and I see there is a video/flame_candle.roq file and the corresponding shader in the material file tdm_video.mtr, both seem to be unused, at least I couldn't find any references to them.

 

Am I assuming right that I can go ahead and remove the candle flame video or at least exclude it from the package?

[Springheel]

Yes, that was an experiment that didn't pan out.

[Dram]

Ahh! Forgot to remove it It was a year and a half ago or so, feel free to delete.