Apparantely, the Doom 3 engine has the level editor built into the executable.
If the current level designers are using this engine to create the levels, there’s no way the BSP could be calculated on the fly, especially when you consider that at times huge sections of a level may well be cut and pasted somewhere else.
Presumably then, BSPs are out of the window. Has anything being mentioned about the rendering processes?
On a different subject, I was thinking about the real time lighting/shadows. What if a monster was standing behind a closed door, with it’s shadow on the door. That must be a bugger to render correctly when the door opens. Which again points to an alternative to [conventional] BSP rendering.
Any thoughts on the subject?
From what I understand Carmack is using stencil shadow volumes with a z-fail approach. This will shadow a door opening properly as well as just about anything set of objects you can think of. This includes self shadowing and depending on implementation is pretty easy to avoid double blending and any of the normal shadow related artifacts (see nvidia’s robust shadow paper/demo).
As for the bsp. I think its still there. I don’t see how it couldn’t be. Every Quake engine (and even doom/doom2 for that matter) are entirely based on a bsp. I don’t have any specific .plans to list but from what I gather the level editor is integrated into the engine to make development and mods easier. Using your game engine to make the level allows you see exactly what everything will look like. I imagine that the integrated level editor will not be doing bsp (same as the stand alone q3radiant never did). Modeling be it a character or a level is generaly slower than final product. This is a result of the modeller having to be very general and support a very large amount of dynamic content. While editing everything is dynamic. In game things like a door was treated as a dynamic object while the walls were all static brushes. I imagine doom will do the same as previous quake games. Although the editor will be within the executable (for quick previewing of a work in progress) there will be a way to generate a bsp and vis when everything is the way you like it.
When using shadow volumes the best speed trick you can use is culling complete sets of shadow volumes that aren’t visible. This is really no different then culling any other objects using the PVS. And of course the PVS is nothing more than a complex extension to BSP. Or perhaps more correct is that PVS is built using the information from the BSP.
BSP and PVS and all those things are all about the idea the the fastest way to compute anything is to precompute it. DUH !! Carmack is without a doubt one of the biggest fans of precomputing. Look at the quake 2 source. For the models the normals are stored as a char. With that value used to look up the normal. The dot product between the normal and the light is also precomputed and stored in a look up table. (Although I am not entirely sure how that works, I think I understand what he is doing). I don’t see carmack leaving the world of precomputing. Although the video cards are becoming more about processing in real time determining whether an item is truely static and precomputing will always be faster. Always. As I said the fastest way to compute something is to precompute it. Always has been always will be. I don’t see Carmack deviating from that any time soon.
The reason I queried it to start with, was the fact that it’s been stated that all lighting and shadows are generated real time.
I can’t see that being true - I’m sure most static shadow volumes are precomputed, leaving only moving lights/shadows to deal with in real time. Simply because the ‘infinite’ shadow capping can’t be ‘infinte’ at all - the capping must be clipped to the geometry in the world, otherwise shadows would obviously project into other rooms etc. This in itself must place a heavy load on the CPU. That’s kind of where I was coming from when thinking about doors etc - As a door opens, only a part of the shadow would be visible. The rest must be clipped against the door.
The trouble is, until we get to see the video that’s being shown no-one really knows what level of effect Carmack has achieved.
ERM … dumbest thought in, well … hours
[This message has been edited by Shag (edited 05-24-2002).]
You don’t have to clip your volume to the door since the door already casts a shadow, it won’t make a difference when your monster also casts a shadow.
I also think they are still using a Bsp it is to practical to ditch it. In one inteview Carmack said levels would reqire about 10mins preprocessing. I guess thats the time they need to generate the bsp/preprocess volumes.
On a side note the screens on http://gamespot.com/gamespot/filters/products/screenindex/0,11104,469881,00.html?page=1
don’t seem to show any self-shadowing (e.g. the fat-guy’s nose has te usual dot lighting but it doesn’t cast a shadow on his face, same thing with those orange demons)
Wich is strange since it shouldn’t be that costly with stencil shadows (well you render the volume anyway all you can save is rendering your meshes a few times)
Thanks for the link to the screens. They’re quite impressive (excellent use of bump mapping), but… does anyone know:
a) Is there ever more than one shadow-casting light?
b) Is there any ambient light?
I ask this because it doesn’t look like either is true, which would limit the engine to poorly lit environments. The lack of ambient in the toilet screen makes the shadow look rather unconvincing (bright light + white walls = lots of ambient).
Originally posted by Shag:
Simply because the ‘infinite’ shadow capping can’t be ‘infinte’ at all - the capping must be clipped to the geometry in the world, otherwise shadows would obviously project into other rooms etc.
well… normally here where i live, there is no direct light in other rooms than the one the light is in (assuming dors are closed) so its right they are in shadow => in shadow volumes. but those rooms can have other lights casting other shadows…
think about it, its easier than you think…
on the nvidia page you see the solution for perfect shadow volumes for EVERY situation (except translucent objects (blend/alphatest stuff)). its not the fastest way, cause most scenes are not “general” but very specific, so you can optimize, but the general solution DOES exist for perfect direct illumination… no problems there…
as we all know, real illumation lives from the indirect lighting, but well… first we get doom3, wich has correct direct lighting, wich is nice as well
Carmack uses beam trees on the fly to limit the scope of the lights. I think the engine can handle arbitrary numbers of lights, but the onus is on the level designers not to overload the engine. So you can have many lights but the designers make sure that they don’t all overlap and illuminate too much of the same geometry.
They can be visible and illuminate the same scene but each portion of the scene is only rendered for the illumination passes for the lights in the beam trees it occupies.
[This message has been edited by dorbie (edited 05-23-2002).]
A quote from the great JC himself:
“Level designers have to retrain themselves to use lighting more efficiently. Instead of plastering in hundreds of little lights to get your light maps the way you want, you need to think about primary key lights in a scene, and fill in around them as necessary. Cinematic lighting skills are now directly relevant.”
Hey guys. I just got back from E3 where I got to see all of the stuff in the screenshots on the web, as well as some actual in-game footage (which I haven’t seen pop up on the net yet). There is a little theater in their booth where a few people at a time could see a ~12 minute scripted game sequence.
This sequence was, far and away, the most impressive thing I’ve ever seen rendered real-time (including nvidia’s real-time final fantasy or werewolf). The animations are complex and silky smooth and did things you don’t normally see with skeletal animation. For example, the bathroom demon’s head seems to be able to slide in and out of it’s body and one demon-creature had a tentacle arm that would snake out towards the player.
I know this isn’t that big a deal, but the rendering system handles different materials really well. Skin looked like skin, and metal looked like metal.
Unlike past Id games, this demo had what appeared to be a pretty solid physics model. When one of those fat-man zombies was shot on a stairway, his limp but still-articulated body bent over the railing and slid down the stairs. The player was also shown shooting some boxes off of a shelf and one zombie knocked a barrel down a flight of stairs. It also looked like wounds appeared at the correct spots when the monsters were being shot, but it was almost too fast or dark to tell for sure.
Lastly, I wanted to mention that I’m not the kind of person who gets “tense” at horror movies or when playing the old Doom, but this one almost made me jump a couple of times…it’s just so realistic.
To take a stab at Don’t disturb’s questions:
a) There was definitely more than one light in some scenes during the scripted demo (the zombie’s faces would light up when they were being shot at with the shotgun) but I don’t recall seeing a flash of their shadow behind them.
b) It’s difficult to tell whether there was any ambient light, as sometimes you can mistake diffuse light for ambient and there was a lot to take in…I wish I could have watched it two or three times just to look for stuff like that . I didn’t specifically notice any ambient, but I didn’t miss it either.
The lighting sure is more realistic than real, but are all the lighting dynamic, something like per-pixel lighting, or are there percalculated lightmaps?
Originally posted by blender:
But are all the lighting dynamic, something like per-pixel lighting, or are there percalculated lightmaps?
No, John has said many times over the last few years that one of the coolest things about D3 is the unified lighting model. Everything in the game gets lit with a single algorithm. No “lightmaps for this, vertex lighting for this, dynamic lightmap for this…” sort of thing.
So… I wonder how he does the unified lighting… And is the shadowing “happening” at the same time?.. And thus, unified shadowing?, hardly I think. Same shadowing system on the map and the characters?
Surely there are some lightmapping taking place… Why else would he need up to 7 passes?!
Originally posted by AndersO:
Surely there are some lightmapping taking place… Why else would he need up to 7 passes?!
You are welcome to think whatever you want, but John has made it EXPLICITLY clear many many times that all lighting in Doom 3 will be generated the same way, and there will be no more lightmapping. That implies also that all shadows are generated the same way (since shadows are actually just the absense of lighting). Whether or not he’s telling theh truth is another matter, but I think its very unlikely a person who has been as open with the community and for as long as he has would be lying to us.
Why 7 passes? What was the context of this statement. To the best of my recollection, he was talking about cards with only 2 texture units. Depending on what features you use, you can easily run up to 5 or 6 passes per light.
I think if he tried to mix true dynamic lighting with static lightmaps, it might look crap.
Quake2-3 used a very poor dynamic lighting system (rendering a decal), which didn’t fit with the lightmaps at all.
What questions would you guys like to ask JC given a chance?
The reason I ask is that I’m seriously tempted to mail him and ask him to post some technical info in here. He obviously likes talking about the technology he’s using, and being an OpenGL forum he may well drop a post in.
What do you think? It can’t hurt to ask …
I know what you mean, I’d like to ask him a thing or two aswell, altough I think I have a good idea how he does most of it.
Regarding Doom3, I found this quite interesting:
Obviously Doom3 was demoed on a R300 at E3, which I suspect means that it should be ready for launch quite soon.
Patience guys, I am sure when the Doom 3 test comes out Carmack will start talking more and more about the technology and how he goes about everything (lighting, shadowing models/animation). As said Carmack is very open about letting everyone know what he is doing and I am sure that the Q3 source code will be released eventually too. Same as with doom, quake, and quake2. Carmack is all about the community and as far as I am concerned he wants everyone to see his code and learn from it.
How many companies out there release the full source code to their games. I mean I can see why carmack won’t release the doom 3 code anytime soon but he is one of very few that release the source of previous projects.
One of the coolest things I have seem was posted here on opengl.org. Don’t know who it was (Props are definately deserved) but someone took the quake 1 source and added in stenciled shadow volumes aka Carmacks reverse method/Doom 3 shadowing. It looked so cool in quake 1. Very entertaining. I am sure Carmack got a kick out of seeing it. And I garuntee that he did check it out.
I wrote that. I think it demonstrates a some of questions asked here in a practical way. (Yes you can have multiple lights up to 30 in some areas (60+ passes that))
Since i’ve seen those screen shots I’m seriously thinking of adding bump-map support. (It looks soo cool)
(Those shots taken from the video do seem to show some self shadowing, but somehow I thing they are using a low-res mesh for the volumes)
Lower res mesh for shadow volumes would make some sense, but correct volumes require zbuffer capping by the shadow casting geometry, so for self shadowing this could cause very obvious artifacts which would only be partially fixed with additional work wedding the volume to the high res mesh. You could cap with the low res mesh itself but that might cause other problems.
I think what you are seeing is the bump map simulating high res surface detail on a lower res model mesh. So although the model looks very high res, it is perhaps lower resolution than you assume and perhaps it shows in the shadow map. Look at the silhouette of the models.
[This message has been edited by dorbie (edited 05-24-2002).]