This post isn’t really OpenGL related, but since DooM3 uses OpenGL, I thought I may post it here and see wath you think about it
Ok here are some ideas/questions what methodes/algos could have been used in the new DooM engine:
I’m pretty sure that JC’s going to use something ‘completely new’(but only for id)- namely portal/areas based engine(Unreal already used it 3 years ago, but that’s not the important point). The advantages of this method are:
-the brushsides/faces don’t have to be split up and since the 3d cards of the new generation(GF 1&2&3) can handle 20482048 textures that wouldn’t be a problem for the HUGE lightmaps(more on that later). In fact, if a face in Q&Q2&Q3 was larger than 12816x128*16 lightmap texels, it had to be split up into smaller pieces. That’s not a problem anymore.
-Fast lighting calculations
I think JC could have used some methods I’m going to describe here:
Since the map is divided up into ares and each area has portals pointing to other areas that can really accelerate the lightning proccess. In the beginning the light has 6 frustums, that are split up against the portals they’re in- and then, using the stencil buffer, they’re drawn so that only the litten parts of the siurfaces would be affected by the light in question. Then, using the NV_REGISTER_COMBINERS, just let the card compute the lighing.
That’s quite similar to the 1 method and to the method the Q3MAP tool uses(everybody who’s looked into its source knows what I’m talking about). In this method the split up frustum sides are projected on the faces and then, using something like a scanline algo, the light values are computed and stored into the lightmap.
Quite similar to 2 one- but only computing the visibility of every light on every face visible from that light and have the 3d card compute the lihghting values
Since sounds and lights are waves, quite similar methodes could be used for the sound engine(just imagine the echos of your steps if you walk into a large room
Hope you understood most of this stuff