roq effects

[Dram]

I just uploaded a change to my glared candleflame. I (in RL) recorded a candle flame and made it into an roq, which the particle uses as its effect. This makes the candleflame look very realistic, as it also slightly jumps around etc. You can check it out in any map which uses this, for example the wall candles in my blackheart manor.

 

I just have to tweak the particle file a little more as the particle does not disappear straight away after being put out (I forgot to change the lifetime again)

 

 

Anyways, I'm going to do a similar thing for things like wall torches etc or where it is appropriate, if it looks good. So please try it out and give me some feedback people

[Dram]

Forgot the most important thing - mandatory screenshot

 

[greebo]

I wonder how this affects the performance in comparison to our previous candle flame particle? Is playing the ROQ expensive?

 

Apart from that it looks quite good. If you look closely you can see where the video restarts (flame is slightly jumping), but it's not very noticeable. The part where the flame gets disturbed is probably a bit overdone, the particle becomes "interlaced" somehow (I tried to catch it with a screenshot, but I only got this, the interlacing is even stronger at one point):

 

 

Cool idea nonetheless, I hope it doesn't cripple the performance, because it looks very believable.

[Springheel]

That is a nice idea, and it does look better than our current flames. I also wonder about the performance impact, however. I'd be surprised if loading a roq didn't cost more than a particle effect. Also, would all the candle flames in a given setting be moving in unison?

 

What is that sideways shot represent? Does the flame actually react to being moved? That would indeed be cool.

 

I always thought roqs were being underused. Definitely worth exploring further.

 

(btw, any chance of a vid for those of us at work?)

[OrbWeaver]

That is a nice idea, and it does look better than our current flames. I also wonder about the performance impact, however. I'd be surprised if loading a roq didn't cost more than a particle effect.

 

I don't see why -- playing a video is just swapping out a single polygon's texture at regular intervals, whereas a particle effect requires transforming and rendering multiple polygons. Of course only testing will answer this.

[SneaksieDave]

Yep, looks quite good. And this, coming from the guy whose poor candleflame can't get no respect!

 

Some critique:

-important: when viewed from top or bottom it looks wrong, because after all it's a flat image,

-minor: the start spot is noticable, as greebo mentioned,

-minor: the halo is maybe a bit strong or too orangey,

