Selective interpolation for models

[Enjay]

I don't *think* this is in, and I've no idea if it is actually possible, but I'll ask.

Model interpolation is great. It smooths things out very nicely for most models. However, some models actually look better without interpolation (for example some early Quake ports would have the flash from the nailgun moving smoothly across from one barrel to the other rather than flashing at one and then the other like it is supposed to, the torches on the wall in the starting area would also tend to look odd). So, would it be possible to have a modeldef flag to disable interpolation for specific models?

Presumably that wouldn't cause a problem (seeing as how originally GZDoom didn't have interpolation) but I don't know if forcing interpolation for individual models on a system where it isn't enabled would, so I'm not asking for that, but I am offering it up for consideration.

[Nash]

Me and Torr had a discussion about this around the time I pestered him to add model interpolation into the GZDoom renderer, and he saw my point, but never (forgot?) implemented it.

[Torr Samaho]

Yeah, you're right. I wanted to postpone the implementation of this till I add model rendering flags. Well, by now I have added some rendering flags (which Graf already ported to GZDoom 1.0.29 btw), but forgot about this one. I'll add this soon, it's easy.

[Nash]

That sounds good. So what are the new rendering flags if I may ask?

[Gez]

Presumably, INTERPOLATEDOUBLEDFRAMES, PITCHFROMMOMENTUM, ROTATING and IGNORETRANSLATION.

There may be some I missed.

The first is so that when a frame is repeated (like a monster with frame AABBCCDD 2 for example, instead of ABCD 4), it looks better. The second can set the model's pitch according to the object's momentum (useful for things like rockets when they aren't on a horizontal path). The third makes the object constantly rotating like a Doomsday pickup. You probably shouldn't use it for a monster! The last presumably prevents translations from being applied to its skin.

[Torr Samaho]

You can now add NOINTERPOLATION to the list, just added it to ST .

[Nash]

Very, very nice!

[Enjay]

The first is so that when a frame is repeated (like a monster with frame AABBCCDD 2 for example, instead of ABCD 4), it looks better.

How better? What does this do? What does the non interpolateddobleframes version not do that this does? I'm assuming it does something like allow the second frame to be intermediate between, for example, the first A and the First B rather than assuming that both A frames should look exactly the same?

[Torr Samaho]

The first is so that when a frame is repeated (like a monster with frame AABBCCDD 2 for example, instead of ABCD 4), it looks better.

How better? What does this do? What does the non interpolateddobleframes version not do that this does? I'm assuming it does something like allow the second frame to be intermediate between, for example, the first A and the First B rather than assuming that both A frames should look exactly the same?

The model interpolation code interpolates the model from one state with the one from the next state. If you now look at the imp for example:

Code: Select all

   See:
      TROO AABBCCDD 3 A_Chase

The first four sprite frames in this case are TROOA, TROOA, TROOB, TROOB, each of them displayed for 3 tics. For the first 3 tics, an interpolation between TROOA and TROOA will be shown, which of course is constant. For the next 3 tics the interpolation between TROOA and TROOB is shown, which should be nicely smooth. This is followed by 3 tics displaying TROOB. All in all this looks really jerky.

If you apply INTERPOLATEDOUBLEDFRAMES, the model will be rendered as if the definition was ABCD 6 (although there is still a minor problem when interpolation from the last frame to the first), resulting in a smooth interpolation.

Unfortunately there is still a jerkiness I couldn't fix yet (suggestions welcome ): The position of the imp only seems to be updated when changing from one frame to the next. So the position of the imp is only updated every 3-tics. Therefore, even though the frames of the imp are nicely interpolated, the movement still seems jerky.

[Graf Zahl]

Actor movement interpolation is an option that can be enabled in the menu. By default it should be on.

[Torr Samaho]

You are referring to the interpolation that can be toggled by nomonsterinterpolation, right? Thanks for the hint, wasn't aware of this interpolation code.

Unfortunately it doesn't seem to do what I need. I made some experiments with the ZombieMan and from what I can tell the movement is only interpolated during the tic, where the actor is actually moved (every 4-th tic for the ZombieMan). Since the model frames are interpolated during all 4 tics, this still looks very jerky.

[ZardoZ]

My suggestion : ( i will try to explain.... hey, this not is my mother language!)

If i have a md2 or a md3 which the model of the barrel and a animation of 13 frames of the exploding barrel, i use this in the modeldef.txt to assign the sprite frames to animation frames ...

Code: Select all

  

   <SomeKeyword to put this ON>
   FrameIndex BEXP A 0 0      // Barrel before explode   
   FrameIndex BEXP B 0 3      // Frames of the explosion
   FrameIndex BEXP C 0 6
   FrameIndex BEXP D 0 9
   FrameIndex BEXP E 0 12 

And GZDooM / ST, instead using a fixed time 3 tics per frame animation, use a one tic per frame animation, and runs between the frames. You will get a much more softer animation..... You will need to put something to know were model frames will be runned or not ..... I not very secured if you understand me, but i think that you will get the point very fast.

Other small suggestion .... Animated skins .... It will be great for some thing of Doom that can be better which a not animated mesh but which a animated skin (like some tech lamps that glows or for example .. the SoulSphere)

[Nash]

Animated skins for the MD3 format are possible via Quake 3 shaders. The code for it is readily available just as the MD3 code is, but it all depends if Graf is interested in implementing it (probably not).

[ZardoZ]

My suggestion : ( i will try to explain.... hey, this not is my mother language!)

If i have a md2 or a md3 which the model of the barrel and a animation of 13 frames of the exploding barrel, i use this in the modeldef.txt to assign the sprite frames to animation frames ...

Code: Select all

  

   <SomeKeyword to put this ON>
   FrameIndex BEXP A 0 0      // Barrel before explode   
   FrameIndex BEXP B 0 3      // Frames of the explosion
   FrameIndex BEXP C 0 6
   FrameIndex BEXP D 0 9
   FrameIndex BEXP E 0 12 

And GZDooM / ST, instead using a fixed time 3 tics per frame animation, use a one tic per frame animation, and runs between the frames. You will get a much more softer animation..... You will need to put something to know were model frames will be runned or not ..... I not very secured if you understand me, but i think that you will get the point very fast.

Other small suggestion .... Animated skins .... It will be great for some thing of Doom that can be better which a not animated mesh but which a animated skin (like some tech lamps that glows or for example .. the SoulSphere)

Ok .. i was seeing the decorate files ... Understand that I'm "old school" doomer, and i never see how works a decorate file, and less that can redefined the animations to use more frames which less tic times and make more softer animations...


A thing... why hells implement MD3 files, if after you not use 1/10 of the power of it ?

[Enjay]

A thing... why hells implement MD3 files, if after you not use 1/10 of the power of it ?

I suspect because lots of people asked for model support - which we have - but Graf has stated that it's not a huge area of interest for him so it has low priority. It's his hobby too remember, so it has to be fun for him as well.