FitzQuake Gem: Render to Texture

[Baker]

I just stumbled across this while checking FitzQuake's viewport and canvas control stuff for something while adding a model viewer in my own (not FitzQuake derived) engine.

I was like, what's this doing there?

R_SetFrustum (r_fovx, r_fovy); //johnfitz -- use r_fov* vars

R_MarkSurfaces (); //johnfitz -- create texture chains from PVS

R_CullSurfaces (); //johnfitz -- do after R_SetFrustum and R_MarkSurfaces

R_UpdateWarpTextures (); //johnfitz -- do this before R_Clear // Baker: thinks ... err???[/color]

R_Clear (); // Baker: Clears color buffer and depth buffer glClear, etc.

FitzQuake draws the warp textures the screen and writes the color buffer to a texture before R_Clear, which clears the scene being drawing the world and the entities, etc. etc.

Code: Select all

/*
=============
R_UpdateWarpTextures -- johnfitz -- each frame, update warping textures
=============
*/
void R_UpdateWarpTextures (void)
{
   texture_t *tx;
   int i;
   float x, y, x2, warptess;

   if (r_oldwater.value || cl.paused || r_drawflat_cheatsafe || r_lightmap_cheatsafe)
      return;

   warptess = 128.0/CLAMP (3.0, floor(r_waterquality.value), 64.0);

   for (i=0; i<cl.worldmodel->numtextures; i++)
   {
      if (!(tx = cl.worldmodel->textures[i]))
         continue;

      if (!tx->update_warp)
         continue;

      //render warp
      GL_SetCanvas (CANVAS_WARPIMAGE);
      GL_Bind (tx->gltexture);
      for (x=0.0; x<128.0; x=x2)
      {
         x2 = x + warptess;
         glBegin (GL_TRIANGLE_STRIP);
         for (y=0.0; y<128.01; y+=warptess) // .01 for rounding errors
         {
            glTexCoord2f (WARPCALC(x,y), WARPCALC(y,x));
            glVertex2f (x,y);
            glTexCoord2f (WARPCALC(x2,y), WARPCALC(y,x2));
            glVertex2f (x2,y);
         }
         glEnd();
      }

      //copy to texture
      GL_Bind (tx->warpimage);
      glCopyTexSubImage2D (GL_TEXTURE_2D, 0, 0, 0, glx, gly+glheight-gl_warpimagesize, gl_warpimagesize, gl_warpimagesize);

      tx->update_warp = false;
   }

   //if warp render went down into sbar territory, we need to be sure to refresh it next frame
   if (gl_warpimagesize + sb_lines > glheight)
      Sbar_Changed ();

   //if viewsize is less than 100, we need to redraw the frame around the viewport
   scr_tileclear_updates = 0;
}

I thought this was cool. I've always tended to use FitzQuake as an OpenGL reference. And every once in a while, I see something I didn't notice before.

This same method could be used for an off-screen "screen shot" without using OpenGL extensions.

[mh]

It's a neat way of doing it, but be aware that it places an absolute upper bound on the size of your liquid textures. It also requires that you don't mipmap liquid texes (any kind of RTT - even with GL FBOs or D3D RenderTargets - doesn't work well with mipmaps).

[Baker]

It's a neat way of doing it, but be aware that it places an absolute upper bound on the size of your liquid textures.

According this link, liquid textures must be 64x64 for WinQuake compatibility. http://www.celephais.net/stuff/texturefaq.htm At least the ones in the map, obviously that doesn't have anything to do with possible replacement textures (.tga, .jpg, etc.)

[mh]

I'm thinking external textures, yeah. Say we have a 512x512 *water04 or whatever; because warp images need to be larger than the original texture (in order to get the correct warp, can't recall if it's 2x or 4x) in this case the eventual RTT texture will likely be too small.

[leileilol]

quake doesn't mip its liquids either, and also it imposes a strict 64x64 size for its turbulent mip

This is why Valve did the procedural ripples effect instead in software mode on Half-Life, and kept the vertex warp effect on GL/D3D