DRD Team

I will definitely run into problems once interpolation is added.

I have models that are animated such that their heads twitch erratically (if you've seen horror movies, you'll know what I'm talking about ).

Interpolation will most probably screw things up. Look what interpolation did to Quake 1's nailgun firing animation...

The current definition format won't interpolate.

Nash wrote:Look what interpolation did to Quake 1's nailgun firing animation...

Ahhh! is that what causes the flash to move smoothly from barrel to barrel. It looks terrible. A lot of other animations suffered from being smoothed out too now that I think about it. I remember wall torches looking a bit odd...

Obviously, any decent implementation should allow for interpolation to be disabled between two arbitary model frames as well as on a complete frame sequence.

The difficulty comes in when you have to jump between two frames in two different sequences (bare in mind that in DOOM a frame sequence is only 4 frames in length on average so we also NEED to create "inter frame animation" (where eg; a 30 frame animation in a model is scaled between the 4 sprite frames) therefore there are two transform targets plus an additonal inter point to take into account. Without this you get teh-suck which is the Vavoom model renderer.

The easiest way is to interpolate (linearly) between the two frames in question once the two inter frames (in both frame sequences) are determined but a much better method is full sub-interpolation (as used in Doomsday).

Graf, are you planning Vavoom-style lightmap or is that completely out of the question? Plain curiosity.

No plans at the moment.

I'm just curious, how does Vavoom's lightmap look and work? I'd really rather not download it, being a dial-upper and all.

It creates real lightmaps like Quake uses on the fly. That allows realistic shadows but the downside is that such a lighting model is highly static and somewhat limits the use of geometry.
It also requires the use of a glVis utility that has to be run for each map.

But... lightmaps are nice... I hope you implement them some day. It's the best we will get out of the Doom engine next to real-time shadows.

I wouldn't play classic Doom anymore if it had real-time shadows. It'll probably be slow like hell and I'd rather switch to a modern engine for real-time shadows!

So back to lightmaps. I can't be bothered to download Vavoom because it's weird. Not to mention the site hasn't been loading for me. So what happens to the lightmaps when stuff like moving platforms and lifts move up and down? What about polyobjects too? Doors?

Nash wrote:Why would you want MDL support? It's such a crappy format anyway.

It's HL1's model format.

Nash wrote: So back to lightmaps. I can't be bothered to download Vavoom because it's weird. Not to mention the site hasn't been loading for me. So what happens to the lightmaps when stuff like moving platforms and lifts move up and down? What about polyobjects too? Doors?

Judging by how stuff works in Quake engines, the moving brush (brush is kinda 3d floor in Doom) has it's lightmap remained on it's self as it moves, meaning if it was iluminated dimly and it goes to a bright sector (imagine a 3d platform riding from a dungeon to an exterior) it'll come out dark onto the fresh air. Lightmaps are not dynamic. At least not in quake-engine games.
In unreal the objnect was iluminated but it lost it's shadows (polygon ilumination).

Nash wrote:
So back to lightmaps. I can't be bothered to download Vavoom because it's weird. Not to mention the site hasn't been loading for me. So what happens to the lightmaps when stuff like moving platforms and lifts move up and down? What about polyobjects too? Doors?

I don't use Vavoom either. But from what I heard it recreates the lightmaps and in Map06 of Silent Steel it causes a massive frame rate breakdown.

Whoa. The thought of it re-creating lightmaps in real-time kills me already...

Where can I download Silent Steel?

From the /idgames archives. With a little tinkering you should be able to run it in GZDoom as well. The mapper used a hack-ish method to define the slopes. It might create problems in GZDoom (but then also in the latest Vavoom because it supports Plane_Align since 1.19.)

To run this map set without problems all Plane_Align's have to be replaced with Line_SetIdentification. Otherwise some slopes might be wrong.