-??: performance concerns (maybe it'll be faster than particles, maybe slower... just another brick in the wall?)

 

Edit:

Also, would all the candle flames in a given setting be moving in unison?

Also a good point; I'd assume that might be the case.

 

Edit: The first critique above, about the view alignment - it is also affected by leaning. So if you lean, the flames lean with you. I don't honestly know if there's a way around this, because it is an image -- the same problem existed with the very first flames -- they only looked right under face-on conditions.

[sparhawk]

Can they not started with a randome offset? Then they wouldn't look all exactly the same. If you have a hallway with several candles it would look strange if they are all perfectly synched.

[Springheel]

You can check it out in any map which uses this, for example the wall candles in my blackheart manor.

 

What other maps use this effect for those of us that can't load the mansion?

[SneaksieDave]

Confirmed, they do move in unison. But I have to believe there is some kind of staggered startup command somewhere. Then again, I'm not sure that'll much help it look better though, because imagine if they are in the same wall mount: first the left one blows, then a 3 second pause, then the right one blows. Maybe if such a pronounced event (the blow) wasn't part of the anim, it would be harder for the eye/mind to track.

 

I ran into another problem. When I edited my map to try two of them side by side to test the above case, the flames no longer animated. They froze on one frame and stayed there, despite multiple disconnects and re-issued map commands. I had to fully exit Doom and restart to get the anims to resume.

[sparhawk]

I was not talking about a dealyed start, rather about an offset where they start from. So you can assign it to a number of candles, and they would all start at the same time, but at a different startingpoint. If you look long enough you would still recognize the pattern, probably, but it wouldn't be so obvious.

[Dram]

Well this effect should be faster then using 60 particles for the flame, but of course there are the problems of alignment etc.

 

If it could be coded, I could make 2 videos of the candle - one where it is being blown around and one where it is upright - this would be loaded dynamically if the candle is being moved etc and maybe even randomly a bit too.

 

I can make the video play at different intervals etc, using shaderparms, so for one candle you set it to animate at a different rate then another etc.

 

 

Yeah the video compression added those horizontal line unfortunately. I'll see if I can fix that.

 

Hmm actually I don't know of any other maps that use this. I'll make a quick test map. BRB

[Dram]

Ok, on SVN is now test/candles. It contains 2 moveable candlesticks and 1 wall candle.

 

I've noticed several problems with the roq, (one as someone mentioned the roq stopped playing back after a reload etc) I'll play around with this later.

[Ishtvan]

I was not talking about a dealyed start, rather about an offset where they start from. So you can assign it to a number of candles, and they would all start at the same time, but at a different startingpoint. If you look long enough you would still recognize the pattern, probably, but it wouldn't be so obvious.

 

Yeah, Id usually refers to that as "diversity" or "phase diversity," because each looping video gets a random phase so it's out of phase with the others. They do it for sounds and some other things, so I wouldn't be surprised if roq materials had an option for random phase on the looping video as well.

[sparhawk]

Normaly most options are timed, so if you use a different offest for the time, it should work.

[Springheel]

I just got around to trying the map, and all I could see around the candles was a (pretty strong) glow. There was no flame at all. Am I missing something?

 

[Dram]

Wierd

 

Yeah the glow is really good if the flame is actually there, but I don't know wtf is going on there.

 

I'll have a look into it. The roq material is meant to be referenced in video.mtr, so maybe that's changed?

[Tels]

Wierd

 

Yeah the glow is really good if the flame is actually there, but I don't know wtf is going on there.

 

I'll have a look into it. The roq material is meant to be referenced in video.mtr, so maybe that's changed?

 

I see the flame just fine, but extinguishing these candles makes the flame stay for a while until it finally goes out (the video finishes playing first?)

[Dram]

I see the flame just fine, but extinguishing these candles makes the flame stay for a while until it finally goes out (the video finishes playing first?)

 

Ahh yes, that problem. Yeah I have to tweak the video properly. It does indeed stay until it has finished playing.

[Domarius]

Well this effect should be faster then using 60 particles for the flame, but of course there are the problems of alignment etc.

The only way to really know is to test, because the flipslide could be: This is a video file, not a power of 2 texture that fits neatly into video ram. It could be that the entire video is stored in system ram and the correct image from the video is put into video ram as a texture, as needed. And if multiple candles are able to have a different offset, that would be getting a new texture from the video from system ram, into video ram, for each candle, which may be why they are all in unison at the moment. Each frame in the video is just streamed into the one texture area in video ram.

 

We know that the Doom 3 engine can handle lots of polygons, so it could be that a process like this would be worse than more polygons. Just saying.

[Dram]

Actually I just realised that it's not the video that has to play to the end but actually the particle lifespan being too long

[Tels]

The only way to really know is to test, because the flipslide could be: This is a video file, not a power of 2 texture that fits neatly into video ram. It could be that the entire video is stored in system ram and the correct image from the video is put into video ram as a texture, as needed. And if multiple candles are able to have a different offset, that would be getting a new texture from the video from system ram, into video ram, for each candle, which may be why they are all in unison at the moment. Each frame in the video is just streamed into the one texture area in video ram.

 

We know that the Doom 3 engine can handle lots of polygons, so it could be that a process like this would be worse than more polygons. Just saying.

 

But the candle flame is a really small resolution like 32x32 pixel or so?

 

I think the best (video-ram wise) solution would be to write a fragment shader that can render a real-time, pseudo-random candle flame, without using more than one or two textures. That way it would never render more pixels than nec, and not read too much texture memory.

 

But I don't know anyone who can do this :/

[Tels]

But I don't know anyone who can do this :/

 

Gosh, these guys are incredible, they heard my cry for help:

 

http://www.siggraph.org/publications/bibli...hp?detail=17201

 

...we propose a model that reproduces the shape, animation and illumination of simple flames produced by candles and oil lamps in realtime. Flame dynamics is simulated using a Navier-Stokes equation solver animating particle skeletons. Its shape is obtained using those particles as control points of a NURBS surface. The photometric distribution of a real flame is captured by a spectrophotometer and stored into a photometric solid. This one is used as a spherical texture in a pixel shader to compute accurately the illumination produced by the flame in any direction. Our model is compatible with existing shadow algorithms and designed to be easily incorporated in any cultural heritage real-time application.

 

I wonder weather TDM is a "cultural heritage real-time application", tho

 

Then there is this:

 

http://director-online.com/buildArticle.php?id=1160

 

And this:

 

http://www.cs.ucdavis.edu/research/tech-re...CSE-2006-22.pdf

 

That is a hot topic (sorry

[Ishtvan]

Okay, we'll just assign 10 people from our 100 person programming team to work on implementing that research algorithm in an existing game engine. Oh, wait...

[Tels]

Okay, we'll just assign 10 people from our 100 person programming team to work on implementing that research algorithm in an existing game engine. Oh, wait...

 

I know what you are saying, but we _did_ have time for someone to include that pre-made rotoscopic (sp?) shader into TDM and that effect was on no "todo" list as far as I can see.

 

So, when someone comes up with a nice working real-time candle-flame shader, we just snag it and include it the same way.

[Dram]

I know what you are saying, but we _did_ have time for someone to include that pre-made rotoscopic (sp?) shader into TDM and that effect was on no "todo" list as far as I can see.

 

So, when someone comes up with a nice working real-time candle-flame shader, we just snag it and include it the same way.

 

I implemented the rotoscope shader because it already worked for Doom 3 specifically. The shader thing you mentioned above - would that work with doom3 or would it have to be modified quite a bit to be implemented? The rotoscope shader took all of 5 minutes to implement, and I did that, so it was no detraction from the coders etc. For example, there is no way I could code AI.