flipCode - Tech File - Muresan Robert [an error occurred while processing this directive]
Muresan Robert
Click the name for some bio info

E-Mail: Robert.Muresan@email.ro

   06/19/2000, Back Again...

Welcome to a new .tech file update. A lot of good things happened these days so i'll do a bit of rambling on the ongoing things.

DirectX 8. I'm not a big Direct3D fan ( OpenGL rulez ) but i saw the preview of the new game SDK and it looks very promising.I like the new shader technology that is going to be present in DirectGraphics ( DirectDraw + Direct3D) ,but there is one thing i fear about: ovearhead. I hope they aren't going to do the same thing with this, like they have done with Direct3D IM. I think after all i will start learning some Direct3D. It looks promising.

Doom III. Shotgun is back!!! I really like id's idea of creating a new Doom game. I spent a lot of hours playing Doom at his time, and with a new engine is going to be just great.

Let's chat about some coding now.

Finished research, started working on my next engine. I hope it will look great since, I've put almost a year of research in it. I call it Sandra since i couldn't figure out any name. I will put a game on top of it , called Quad.

Visibility Systems

I saw Paul Nettle's new site and it's just great. I have started thinking about realtime HSR myself. It's really a tricky problem to solve. I 'll just stick to a combined octree / portal system in my engine. I had a small idea of calculating the view-frustum volume, and presumming that i have my raw polygon data sorted front-to-back and creating a frustrum for every polygon ( clip it against the view-frustum) , calculating its volume and substracting it from the view-frustum volume. And then every polygon was supposed to be clipped against the previous poly frustums and the view frustum , calculating the volume, substracting it from the view-frustum volume and going one like this until the view-frustum volume was 0 (remember that the polys are sorted front-to-back). This was just a small idea at the moment, and it lakes at some points.

Texture Management Under OpenGL.

I read a cool article over at Delphi3D about texture-managment. Tom Nuydens has very cool ideas. Based on his article i started thinking about the high detail textures, i was talking about in the last issue. I grabbed a few 3D shooters and started looking at the geometry. In almost all of them, per each frame you have only a few ( about 5 , more or less) textures that are visible at a close distance to the player. So here is my idea:
  • Alocate a few empty textures (big ones: 1024x1024)
  • Calculate the priority of each texture at every frame.
  • Let's say textures 1,2,3,4,5 ( just an example ) are the closest( 1 is the closest, then 2 and so on...)
  • Start filling texture 1 with glTexSubImage with 64x64 blocks (no big deal for a 3D card)
  • And as the priority decreases so does the uploaded image block ( 32x32 ...)
  • If you finished uploading the big texture, then just show it to the player
  • There are two tricks to this one:
  • Choosing the apropriate TexSubImage size, to avoid speed drops
  • Priority change: Let's say you didn't finished loading texture 1 (highest priority) , but texture 2 becomes the next most important thing.You will have to change to uploaded image block size and take care to still fill the texture right. This can be done like this: Imagine that textures are a big line of pixels ( I Konw they are like this in ram, i've coded software rasterizers myself) and upload constant length lines each frame.
  • texture 1 gets 64 full length lines
  • texture 2 gets 32 full length lines , and so on.
  • With this trick you can create a continuous data "flow" from the system to the video card.Keep this flowrate low and your framerate won't have to suffer. The trick is to find the maximum flowrate you can afford.

    Recently i went trough John Carmack's older .plan files and read some stuff about lighting and a pretty good idea strucked me. ( isn't this .tech file based on other articles? :) ). Would't it be great to see him having a .tech file here on flipCode? No, not this idea strucked me. He said something about using 3D textures to create dinamic lights. I thought about using a 32x32x32 texture to represent the ligth volume , with the light in the center of the texture and each texel representing a light value. Now, scale each of the polys that are lit by this light to the size that fits in this 3D texture. Calculate witch 3D texel coresponds to each lightmap texel on that poly. Trace a ray trough the texture from the center of the texture to the texel that touches the poly, and continue the ray until it reaches the edge of the texture, but set each texel behind the poly to 0 ( no light - shadow). The trick ( i use this word to often) is to sort your poly's and start with the closest one to the light. In a portal system you can set each light to light only the sector in wich it is , and if you have a bsp for the room, then your good to go.

    Ok, if this was confusing , then imagine a 32x32x32 "cube" grid ( the texture) put over your room ( like an octree or something ) with it's center in the position of the light. This is an "axis-aligned texture" so is pretty easy to work with it.


    Just passed my C++ exam at the uni with 10 ( best you gen get), still have 4 more to go, but summer comes, lots of time for coding. As always, keep coding, havin' fun ,and sometimes go out to the see the sun.

  • 06/26/2001 - Tech File Update
  • 06/19/2000 - Back Again...
  • 04/20/2000 - Detail And Hardware
  • 03/28/2000 - Introduction & Programming Issues

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]