TextureQuad viewed at an angle

[stevmjon]

just noticed this today when i was mucking around with quad polygons.
i was converting a tile grid map to 3D co-ordinates to draw a quad polygon where the tile is.

so i was using raycasting to check which tile the ray collides with then converting this tile to 3D to draw the quad texture.

the problem is the texture distorts when viewed on angles. so i assume the polygon is drawn from top to bottom in horizontal lines? this is causing a tri polygon look when the lines are going from say top edge to side edge, but is good from one side to opposite side?

[stevmjon]

i remembered that i looked at this some time ago. i found a demo i modified to get better looking textures, and i modified this again to add a few new ways to sub-divide the polygon.

run the demo and press 'enter' to see the outlines of the sub-divisions, and press 'space' to cycle through all the variations (also press 1 - 8 to see out of order).

i actually like number 4 & 8. 4 is tri's and 8 is quads, but they look similar when rotated around on angles.

   enjoy , stevmjon

[kevin]

  Yeah dude, subdividing the surface up into a grid is probably the best bet to avoid affine slipping for a camera with 6 degrees of the freedom.  The closer the camera the worse approximation gets.. This gives a  kind of gives you a Playstation One / Sega Saturn look.

  But..  In something like a Wolf 3D / Doom game/scene, where you don't really need a 6 degrees of freedom,  and the camera is rotating around a one axis, then the wall segments just need to compute a U ans then draw the strip and Z is constant across the strip.  So along the wall, have 4 or maybe 8 samples and just draw a quad from top/bottom.

  Roof / Floors are much the same, since the Z is constant along each span of the polygon.  You can compute a prospectively correct U/V pairs along each edge of the surface, then you can just affine texture map between them. 

  That's pretty much the core idea behind DOOM.

[stevmjon]

so the grid is best for subdividing polygon, cool. i like this one too.

with the doom style, are you saying to draw the wall polygons as verticle strips (which gives a more perspective correct look), and to draw the floor/roof with horizontal strips (which gives a more perspective correct look)?

i did make a demo where i draw the whole screen (roof/wall/floor) with verticle strips, but the fps slows down to 30 fps. so i thought that using subdivided polygons will be faster to draw, even though not perspective correct, but looks good enough at a faster fps.

[kevin]

  Wolf / Doom and its variants rely upon lines of equal z.  They know that since the depth of a strip (horizontal or vertical) is uniform there's no point sampling uv's across it, so they compute the strip start and end points and then interpolate the between them. 

  Imagine if you had a set of vertex that represent the map.  The maps a 2d array, where each element is a texture index.  Zero meaning empty space, positive integers meaning texture selection for the block. 

This kind of thing
 

Code Select Expand

1,1,1,1,1,1,1,1
1,0,0,0,0,0,0,1
1,0,0,2,2,0,0,1
1,0,0,2,2,0,0,1
1,0,0,0,0,0,0,1
1,0,0,0,0,0,0,1
1,1,1,1,1,1,1,1

 

  To brute force walls (i.e. see terrible idea)

 

Code Select Expand

      for zlp=0 to MapHeight
       for xlp=0 to MapWidth

            Tile=Map(xlp,zlp)
            if Tile=0 then continue           


            // check how far from the camera this thing is ?   
            cx#=(xlp+0.5)*TileSize
            cz#=(zlp+0.5)*TileSize

            if DistanceFromCamera(cx#,cy#)>viewdepth then continue           

            // compute vertex for this tile in world space

            // vertex 0
            Vertex#(0)=xlp*TileSize
            Vertex#(1)=zlp*TileSize

            // vertex 1
            Vertex#(2)=(xlp+1)*TileSize
            Vertex#(3)=zlp*TileSize

            // vertex 2
            Vertex#(4)=(xlp+1)*TileSize
            Vertex#(5)=(zlp+1)*TileSize

            // vertex 3
            Vertex#(7)=(xlp)*TileSize
            Vertex#(8)=(zlp+1)*TileSize

            //  Use the distance from the block to approximate the sub division level to use,
           //  so stuff closer is cut up into small chunks, where as far way stuff is less accurate.   

           GenerateSubdividedVertexList(VErtex(),Divided_Vertex#(), Sub_Division_Level)

           Transform_And_Render(Divided_Vertex#())
 
       next
      next
 

   So the render routine takes the wall end points and chops them up the wall into X chunks, which are then drawn as span of textures.   

   In concept such a raw approach should work, except the wall chunks would overlap. You could buffer them based upon depth from the camera say, which would most likely work, but trade off ends up being that's its more expensive than drawing strips due to high amount overdraw. 

[stevmjon]

thanks kev. i have a couple of idea's now.

#1 :
> use raycasting and draw the walls with verticle strips (fast)
> use raycasting (from above) to look at each tile the ray steps on and draw that floor tile with horizontal strips keeping tabs on not repeating that floor tile (mirror strip for roof).

NOTE: verticle wall strips is same z across strip, and horizontal floor strips is same z across strip

#2 :
> use raycasting to look at each tile the ray steps on and draw this floor tile as a quadtexture, keeping tabs not to repeat it. closer tiles get sub-divided. when i reach a wall then stop ray here. this will have minimum overdraw and only draw what is inside camera view frustum. also don't need to cast every ray either. can step across view frustum.

raycasting :
DDA (Digital Differential Analysis)
this technique is fast to step across tiles that are inside the camera view frustum.

anyway, having fun with experimenting.

[kevin]

  On way out, but this is basically the approach described above.  Will post a final later

  Added light mapping.. coz, why not

Download Source Code:

 Download  Yet Another Wolf 3D Demo Source Code

[stevmjon]

looks awsome kev. looking forward to seeing the final code.

[kevin]

  Was thinking about the floor/Roof generation yesterday.  Regarding preparation work, there's a lot of common calculations going and data generation. 

For stuff like the ground, we're potentially generating a set of unique vertices each map within tile around the camera. 

The thing is there's really only a hand full of variations.  A tile can be divided into TextureSize/1  , TextureSize/2, TextureSize/4, TextureSize/8, Texturesize/16  .. 

It seems to me those chunks can be precomputed and then copied in the vertex buffer,then customized

So a tile that's under the camera there's that needs a 16 by 16 polygon mesh to represent it, makes a vertex buffer that's (17 by 17) vertex. 

rather than run through and generate these all,  We copy for the pre-calced cached vertex data we need, then run through and apply the vertex offsets..



 

 

  Download

[kevin]

  Had a quick fiddle with rendering objects.... seems viable

[stevmjon]

polygon depth order seems good.

[kevin]

  it's just rendering on top of the scene directly to the screen, so a separate pass.   

  Just adding a view from player routine(s) to it at the moment..  It'll be poppy with walls given a scene buffer full of average Z polygons.. but there's no visibility clipping, so that'd sort a lot of that out. 

  This is This is basically do with Reality on  Amiga..  some 30 years ago

  Reality Demo

[kevin]

Wolf 3D - With Objects Teaser Video

Download
 
  Source Code Yet Another Wolfenstein 3D Demo (Texture Mapped Floors & Ceiling)