Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Tobias Johansson, posted on November 03, 2000

Image Description, by Tobias Johansson

These are screenshots of a Quake2 level viewer I've written the past weekends. It uses Quake2 PVS to render worlds, and it is almost identical to quake2 renderer except for entities, warping water and dynamic lighting, which I plan to implement sometime. I think I get pretty decent framerates out of it, 25-30 fps on a PII-300 with ATI Rage Pro using multitexturing. There are still optimizations to be done, like texture-sorting. It uses Direct3D for rendering.

Tobias Johansson

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

November 03, 2000, 01:40 PM

It looks clean and it's probably very fast. Any demo available?
How extensible is the engine? Is it capable of rendering curved surfaces? What about LOD-ing?



November 03, 2000, 03:16 PM

Looks nice. I wonder why the scene with lightmaps has a higher framerate than the scene without.

Went to your site, and so you know the download for the bezier curves doesn't work.

Phil Carlisle

November 03, 2000, 04:15 PM

You couldnt paste your code that works out texture coords for the lightmaps could you?

Thats the only problem I have left for my halflife bsp renderer.



November 03, 2000, 05:19 PM

Phil, if you are using Direct3D, you'll need to normalize and quantize the lightmap coordinates to 0.0-1.0 because Quake/Half-Life lightmaps may not be powers-of-two. (They don't have to be, because OpenGL offers the rather kick ass glTexSubImage2D which allows you to work with arbitrarily sized subimages.) The base lightmap coordinates are the same as the face's.


November 03, 2000, 05:58 PM

To Brandon:

Well under Direct3D you can also Lock portion of texture,
and copy to it... Actually Direct3D provides a lot more
functionallity when comes to 2D and texture support.
It may be uglier looking - but it's more straightforward.
I like OpenGL for it's simplycitness, but sometimes OpenGL
code may gets weird and unreadable, especially when you
have to deal with 2D imaging...

Chris Killpack

November 03, 2000, 06:16 PM

Sorting by texture should give you a massive speedup. Changing texture is by far the largest performance hit you can 'achieve' (not that you would want to of course) on a 3D accelerator.


November 03, 2000, 06:28 PM

Of course if you sort/draw your scene by texture you lose the benefits of BSP back-to-front leaf order. (which is handy for alpha world surfaces)

David Frey

November 03, 2000, 07:20 PM

One thing I've done (and I got the hint from the GLQuake source code), is to chain the opaque faces to the texture object it uses. And chain all non-opaque faces in a seperate linked list. Then draw all the opaque faces in texture order, then draw the transparent ones which will still be in the correct order with respect to one another.


November 03, 2000, 11:38 PM

Looks great, abliet a little dark.

You may wanna switch to a modulate 2x blend. (src*dst + dst*src). If you are using multitexture, or just want to avoid the mod 2x blend, use the gamma ramp to double the potential brightness (ala Q3).


November 04, 2000, 10:14 AM

DirtyPunk, could you please explain more about the gamma ramp you mentioned. It sounds interesting (i'm using mod2x myself to get more brightness, and it's not avalable on all cards...)


Phil Carlisle

November 04, 2000, 10:37 AM

Thanks for the heads up Brandon, but I'm using OGL, (not switched to D3D yet), right now for my tests I'm using glutBuild2Dmipmaps (so that it scales to power of two), I had thought that my Lightmap texture coords were wrong, but now I'm not sure I dont have a problem with the textures themselves.

Going to code a little test and see if thats the case.



November 04, 2000, 01:01 PM

Malkia, locking a texture to write a lightmap to it would be slower than ass.


November 04, 2000, 01:25 PM

Well, there is actually a windows command to set the gamma ramp.


Use this func to raise your values up.

Phil Carlisle

November 05, 2000, 04:17 PM

Well, as it turns out, there was a bug in gluBuild2DMipmaps (and gluScaleImage which it presumably uses). Writing my own little rgb scale function sorted that.

There is still a bit of "banding" on the lightmap edges though. Which is kind of weird. Been playing with different render settings and mipmap settings to see if I cant find the cause. Will have to have another dig through the Q1 source I guess.


This thread contains 14 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.