PDA

View Full Version : Doom 3, lighting/shadows, and BSPs



Pages : [1] 2

Shag
05-23-2002, 12:55 AM
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?

Regards

Devulon
05-23-2002, 01:59 AM
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.

Devulon

Shag
05-23-2002, 02:20 AM
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 http://www.opengl.org/discussion_boards/ubb/smile.gif

[This message has been edited by Shag (edited 05-24-2002).]

Pentagram
05-23-2002, 02:34 AM
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)

Charles

Don't Disturb
05-23-2002, 11:39 AM
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).

davepermen
05-23-2002, 12:20 PM
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 http://www.opengl.org/discussion_boards/ubb/wink.gif

dorbie
05-23-2002, 12:49 PM
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.

....I think.

[This message has been edited by dorbie (edited 05-23-2002).]

dorbie
05-23-2002, 01:12 PM
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."

Zeno
05-23-2002, 09:17 PM
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 http://www.opengl.org/discussion_boards/ubb/smile.gif. I didn't specifically notice any ambient, but I didn't miss it either.

-- Zeno

blender
05-24-2002, 02:38 AM
The lighting sure is more realistic than real, but are all the lighting dynamic, something like per-pixel lighting, or are there percalculated lightmaps?

LordKronos
05-24-2002, 02:46 AM
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.

AndersO
05-24-2002, 03:02 AM
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?!

LordKronos
05-24-2002, 03:47 AM
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.

knackered
05-24-2002, 03:49 AM
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.

Shag
05-24-2002, 04:13 AM
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 ...

bakery2k
05-24-2002, 04:39 AM
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.

Humus
05-24-2002, 06:51 AM
Regarding Doom3, I found this quite interesting:
http://quote.fool.com/news/symbolnews.as...027B5941F0BC%7D (http://quote.fool.com/news/symbolnews.asp?currticker=&symbols=ATYT,NVDA,TDFX&GUID=%7BE0DBBAF8%2DD205%2D4A96%2D9E43%2D027B5941F0 BC%7D)

Obviously Doom3 was demoed on a R300 at E3, which I suspect means that it should be ready for launch quite soon. http://www.opengl.org/discussion_boards/ubb/smile.gif

Devulon
05-24-2002, 06:55 AM
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.

Devulon

Pentagram
05-24-2002, 07:27 AM
Hello
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)

Charles

dorbie
05-24-2002, 11:37 AM
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).]

dorbie
05-24-2002, 11:49 AM
I don't think a unified lighting model eliminates the possibility of some light map effects. There is evidence for sharp stencil shadows and soft edged penumbra effects in the screen shots and animations. Clearly this requires two different approaches, even if the scene description is a single one and the approaches are seamlessly "unified".

A projected light map is still a light map....

davepermen
05-24-2002, 12:59 PM
Originally posted by dorbie:
I don't think a unified lighting model eliminates the possibility of some light map effects. There is evidence for sharp stencil shadows and soft edged penumbra effects in the screen shots and animations. Clearly this requires two different approaches, even if the scene description is a single one and the approaches are seamlessly "unified".

A projected light map is still a light map....

please stop this talking all the time about the highresmeshes for shadowvolumes and the shadowmaps. carmack states he is using simple shadowvolumes with a from him well and accurate described technology. thats all. and i can't see any of your fancy softshadows nor any shadowmaps on your screenshot. in fact, it looks like a demo from humus with some different leveldata and quite good drawn meshes. and humus only uses simple bumpmapping and simple shadowvolumes, no fancy new_world_order technology, but the stuff that is actually possible on hardware, instead of your fancy dreamings.

you can't combine shadowmaps and shadowvolumes in a way they look nice. no way...

stop it till its out or official, okay?

zed
05-24-2002, 01:35 PM
is it just me but from what ive seen half the stuff is the same as was shown at the gf3 lanch (when was that over a year ago?) it does feel like theres quite a bit thats being keep back, but then again doom3 will have to come out soon before opengl2.0 comes upon us.

Michael Steinberg
05-24-2002, 01:36 PM
davepermen. I wouldnt see it like that. There are definitively hints on the usage of soft shadows. Look at the background of the scene with the bridge moving.

dorbie
05-24-2002, 01:37 PM
What? :-)

I can see them, you'd have to be blind to miss them. There are soft shadows and sharp shadows in some of the animations. That's a simple fact Dave.

As for the high vs low res meshes, I never said there were different resolution meshes for geometry vs shadow. I pointed out some obvious problems with shadow meshes which differ in resolution from the casting meshes which must cap them so they are therefore very unlikely. As for the bump maps, it's documented that bumpmaps are being used to reconstruct high res geometric appearance on a low res poly mesh in Doom3. Probably similar to this paper:
http://www.cs.unc.edu/~olano/papers/aps/APSlossy.pdf

We can have any technical discussion we like here without everyone's approval. This is not a threat to anyone, let us discuss & learn, if you don't like it then move on but there's no need to get defensive.

Discussions about high res models vs low res poly meshes help some people to learn that there are potential artifacts with this and lead to discussions about generating bump mapped low res poly models from higher resolution geometry. It's fun, it's educational and it is on topic. There's no need to try and censor this discussion.


Look at the soft shadows on the walls in the video sequence of the demon walking down the hallway. There appear to be several that are are independently modulated (they appear to flicker independently) and they are combined with sharp stencil shadows cast from other sources. It's obvious that some kind to light texture modulation is going on, whether it's depth texture or light map I don't know but it IS being rendered like this.

Now, this may be something as simple as a projective texture on each light, but let's not pretend they aren't there simply because Carmack has written a consistent light model.

Gorg
05-24-2002, 01:57 PM
I am with Davepermen on this one. There are no soft shadows casted from objects. Sure the spotlights softly dies down, but the shadow casted from objects is definitely only hard.

The bathroom scene demontrates this very well.

dorbie
05-24-2002, 02:20 PM
There are soft shadows, perhaps not cast from objects (it's difficult to tell), but they exist. They are light modulating textures, i.e. light maps. They appear to fixed and they overlap and are independently modulated to emphasize multiple light sources. I suspect they are projected. They appear to correctly modulate on the dynamic character.

Look here:
http://www.doom-3.net/E3/36.jpg

Look at the walls.

There are also some interesting lights on the gantry in the background of this shot, I'm not suggesting these little eye candy lights are full light sources and light maps but it does indicate that the creation of light sources in this engine is more pragmatic and flexible than is being assumed.

dorbie
05-24-2002, 02:24 PM
BTW it would make some sense to cook occulting objects near lights into a texture and project it for objects in the beam tree beyond the near occulter. It would give a soft edge effect and significantly reduce shadow volume stencil pass depth complexity. This would still be a unified model. It's simply another optimization.

Reguardless of whether this is or isn't in the engine, it's a valid general observation.

LordKronos
05-24-2002, 02:33 PM
Originally posted by dorbie:
I don't think a unified lighting model eliminates the possibility of some light map effects.

Does this eliminate it enough for you?

"The big things from the graphics side are the complete unification of lighting, shadowing, and bump mapping across all visual elements. In previous games, we had to use a variety of techniques to light the combinations of static and dynamic lights versus static and dynamic surfaces, which tended to give games a characteristic separation between active elements, like monsters, and the rest of the world. There are lots of effects with light and shadow that people have always wanted to see in games that just work naturally now, with no special hacks."

Notice how he keeps reiterating "unified", "complete", and talks about how he used to have to mike different techniques together but no longer has to. I dont think the explanation could be any clearer if John Carmack knocked on your front door, sat down in your living room, and explained it 100 times.



There is evidence for sharp stencil shadows and soft edged penumbra effects in the screen shots and animations.

Huh??? What the $#!*@???? Could you please, please, please, please, PLEASE show me where this "evidence" is. I dont see anything like that in any of the pictures I looked at. I do see soft edges in the distance attenuation and diffuse self-shadowing, but no soft shadows.


That's a simple fact Dave.
Well, maybe a fact in your corner of the galaxy, but not over here on planet earth. File that under "O" for "opinion", or maybe "I" for "interpretation" http://www.opengl.org/discussion_boards/ubb/smile.gif

zed
05-24-2002, 02:39 PM
it does look like the soft shadows in the pictures are coming from projected textures the problem though is its very hard to make the work when the light is very close to the object (from my experimentation a while ago, at the moment i cant remember why that is) but they work perfectly for stationary lights/objects but personally having exceptions like this doesnt feel like a 'unified shading system thingee'

i do agree both with dorbie (btw thanks for the www.doom-3.net (http://www.doom-3.net) link, until now i could only find a few screenshots) + the others (ie dorbie vs the world)

true the lightmap doesnt have to be precalculated (ive got a nice demo if anyone cares to look), (its a little bit faster if it is but its not really that much slower when its on the fly) but personally doing various sorts of lighting depending on what the light or object is is not IMHO unified lighting

another point looking at the screenshots it does look like stencil shadows but theyre all black which personally looks crap.

[This message has been edited by zed (edited 05-24-2002).]

dorbie
05-24-2002, 02:41 PM
Lord Kronos,

See my post above. In the video these light maps flicker with different intensities. Here's the link again:
http://www.doom-3.net/E3/36.jpg

I just don't get it, why are people getting their panties in a twist over this? It's plain as day, and even if it wasn't it'd just be a discussion over some interesting technology.

Why the abuse? You'd think I'd killed your dog or something.

A light map doesn't have to be precalculated and is not incompatible with a unified consistent lighting model.


[This message has been edited by dorbie (edited 05-24-2002).]

dorbie
05-24-2002, 02:52 PM
Zed, it would be unified if 1) they are just projected luminaire textures, or 2) they are auto generated from near occulters. There are other options but I won't mention them for fear of upsetting the unified purists reading.

LordKronos
05-24-2002, 03:12 PM
Originally posted by dorbie:
Lord Kronos,
Here's the link again:
http://www.doom-3.net/E3/36.jpg


You posted that link after I already started typing my response, so I didnt see it. Although the compression artifacts on that image are horrible, my best guess would be that it is encoded into the attenuation map (like the way I do spotlights and disco lights in my tutorials). This is completely different from a shadow.


I just don't get it, why are people getting their panties in a twist over this?
It's plain as day...Why the abuse?

Whose getting abusive? I dont see anything like that. Perhaps you're just being over-sensitive?

knackered
05-24-2002, 03:33 PM
In support of dorbie, I definitely see soft shadows in the mpeg. You can see that there's a marked distinction between the shadow volumes of the characters and some of the animated scenery. Such as the scene with the rotating air vent fan with a light behind it - they seem to be projecting the fan as a texture onto all geometry in its frustum.

dorbie
05-24-2002, 03:39 PM
Ron, "over here on planet Earth" we call that style of post abusive.

You should try and download the E3 video, it has the same scene in the video at about 5fps, crappy resolution but it shows you the independent modulation of the multiple maps.

It could be built into the attenuation map as you say, and infact even if it were a shadow it probably should be built in there too. The key observation is that it could easily be generated from scene geometry and doing this could significantly improve performance for static lights, and it would still be "unified".

I think this paper may be related to what is being done here:

Fast Soft Shadows, Michael Herf and Paul Heckbert, Technical Sketch, New Orleans, Aug. 1996, SIGGRAPH '96 Visual Proceedings, p. 145.

In anycase we should be able to discuss this without getting flamed by people who are way too adamant about their speculation.

cass
05-24-2002, 03:51 PM
Yeah, let's keep is civil.

John Carmack is doing some pretty cool stuff in Doom3. It's interesting to speculate on exactly what he's doing, but until you can play the game yourself, it'll have to remain speculation.

Unless, of course, Shag can get him to post on OpenGL.org.

Cass

LordKronos
05-24-2002, 04:11 PM
Originally posted by dorbie:
Ron, "over here on planet Earth" we call that style of post abusive.

Not me. I was just making a cute little joke. You were going around trying to pass off your opinion or interpretation as "a simple fact". I was reminding you the difference between fact and opinion/interpretation.

And by the way..."I can see them, you'd have to be blind to miss them" could just as well be considered abusive by the same lines.


You should try and download the E3 video
Do you have a link? Because the only video I have been able to find is that old Mac expo one from last year (or whatever).


In anycase we should be able to discuss this without getting flamed..
I dont see any flaming. I think you are just being over sensitive. Was I getting a slight bit irritated? Possibly, because the gist of this thread has been:
It looks like lightmaps
John said there are no lightmaps
I think they could be lightmaps
John said there are no lightmaps
You could still mix <whatever> and lightmaps
John said there are no lightmaps
Just because everything's unified doesnt mean they arent lightmaps
John said there are no lightmaps.

[This message has been edited by LordKronos (edited 05-24-2002).]

[This message has been edited by LordKronos (edited 05-24-2002).]

LordKronos
05-24-2002, 04:19 PM
Originally posted by cass:
Unless, of course, Shag can get him to post on OpenGL.org.

Yeah, Shag. And dont forget to get him to post a link to the binary for us http://www.opengl.org/discussion_boards/ubb/smile.gif

Shag
05-24-2002, 06:15 PM
Take a copy of the image in question, and copy into PSP or someother paint program.

Enlarge the section around the feet where BOTH types of shadow are present. The shadow generated from the monster is totally different to the other shadow. This simply means one of two things:

1. Lightmaps
2. A different rendering technique for moving objects (lights?)

The second technique could still easily fall within a unified lighting approach: If static shadow geometry is precalculated and stored within the BSP (assuming there is a BSP) as 'normal' polys, then it wouldn't be too hard to create soft shadows using some jittering method.

Think about it - a simple case would be a pillar in a square room - six quads would make the shadow volume. redrawing this another 6 times (3 either side) creates a total of 42 polys. Not too bad really. However, a complex model would contain several hundred polys minimum.

I can't be arsed to think exactly how it would be done, but geometry wise, it should be quite possible.

OR ... it's a lightmap http://www.opengl.org/discussion_boards/ubb/smile.gif

Regards

zed
05-24-2002, 07:08 PM
i take it by lightmaps everyone means projected textures containing the lighting info (well thats the sense i used it in)

dorbie
05-24-2002, 07:18 PM
Ron, if I didn't see it as a cute joke, it was because it was surrounded with other material "*%(*&% please please please" and followed by "O" "I". If you try to ridicule me and follow it up with a smiley it doesn't make it OK. Let's just put it behind us, I know there are lot's of smart people posting on this thread (you are definitely one of them) we can have fun discussing some phenominal graphics work without bickering. I just don't see is as such a big deal if I say that there are some light maps / soft shadow effects in a screenshot.

I don't think I was presenting opinion as fact, and that should be self evident now with the screenshot and the video if you look at it.

One of the interesting aspects is that we can discuss Doom 3 without being constrained by Carmack's design decisions. Even if Carmack doesn't cache near occulters to a projective shadow texture to reduce stencil depth complexity (and he might), we should be able to discuss that option. Graphics won't stand still with the Doom 3 engine.

[This message has been edited by dorbie (edited 05-24-2002).]

jwatte
05-24-2002, 07:18 PM
Dorbie, (and others)

John has repeatedly said that his lights are projected, that his models are bumped mapped and specular, and that "everything" has shadow volumes and gets lit the same way.

Briefly, this means that he's probably first "painting light" in additive mode, and then modulating in color mapping. This is much more similar to how light actually works in the real world than any previous real-time method!

When you're "painting light" it's easy to do that with a texture projected from the light (maybe even a cube map) to simulate things like spot lights, rotating colored warning lights, fire grates, or what have you.

A rotating fan may be done with a projected shadow, or it may be done with an actual shadow volume. However, if there's a soft "shadow" then that's most probably a property of the light being painted, not of the shadow volume.

Now, what's a good name for these projected light textures? "dynamic light map" seems a little complex, and somewhat confusing compared to regular light maps. How about "projected light texture"? :-)

dorbie
05-24-2002, 07:27 PM
Painting light is another way of saying light map. OK so it is projected, I said this early on and observed multiple overlapping independently modulated light maps. Maybe "shadow texture" is appropriate, see the Siggraph technical note I referenced. To set this up as a big adversarial thing is counter productive. Everybody ends up beating their chest and refusing to acknowledge common ground. I do think many of us have a pretty good idea of how this lighting works, and the details where we don't agree could be fertile ground for discussion.

You do make a good point that much of the disagreement may be over semantics and preconceived notions of what a light map is and how it is generated and applied.


BTW JWATTE, Performer uses coloured additive projective texture lights for it's spotlights. It didn't have fancy fragment effects and occulters but it did paint the spotlight effects that way to the framebuffer.

[This message has been edited by dorbie (edited 05-24-2002).]

Gorg
05-24-2002, 08:13 PM
Did not mean to start a war by picking a side http://www.opengl.org/discussion_boards/ubb/wink.gif I see what you mean now dorbie. And I think jwatte as it right.

I am sure they build their lights a way similar to this.

The artists creates a model of the light and textures it. Then you simply create a texture of the light surface. You then use this texture as your projected light. You need to create a texture of the light, because the light could be of any shape.

This obviously will give nice smooth "shadows" if light is textured with grates. But this is simply implicit to the texture filtering and was not originaly intended. That is what I meant with there are no soft shadows.
So I guess everybody is just arguing over the same thing.

dorbie
05-24-2002, 08:45 PM
Gorg,

I don't think you started anything, I too agree that this is likely, it is exactly what I described in post 21 in this thread before I was char broiled :-). I later realized it would be similar in many ways to the Siggraph technical note I mentioned subsequently. I've tried to be pragmatic about interpreting what I see. There may be several shadow layers as per the Siggraph sketch which modulate (or simply replace) each other and are applied depending on location inside the shadow beam tree, I mentioned this in an earlier post but it probably got lost in the noise for most readers.

As for soft shadows, I wouldn't rule it out this may include some filtering or multipass sampling to the "shadow texture" especially for static geometry. At the very least some antialiasing would be desirable to avoid horrible shadow aliasing, and when you then project the texture the penumbra (or at least the antialiased shadow edges) automatically increases correctly (approximately) in scale.

This speculation may be incorrect but one thing is certain, it is wrong to make sweeping generalizations simply because the lighting model has been called unified. Carmack has never said there are no light maps or shadow textures in his approach. He has only said his approach is a general and consistent solution. How he arrives at that could easily include shadow textures.

Despite accusations about light maps and a misleading discussion summary that tries to present me as the idiot, I mentioned this projective shadow method as an option immediately BEFORE I was ridiculed.


[This message has been edited by dorbie (edited 05-24-2002).]

PH
05-24-2002, 09:21 PM
I think dorbie may be right that the projected "shadow" textures could be automatically generated ( pre-generated on load time seems more likely but anything is possible ). I like to think of this as a "canned" light source. For example, a simple lamp shade could be made to project a soft'ish shadow, it would be wasteful to use shadow volumes for this ( and it wouldn't look as good ). Anyway, I've used this technique with cubemaps so it's definitely a possibility.

Also, I think some lights are handled in clusters ( with a single reference point for shadow volumes ).

dorbie
05-24-2002, 09:22 PM
I agree PH, no need to do more work than you have to.

zed
05-24-2002, 10:52 PM
projected shadows textures aint hard (and are cheaper than u think my vanta had no real problems dealing with them (except the extra verts of course but on a hrdware t+l card this aint an issue))
ive been using them for about 2 years to do soft shadows of moving objects/lights http://uk.geocities.com/sloppyturds/gotterdammerung.html
the problems with them are when the light/object become very close to each other.

cause this is has gotten a bit to friendly i'll throw in my desenting voice unified for me means every polygon goes through the same path, im not 'quibling' (is that the right word) with words but unified aint
all polys
{
use_projected_shadow_texture
else
use_stencil_volume
}

LordKronos
05-25-2002, 03:06 AM
Originally posted by dorbie:
Painting light is another way of saying light map.

I dont think so. Maybe it is a light in the sense that it is a texture-MAP of LIGHT information, but the traditional idea of lightmaps has always been a texture map that has all details of the scene lighting baked into it and is simply modulated into the base texture. What I think this looks more likely to be is a sort-of-filter (jwatte: I like the term "projected light texture") for the perpixel lighting model. As I interpret what is being done, I suspect this can all be done right along with the bump mapping, diffues attenuation, etc...stuff that isnt dont with traditional lightmaps.

As for soft shadow (jittered volumes, etc) I highly suspect that is not done simply because of the fill rate required. Narrowing it down to a small number of tris is pretty irrelivant, because the typical limitation with shadow volumes is NOT about how many tris you have, but on how much fill rate you consume. Because the way the shadow volumes are projected out into the distance, they tend to consume a LOT of fill rate. Even a simple 3 sided shadow volume can take up tremendous fill rate. Another reason I dont believe this is a jittered volume is because even jittered volumes dont produce that nice of a soft edge with out a few dozen (or more) jitterings (is that a word???), which would be a fill-rate-hungry-frame-rate-killer.


Carmack has never said there are no light maps or shadow textures in his approach
Actually, Im almost 100% sure he said this at one point. I'll have to go try to find out where he said it (although if you take a look through the archives here, you will see what happened the last time I was "almost 100% sure" of something John Carmack said http://www.opengl.org/discussion_boards/ubb/smile.gif )

As far as what gets baked into the projected light texture, remember that when this light is projected out, the object casting this shadow is also going to incorrectly appear shadowed. For this reason, it could only realisticly be done for object close to the light (as dorbie said) or objects that the camera will otherwise never see the back-unlighted side of. Also, doing this for moving lights makes it even trickier becuase then its harder to ensure that the player doesnt see the backside (unless you really dont even care if the viewer sees the errors)

davepermen
05-25-2002, 03:43 AM
dorbi. you just call everything lightmap, don't you? please refer to the standart-usage of these names.
when you use shadow-volumes, you are in fact realtime generating a lightmap for sharp lightsources in screen-space, and the resulting texture, wich fits perpixel to the screen is then logically as well a lightmap

lightmaps are normally precalculated textures wich store lighting information, they have been precalculated, and have defined constant texture-coordinates.

shadowmaps are depthmaps rendered from the camera point of view, then doing a z-test against the pixel-distance from the lightsource to compare if in shadow or not, or they draw an indexmap and compare against the index again. this is normally a projected texture, or can be a cubemap as well.

the painted lights are on the other hand independend of geometrie, but simply an extension to spotlights, meaning they have a map, wich stores for each direction what the color of the lightsource is. this can simply result in a spotlight, or a beacon, a disco-light or whatever, but has nothing to do with shadowing and is independend from geometry. in this sence, its part of the lighting-equation of the local surface element, like the diffuse term, ambient term or specular term are in the phong-equation (or blinn one, or brdfs or what ever).

don't just mix all the stuff up to do like you're right with your wrong statement.

carmack said he uses shadowvolumes to determine the shadowing-term of each pixel. no more, no less. if this is not the case, he is a liar.

this is independend on how he does the lighting itself. there he uses bumpmaps with some specular term, and depending on material environmental maps as well, possibly env-bumps for waterplanes even, and possibly even some brdf-functions somewhere. i don't know much about how he does calculate the lighting, but it looks like some sweet approximation/extensation of the standart blinn/phong model.

okapota
05-25-2002, 08:35 AM
ok, i just THINK http://www.opengl.org/discussion_boards/ubb/smile.gif, that the option he is not using a regular radial attanuation map was overlooked. i think that by using 3d textures instead of 2*2D textures gives u the option to encode lots of lighting effects into the attanuation map beyond spotlights. the only problem i see with this problem is that it will use too much video memory if every light will have a different attan map, but this can be optimized. what do you think?

zed
05-25-2002, 11:59 AM
>>carmack said he uses shadowvolumes to determine the shadowing-term of each pixel. no more, no less. if this is not the case, he is a liar<<

can u show link us to the quote thanks, cause shadowvolumes personally can mean 'projected shadow textures' cause u need to cast them in the 'shadowvolume' as well as the 'stenciled shadow volumes'
maybe we need a glossary so we can look up the standard terms so no confusion results http://www.opengl.org/discussion_boards/ubb/smile.gif

but like i said project shadow textures have problems (which can be worked around but do get expensive)

after another look at the screenshots it looks like 2 techniques stencil shadow volumes + projected shadow textures which like i said before aint IMHO unified, to reiterate what i said 6months - 1 year ago i believe carmack aint using either of these methods then again i might just me RAMBLINGKT

btw LordKronos i believe noone was suggesting doing jittering of the shadow volumes were they?

Pentagram
05-25-2002, 12:08 PM
I don't think 3d textures is an option since they still want it to be able to run on "low-end" 3d cards like geforce2.

Also from looking at the screen JC is before in the doom legacy movie (while working on the doom3 shadow code!) I guess they are using stencil with scissor testing to speed things up. And an ambient light term!
And I dont see any c++ seems plain typedefs to me http://www.opengl.org/discussion_boards/ubb/frown.gif
(unless is is a mockup to mislead us mere mortals of course)
If you want to look at fuzzy code you can find some shots here http://users.pandora.be/hollemeersch/blackrose/images/shot1.jpg http://users.pandora.be/hollemeersch/blackrose/images/shot2.jpg

Charles

(ps:is this legal??)

[This message has been edited by Pentagram (edited 05-25-2002).]

davepermen
05-25-2002, 12:17 PM
Originally posted by zed:
can u show link us to the quote thanks, cause shadowvolumes personally can mean 'projected shadow textures' cause u need to cast them in the 'shadowvolume' as well as the 'stenciled shadow volumes'
maybe we need a glossary so we can look up the standard terms so no confusion results http://www.opengl.org/discussion_boards/ubb/smile.gif

well, if i find it again, i'll show it
about the glossary:
"projected shadow textures" are called shadowmaps. go to the nvidia dev page and you'll see it.

about the carmack and usage of STENCIL shadow volumes.. i just say one thing: carmacks reverse.
i say another thing: GL_NV_depth_clamp
this extension came right after carmack stated this would help to get with its own developed reverse to perfect shadowvolumes

Quaternion
05-25-2002, 12:27 PM
Hi,

I think that using an absolutley unified lighting model can not produce good results. The doom 3 movie is full with quite complex scenes, with a complex shadow being cast on them. In most of the scenes there is a shadow of some kind of bars or shuttres, being cast on the geometry. It is highly unreasonable that those bars/shutters are real geometry.

I believe it could be done with some kind of projected texture, or a 3d texture as suggested. That adds to the realism of the scene, in the cost of a bit of work from the artist/designer. A light map, as far as I concerned, is not an option, if the compiling time (of the level) is very short (is it?).

I think that using only stencil shadows can look too sharp and not realistic in many cases, and I am sure that there are some "soft shadows" of some kind in doom 3.

Quaternion.

[This message has been edited by Quaternion (edited 05-25-2002).]

zed
05-25-2002, 12:45 PM
>>"projected shadow textures" are called shadowmaps<<

http://www.opengl.org/discussion_boards/ubb/smile.gif we definitly need a glossary http://www.opengl.org/discussion_boards/ubb/smile.gif

projected shadow textures" are NOT shadowmaps, with shadowmaps u cant really do softshadows easily

LordKronos
05-25-2002, 12:58 PM
Originally posted by zed:
btw LordKronos i believe noone was suggesting doing jittering of the shadow volumes were they?

Shag was discussing the screenshot and said "it wouldn't be too hard to create soft shadows using some jittering method".

davepermen
05-25-2002, 12:58 PM
Originally posted by zed:
>>"projected shadow textures" are called shadowmaps<<

http://www.opengl.org/discussion_boards/ubb/smile.gif we definitly need a glossary http://www.opengl.org/discussion_boards/ubb/smile.gif

projected shadow textures" are NOT shadowmaps, with shadowmaps u cant really do softshadows easily

okay sorry, i understood projected shadow textures wrong.. http://www.opengl.org/discussion_boards/ubb/smile.gif

projected shadow textures i never count to shadow-methods at all, cause they don't store geometrical information at all. its just a texture with bright and dark parts projected onto the scene and modulated (and it looks exactly like this in the videos). that is just a texture, nothing more. at least for me.. http://www.opengl.org/discussion_boards/ubb/smile.gif

let the war continue..

LordKronos
05-25-2002, 01:05 PM
Originally posted by zed:
projected shadow textures" are NOT shadowmaps, with shadowmaps u cant really do softshadows easily

Yes, it is a bit confusing. Projected shadow textures (if thats the correct term) basicly just modulate the light level. This can create soft shadows. Unfortunately it is also depth unaware and (if projected onto the object casting the shadow) will actually incorrectly shadow the casting object.

Shadow maps (or should it be a shadow depth map?) stores the distance at every texel from the light to the nearest object. For every pixel rendered, the distance of the pixel from the light sorce is compared to the depth stored in the shadow map. IF the distance is greater, it gets shadowed. This has the advantage that it can correctly self shadow the object, but it does not generate soft edges.

jwatte
05-25-2002, 01:36 PM
Dorbie> There may be several shadow layers
Dorbie> as per the Siggraph sketch which
Dorbie> modulate (or simply replace) each other


I think this is incorrect. I don't think there's any modulation nor replacement. I think the scene starts out as all shadowed, and all the light that's painted is ADDED, not modulated. I think the shadow volumes serve as gates for whether the light gets added or not, but there's no modulation going on. Unless you want to be really mis-leading and calling additive blending for "modulation" which would just be plain wrong, again IMHO.

Thus, calling the projected light textures "shadow maps" is, to me, misleading enough to be called inaccurate. And calling them light maps is also misleading because that term is already used for another kind of map, which gets modulated instead of added.

When John Carmack described his engine in one sentence, he said that "once we decided that all lights were projected, that everything cast a shadow volume, and everything was specular bump mapped, everything followed neatly from that". I think this explains the model quite neatly, and there's no shadow maps needed or implied by this approach.

Anyway, so while this discussion may be somewhat about just finding common words for the same things, it seems that the words that have been used (mostly the ones including the stems "shadow" or "modulate") are misleading enough that using them leads to more confusion than clarity.

"Projected light textures" for the future!


EDIT: Of course, there has to be at least one modulation pass, which happens when you have decided on the lighting for a specific frame buffer pixel, and then go to apply the "base color" map/shader to the pixel. However, I don't believe this form of modulation should be mentioned while discussing the lighting solution, as it's not part of the lighting calculation, but instead of tinting happening after "full albedo" lighting and shadow is already calculated.

[This message has been edited by jwatte (edited 05-25-2002).]

Pentagram
05-26-2002, 10:50 AM
To get back to the original topic they will have a bsp as you can read on http://www.gamespy.com/e32002/pc/id/
GameSpy: It sounds like the BSP process has radically changed for DOOM III, possibly even being gone altogether

Robert Duffy: It's not gone. The BSP process used to be three things - it used to be a BSP, then it would be visibility and lighting calculations. Now we just do a BSP, and the lighting and visibility are all calculated in real-time.

[This message has been edited by Pentagram (edited 05-26-2002).]

okapota
05-27-2002, 01:02 AM
so i wander what they need it for, i guess for the beam trees, i think there is a connection.

i want to raise an issue not discussed here so far, transperency. i saw a floor with a hole in it, and fire coming out of the hole.
i wander how they shadow such objects like the floor. i think it is dine regularly, and is being avoided as much as possible.

one more thing, in the legacy movie there is a scence of monster going in a hallway with big columns on each side, and a light rotating in a circle from above. the column's sahdows are jagged, like they were generated using shadow maps, and we know they are not. so what is it?

thefirstbigd
05-27-2002, 02:06 AM
if you reject pixels with the alpha func then they never get written to the z-buffer so things like holes in walls receive shadows correctly. They don't transmit them though, unless mess about projecting a rendering of the hole in the wall from the light's frustum, and switching off stencil bits which fail the alpha test.

if you're using cubemaps you can clamp your lights, for example to match the shape of a lamp shade, doesn't that mean you need a lightmap for the inside of the lamp shade?

Carmack did say binary formats have gone, so the BSP must be calculated as the level is loaded?

I'd like to know how general the shader scripts are, do they just have TGAs for bump, ambient, diffuse, and specular textures? Or is it more complex, like a Quake3 shader script for each term, or maybe even something like the Render Tree in Softimage XSI.

Does anyone have any ideas how the can fly without offline-calculated PVS?

Pentagram
05-27-2002, 02:14 AM
Bsp's are certainly needed for the Beam-Tree since you must insert polygons front to back in them (so the "nearer"polygons can hide the further ones) and that's very easy with a bsp.
And mabye for collision testing.

Charles

FXO
05-27-2002, 03:14 AM
Hey there!

Starting at post 20 by dorbie, he has a very valid, on topic, and IMO intresting rant about the use of different res. meshes for selfshadowing.

He also goes on a bit about all the soft-shadows, and possible ways they coul'd be created.

Now here comes the scary part:
People turn against dorbie as if they were offended by his thoughts, saying "there are no softshadows".

The strange thing is that so many (3? :) people go at it, without even looking at the facts.
I mean, come on, you all saw the soft shadows in the old Macworld demo even.

I was shocked, cuz of some of you that were in "denial" :), were people I have read lots of intelligent post from before.

Q:s
1) Whats wrong with discussing the use of different res. models for shadowing?
2) If you haven't seen any vids from D3, how can you be confident that there are no soft-shadows (No offence, but you cant possibly have seen any videos when claiming that)?

Thanks
/Fredrik Olsson

edit: removed smilies

[This message has been edited by FXO (edited 05-27-2002).]

LordKronos
05-27-2002, 04:29 AM
Nobody is in denial. You can call whatever you want a soft shadow, but that doesnt make it a soft shadow. You can call whatever you want a lightmap, but that doesnt make it a lightmap. Saying that you see these things in the image may be fine and dandy to a layperson, but in here we need to be more technical and more precise in how we describe these things.

knackered
05-27-2002, 04:42 AM
Oooooooooooooooooooooo!

peterpan
05-27-2002, 06:09 AM
jwatte is right:

"I think this is incorrect. I don't think there's any modulation nor replacement. I think the scene starts out as all shadowed, and all the light that's painted is ADDED, not modulated. I think the shadow volumes serve as gates for whether the light gets added or not, but there's no modulation going on."

I'm really shure DOOMIII uses rendering loop like this ( a) assume newest Radeon b) don't blame me for stencil modes/operations - it's for example only).

Clear All Black.

[Draw scene using ambient light(s)] - optional if there is no ambient light(s) in scene

for(EACH light in scene) {
set stencil to '0'
disable drawing to video buffer
enable drawing to stencil buffer

for(EACH shadow-caster object in the light's scope) {
generate/draw object's stencil shadow volume, marking stencil pixels where light is with '1'.
}

// now we have stencil pixels in light marked with '1', pixels in shadow - '0'
disable drawing to stencil buffer
enable drawing to video buffer ("only where stencil is '1'")
set blending mode to "additive"
enable light's "projective light texture" if any (it used in per-pixel light computations)

for(EACH geom object in light's scope ) {
draw the object using diffuse texture, specular texture, bump texture, projective light texture // single pass on newest Radeon?
}

} // for: lights

At first look, there is too many passes, but don't forget: light sources usually are limited in range, so only part of scene's geometry required to be redrawn in each pass.

Probably I left something important out (or, I left nothing out, but You don't think so http://www.opengl.org/discussion_boards/ubb/smile.gif ). Tell me about it, I will answer here.

Any comments?


edit: typos etc.

[This message has been edited by peterpan (edited 05-27-2002).]

thefirstbigd
05-27-2002, 07:45 AM
This kind-of solves the 'is there any ambient' problem; if you have to render the scene before any kind of shadow-dependent passes to get the depth buffer for stencil shadows, then why not do ambient lighting then?

Carmack said expect 3x fill rate hit per realtime light. So rather than adding more lights for a scene a la Quake3 lighting, you get your ambient lighting right first, then set the mood with other lights.

jwatte
05-27-2002, 09:01 AM
> you all saw the soft shadows in the old
> Macworld demo even

Nope. All I saw was projected light textures (a la "spot lights"). I could see no diffuse shadows, and nothing that has been made public about the engine indicates that there are soft shadows, so I think anyone claiming the game does soft shadows is on very shaky ground.

> [Draw scene using ambient light(s)] -
> optional if there is no ambient light(s)
> in scene

This is not optional. You need to draw this so that you get the Z buffer right, for the stencil test to actually have anything to work with. As you need to clear the color buffer, too, you might as well clear to ambient instead of clearing to black.

The problem with doing diffuse color & specular per light is that if you need to multi-pass, your previous data will most probably get in the way, because the successive passes don't know how much is contribution from the current light, and how much is contribution from previous passes. Thus, I'd think you'd want to paint bump mapped light first, assuming a diffuse white on everything, and only modulate color at the end. The problem THEN becomes one of how to apply specular without re-doing the stencil volumes.

Perhaps with destination alpha?

peterpan
05-27-2002, 09:50 AM
Originally posted by jwatte:
> you all saw the soft shadows in the old
> Macworld demo even

Nope. All I saw was projected light textures (a la "spot lights"). I could see no diffuse shadows, and nothing that has been made public about the engine indicates that there are soft shadows, so I think anyone claiming the game does soft shadows is on very shaky ground.


It's dictionary problem again http://www.opengl.org/discussion_boards/ubb/smile.gif. People say "you all saw the soft shadows", but they saw "projected light textures". It's [projected] texture which is used in per-pixel lighting calculation. Of course, it's not a "soft shadow".



> [Draw scene using ambient light(s)] -
> optional if there is no ambient light(s)
> in scene

This is not optional. You need to draw this so that you get the Z buffer right, for the stencil test to actually have anything to work with. As you need to clear the color buffer, too, you might as well clear to ambient instead of clearing to black.


Yes, I'm wrong (about word "optional"), and you're right. It's "must be" rendering pass.



The problem with doing diffuse color & specular per light is that if you need to multi-pass, your previous data will most probably get in the way, because the successive passes don't know how much is contribution from the current light, and how much is contribution from previous passes. Thus, I'd think you'd want to paint bump mapped light first, assuming a diffuse white on everything, and only modulate color at the end. The problem THEN becomes one of how to apply specular without re-doing the stencil volumes.


Sorry, English is hard to me (i'm Russian), but I think something is wrong with your conclusions.

Hm... "...if you need to multi-pass, your previous data will most probably get in the way..."? No way.

Each pass ADDS values to framebuffer. No any 'MODULATE'. Never. (By saying 'modulation' you mean fragment -- colorbufer operation?). I don't need to know what is stored in color buffer, bacause I use ADD operation only.

Below is a colorbuffer pixel's changings history (I assume ambient is 0, for clarity):

1. cbuffer = Zero (black)
2. cbuffer += Light0Based.DiffuseLightValue * TexturePixelFromObject0
3. cbuffer += Light0Based.SpecularLightValue
4. cbuffer += Light0Based.DiffuseLightValue * TexturePixelFromObject1
5. cbuffer += Light0Based.SpecularLightValue
6. cbuffer += Light0Based.DiffuseLightValue * TexturePixelFromObject2
....
120. cbuffer += Light5Based.DiffuseLightValue * TexturePixelFromObject0
121. cbuffer += Light5Based.SpecularLightValue
122. cbuffer += Light5Based.DiffuseLightValue * TexturePixelFromObject1
123. cbuffer += Light5Based.SpecularLightValue
...

Note1: LightXBased.DiffuseLightValue is per-pixel diffuse value computed by using projected light texture, bump map, surface's normal.

Note2: LightXBased.SpecularLightValue is per-pixel specular value computed by using projected light texture, bump map, surface's normal.

Note3: If you have troubles with SINGLE pass computing LightXBased.DiffuseLightValue (or specular), then you can split it to two or more passes: no problem, because we use '+=' operation only.

Note4: You can use ANY order of computings of diffuse, specular, objects while you use SAME light. No lost of stencil buffer, so, do drawings in any order. For example:

for(objects) {
draw diffuse
draw specular
}

or

for(objects) {
draw diffusePartOfComplexComputings
draw specular
draw diffuseOtherPartOfComplexComputings
}

or

for(objects) {
draw diffuse
}
for(objects) {
draw specular
}

or

for(objects) {
draw specular
}
for(objects) {
draw diffuse
}

As you wish.


Perhaps with destination alpha?

No.
Don't invent complicated methods. Use simplest methods. Cramack always does so.

edit: added Note3, Note4

[This message has been edited by peterpan (edited 05-27-2002).]

peterpan
05-27-2002, 10:26 AM
Originally posted by jwatte:
EDIT: Of course, there has to be at least one modulation pass, which happens when you have decided on the lighting for a specific frame buffer pixel, and then go to apply the "base color" map/shader to the pixel. However, I don't believe this form of modulation should be mentioned while discussing the lighting solution, as it's not part of the lighting calculation, but instead of tinting happening after "full albedo" lighting and shadow is already calculated.


jwatte, to avoid problem like this:

"All lights are mixed (with specular and diffuse) in color buffer, how can I extract lighting components to compute correctly lighted pixel? (specular needs ADD, diffuse needs MUL operation with texture pixel)"

we need to use base texture EACH TIME when we compute diffuse/specular things.

It differs from QuakeIII (IMHO) "draw all lights, then multiply my texture by color(light) which is already in colorbuffer".
Doom3 is:
"[Many times] add lighted pixels (lighted pixels, not light) to the color buffer".

If you mean same thing, sorry.

Edit: some info

[This message has been edited by peterpan (edited 05-27-2002).]

Robbo
05-27-2002, 11:29 AM
Well, heres my two pence: Carmack hasn't got a clue how to implement all this. He just threw the ball up in the air and you guys have run with it. He'll be reading this later http://www.opengl.org/discussion_boards/ubb/wink.gif

LordKronos
05-27-2002, 11:47 AM
Originally posted by peterpan:
Hm... "...if you need to multi-pass, your previous data will most probably get in the way..."? No way.

I think you misinterpretted what jwatte was saying. He was saying that if you need to do multiple passes PER LIGHT, then previous data will get in the way. This is correct (to a certain degree). Say each light you draw is lit with diffuse light using both a bump map and distance attenuation, and you are doing this on a dual textured card. For each light you need

A) bump map (normal map) texture
B) light vector normalization cubemap
C) distance attenuation texture
D) diffuse color map

You need to calculate (A dot B)*C*D, and since the card is dual texture, you have to do this using multiple passes. So, the first pass you calculate (A dot B) and store it to the frame buffer. Second pass you calculate C*D and multiply it into the framebuffer. Now when the second light comes along, you have a problem on the second pass (when you need to multiply (A dot B)*(C*D) for the second light). The data from the first light gets in your way here.

The typical way to solve this is to (as jwatte speculated) store the temporary value to the alpha buffer instead of the color buffer. You can also do other things such as rendering the partial results to a p-buffer, but alpha is usually the most optimal.

John Pollard
05-27-2002, 12:28 PM
He appears to just be using projective textures for all light sources (I think he even says this in an interview).

The projective texture could be anything the artist wants it to be. They could even paint in fake shadows in the texture to be projected (which they appear to be doing), or they could just make it a normal spot light attenuation map. Heck, they could project a smiley face if they wanted. Then when finally projected, the stencil pass will stop the texture from being projected onto geometry that is occluded from the light source.

I'd guess it all revolves around projective textures.

John

zed
05-27-2002, 12:40 PM
see here http://www.doom-3.net/E3/36.jpg
this shows a shadow on the dudes left arm, this is what we're discussing right?
now ppl have mentioned this as a 'projected light texture' whereas i say its a 'projected shadow texture'. ideally u would want to use 'projected light textures' (as with lighting generally u begin with black + then add the light sources) but from my experience this just aint practical. i believe u begin with a white screen + the shadows (stencil+projected) are modulated in. im ignoring the problems with 'projected shadow textures' but looking at the screenshots all the geometry (pipes grill fan etc) that appears to cast these softshadows wont suffer from those.
on a personal note im still investing my time in a 'grand unified lighting system very similar to radiosity' where each surface is treated equally (though im still a ways off having this in a doom3 level http://www.opengl.org/discussion_boards/ubb/smile.gif hell ild be happy having it in a quake1 level at 30fps)

LordKronos
05-27-2002, 01:38 PM
No, its generally more practical to start with black and add the light. Trying to remove light is just a pain in the neck, and you can never get it to work properly without tons of effort. Here are a few reasons:

1)Shadowing everything: If you start with white and then remove light, this means you have to mask off every area of the scene that is not hit by light. To be sure you catch everything, you have to "path trace" the light everywhere visible and make sure to draw the shadow wherever the light can't reach. If the visible portion of your scene consists of a hallway divided into 10 segments, and the light can only reach one of those segments, then you need to trace the shadow throught the other 9 segments and draw all the shadows. Not a pretty thing to do. With additive lighting, you only need to be concerned with the areas that the light can reach, which is a much smaller subset.

2)Light saturation. What happens when you have 2 lights together that saturate to white. For instance lets assume you have 2 white lights each with an intensity 0.6(to make things simple for this example, lets assume no attenuation of any kind). If these 2 lights hit the same area, you have a potential total luminocity of 1.2 (which saturates to 1.0). Now, if we start with a luminocity of 1.0 and subtract 0.6 for each light that doesnt hit a surface, we end up with a problem, because we get:
1.0 for anyplace illuminated by both lights (this is fine)
0.4 for anywhere that only gets hit by 1 light (this should be 0.6)
-0.2 (saturates to 0.0) for any surface that gets hit by no lights (this is correct)

To get things correct, we either need to start with an intensity of 1.2 (not possible in the frame buffer) or we need keep track of where lights overlap and special case it (gets to be a real mess).

zed
05-27-2002, 01:44 PM
Originally posted by John Pollard:
He appears to just be using projective textures for all light sources (I think he even says this in an interview).

The projective texture could be anything the artist wants it to be. They could even paint in fake shadows in the texture to be projected (which they appear to be doing), or they could just make it a normal spot light attenuation map. Heck, they could project a smiley face if they wanted. Then when finally projected, the stencil pass will stop the texture from being projected onto geometry that is occluded from the light source.

I'd guess it all revolves around projective textures.

John

gotta laugh http://www.opengl.org/discussion_boards/ubb/smile.gif if in fact it sounds as if he is using the techinque i ditched last year (though his is prolly better optimized + solid), the reason i ditched it was because it required lots + lots of passes over the geometry (killed my vanta) and it wasnt 'a unified approach + required a lot of hacking' i might have to dig out the old files on my harddisk + see how they perform on my gf2mx

u dont believe me when i say i was doing this (uotes from june2001)
>>but now single pass meshes are rare. most of the stuff im drawing now uses 3-4
passes (perhaps ill even go to double figures passes in the future) which
basically means its worthless to sort meshes by state<< http://groups.yahoo.com/group/opengl-gamedev-l/message/18594

from the followup post
>> perhaps ill take the easy way out and just use method B (im using A at the moment) + ppl without hardware t+l can
choose to have dynamic shadows (+ the single digit
fps) or not<<

i guess theres something in that saying 'great minds think alike; http://www.opengl.org/discussion_boards/ubb/wink.gif

zed
05-27-2002, 02:13 PM
thinking about it more i realise im talking out my ass, sorry folks, i failed to notice that gotterdammerung is predominately outdoors + doom3 is indoors doh!, big difference! with outdoors shadowed pixels are usually far a lesser area on the screen than non shadowed things this is the opposite to indoor stuff where as LordKronos saiz are corridoors and such where light is confined to a certain area a LOT more of the screen is in shadow. the reason this is important is with this lighting/shadowing technique u end up doing heaps of passes over certain geometry which u want to keep to a minimum (perhaps with todays cards this is not so important) but at the time it was. btw in practice theres no difference between the 2 methods (adding light or removing light except the stencil part) adding light though is by far the better method (mainly cause thats how the world works http://www.opengl.org/discussion_boards/ubb/smile.gif)

btw i remember another reason why i gave up on this technique 'i believe there was a bug in the nvidia drivers on my vanta using multitexture which basically meant of being able to use both texture units i could only use 1 (which is very important to this techniue ie u want to compact those passes into as few as possible)'

jwatte
05-27-2002, 04:44 PM
LordKronos,

You eloquently described the problem I was talking about; specifically when you only have 2 textures. Thanks for bringing clarity. I believe a Radeon with 3 texture units can be coaxed into doing (diffuse*color+specular)*min((bump.light),0) in a single pass; there's a demo of it on the ATI developer site. That would make PeterPan's method work on all cards with 3 or more texture units. But still not those ubiquitous GeForce 2s :-(

zed,

When you are outdoors, shadow volumes are typically small, assuming the sun is reasonably high in the sky. That should lead to fewer pixels being in shadow. That, in turn, should cause LESS fill rate hit when drawing the stencil. Also, when you're outdoors, there are probably fewer lights that actually affect a scene (as you can cull out any far/soft lights which sunlight will drench out).

There may be cases where outdoors doesn't obey these "well behaved" assumptions -- if you've seen them, can you go into a little more detail about what they are?


Last, I've been going back and forth between stencil shadows vs. shadow buffers for my own use. Stencil shadows pays potentially a lot of fill rate per element per light. Shadow buffers pay only a fixed amount per element per light. On the other hand, shadow buffers may need more on-card memory to look OK, unless we get some new extensions that average the tested result and lerp (which is different from lerping the in-buffer values).

Here's where everybody flame me because I mentioned shadow buffers, where Doom III is clearly stated to use shadow volumes :-)

zed
05-27-2002, 06:15 PM
Originally posted by jwatte:

zed,
When you are outdoors, shadow volumes are typically small, assuming the sun is reasonably high in the sky. That should lead to fewer pixels being in shadow. That, in turn, should cause LESS fill rate hit when drawing the stencil. Also, when you're outdoors, there are probably fewer lights that actually affect a scene (as you can cull out any far/soft lights which sunlight will drench out).


exactlly, thats why its usually cheaper outdoors to start from white + modulate (add shadows) to black.
my mistake was thinking of applying the same thing to an indoors scene (where theres typically a lot of occluders)

jwatte u realise im NOT talking about shadowmaps dont u, cause it appears as if u are

Coop
05-27-2002, 11:40 PM
Originally posted by LordKronos:
Say each light you draw is lit with diffuse light using both a bump map and distance attenuation, and you are doing this on a dual textured card. For each light you need

A) bump map (normal map) texture
B) light vector normalization cubemap
C) distance attenuation texture
D) diffuse color map

You need to calculate (A dot B)*C*D, and since the card is dual texture, you have to do this using multiple passes. So, the first pass you calculate (A dot B) and store it to the frame buffer. Second pass you calculate C*D and multiply it into the framebuffer. Now when the second light comes along, you have a problem on the second pass (when you need to multiply (A dot B)*(C*D) for the second light). The data from the first light gets in your way here.



I think Carmack won't use such sophisticated/high quality techniques on "low level" cards (dual texture cards). He might give up normalization cube map and per pixel attenuation. This way the only textures used are diffuse texture and normal map. Light vector is passed in primary color, and there can be per vertex attenuation stored in primary color's alpha channel. It's also possible to incorporate simple specular lighting here. There's a lot of nVidia demos/presentations showing various configurations of such techniques.
Anyway what I want to say is that it's still possible to use pipeline like peterpan described with one pass per light even on dual texture hardware (with lower quality though).

Coop

peterpan
05-28-2002, 12:08 AM
Originally posted by jwatte:
You eloquently described the problem I was talking about; specifically when you only have 2 textures. Thanks for bringing clarity. I believe a Radeon with 3 texture units can be coaxed into doing (diffuse*color+specular)*min((bump.light),0) in a single pass; there's a demo of it on the ATI developer site. That would make PeterPan's method work on all cards with 3 or more texture units. But still not those ubiquitous GeForce 2s :-(


LordKronos & jwatte, thank you for description of my misunderstanding of your words. I think, single-pass additive light computation is definitely very big problem on a two-texture card. Right now I'm trying to "invent" a computation method for this. But...

But I have a question. Does anybody know HOW Doom3 looks on GeForce2? Do you seen it?
I think on GeForce2 Carmack uses (will use?) some simplifications instead of trying to reach GeForce3/R300 quality. For example, he can discard normalization or discard specular (why not?) or discard bump (don't kill me for these words http://www.opengl.org/discussion_boards/ubb/smile.gif). Anyway, Doom3 wants a GOOD NEW card, so why bother about OLD cards? Doom3 will work on GeForce2, but not in full details.

If you have any info about Carmack's speech/chat/etc touching this problem (GeForce2/two-texture rendering), let me know.
May be you are lucky enough to have any Doom3-Geforce2 screenshots? Please, post link to them.

edit: coop, I read your message later than post my message. You and me think in same way. http://www.opengl.org/discussion_boards/ubb/smile.gif

R300 - single pass per light
Geforce3 - two-pass (may be one-pass if you smart enough) per light
GeForce2 - two/one-pass per light and quality is bad


[This message has been edited by peterpan (edited 05-28-2002).]

Michael Steinberg
05-28-2002, 05:26 AM
Okay, to sum up: doom3 uses stencil volumes to shadow the scene and projected textures to light up the scene ?

knackered
05-28-2002, 06:29 AM
...and no lightmaps.

okapota
05-28-2002, 10:00 AM
what about the jagged shadows i mentioned? its still there...

davepermen
05-28-2002, 10:10 AM
what? where?

oh, and in 2 passes approximated diffuse and specular with selfshadowing and distance-attentuation is working. on gf3 this is possible in one pass. doing correct blinn/phong is only possible on radeon200+ (if it is there, i'm not sure about how good i can normalize all values, but well.. http://www.opengl.org/discussion_boards/ubb/smile.gif)

LordKronos
05-28-2002, 10:22 AM
Originally posted by okapota:
what about the jagged shadows i mentioned? its still there...

I dont have the movie handy, but can you indicate at what timestamp within the movie you are referring to the column with the jaggie shadows. I have the movie at home and will look at it tonight, but I really dont want to sit there for another 10 minutes trying to figure out exactly where you are talking about (and with my luck, I wouldnt even find it anyway).

Mortvola
05-28-2002, 12:11 PM
I believe the scene he is refering to is at 3:34. The pillar's shadow does look a little bit jagged.

Another thing that looks strange is that the creature doesn't look as shaded as I would expect him to be. His feet are greatly darkened, as much as the floor but from his calves up he is only slightly darker than he was when he wasn't in the pillar's shadow. Does this look odd to anyone else?

-Richard

phlake
05-28-2002, 02:07 PM
Originally posted by Mortvola:
I believe the scene he is refering to is at 3:34. The pillar's shadow does look a little bit jagged.


the floor looks kinda bumpy, there, though. is it really a jagged shadow, or is the floor made of small bumps?

Mortvola
05-28-2002, 02:44 PM
I wondered that as well. I was trying to get a feel for how deep the cracks between the tile could be to produce the jagged edge. I haven't been able to convince myself that the jaggies are from the floor material but I haven't dismissed it either.

-Richard

LordKronos
05-28-2002, 03:17 PM
OK, I has a chance to look at the scene at 3:34, and Im not positive but I think its a compression artifact. Dont video compression algorithms make things blocky in the first frame, and then gradually resolve the detail in each successive frame? Take a look at the scene right after that (the demon-doggie thing in the fire) where the lighting changes rapidly...the entire scene is blocky. Every transition between scenes is blocky at first and clears up in about a half second or so. In areas of the scene that are changing (such as the edge of a moving shadow) there is never enough time to resolve the details so the edge stays blocky.

phlake
05-28-2002, 03:27 PM
Dont video compression algorithms make things blocky...?

this is also a reasonable hypothesis. i don't think that detailed speculation based on a single compression video can be fruitful.

dorbie
05-28-2002, 06:30 PM
If a fixed light source is projecting an illumination pattern onto a surface it is fair to describe it as a light map. A light map is not just defined in tangent space and it is not just something precooked from a global illumination model. A light map doesn't just modulate, you can sum light contributions from various light maps prior to modulation, or use them in a more general equation. A light map has never been any of these things and I have said this consistently in this thread. Even for a projective light pass, the polygons generating the fragments are still the same tangent space ones. Projected texture is merely the means used to apply the light map. The fact that an artist may have interractively designed the texture to look good after projection to tangent space reinforces the light map label.

A shadow texture is similar but the contents of the projected map is generated from scene geometry. I'd say the two approaches are inherently closely related, infact one might be called a subset of the other. In anycase I was the first to describe this approach, cite the paper and give it it's correct "shadow texture" name in this thread, to suggest that I need the remedial study is just crazy.

Read post [EDIT] 28 made by me, to see who's wrong and who's trying to distort the facts in this thread (as I have been accused!). Or how about post 37 by LordKronos where everything I wrote about was called a light map. I was flamed for the ideas not the name. When I was flamed the "light map" name was used as a generalization to heap scorn, NOT BY ME. Even if "light map" means something more specific through common useage, that is hardly the point is it? We're debating the semantics of projected light map vs projected light texture. No wonder Carmack looks good by comparrison, we waste our time with this crap.

This has always been fun speculation for me, at least that was the intent at the outset. I'm STILL agnostic about what's in there but I do see soft shadow / light map effects.

FXO, thanks, I appreciate your support.


[This message has been edited by dorbie (edited 05-29-2002).]

Mortvola
05-28-2002, 06:35 PM
I don't believe the jagged pillar shadow is from blocking artifacts. I was one of the developers behind Sorenson Video 1, 2 & 3 as well as Sorenson MPEG-4 so I've seen a lot of artifacts in my time. Of course, I won't stake my reputation on it :-) since I'm home right now and don't have access to the video.

I was really disappointed to see how badly compressed the pinkydemon scene turned out (I understand that is what the id team calls that creature). It's a shame that whoever compressed it didn't use a two-pass variable bit rate algorithm. :-( That was the one scene I was looking forward to seeing.

dorbie
05-28-2002, 08:29 PM
There have been numerous published approaches which claim to produce what have been called soft shadows. Methods which certainly don't produce accurate penumbras (from area light sources) have produced what have been referred to as soft shadows, merely because they have soft edges. A projected shadow texture can produce reasonably good quality soft shadow especially if multiple textures are used at different depths and jittering or appropriate convolution is used when generating the shadow texture (see reference material).

I have never suggested jittered shadow stencil volumes. The idea of jittering the shadow texture involves multiple rendering of occulters to the shadow map with a jittered light projection position, prior to projection of the shadow texture from a single central position. It's still an approximation but a reasonably good one and better than what has passed for soft shadows in the past. For example Luxo Jnr style depth map shadows (which I refer to as a "shadow map" or "depth map shadow" as opposed to "shadow texture") take no account of the occulters correct distance from the light source. Shadow texture jitter and/or convolution does.

As I said early on, the idea of near occulters being drawn to the projective texture is just a bit of interesting idle speculation. Take it or leave it, but SOMETHING beyond mere stencil operations is being done here I think we can all agree on that, because the video demonstrates soft shadows.

I personally think shadow texture is likely, since in the scene where the demon is in the corridor has some detailed structure on the floor, that would be difficult for an artist to arrange to project consistently with the rest of the scene for anything but the most trivial of objects. On the corridor floor there is some complex structure, including what looks like semi-transparent shadowing (light modulation through glass?). This would look strange if you're in game you see a shadow look up and don't see the object or structure casting it and keeping this consistent would be difficult if it is too manual a process.

On top of this there is evidence of some other types of light in the scene. There's the blue illumination from the 'monitors' which illuminate the demon but cast no shadow. There's the gantry lights on the floor and their little light maps (irrefutable really) There's the flickering grille texture on the right wall cast from the left but only stencil shadows from the dominant right light source are casting, (maybe it doesn't cast that low).

zed
05-28-2002, 08:54 PM
u win dorbie 'projected lightmaps' it is, all those in favour say aye.
im still not in agreement about 'unified' though but anyways, what are u raving about softshadows being not perfect, mate nothing in cgi is perfect. actually looking around now at the shadows (in room with light on in the middle of the ceiling) basically most of the main shadows in the room are not soft, but yet in cgi softshadows usually look more realistic, ive noticed that a lot in cgi often fake looks better than an accurate representation

edit - even though doom3 does look like it uses projected lightmaps + stencil shadows, as ive mentioned a few times on these forums ive got a feeling its something else, something like doom

[This message has been edited by zed (edited 05-28-2002).]

dorbie
05-28-2002, 10:12 PM
Zed,

I'm not trying to win, just have a discussion without the flamethrowers. I haven't looked for divisive issues, others have.

I know CGI is an approximation, raving? :-) I was just catching up with a few points after the holiday. Don't assume that because it isn't part of a flamewar that it isn't worth discussing. As for your room, soft shadows are a function of luminaire size and the distance between light, occulter and illuminated object. Many situations don't match your room.

zed
05-29-2002, 12:31 AM
>> As for your room, soft shadows are a function of luminaire size and the distance between light, occulter and illuminated object. Many situations don't match your room.<<

there u are getting technical again

look around reallife is boring, heres a challenge, take a photo of a persons face u will find it resembles quake2 (ie only diffuse colour) than it does doom3 (shadows + bumpmaped) im assuming of course the same quality textures are used in both
example http://www.iann.net/conventions/vip/vipalb1.htm (result from google)

true the specular etc might be there but its usually not in your face so to speak

knackered
05-29-2002, 12:39 AM
A war of words...and dorbie has a larger vocabulary.
This speculation is interesting, but why argue over jargon? Just describe in english (or psuedo code) what you think is going on in the doom III renderer...like peterpan attempted to do.

peterpan
05-29-2002, 01:22 AM
Originally posted by dorbie:
If a fixed light source is projecting an illumination pattern onto a surface it is fair to describe it as a light map. A light map is not just defined in tangent space and it is not just something precooked from a global illumination model. A light map doesn't just modulate, you can sum light contributions from various light maps prior to modulation, or use them in a more general equation. A light map has never been any of these things and I have said this consistently in this thread. Even for a projective light pass, the polygons generating the fragments are still the same tangent space ones. Projected texture is merely the means used to apply the light map. The fact that an artist may have interractively designed the texture to look good after projection to tangent space reinforces the light map label.


dorbie,
I prefer "projected ligth textures" term (instead of "ligth map" or "shadow map"). May be I don't like term "light map" personally, but I think "projected light textures" is more suitable and less confusing term.

Why? Because these nice "soft shadows" made by using PROJECTED LIGHT TEXTURES. These textures not generated in real-time (no need to do that), they painted by artists. An artist creates light source and attach a projected light texture to it (not far from light source's center, I suppose), like protective glass in projector. This texture contains RGB values which used as light intensity (or color, if you like this term more) in particular direction. These RGB values used to modulate decal and/or gloss texture pixels (in per-pixel lighting computations).

In the movie I don't see any OTHER types of light sources (except small lamps on floor, which aren't light sources at all).

Quaternion
05-29-2002, 01:32 AM
In the movie I don't see any OTHER types of light sources (except small lamps on floor, which aren't light sources at all).

About that small lights on the floor behind the monster, they do look like a light sources. And I don't think a projective light texture could generate such lighting. What do you think?

dorbie
05-29-2002, 01:33 AM
zed,

if you photograph a face and stick it on a model as a diffuse map, then yes it will look OK, but that diffuse map actually encapsulates many aspects of a real face with complex illumination. It doesn't work very well as illumination changes but it's a good rough approximation. I think you can forgive a lot when someone is darting past at superhuman speed shooting at you.

Look at the face on Lando Calrissian character in "Jedi Knight II: Jedi Outcast" for example. He's a black skinned character, both sides of his face are illuminated from behind with some kind of specular highlight, but it's just burned onto his face. It looks fantastic, but you can't change the lighting in any meaningful way, you certainly can't have interesting & dramatic illumination and it can look downright strange under some circumstances, see this shot:
http://www.gamespot.co.uk/stories/screens/0,2160,2107911-22,00.html

In a game we currently accept things which just don't look real. If you saw a face in real life with no sub surface scattering and no specular highlights it would look like a badly painted mask. The person wouldn't look real to you, maybe like they'd troweled on paint for makeup.

Just my opinion of course. Some good faces were created in Final Fantasy the movie, shame about the facial animation. You just don't see that quality in a game (yet), and you just don't hold games to the same standard. One day I think we will.

Tom Nuydens
05-29-2002, 01:44 AM
Originally posted by Quaternion:
About that small lights on the floor behind the monster, they do look like a light sources. And I don't think a projective light texture could generate such lighting. What do you think?

In addition to the projected textures, I've heard Carmack mention cube maps and 3D textures. Cube maps could simply be a normalization thing, but they could be used to encode lighting as well. The same goes for 3D textures. Maybe that's what those little floor lights are?

-- Tom

Quaternion
05-29-2002, 01:55 AM
I believe it is possible that it's just one big 3d texture, but that will be a waste...

It can be just a lot of small attenuated lights, so they affect only the floor.

dorbie
05-29-2002, 02:12 AM
peterpan,

I've never cared about the semantics as much as the descriptions, which is where I came in.

After giving this some thought, here's what I think is required.

A "shadow map" belongs to a class of things called a "projected light texture"

A "projected light texture" belongs to a class of things called "light maps".

If you want to get specific you can use the more specific terms, but it gets grey as you look at deliberately hand painted shadows of casting objects like grilles.

I don't think it's our prerogative to define these terms here. They are defined by broader useage and citations in the papers of the inventors.

When someone describes a technique in plain English people shouldn't get all agressive about it and ignore the description.

Tom Nuydens
05-29-2002, 02:22 AM
Quaternion, that's what I meant -- a single big 3D texture with all the lighting in it would of course be impossible.

I think we have to agree that the shadows are stencil-based, so anything else would fall under "lighting and attenuation". Carmack said that the lighting model requires 7 texture reads (see http://www.gamespy.com/e32002/pc/carmack/index2.shtml). Which textures are those?

- normal map
- normalization cube map
- "light texture" (can be a projected 2D texture, a cube map or a 3D texture)
- attenuation map (could be a single 3D texture or a 1D and a 2D texture)
- diffuse color texture
- specular/gloss map?

I would tend to agree with those who said that the "light textures" (erk, nomenclature again) are artist-generated. There are plenty of scenes with "soft shadows", but as far as I can tell there are never scenes where you can actually see the objects that cast these soft shadows. I would guess that the engine allows the artists to attach a custom "gel" to each (spot?)light they create, and that this is where the "soft shadows" come from.

-- Tom

dorbie
05-29-2002, 02:28 AM
Quaternion,

I think they may be little textured quads drawn around the luminaire on the illuminated surface to the framebuffer and modulated by the surface properties.

Thinking about it they may be full on bump map illumination passes with the whole lighting equation just for that tiny quad. The lighting result gets added to the framebuffer like everything else drawn in the scene. The overhead per light is very small. Again that's just speculation but it seems you have limited options for a generalized treatment of something like this. It may not jibe with the unified lighting purists but it's clear these eye candy lights have to be doing something pretty limited in scope.

If it were completely general the floor would have to be heavily subdidided and the light pass traversal impossibly efficient. MAYBE pre processing would automatically handle this and all you have to do is set the radius/attenuation of the light to something small and possibly subdivide the floor manually in the editor. So it still might be part of the general lighting. I don't think we can know this stuff without more information.

peterpan
05-29-2002, 02:31 AM
Originally posted by Tom Nuydens:
In addition to the projected textures, I've heard Carmack mention cube maps and 3D textures. Cube maps could simply be a normalization thing, but they could be used to encode lighting as well. The same goes for 3D textures. Maybe that's what those little floor lights are?

Quaternion, Tom Nuydens, my version#1 is:
These small-floor-lights are lights http://www.opengl.org/discussion_boards/ubb/smile.gif (with VERY small lighting range) and: they don't use projected textures, they don't generate shadows. So I will call them "furniture lights" http://www.opengl.org/discussion_boards/ubb/smile.gif. 3D textures are used for them? May be.

How pity, I don't see any moving objects near them, so, I don't know will monster lighted by the furniture lights or not.

If "no", then Carmack can use [precomputed] static data list of lighted geometry faces (near this light) and light (draw) these faces by using the 3d texture.

If "yes", then situation is not good (for my taste), because this case requires redrawing a monster few times if few furniture lights placed near the monster. Drawing only a subpart of monster can speed up a bit, but I don't sure this is best solution. So, I prefer to think Carmack don't lights monsters by these furniture lights http://www.opengl.org/discussion_boards/ubb/smile.gif.

Don't ask me about volumetric effects like monitors' glow -- I don't know yet (I need to think about it later).

My version #2:
The furniture lights are usual projected lights which use 3D texture instead of 2
(and they don't generate shadows)

My version #3:
The furniture lights are usual projected lights which use 2D(!) texture (because actually I don't see any 3D effects near these "furniture lights" in the doom3 movie)
(and they don't generate shadows).

Key notes: very limited range; no shadow generation; 2d (I think so) or 3d (may be) textures; lights static geometry only (not sure about it)

LordKronos
05-29-2002, 02:38 AM
I've been flamed, I've been char-broiled, I've been abused, I've been ridiculed, I've been accused, I've been scorned....dorbie, please stop playing the wounded animal.

Fine, call them lightmaps if you want. However, I imagine that if you had the chance to walk up to John Carmack and say "hey, I saw that Doom 3 video and I LOVE what you did with those lightmaps...how'd you do that" I imagine his response would start off something like "thanks, but they aren't actually lightmaps...."

But, whatever....lightmaps it is. Everythings a lightmap. Heck, lets even call our diffuse textures maps lightmaps from now on because, hey, they are just texture MAPS indicating which LIGHT componenets get reflected by the surface they are applied to.

davepermen
05-29-2002, 02:42 AM
the so often mentoied soft shadows i see in the videos and screenshots don't have a real world occluder wich generated them. at least, i can never see one of them. and its not a stupid projective 2d texture for sure, just because using a cubemap makes much more sense as it is a projective texture for ALL directions (and as they are generally all pointlights, this is _VERY_ handy http://www.opengl.org/discussion_boards/ubb/wink.gif).
http://www.ronfrazier.net/apparition/index.asp?appmain=research/per_pixel_lighting.html

here you see how cubemaps can be used to generate spotlights, discolights or beacons. with this way you can create nice fancy shadow-effects without knowing how the geometry of the world is, and can make a feeling of a dark dark dangerous world.
http://www.ronfrazier.net/apparition/index.asp?appmain=research/advanced_per_pixel_lighting.html

here you can see stencil shadowvolumes and shadow-buffers.

the depth cube mapped shadows are NOT useful for doing shadowing on current hardware, as there is no accurate depthtest function implemended for cubemaps, only for projected ones. and as the lights _ARE_ pointlights, the highres 24bit depthtest of gf3 and gf4 can't be done (and no, an 8bit depthbuffer would no one use http://www.opengl.org/discussion_boards/ubb/wink.gif)

so, it will be stencilshadowvolumes and lights with a lot of features. i guess the papers from ron frazier explain more or less quite good what the lights will do in doom3. except that they will use 3dtextures and 4textures per pass, wich helps logically to do some work different/bether than done in this paper/program..

and i took long looks in the videos and there is NO image proving me i'm wrong. show me one..

dorbie
05-29-2002, 02:46 AM
peterpan,

The blue monitor glow illuminates the demon & it's bump mapped face, it's pretty impressive. This is accumulated to the framebuffer like all other lights, the key question I agree is do all lights cast shadows. If they only cast shadows within the range of their attenuation mask, that would really limit the scope of the work to be performed. Shadow projection etc only has to kick in when an object enters the attenuation range and the volumes need only extrude to the limit of that range. For something as trivial as the furniture lights on the floor I suspect no shadow casting and possibly no dynamic illumination but who knows. I'd love to see the demon plant his foot right down in front of one of those lights to see if the extra passes kick in on the geometry. I don't think the overhead of the bounds tests is too high and if the lights are correctly spread around it shouldn't be too big an overhead unless something really big hoves into view.

peterpan
05-29-2002, 02:47 AM
Originally posted by dorbie:
peterpan,
I don't think it's our prerogative to define these terms here. They are defined by broader useage and citations in the papers of the inventors.

When someone describes a technique in plain English people shouldn't get all agressive about it and ignore the description.

dorbie, sorry, if my posting looks aggresive. English is not native for me.

I need to call these light textures/techniques with some name, so I choose a term "projective light textures", because I think it fits right. When I call it so, I don't mess it with anything else. When I call it "light map" or "shadow map", then it hurts me and stops my thinkings http://www.opengl.org/discussion_boards/ubb/smile.gif.
If you think it's not right term, give me a better term, and I will use it. May be you like "plain english" descriptions (with lot of "shadow map", "light map" and other names of SAME thing), but I think "plain english" must be without any "shadow map", "light map", "projected light texture" terms. If we use a term, let use the it alone, without its sister, brother, parent terms which are placed all around.

Thank you for your postings.

dorbie
05-29-2002, 02:56 AM
peterpan I wasn't referring to your post when I descriver other responses as agressive, you've been nothing but a gentleman :-).

[This message has been edited by dorbie (edited 05-29-2002).]

Quaternion
05-29-2002, 03:05 AM
dorbie, I think that using "tiny quads" is, as you said, extremely not unified. And how some subdivision of the floor will help? I can't believe every lights knows the exact polygons that it lights (but surely the exact objects). Preproccesing on the other hand can create a list of polygons lighted by the small lights (maybe that's what you meant?).

dorbie
05-29-2002, 03:09 AM
Well subdivision on the floor would provide a quad of limited scope for reduced fragment fill from the scene geometry (keeping things more general).

peterpan
05-29-2002, 03:18 AM
Originally posted by dorbie:
peterpan,
The blue monitor glow illuminates the demon & it's bump mapped face, it's pretty impressive. This is accumulated to the framebuffer like all other lights, the key question I agree is do all lights cast shadows.

Some lights casts shadows, some don't, IMHO. I think it's specified by level designers.



If they only cast shadows within the range of their attenuation mask, that would really limit the scope of the work to be performed.


It's "must be" feature. So, it exists in Domm3.



Shadow projection etc only has to kick in when an object enters the attenuation range and the volumes need only extrude to the limit of that range.


Yes, I think so.



For something as trivial as the furniture lights on the floor I suspect no shadow casting and possibly no dynamic illumination but who knows


I think, monitor's don't cast shadows too. Why? Because it's very natural due to following fact: monitor have BIG planar light emitting surface (screen). So, monitor is not a POINT light. Because it's not point, we can't use shadow volumes (which are base on point light assumption). So, no any user will worried about monitor's light falling through monstre's hand to monster's head. Add a very fast attenuation and voila - you get nice monitor's light.

I don't know which textures are used for these cheap lights - 3D (trivial to use them for these lights?) or 2D projected.



I don't think the overhead of the bounds tests is too high and if the lights are correctly spread around it shouldn't be too big an overhead unless something really big hoves into view.

Bounds tests are not big deal, but overdrawing is. If a monster stays very close to, say, two these small lights, then you must redraw the monster twice. It hurts.

dorbie
05-29-2002, 03:19 AM
I've made some references to post 21 in this thread, I meant post 28, I must've miscounted.

peterpan
05-29-2002, 03:33 AM
Originally posted by Tom Nuydens:
Carmack said that the lighting model requires 7 texture reads (see http://www.gamespy.com/e32002/pc/carmack/index2.shtml). Which textures are those?


tom. you're wrong. Carmack said "seven texture accesses", not "7 texture reads".
So, here is my version of your list:



- normal map
- normalization cube map
- "light texture" (can be a projected 2D texture, a cube map or a 3D texture)
- attenuation map (could be a single 3D texture or a 1D and a 2D texture)
- diffuse color texture
- specular/gloss map?


- normal map
- normalization cube map
- normalization cube map
- "light texture" (can be a projected 2D texture, a cube map or a 3D texture)
- diffuse color texture
- specular/gloss map (can be encapsulated in bump map, but I don't sure Carmack does so)

6 accesses.

I don't know for what is "attenuation map" texture. May be per-vertex distance to light is better? Please, describe cases (for Doom3) in which this attenuation map texture must be used.

dorbie
05-29-2002, 03:39 AM
Ah Ron (LordKronos) your true colors are shining through.

When you made post 37 in this thread did you completely misunderstand what I wrote in post 27 and 28 or were you intentionally intellectually dishonest in misrepresenting that and several other posts I had made?

Do you really expect anyone to believe that when you made post 29 that your misunderstanding was due to light map semantics? The fact is you never saw the effect being discussed and swore against all forms of light modulation. You only saw:


Originally posted by LordKronos:
Huh??? What the $#!*@???? Could you please, please, please, please, PLEASE show me where this "evidence" is.

I dont see anything like that in any of the pictures I looked at. I do see soft edges in the distance attenuation and diffuse self-shadowing, but no soft shadows.

That was wrong, I showed you the evidence and ever since then you've been attacking me, even after I searched for common ground. It's sickening.

You attacked my for seeing soft shading effects, of whatever stripe I used shadows and light maps to describe and explained what I meant in plain English.

Then you riddiculed me for asserting "light maps" when I had described shadows as an option both projective lights in post 27 and shadow texture in post 28.

Next you lecture me for using "light maps" when YOU called everything I described a light map. That's the pot calling the kettle black, especially after my explanation in post 27 and what you wrote in 37.

Now you're attacking me because I complain about your repeated attacks and still pretend I confused you with semantics. It's always been clear what I've been discussing and it's in this thread on record.

Even when I present a completely clear and demonstrably required hierarchy which is not only consistent with what I have been writing but makes a lot of logical sense you turn up the heat on the attack.

Once again when it looks like someone might show that you are wrong (wrong to attack someone who has significant justification for what they wrote) you get all defensive, defensive as in the best form of defense is another more vociferous attack.

I've deliberately avoided being confrontational in my responses (something you unfortunately interpret as playing the wounded animal) but enough is enough. You need to seek help, and quit trying to cover your ass by attacking me.


[This message has been edited by dorbie (edited 05-29-2002).]

davepermen
05-29-2002, 03:49 AM
when people start exlaining and listing up where they got blamed they have a _HUGE_ problem themselfes. cool down, cool down fast. possibly your feelings everyone is bitching on you is because you are _possibly_ wrong with your statements and don't see that _possibly_ we have right with our approaches.. so you'll get the very same answers all the time, and logically you get into jokes about everything that you don't understand because thats normal in a discussion if it goes on for more than 100 posts..

stay ontopic, explain with code, don't use famous words never seen on the devpage from nvidia or ati before and think about what you tell us. why there are no realtimedemos of stuff you try to tell us is possible? why are there a lot of realtime demos of stuff i try to tell you is used? possibly cause some stuff IS possible and some NOT. and if it does not run well as a simple demo on my gf2, it will not run well as a game on gf4. (except for features i don't have, but shadows i can do as well as a gf4, just slower)

davepermen
05-29-2002, 03:55 AM
Originally posted by peterpan:
tom. you're wrong. Carmack said "seven texture accesses", not "7 texture reads".
and where is the difference? when ever i access a texture i read from it. if you would say textures, not reads, then, well on an ati radeon 8500 it would make a difference, but as you say accesses compared to reads, what is the difference?



I don't know for what is "attenuation map" texture. May be per-vertex distance to light is better? Please, describe cases (for Doom3) in which this attenuation map texture must be used.

well, its for perpixel attentuation. and this is MUCH bether than pervertex, mostly if lightsources are small in radius you'll see the difference VERY much. thats why even original unreal and i think from quake2 on all the bullets that are glowing have some form of perpixelattentuationmap. they don't calculate a n.l term, but they enlighten according to distance. this is VERY important for having a good lightingeffect. and its important to be perpixel, yes, as it is not at all a linear term, so will not approx well over triangles if linearly interpolated.
much more needed than normalizationcubemaps for point_to_light vectors for example for diffuse.

knackered
05-29-2002, 04:25 AM
I think dorbie is right to defend himself, he's not suffering from any mental disorder, he's just a human being - although all this is getting in the way of the discussion, so enough is enough surely.

Anyway, I just want to focus on peterpans' ascertain that the light from a monitor screen cannot (or should not) produce a shadow volume. I'm not sure about that - what could be better than having an enormous cinema screen in a room, and having the character models cast huge shadows as they walk past it - it would look incredibly dramatic.
The solution would be simple - check to see if model is in cinema screens' frustum, then calculate silhouette as if the screen were a directional light (direction=normal of cinema screen quad), then extrude the silhouette down the cinema screens frustum (in other words, project each point onto the cinema screen frustums' far plane).
That would work, wouldn't it? Same amount of calculation, roughly...

edit: BTW, obviously I'm referring to a back projected cinema screen http://www.opengl.org/discussion_boards/ubb/smile.gif

[This message has been edited by knackered (edited 05-29-2002).]

dorbie
05-29-2002, 04:31 AM
Dave, my problem is with incessant attacks. You might hope I don't refer to what's actually been written in the thread but after trying to be nice I've had it with the mean spirited attacks. When you go at it double team like this you have a _HUGE_ problem.

It's not a pissing contest, the merit is in the technical posts made which were a friendly exploration of an interesting subject, not what PC demos anyone has written. Anyone who understands the subject and has an open mind can see the merit for themselves.

Your post reflects a status oriented bias which explains a lot. You have no idea what I've done but you patronize me over "famous words" a lack of real-time demos and "jokes about everything that you don't understand".

I haven't posted any stencil stuff online, I did write stencil volume lights about 12 years ago at Marconi in IrisGL on a VGXT. I have other light map stuff online and there's a bunch of light map stencil clip and projective shadow depth texture and bumpmap demo stuff online on my web site. All written when you couldn't download it all from NVIDIAs dev rel site. See my profile for the URL or use google.

Am I L334 enough to post to the same thread as you Dave?

[This message has been edited by dorbie (edited 05-29-2002).]

peterpan
05-29-2002, 04:34 AM
Originally posted by davepermen:

quote:
Originally posted by peterpan:
>tom. you're wrong. Carmack said "seven texture accesses", not "7 texture reads".

and where is the difference? when ever i access a texture i read from it. if you would say textures, not reads, then, well on an ati radeon 8500 it would make a difference, but as you say accesses compared to reads, what is the difference?


Oh... Sorry. No difference, I think. I'm bored by typing/reading http://www.opengl.org/discussion_boards/ubb/smile.gif.

I remember Carmacks state (in .plan?) he need six UNIQUE textures and SEVEN texture accesses (because normalization map accesed twice -- I suppose for L and H vector normalization).

So, my lsit of texture accesses (6 accesses, 5 textures) miss a texture. Below you state missed texture is attenuation texture:


well, its for perpixel attentuation. and this is MUCH bether than pervertex, mostly if lightsources are small in radius you'll see the difference VERY much. thats why even original unreal and i think from quake2 on all the bullets that are glowing have some form of perpixelattentuationmap. they don't calculate a n.l term, but they enlighten according to distance. this is VERY important for having a good lightingeffect. and its important to be perpixel, yes, as it is not at all a linear term, so will not approx well over triangles if linearly interpolated.
much more needed than normalizationcubemaps for point_to_light vectors for example for diffuse.

Thank you, davepermen!!! THANK YOU! No more misterious parts in Doom3's render quest (I hope) http://www.opengl.org/discussion_boards/ubb/smile.gif.

Oops. I'm wrong. One more question http://www.opengl.org/discussion_boards/ubb/smile.gif: Are 3D textures REQUIRED for attenuation map? Or we may use a 2D texture (or 1D?)?

LordKronos
05-29-2002, 04:55 AM
Originally posted by peterpan:
One more question http://www.opengl.org/discussion_boards/ubb/smile.gif: Are 3D textures REQUIRED for attenuation map? Or we may use a 2D texture (or 1D?)?

Depends on how you want to attenuate. If you are simply doing radial distance attenuation, you can do it with a 2D projected texture and get the 3rd component from the tangent space light vector. If you want something fancier (like maybe a lampshade, where the intensity is brighter from the top and bottom of the shade) you might have better luck trying to do that with
a 3D texture. Though you could certainly do something reasonably close to that with a 2D texture, I'm not sure (without siting down and doing the calculations) that it would be as accurate as the 3D texture would

LordKronos
05-29-2002, 05:13 AM
Dorbie: I tried formulating a response to everything, but following post 21 to 27 to 37 to 28 back whatever was making my head spin like debuggin spaghetti code. But a few points:

The "please, please, please.." comment, I already explained that I started typing this before you posted a link to the picture, and that I had not seen any pictures demonstrating what you thought you saw. When I actually saw it, I explained that I thought it was just something baked into the attenuation map or the projective light texture...seems like maybe you were trying to say the same thing, but that brings me to my next point...

Terminology: Whenever you say something, in order for me to understand what you are saying I have to try and look at things from your point of view. The only way I can look at things from you point of view is to try and reconstruct that point of view from what you have said so far. When you start using terminology like "lightmaps" incorrectly, the point of view that I think you are coming from gets distorted. Then you go and make a statement like this:

"There are soft shadows, perhaps not cast from objects (it's difficult to tell), but they exist. They are light modulating textures, i.e. light maps. They appear to fixed and they overlap and are independently modulated to emphasize multiple light sources. I suspect they are projected. They appear to correctly modulate on the dynamic character."

And by this time, Im already thinking that you mean one thing, and it sounds like you are talking about objects that project out some lightmap modulating texture that overlaps with the projected light texture and
modulated its value, and what not. Is it very hard to see how I could take it wrong? I can see now what you probably meant, but its hard to tell if thats really what you were thinking or not. Had you not referred to everything as a lightmap, I probably would not have viewed your comments in an incorrect context and might have realized what you were saying.


But, to no end, I guess I haven't much to contribute to this thread except trouble, so I'm on my way. Sorry for the inconvenience. Carry on.

knackered
05-29-2002, 05:24 AM
I'm still waiting for peterpan to tell me why he thinks that a monitor screen should not cast shadows, even though it would be a better (read: bangs for bucks) effect than normal point lights. http://www.opengl.org/discussion_boards/ubb/wink.gif

peterpan
05-29-2002, 05:27 AM
Originally posted by knackered:
Anyway, I just want to focus on peterpans' ascertain that the light from a monitor screen cannot (or should not) produce a shadow volume. I'm not sure about that - what could be better than having an enormous cinema screen in a room, and having the character models cast huge shadows as they walk past it - it would look incredibly dramatic.


no problem with your "cinema screen". It's usual light with projected light texture (you even may use an animated texture (a movie) and the movie can be seen on monster's body).

But I described MONITORS, not CINEMA SCREEN.
They sre small, they have VERY SMALL light range, so why bother about casting shadows?

anyway, If you (as level designer) want monitor to cast shadows - do it. No problem. All handles are in your hands.

I don't recommend to force mnonitors to cast shadows. You'll end with too many lights which are casting shadows and your level will be slo-o-ow. Why bother about some effects if these effects are invisible (remember -- VERY small lighting range of monitors)?

As with monitors, I'm tried to describe a method to speedup/simplify some light calculations in scope of a general lighting solution. But if YOU want to do things RIGHT - use shadow-casting projective-light-texture light for monitor (light's position is somewhere inside monotor, or even deeper). If you want speedup - don't cast shadows.



The solution would be simple - check to see if model is in cinema screens' frustum, then calculate silhouette as if the screen were a directional light (direction=normal of cinema screen quad), then extrude the silhouette down the cinema screens frustum (in other words, project each point onto the cinema screen frustums' far plane).
That would work, wouldn't it? Same amount of calculation, roughly...

I don't understand your words about projecting points and so on... If you mean stencil shadow volumes, then I'm sorry, but it's like lighting (with projected light textures) in doom3 works -- so, you invented nothing new (it's discussed many times). If you mean other method, then you're wrong -- it is a hack and it can't work right.


I'm still waiting for peterpan to tell me why he thinks that a monitor screen should not cast shadows, even though it would be a better (read: bangs for bucks) effect than normal point lights. http://www.opengl.org/discussion_boards/ubb/wink.gif

Here I am http://www.opengl.org/discussion_boards/ubb/smile.gif. Sorry, my connection to Internet was lost.

dorbie
05-29-2002, 05:39 AM
Ron, I think the intent shows through especially when posts 27 and 28 are taken together and it anticipates much of the subsequent discussion.

I probably assumed too much common ground when making those posts and was therefore surprised by the response. On terminology, I see some of these approaches as a subset of a light map and thought I had made this clear in the posts I mentioned.

Thanks for making the effort to explain how I could have improved my posts to avoid our misunderstanding.

[This message has been edited by dorbie (edited 05-29-2002).]

knackered
05-29-2002, 05:43 AM
Err, I'm not suggesting I've come up with anything new...
I mean that a monitor screen (or any light emitting surface) should be treated as a directional light to find the silhouette of a model that falls within its' frustum, but the silhouette should be extruded to the back plane of the monitor lights frustum instead of along the direction vector of the light (which is the normal way a directional lights' shadow volume is created).
As for whether a monitor should cast shadows or not, then yes it should be up to the level designer...but the designer should just allocate "shadow priorities" to each light source, linked in with LOD ranges - so if the viewer is close to the monitor, then it may nudge the shadow priority value to the point where it generates shadows.
Anyway, a monitor screen in a dark room has a huge range within which to generate shadows.

peterpan
05-29-2002, 05:49 AM
Originally posted by LordKronos:

But, to no end, I guess I haven't much to contribute to this thread except trouble, so I'm on my way. Sorry for the inconvenience. Carry on.

I'm not sure I'm understand you right, but if you mean you want to go away, then I say you: "Don't do it". Smart people are rare, don't go away. Otherwise, how can we answer DoomIII render questions?

As for me, I don't see any troubles in your presence. And I don't see troubles in dorbie's precence.

Of course, this forum contains too many off-topic phrases http://www.opengl.org/discussion_boards/ubb/smile.gif. But hey, humans, words aren't bullets. Ignore them if they hurt you.
Let's talk about doom3 render.

davepermen
05-29-2002, 06:02 AM
Originally posted by dorbie:
I probably assumed too much common ground when making those posts and was therefore surprised by the response. On terminology, I see some of these approaches as a subset of a light map and thought I had made this clear in the posts I mentioned.

and i'm assuming too much common usage of language/words, i think. as i DO HAVE the knowledge of different approaches that work in realtime, and of approaches that dont work in realtime as well, i think i _should_ understand what you're describing. but a) i dont, and b) you don't look like you know what can be done fast on TODAYS hardware. not really at least (remember the rtrt-topic? you where bitching around there as well, and you had there another state as nearly everyone else as well, and there is NEVER a chance to get you change your mind, even if we can actually show it to you directly)

you're sounding like a newbie, and the personal attacked feelings you always get are improving this feelings. this does NOT mean you are one, but you should prove you're not a stupid child reading a lot of stuff not knowing what it is. it just does NOT sound like you really know it (but i assume you do, because somehow i just have the feeling you're quite advanced, irritating http://www.opengl.org/discussion_boards/ubb/wink.gif)

and btw, the stuff i said above you told me that is personal against you, was not ment against you but showing how it feels for you how all are against you. (means against the others)

but we should really continue this on gamedev.net, as this is the flamefield for gamedevelopers..

oh, and this time it was personal against you, yes. just because its getting annoying how you feel attacked all the time i thought now i _DO HAVE_ to attack you. now you know what attacking means (i hope) and dont feel attacked through the normal time.

for a better community..

now you can the first time start flaming me if you want. but if you're cool and advanced, you won't http://www.opengl.org/discussion_boards/ubb/smile.gif i'm off this thread.

anyone who wants to talk about perpixellighting and perpixelshadowing technology of doom3 because he has questions can now post a new topic as this one went too big anyways..

peterpan
05-29-2002, 06:05 AM
Originally posted by knackered:
Err, I'm not suggesting I've come up with anything new...
I mean that a monitor screen (or any light emitting surface) should be treated as a directional light to find the silhouette of a model that falls within its' frustum, but the silhouette should be extruded to the back plane of the monitor lights frustum instead of along the direction vector of the light (which is the normal way a directional lights' shadow volume is created).
As for whether a monitor should cast shadows or not, then yes it should be up to the level designer...but the designer should just allocate "shadow priorities" to each light source, linked in with LOD ranges - so if the viewer is close to the monitor, then it may nudge the shadow priority value to the point where it generates shadows.


Hm... For what we need project "silhouette should be extruded to the back plane of the monitor lights frustum"? I don't understand....

You mean "usual cinema", where a movie-light projector projects a movie image onto huge screen on the wall? In this case light is placed where it is: in cinema projector. So it's again an "usual doom3 light".

Otherwise, I dont' understand you, as I stated before http://www.opengl.org/discussion_boards/ubb/smile.gif.

LODs in lighting scheme? May be it's interesting idea, may be not http://www.opengl.org/discussion_boards/ubb/smile.gif -- need to think about it.



Anyway, a monitor screen in a dark room has a huge range within which to generate shadows.

And it's not point light, because emitting surface have big area. So, I prefer not to draw shadows at all, than to draw them. To resolve this situation (dark room with monitor lights without shadows) we can avoid to do such scenes http://www.opengl.org/discussion_boards/ubb/smile.gif. Or use an SINGLE invisible light source somewhere in middle of wall with twenty monitors (instead of trying to make 20 shadow casting lights). Or we can use an light source from ceil, to avoid complete darkness in such room.

peterpan
05-29-2002, 06:13 AM
Originally posted by davepermen:

i'm off this thread.

anyone who wants to talk about perpixellighting and perpixelshadowing technology of doom3 because he has questions can now post a new topic as this one went too big anyways..

Looks like this thread dies.

Should I go away too? http://www.opengl.org/discussion_boards/ubb/smile.gif

No jokes, I want to talk about Doom3 render. Where I have to go? Any ideas?

dorbie
05-29-2002, 06:21 AM
Knackered, the most significant effect of your adjustment of the shadow geometry would be objects near the monitor and off to the side slightly would have wrong shadow directions and the clip at 180 degrees would be impossible. Objects close and behind the monitor display plane would have to be illuminated if objects distant and in front of it were to be. In other words your point behind the monitor forms a projective frustum with the display plane rectangle which limits the scope of illumination if objects behind the monitor are to remain in shadow.

For a diffuse flat plane like this the shadow volume starts as a complete hemisphere until you introduce occulters. Shadow casting directions seem best approximated by a point in the middle of the monitor screen. There are better examples for your shadow volume origin shift I think, for example a halogen worklight where the source should be behind the flat surface of the light or even behind the parabolic mirror somewhere. Then again light is cast directly from the element and the mirror so it's probably best to have the wider frustum and use the attenuation map.

I think what you are instinctively driving for is an attenuation map for an area light source on the monitor which would account for the cos (monitor direction vector) attenuation plus appropriate range falloff. It's similar to a global illumination equation when also considering the fragment normal. Illumination would be range attenuated and attenuated by cos (light normal [in tangent space]) * cos (luminaire surface normal).

This would give a very gently attenuated and realistic illumination on the desk for a monitor for example, without illuminating behind the monitor and casting shadows in roughtly the correct direction for objects off to the sides.

knackered
05-29-2002, 06:25 AM
Sorry peterpan, I've just realized what I've been saying (and your answer makes sense now) - a monitor screen is a spot light (with a projected texture of whats on the screen), it's just a small distance behind the monitor screen itself....duh! I really should stop drinking in the week http://www.opengl.org/discussion_boards/ubb/smile.gif

davepermen
05-29-2002, 06:31 AM
well.. post an own topic, about shadowing, or perpixellighting, or what ever (and write &~DORBIE in.. http://www.opengl.org/discussion_boards/ubb/smile.gif)


to dorbie:

"please stop this talking all the time about the highresmeshes for shadowvolumes and the shadowmaps. carmack states he is using simple shadowvolumes with a from him well and accurate described technology. thats all. and i can't see any of your fancy softshadows nor any shadowmaps on your screenshot. in fact, it looks like a demo from humus with some different leveldata and quite good drawn meshes. and humus only uses simple bumpmapping and simple shadowvolumes, no fancy new_world_order technology, but the stuff that is actually possible on hardware, instead of your fancy dreamings.

you can't combine shadowmaps and shadowvolumes in a way they look nice. no way...

stop it till its out or official, okay?"

this is now 3 pages behind, and there is no change http://www.opengl.org/discussion_boards/ubb/wink.gif

"They are light modulating textures, i.e. light maps." well.. they are modulating textures.. that means when ever i do a multiplication of two values in school, i do enlighten one value by the other? its just a modulated texture, does not mean it has to do with lighting really http://www.opengl.org/discussion_boards/ubb/wink.gif (yes it is enlightening, but it has nothing to do with shadowing at this point, its kind of the "decal-texture" of the lightsource itself.

projected stuff, never..

"That's a simple fact Dave."
well. a fact that you're wrong, yes http://www.opengl.org/discussion_boards/ubb/wink.gif


oh, and btw, quake3 used unified lighting-model as well: it used lightmaps if the light was static and well, lightmaps if it was animated as well.

i use unified lightingmodel as well if i enable glLighting for one part, project textures for another one, use multitexturing for lightmaps at a third one and switch to bumpmapping in the last one (and do raytracing on the spherical stuff i have to enlighten), because its one function with a lot of ifs in.

and yes its an unified world, we're all one, thats why we are splittet into nations, thats why we have wars all the time, thats why some are rich some are poor. because we're all the same.. yes..

dorbie, thanks to you now i know that even 2 == 1 because they are both numbers..

finally i understand the world.

peterpan
05-29-2002, 06:33 AM
Originally posted by knackered:
Sorry peterpan, I've just realized what I've been saying (and your answer makes sense now) - a monitor screen is a spot light (with a projected texture of whats on the screen), it's just a small distance behind the monitor screen itself....duh! I really should stop drinking in the week http://www.opengl.org/discussion_boards/ubb/smile.gif

Ok, but I think MOST IMPORTANT thing about monitor screen is: it is not point light. It's light emitting SURFACE. So, any stencil volume shadows from it will look WRONG, because they have hard edges. To check it, turn off light in your room (don't turn off monitor or computer http://www.opengl.org/discussion_boards/ubb/smile.gif) and look at your shadow on room walls. You'll be impressed http://www.opengl.org/discussion_boards/ubb/smile.gif. I don't tried it, but I think shadow will be VERY VERY blurry.
Because of that, I prefer not to cast stencil shadows by monitors.

knackered
05-29-2002, 06:36 AM
Have you finished, dave? Feel better?

Mortvola
05-29-2002, 06:47 AM
Originally posted by peterpan:
And it's not point light, because emitting surface have big area. So, I prefer not to draw shadows at all, than to draw them. To resolve this situation (dark room with monitor lights without shadows) we can avoid to do such scenes http://www.opengl.org/discussion_boards/ubb/smile.gif. Or use an SINGLE invisible light source somewhere in middle of wall with twenty monitors (instead of trying to make 20 shadow casting lights). Or we can use an light source from ceil, to avoid complete darkness in such room.

I would imagine that a monitor could be treated as a point light. Couldn't the artist define a point light behind the monitor's surface? After all a CRT is really a point light set inside a box.

I'm just beginning to delve into lighting algorithms. If the monitor could be treated as a point light couldn't it use shadow maps?

[EDIT] Looks like this thought was thought of already a few posts back... sorry for the redundancy :-)

-Richard

[This message has been edited by Mortvola (edited 05-29-2002).]

knackered
05-29-2002, 06:52 AM
I see what you mean, peterpan.
Just had a thought - has anyone considered something like rendering the shadows (only) into a smaller viewport, capturing it as a texture, and blending a quad with this texture into the final scene?
Granted, you'll lose depth resolution, but maybe you could render the shadows into a screen sized viewport, capture this into a texture, clear the viewport, and render it at a lower mipmap over the scene?
Something to add bluriness into the shadows...

davepermen
05-29-2002, 07:00 AM
Originally posted by knackered:
Have you finished, dave? Feel better?

yeah http://www.opengl.org/discussion_boards/ubb/wink.gif (there are days a man needs this.. this is one)

Adrian
05-29-2002, 07:11 AM
Knackered, if you did that some of the blurred shadow might then overlap with objects that should be occluding it.

dorbie
05-29-2002, 07:18 AM
Dave, the record in this thread is there for all to see. You've degenerated to personal attacks which are way over the top but they betray the motivation of your other posts, at least now you've made it clear that your posts are fueled by hatred dating back to earlier threads, and earlier anti-American propaganda you sent offline which I won't go into.

You tried to criticize my graphics knowledge because I haven't published any demos online when my posts should have been enough for anyone who understands the subject. I demonstrated you were spectacularly wrong by supplying a URL and now you say my abilities aren't up to date and I don't understand modern graphics cards! You still don't have a clue what I've done on modern graphics cards. Just who is qualified to have a discussion with you Dave?

As for the RTRT that stuff is not fast, you don't sound like you understood the number of passes involved to execute the loop or the texture fetches involved even with the MIMD shader in the Stanford paper or the geometry transformation in the UNC paper. MIMD floating point pixel shaders, do you even have a clue what kind of a departure that is? It sounds like you read these things get all excited because it's ray tracing and don't really understand the content. Ofcourse you've never implemented a real-time ray tracer just read about it but you're somehow more of an expert than others.

knackered
05-29-2002, 07:29 AM
1) Render scene into depth buffer only.
2) Render shadow volumes into stencil buffer.
3) Reveal shadows created from volumes by rendering a screen sized quad.
4) Copy this into a texture, with automipmapping.
5) Render scene into colour buffer only.
6) Render shadow texture at lower mipmap level over whole scene, only where stencil bit is set.

A lot of rendering, but it might just work http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
05-29-2002, 07:31 AM
Dave,

your latest post is a distortion of what went on in this thread.

You objected to someone elses post on high res meshes in response to my post when all I'd done is describe why you wouldn't want to vary the volume and model resolution, basically I'd said they need to match and then described the bump map preservation of detail that's long been understood to be in the engine.

That didn't stop you though you were barelling full speed ahead. Did you offer a cojent argument, a discussion. No! Just "stop". What kind of crap is this? You still haven't offered anything intelligent on the subject and you still pretend that I raised the subject when it was me who posted accurate comments in response to another post.

As for the other comments see my posts at the time, there's nothing new there.

[This message has been edited by dorbie (edited 05-29-2002).]

peterpan
05-29-2002, 07:36 AM
Originally posted by knackered:
1) Render scene into depth buffer only.
2) Render shadow volumes into stencil buffer.
3) Reveal shadows created from volumes by rendering a screen sized quad.
4) Copy this into a texture, with automipmapping.
5) Render scene into colour buffer only.
6) Render shadow texture at lower mipmap level over whole scene, only where stencil bit is set.

A lot of rendering, but it might just work http://www.opengl.org/discussion_boards/ubb/smile.gif

Sorry, this thread is about DoomIII, so your scheme is off-topic http://www.opengl.org/discussion_boards/ubb/smile.gif.

Anyway, I think you invent not very good render technique http://www.opengl.org/discussion_boards/ubb/smile.gif.

Quaternion
05-29-2002, 07:44 AM
what knackered propose can be done using a pbuffer. I guess it should work, but a mipmap blurring (from my experience) may not yeild good results...

knackered
05-29-2002, 08:00 AM
No, peterpan - I don't invent anything - this is a standard way of producing many effects, such as depth-of-field, motion blur etc. It's a good trick (and everything is a trick in realtime graphics).
It isn't adding any extra fill burdon, except for the screen sized quads, but it does mean more transforms every frame.
It may not yield very nice results, but I'm going to try it over the next few days...I'll let you know if it looks acceptable.

peterpan
05-29-2002, 08:13 AM
Originally posted by knackered:
No, peterpan - I don't invent anything - this is a standard way of producing many effects, such as depth-of-field, motion blur etc. It's a good trick (and everything is a trick in realtime graphics).
It isn't adding any extra fill burdon, except for the screen sized quads, but it does mean more transforms every frame.
It may not yield very nice results, but I'm going to try it over the next few days...I'll let you know if it looks acceptable.


Sorry, I use word "invent" here because it was hard to me to remember RIGHT english word for your action http://www.opengl.org/discussion_boards/ubb/smile.gif. I'm russian, so forgive me.

May be your method is good... How about multiple lights? Can your method handle it?

davepermen
05-29-2002, 08:19 AM
okay dorbie, back to the topic.

yes there are soft shadows in the scene, and yes there are stencil shadows in the scene.

but no there are no shadowmaps in the scene. because a shadowmap does have SHADOWS in. REAL shadows for me are shadows generated by some occluder, and those shadows we see, those soft shadows, are NOT from real objects ( i havent found a SINGLE one in the whole presentations and screenshots, and i've downloaded videos the whole weekend just to make this sure (i'm a 56k modem user)). and as long as it is NOT from real objects, its NOT a shadowmap imho. and THATS the point.
the only REAL shadows in are the stencil shadowvolumes, wich may or may not be from lowres meshes, but it looks more than the highres-meshes themselfes are lower than i thought at the first moment (once gain, while watching the videos and the screenies. on the edges you can see quite easily that the meshes are not really round, just the bumpmaps give this feeling on the surface)

the other "shadows" are simply a decalmap for the lightsource, as i mentoied somewhere above. to see the impressive results, take a look at the ronfrazierdemo. replace the beaconcubemap by one with some gridlines (black ones) and you see thats actually looking like doom3 http://www.opengl.org/discussion_boards/ubb/wink.gif

there are no real (and real-time) shadow techniques wich do not use sort of shadowvolume. stencilshadows use them to check the point_to_eye ray (or the point_away_eye ray in carmacks method) if he is in shadow, shadow maps (DEPTH shadow maps) use the point_to_light ray.

tell me another technology wich works and works general and works fast.
one would be indexed shadowmaps, but that works, well, not really well. a last one would be having a general lightmap grid to have the possibility to draw onto all surfaces or something like this.

but for generating shadows there are only two ways, both generate sharp shadows, and one is perpixel accurate, one not. you can jitter them with multipass or image-post-processing to get them softener, but thats it. you can't map them onto some projective texture as you need a 3d-representation.

there is only ONE way that came into my mind for now: using the mipmaplevels in an inverted mode. means near the light you use the smallest mipmaplevel, one behind the secondsmallest and the farest away the highest res. with the help of a rendered depthview from the cam you could then generate boolean maps for each layer of the mipmap for this distance. these you can blur then. that _could_ be another wa.. but its not yet exposed that much.. so.. dunno if we could actually get this working..

i think thats all about shadows.

dorbie
05-29-2002, 08:58 AM
Happy to return to the topic.

Most of the shots don't have any effects like those described, I think many are from an earlier presentation (MacWorld?). I think it's the newer E3 shots have the demon in the corridor which has most of the interesting stuff we've talked about but I'm not sure of the date distinction.

I remain agnostic about the source of the apparent shadows in the scene. They may or may not be from objects in the scene or they may be artist inspired. I don't think we can rule out occulting objects off camera. Shadows of real scene objects rendered to a texture would be fast they could be jittered, antialiased or convolved or some combination. If the light source is stationary the shadows would not need to be regenerated, whenever it moves they must be at least for the highest quality rendering modes. This is not a depth shadow but a simple shadow texture applied in the beam tree beyond the occulting objects.

Thinks about this. Those (light maps-shadow textures-projected textures) or whatever must be for static sources, if they weren't they would be wrong on a moving source UNLESS they were directly part of the moving luminaire like a grille attached to the light or some light on a moving object casting a shadow of the object. Either that or they are full dynamic shadows from occluders in the scene. So if you're really strong on the unified lighting theory on static vs dynamic you must conclude that those textures were part of the light fixture, or dynamic shadow textures. If they were artist inspired shadow textures in a unified model the light couldn't be moved, no big deal, it's just a limitation. Perhaps this is OK, but if that's OK what's wrong with letting the artist bake occulters to the projected light texture to create a shadow map instead of forcing them to paint? It would allow more complex effects and save a HECK of a lot of stencil fill when rendering many scenes and make different classes of scene possible. Once you do this why wouldn't you include this for general lights and specified near distance occluders?

Just some thoughts. I still agree these may not be generated from occulters, I suspect they are but I'm waiting. I don't think we have enough information to draw firm conclusions.


[This message has been edited by dorbie (edited 05-29-2002).]

Nutty
05-29-2002, 09:10 AM
Why doesn't somebody just ask John C, what those "soft shadows" on the demon/wall actually are? http://www.opengl.org/discussion_boards/ubb/smile.gif

Nutty

SirKnight
05-29-2002, 09:21 AM
Good luck getting a reply from him. At least I never have. http://www.opengl.org/discussion_boards/ubb/smile.gif

-SirKnight

davepermen
05-29-2002, 09:22 AM
the problem with such a sweet shadowmap is that it has NO depth information and like that it does not help for shadowing a real scene. it does help for where you don't have a chance to move in front of an occluder, but if there are several occluders there should be one map for each one. this is not worthing it (because even if he uses such stuff as well as you mentoin, it is too complicated to solve in general => no..)

and i've watched the doom3video rip wich is illegal where they play 11min doom3. there are NO projected textures (i simply don't use shadow in there because they don't have real shadow info) wich come from real geometrie. they are part of the art of the graficers. one place for example is where a big ventilator is rotating. a perfect place to use a rotated texture you project down. but well. its not a shadow. its a drawn texture. there are no shadows but volumetric stencil tested ones. and this statement IS from carmack. applieing textures (like additive refractionmaps for underwater scenes wich you project over the whole geometrie) is part of art, but not part of programming, and is by no means in any way related to the reality, except that the artist draws it in a way it looks real for him. those textures are in fact independent on any lightsources.

i'm just not willing to call this shadows. its modulated textures.. if you would project some stuff and add it, you would not call it specular eighter..

Nutty
05-29-2002, 09:23 AM
I'll give it a shot. Anyone know where I can get his email address. I see lots of ppl on the web seem to be mailing him.

Anyone?
N.

tarantula
05-29-2002, 09:54 AM
Gasp! I need a breather.
Why are you experts flaming each other? I'm sure everyone here is very knowledgeble.
Its really nice seeing you guys give so many different ideas and techniques.
But why the flaming?

Knackered, about the monitor...
The 'images' that a monitor projects onto the surrounding is not at all sharp. The surrounding gets softly lit by a color that's average of the whole screen colors.and the shadows are very very soft.
So a monitor is not at all like a spotlight (ie with a sharp cutoff).
Sure we would like to see them project images and objects to cast shadows but then the images will have to be sharper and the monitor will be a projector.

And Dorbie, you are right about hemispheres or whatever but no one is looking at correctness, no one is writing a raytracer.
Knackered has a nice effect in mind so it doesnt matter if it is realy *that* correct or not.

Even I seem to be talking about correctness about the monitor... but it would look really odd to me.Heck the only thing i see on the book five inches away from the screen is just soft white lighting and the shadows are too faint unless of course the objects casting shadows are very close to the surrounding surface.

zed
05-29-2002, 10:11 AM
>>Why doesn't somebody just ask John C, what those "soft shadows" on the demon/wall actually are?<<

wot? and take all the fun out of it

i suppose i better take a look at the video is this it http://www.doom-3.net/video.htm its not very long + saiz its not official is there anther one?

dorbie
05-29-2002, 10:14 AM
tarantula,

it's just an observation that could be built into a texture already earmarked for the attenuation map. I think the problems with the point behind the light are still there reguardless of the attenuation map, I was just trying to put my spin on the kinds of attenuation effects that you want as distinct from shadow effects.

dorbie
05-29-2002, 10:22 AM
Dave I know that there is no depth information in this texture. But there is no depth information in a painted light map either. The idea I'll repeat is to apply the texture only to geometry beyond the occulter. Geometry nearer the light could self shadow with stencil if it needed to. I've already suggested that this would be only for occulters near the light source but it was always optional and speculative. I'm not insisting this is how it's done I've always kept the option open that this is a projected light map that is not a shadow texture. The Siggraph note I've cited goes into detail on the shadow texture approach if you are interested.

Watching secret videos is cheating :-)

Zeno
05-29-2002, 03:48 PM
Originally posted by Nutty:
I'll give it a shot. Anyone know where I can get his email address. I see lots of ppl on the web seem to be mailing him.

Anyone?
N.

Nutty - Someone from nvnews.net(chalnoth@nvnews.net) recently got a response from him via email, so you could email that guy for his address.

-- Zeno

SirKnight
05-29-2002, 04:21 PM
I think his email address is johnc@idsoftware.com. At least that's what it says in that .plan file web site.

-SirKnight

Mezz
05-29-2002, 07:15 PM
johnc@idsoftware.com is his e-mail
I've mailed him a few times and can verify he's responded (twice, yay!).

Also, to dorbie - I had a problem understanding one of your previous posts (about 80% of the way down page 4, starting 'happy to return to topic' or something similar) you use the word 'occulter' several times - at first I'd assumed it was a spelling mistake for 'occluder' but now I'm not sure - can you clarify it's meaning?

Thanks,

-Mezz

[This message has been edited by Mezz (edited 05-29-2002).]

Zeno
05-29-2002, 09:46 PM
I believe an "occulter" is someone who is really interested in things like witchcraft and ghosts http://www.opengl.org/discussion_boards/ubb/wink.gif

-- Zeno

knackered
05-29-2002, 11:01 PM
I assumed he was talking about the thing in front of the light (grill, fan or whatever) that casts the 'shadow'.

Humus
05-30-2002, 02:10 AM
Originally posted by Zeno:
I believe an "occulter" is someone who is really interested in things like witchcraft and ghosts http://www.opengl.org/discussion_boards/ubb/wink.gif

-- Zeno

Fits Doom3 quite well IMO http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
05-30-2002, 03:38 AM
I almost always use occulter to describe an object which casts the shadow mainly to distinguish from an eye space occluder or some other scenario, I've used the word many times in this thread. It's no big deal, substitute occluder if it helps you read it, sometimes I find the distinction is useful. If you have a good dictionary and look up occult you will see that it doesn't just apply to witches & the supernatural, it was probably applied to such because of it's root meaning.

As for what's actually in Doom3, it would be good to know. I have a depressing feeling that it would not have resolved this after posts 27 and 28 were missed or missunderstood. It was already hostile after the innocuous high/low res meshes post. A lot of this thread hasn't been about substantive technical disagreements, and ultimately we should be able to explore these ideas irrespective of what's in Doom3.

On Doom3 engine descriptions; I wonder if Carmack will bother going into more detail than he already has. In the past it seems to me that it was Abrash or Hook who had a passion for publishing and 'outreach' over the technical details in the earlier engines. Carmack discussed stuff but he never explained the whole thing with the detail Abrash & Hook did. Am I wrong on this?


[This message has been edited by dorbie (edited 05-30-2002).]

davepermen
05-30-2002, 06:31 AM
dorbie. how do you define "behind" occluder? with a shadowvolume? or how? i just dont really see any general way to use it. so i prefer painted textures that i from now on call light-decalmaps

dorbie
05-30-2002, 06:54 AM
I used the phrase "beyond the occulter" in my last post on this, by beyond I mean "more distant from the light source than". If you are interested look at the Siggraph technical sketch I have cited.

The problem with going pure stencil is that complex geometry near the light source creates massive stencil pass depth complexity to cast it's shadows, which remain sharp, so for performance reasons the level designer has to avoid this. For example a room with a light behind complex scaffolding would produce high depth complexity full scene stencil fill when viewing parts of the room. The shadow texture eliminates this, there is no stencil fill caused by any occulter that is drawn to the texture, in this case the scaffolding.

The shadow texture is just applied on all geometry in the beam tree for it's light, excluding the occulter drawn to the texture. The occulter has the usual stencil shadow volume which applies shadow stencil test to itself. There's a place in the beam tree beyond the occulter where the stencil geometry for the occulter is capped and shadow texture starts getting applied (probably quite close).


[This message has been edited by dorbie (edited 05-30-2002).]

Gorg
05-30-2002, 08:38 AM
I was reading an Id Software interview on MSNBC last night.(www.msnbc.com/news/758337.asp)


At some point John Carmack mentions that there are no distinctions of static and dynamic and everything can be moved.

There was also an interview on Gamespy with Id's animator(Fred Nilson) and he said that he takes levels from level designer and he thinks : hmm, maybe this thing should move around, or this monster should come out from there. (http://www.gamespy.com/e32002/pc/id2/)

Carmack also mentionned that he likes elegance of implementation over trying to do everything for everyone, from this I believe(believe because it is pure speculation) that everything is threated as if it could move and so is all drawn the same way and the "soft shadows" we see are simply from the projected texture of the light.

The light texture does not have to be hand made. Just take your standard stand-up light with a grate on the top. So a modeler create a mesh of the this light. Then the level designer simply a insert a point light where the real light should be the mesh. Then a special tool simply render the whole mesh(with stencil shadows) looking in the direction of the inverse of the light direction making sure the top of the light fills the whole screen.

There you go, you have your texture for your light and you have dark spot in your texture when the grate is because of the shadow volumes. And when the texture gets projected, filtering will cause the soft shadow we see.




[This message has been edited by Gorg (edited 05-30-2002).]

Mezz
05-30-2002, 08:41 AM
dorbie, thanks for the clarification - I guess I just don't have a large vocabulary http://www.opengl.org/discussion_boards/ubb/smile.gif

Anyway, I just thought I'd point out that GameSpy have a lot of Doom coverage from E3 and there are some interesting interviews in there. For instance, reading the one with Robert Duffy (tool programmer I believe) he states that BSP is still there, but there is no longer a requirement for the 'light' or 'vis' portions of map compilation as they are now done in real time. I believe this helps answer one of the first queries of this thread (if it hasn't been answered already, I've read most of the posts over the last 5 pages, but not all of them...)

I think the main E3 Doom3 page on GameSpy can be found at this link:
http://www.gamespy.com/e32002/pc/doom3/

As I say, it might be good to have a read of the interviews because the artists / modellers also touch on how they do things, which may also clear up questions about high/lo res meshes, etc.

-Mezz

EDIT:
having neglected to read Gorg's post directly above (like the idiot I am) I see now he's already given a bit of a link to GameSpy's coverage - well, nevermind http://www.opengl.org/discussion_boards/ubb/smile.gif

[This message has been edited by Mezz (edited 05-30-2002).]

peterpan
05-30-2002, 08:45 AM
Originally posted by dorbie:
The shadow texture is just applied on all geometry in the beam tree for it's light, excluding the occulter drawn to the texture. The occulter has the usual stencil shadow volume which applies shadow stencil test to itself. There's a place in the beam tree beyond the occulter where the stencil geometry for the occulter is capped and shadow texture starts getting applied (probably quite close).

Wrong way, dorbie, IMHO.

It's too complex for me: "The occulter has the usual stencil shadow volume which applies shadow stencil test to itself."

Can you describe a method allowing an object to draw shadow volume to itself only?

Note: no other objects must be in the object's shadow!

I prefer to think that in Doom3:
A. Occulters are not very complex 3D objects (or 2D objetcs http://www.opengl.org/discussion_boards/ubb/smile.gif) and can't be seen from side of the light.
B. 'A' alllows us to skip drawing of the occulter when we render scene for this light. We can skip drwaing, because we can see occulter's opposite-to-the-light side only, which is black for this light, so no need to draw it (even if no more light sources in scene, the occulter will be visible already drawn on screen (in first pass, when depth buffer was rendered)).
C. If an occulter is a hand-drawn 2D texture (not a 3D object), like in furniture lights on the floor, then we can render it at the first pass (when rendering depth buffer) or in the second pass (a special pass for drawing furnitre lights http://www.opengl.org/discussion_boards/ubb/smile.gif ).

This scheme allows us to draw scene for the light in SAME way.

Otherwise we must split scene to two parts (before-occulter and after-occulter) and draw these separately (using different shaders or switching textures or changing something else etc..) -- It's too complex.

peterpan
05-30-2002, 09:06 AM
My previous post was too complicated...

Below is another one complex post. (Hm... What happened with my brain?)

Main idea is: occulter and light source are linked together. When you draw scene for a light, then you AUTOMATICALLY use the light's occulter's [projective light] texture. So, no way to disable occulter texture and to draw something without this texture WHEN RENDERING FOR THE LIGHT (it will complicate render pass). If you want to draw something tricky, use firt pass (depth buffer draw) or the last pass (particles and such self-illuminated transparent things) for that. Don't switch rendering methods inside a light's render.

Can't remember any scenes in the Doom3 movie, where these rules were violated.

dorbie
05-30-2002, 10:02 AM
peterpan,

yes to your first question. The stencil geometry for that object is projected to a distance only large enough to contain the object and then capped. Beyond the cap the shadow texture is applied.

I'm just expanding on an idea. As I said, I can live with simple hand painted projected light maps.

I do think I need to write a demo to show what I mean with the hybrid stencil volume + shadow texture map for near occulters now though :-).

Dave,

you may want to revisit the use of the word "light-decalmaps" for the projected hand painted map. This has an even stronger association with something locked in tangent space IMHO. A decal is basically a sticker transfered to a surface, for example some kind of insignia or label on an aircraft. I think the tangent space association was your primary objection to my use of the phrase light map because of it's implied association to something generated in tangent space, so anything with decal in it would probably be the wrong choice.

peterpan
05-30-2002, 11:08 AM
Originally posted by dorbie:
peterpan,

yes to your first question. The stencil geometry for that object is projected to a distance only large enough to contain the object and then capped. Beyond the cap the shadow texture is applied.


dorbie,
Yes? Not exactly. http://www.opengl.org/discussion_boards/ubb/smile.gif

1) If any OTHER object will be located in this "distance only large enough to contain the object", then this OTHER object will be shadowed by occluder's stencil too (and shdowe partially, because of capping). This is wrong.
2) This OTHER object will be shadowed once again, when "Beyond the cap the shadow texture is applied". This is wrong too.

Solution: not allow other objects to reach occluder. http://www.opengl.org/discussion_boards/ubb/smile.gif



I can live with simple hand painted projected light maps.


Me too.



I do think I need to write a demo to show what I mean with the hybrid stencil volume + shadow texture map for near occulters now though :-).


I like your idea, but I think it's complicates things. I don't like TWO different methods to render single light. You need to switch between "use occluder's projective light texture" / "don't use the texture". I dislike non-usual capping (object-depended instead of light-dependent) too. (If we can use single type of capping, why to indroduce second type of capping?).

Uniform rendering per-light is good. Don't complicate it.

I hope I'm right http://www.opengl.org/discussion_boards/ubb/smile.gif.

Hey, people, does anybody see any 3d-geometry (instead of 2D textures) occulters on light sources? (I have no doom3 movies right now, so can't to chek it http://www.opengl.org/discussion_boards/ubb/frown.gif )

davepermen
05-30-2002, 11:36 AM
Originally posted by dorbie:
I do think I need to write a demo to show what I mean with the hybrid stencil volume + shadow texture map for near occulters now though :-).

would be fun to watch.. but i got the idea. i just think its not general enough to be implemented sweet and useful into a complex game engine.. and with a demo you cannot prove the other. just wait for carmacks reply.. http://www.opengl.org/discussion_boards/ubb/smile.gif (or the game)



you may want to revisit the use of the word "light-decalmaps" for the projected hand painted map.
well i refer to the usage nvidia and ati has, and there the decalmap of an object is simply the basecolormap of the object. its normally modulated with the diffuse term in blinn/phong solutions, and represents the surface-painting. i dont really care what a decal is (i know it from bulletsourceholes in game engines as well for example) but i care for its usage. and with a light-decal i mean the decal-texture of the lightsource. some time ago i used instead of decalmap "diffusemap" but i found out that with decalmap more people actually understand me (except you of course http://www.opengl.org/discussion_boards/ubb/wink.gif http://www.opengl.org/discussion_boards/ubb/wink.gif http://www.opengl.org/discussion_boards/ubb/wink.gif).

well. then its just the "texture of the light'ball'", like those lights for childs that paint some figures onto the ceiling in the night. stars and such. and that for example is a usage wich does not at first features SHADOWS but just projected figures. (dia projector or movie projector is another one).

well. you know it. i know it. you just think yours will work, and it will be fun to see if you can prove it. that my one works is clear, because its seen in quite some demos yet.. (and its easy)

[This message has been edited by davepermen (edited 05-30-2002).]

dorbie
05-30-2002, 11:56 AM
peterpan,

I agree it complicates things but not as much as if first appears. I have no great attachment to the idea but it is fun to explore.

There are not two significantly distinct methods in terms of passes. There is one method, stencil is ALWAYS used. Only the shadow texture is toggled on or off for some geometry. So what additional work is there?

1) Render the occulter to shadow texture (instead of the artist drawing it)
2) Cap the occulter silhouette geometry instead of projecting to the full distance (it would get capped with Carmack's reverse anyway).
3) Turn off the shadow texture when drawing the occulter.

So in terms of multiple approaches, item 3 is the only rendering state change. and it's actually DISABLING a texture unit on some geometry.

Everything else in the algorithm remains the same.

You are right about objects approaching the transition region from stencil to texture shadow, very perceptive. I was thinking along the lines of objects not approaching the transition as you say but I also had in mind a situation where if they had to there could be some texture + stencil overlap area beyond the occulter.

In the overlap region the appearance would be a sharp shadow edge with the light fading slightly but not totally towards the sharp edge. There would still potentially be transition artifacts when you enable/disable the texture as an animated object moves through or a static object exits the shadow cap going from a "soft+sharp" penumbra to a soft penumbra. I think the high frequency texture information in this region would mitigate against serious artifacts.

It does need testing though.

[This message has been edited by dorbie (edited 05-30-2002).]

knackered
05-30-2002, 12:11 PM
I've just seen that leaked divx video (the 37mb one) - it's crap quality, but from what I can see, yes, they're projected textures - simple as that...a mixture of projected textures and stencil shadow volumes. One other thing, it looks fantastic - the artwork is lovely, there's a really nice window reflection effect (window is transparent, but has a real reflection...don't know about refraction).
On the whole, I was really impressed by the dynamic lighting - especially the scene in the toilet with the creature eating the stomach of a man lying on the floor, while a broken light swings above it - I don't know if it's me, but it really makes the scene look actually frightening...it stirs an emotion beyong the usual "nice effect" thoughts...
I got a much more diluted feeling from "Severance - blade of darkness", which also features shadow volumes, though its lighting model was much simpler.

[This message has been edited by knackered (edited 05-30-2002).]

dorbie
05-30-2002, 12:25 PM
Dave,

I'm just exploring one idea, I described the near occulter shadow texture in post 28 in this thread. Light volumes require fragments stencil pass even for the shadow texture so they would inherently be required to be combined with stencil volumes, this is exactly what I mean when I talk about projecting it inside the beam tree, the beam tree in post 28 is the stencil volume. You claim you got the idea, maybe you did some earlier work on this good for you. [Edit: I misunderstood you when you said you got the idea, my bad]

I agree a demo is just a demo. I still think if one is happy with a painted map, the ability to generate a map from scene elements is a bonus.

I do understand exactly what you mean when you use the phrase in context, but I thought you were fussy about semantics :-). Decal has an English language definition which is tied to tangent space and the DECAL texture environment for example is directly named after it's intended application in this way, where alpha cookiecuts texture fragment with color fragment. Like placing a texture 'sticker' on a polygon. So the use of that name may prove counter productive. Feel free to call it what you like though.
http://www.dictionary.com/search?q=decal


[This message has been edited by dorbie (edited 05-30-2002).]

davepermen
05-30-2002, 01:02 PM
okay.. so i stick back to the original name of textures: COLOR MAPS http://www.opengl.org/discussion_boards/ubb/smile.gif

its a colormap for the lightsource

dorbie
05-30-2002, 01:08 PM
"Color" being the color of the "light" right?

Only teasing.

No, wait, it's a "Map Light"! :-)

[This message has been edited by dorbie (edited 05-30-2002).]

davepermen
05-30-2002, 01:16 PM
color map is short for
cubic color per light direction map function.
or so.. http://www.opengl.org/discussion_boards/ubb/smile.gif

knackered
05-30-2002, 01:25 PM
I'm astounded that you are continuing to argue over semantics - you sound so soulless... I can understand you wanting to describe what you think is going on, or what you think should be going on, but don't you think you're going a bit far with this arguing over terms?
Maybe it's just me, but it's been a chore to read though this thread, not because I don't understand what's being discussed, but because it keeps being bogged down with digressed rants...rather than talking in plain english about John Carmacks commitment to going for a fully dynamic lighting model.

dorbie
05-30-2002, 01:59 PM
Well I was joking (at least recently) I think he was too. Some of this thread has improved and is almost readable.

peterpan's comments are straight to the heart of the key issues/problems with the shadow textures. Really good critique, the kind that provokes technical discussion.

Technical critique begets technical discussion, but you need to have an in depth understanding and put in the effort to make those criticisms.


[This message has been edited by dorbie (edited 05-30-2002).]

OldMan
05-30-2002, 02:00 PM
I know why JC will never answer directly this question (at least not at this forum). He probably knows of this thread and it must be a lot of fun for him to read all the Ideas that come from our heads.... At the scale this thread is going...soon or later there will be something here that he will find interesting.

zed
05-30-2002, 09:00 PM
though it is important to use the correct terms, some of the arguing over terms here is a bit to much, some ppl will never admit wrongness?
FWIW i suggest ppl have a go at the projected lightmaps (only by doing this will u find out their issues) personally i feel it is a bit of a lost cause im more into a unified lighting solution but thats what im like. 3 of my 5 programming laws that i follow (well try to) are pertinent to this 1/KISS, 2/everything is equal 3/make no exceptions.
also plain english is great though some of us have difficulty in doing even that (like myself) could it have something to do with the great dialogue that i get at work, like today Q/how do i sharpen my pruning clippers A/ u sharpen them with the nob of your cock!. shakespeare would of been hardpressed to come up with a better line

dorbie
05-30-2002, 09:57 PM
Zed, all along one question has (err should have) been paramount, phrased in the most general terms. What is the texture based light modulation in the scene that is NOT due to simple attenuation based falloff. In simplest terms "the soft dark stuff with obvious structure".

There are 3 ways you can be wrong about this 1) adamantly deny the evidence, 2) adamantly claim that it's due to one effect or another or 3) adamantly deny it's one thing that can't be ruled out. With 2 there's a chance you might be right and you win the Carmackology award for screenshot analysis (in your own imagination). With 3 you are probably right but you get no prize because you're a party pooper.

Changing your mind is allowed.
Revisionism shouldn't be.

zed
05-31-2002, 11:49 AM
well done angus youve killed the thread http://www.opengl.org/discussion_boards/ubb/smile.gif
anaylse this http://uk.geocities.com/sloppyturds/volfog3.jpg
excuse the mipmap artifacts

dorbie
05-31-2002, 12:57 PM
Good, it's been sick a long time. Even now I find some of the non sequitur posts stunning.

Your link does not work.

LordKronos
05-31-2002, 01:04 PM
Originally posted by zed:
well done angus youve killed the thread http://www.opengl.org/discussion_boards/ubb/smile.gif

Oh, and so close to the record of 213 posts (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/004150.html) . Oh well, I guess the terrorists win again http://www.opengl.org/discussion_boards/ubb/frown.gif

Or....dorbie and I can go at it again for another 24 posts? http://www.opengl.org/discussion_boards/ubb/smile.gif

zed
05-31-2002, 01:46 PM
>>Your link does not work<<
geocites aint the most reliable, the link will work, u gotta be patient.
i believe the picture is of direct relavence to the doom3 shadowing technique we are bickering about, ppl may find it interesting?

knackered
05-31-2002, 01:48 PM
I wonder where you find the time to program things...some of your posts are like essays http://www.opengl.org/discussion_boards/ubb/wink.gif
Were you two guys members of some kind of debating society at school?

[This message has been edited by knackered (edited 05-31-2002).]

dorbie
05-31-2002, 02:45 PM
There's nothing to go at Ron. It's all been beaten to death. The bloody carcass of this dead horse is immolated by the strokes of a million keys.

knackered
06-01-2002, 01:21 AM
Originally posted by WilliamShakespeare:
Life is but a walking shadow, a poor player who struts and frets his hour upon the stage, and then is heard no more. 'Tis a tale, told by an idiot, full of sound and fury, signifying nothing.


I agree, Wil. http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
06-01-2002, 02:00 AM
Originally posted by WilliamShakespeare( right after that last bit):
I should report that which I say I saw,
But know not how to do it.

[snip]

Let me endure your wrath, if't be not so



[This message has been edited by dorbie (edited 06-01-2002).]

knackered
06-01-2002, 02:18 AM
Hail, King of Scotland!

[This message has been edited by knackered (edited 06-01-2002).]

davepermen
06-01-2002, 02:41 AM
anyone not understanding jokes?

well anyways, i can't get the geocities-pic. and i know that we have to be patient on geocities and copypaste etc and stuff and goes and this and there it works. but it doesnt.. http://www.opengl.org/discussion_boards/ubb/smile.gif

you've taken the pic down yet again? or if not, please upload it there: http://tyrannen.starcraft3d.net/free
as there we can watch it for sure..

and why not going on. dorbie? yet started with the demo of your idea or you gave up yet?

just one other note: topic: doom3,l/s,bsp. well.. doom3 we're discussing, for sure.. l/s, yeah.. but what about the bsp's? they say they use it somehow, but not anymore for the data (and not for lighting/shadowing). how can they generate bsp's then and for what? (the how is ment if i look at all the round objects i see in the game, lot of cutting that would be)
i dont see that much use for bsp except for a raytracer as you there can intersect bsp's VERY fast.. the new super physics? dunno

GeLeTo
06-01-2002, 03:23 AM
About what the BSP is for:
Q3 uses portals for VSD. There are several ways to place the cells/portals:
1. Make the artist define for each object - to which cells belongs, and for each hand-placed portal - to which 2 cells it belongs.
This makes moving things around a lot more complicated. Also it is very complex for the artist.
2. Automaticaly define the cells using the geometry and the hand-placed portals. This is computationaly expensive as it requires you to CSG all that complex geometry...
3. Like #2 but using the low-polygon non-detail objects that outline the rooms, corridors, etc.
4. Like #3 but using automaticaly generated portals.

My bet is that Doom3 uses #3 or #4 and they both work best with a BSP tree. It will probably take only a few seconds.

dorbie
06-01-2002, 03:37 AM
Dave,

I will probably implement the demo after I finish some stuff I'm on right now. I have other priorities right now. There's no question of giving up, I know it will work before I implement it, but is it worth it? It won't determine what's in Doom3 (which is still wide open), and I already have a good idea what it will look like.

If I do implement this it'll be for fun and at my leisure. I'll be sure and post the results if I do.

davepermen
06-01-2002, 04:08 AM
200

well actually its not that undefined how doom3 does the job. as i said, it doesn't use your ones for sure (imho). but we'll see who is right..

dorbie
06-01-2002, 04:51 AM
sigh,

Dave, I've maintained an open mind from the start and kept it very general based on observations. You've constantly tried to imply I've advocated a specific position which I haven't, I do insist some texture modulation of light (in addition to attenuation) is happening.

It's all on record. Post 21 22 25 etc

What will you be right about Dave? Please state your position and check it against your post number 22. Then your claim can be tested when the result is in.


[This message has been edited by dorbie (edited 06-01-2002).]

davepermen
06-01-2002, 06:47 AM
i just say there are no real occluders wich generate the colormap for the light. there is no prove anywhere that this is not true. and as it is much more simple and gives much more freedom to the artist (wich leads to bether resultts then) makes the whole work much much much much much easier. that means faster. much faster.

you have a fancy idea, wich is not really yet completely understood by yourself (it looks like that, just think about several occluders that fit into your map but at different distances, how do they generate smooth shadows in between?). i hope to see some demo from you because its interesting.

but anyways i stay at my statement, there is no real general and unique solution for shadowing possible as long as there is no sort of raytracing involfed. if(intersects_something(from,to)) its in shadow, else its not. that is the general term for any correct shadowing solution for one light point. this can be done with stencil shadow volumes, or with depth shadow maps.

the only other way is checking for matching indecees.

and.. if i would have the choose to enable or disable your approach, i would disable it. why? because if i have a moving occluder, it can move to the lightsource and when its near, it gets a texture, else its a perfect sharp shadow-volume shadow. that would look terrible because there is no real way to lerp that.

carmack stated he uses a general solution for every situation, one unified system. your way does not work yet for every general solution i can imagine, so i don't see yet a way to use it in its system. and i don't think it is really faster.

faster would be generating volumes from near objects first, intersect more far objects against it and determine if they really need some shadow (sort of a beam tree, i guess).

and a gf4 has _VERY_ much fillrate.. http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
06-01-2002, 08:54 AM
Dave.

I have said from the start that there may be no real occluders in the "soft shadow", I said it in practically my first related post in very unambiguous terms. In some respects we now appear to agree although you didn't agree with me at the time :-). You used to call ANY texturing of light "fancy dreamings", now you say render to texture for shadows is a "fancy idea". Neither are particularly fancy.

I think I have formulated a decent understanding of my technique, see my last replies to peterpan to answer your questions about shadows in between and the resulting appearance & transition between stencil & shadow texture of near occulters. The siggraph note I cited describes multiple textures used, I have talked about multiple textures as an option in the beam tree in this thread. There are several other options though, for example selecting a single group of primary occulters with some make or break range test to determine which belong in the beam tree and which in the shadow texture. My replies to peterpan on the overlapping stencil and shadow projection zones in the beam tree are relevant. For many simple scenes depth complexity is no big deal but some types of scenario could generate truly massive depth complexity and therefore cannot be modelled without killing performance. They won't kill an engine which doesn't use this because those scenarios just won't be modeled by the game artists.

Some of the existing screenshots DO show soft and sharp edge "shadow" effects together, even if they are artist drawn, we don't need to guess at their appearance together. Look at the sharp railing stencil shadows and soft texture together on the floor of the corridor with the demon. Well rendered shadow textures could match that quality. If you just go for aliased shadow texture rendering and make no effort to improve on this then yes it would suck because of texture aliasing. Fortunately because a shadow texture is not a "shadow map" i.e. "depth map shadow texture", you have much more control over the penumbra generation when generating the texture, you are not dependent on the texture filter to provide the penumbra.

There is one other important point that I mentioned before. If an artist paints a projected light map (decal-colormap-whatever) it is not fully dynamic. It is static. The equivalent process using scene geometry can match this at the absolute minimum (on a technical level), but it can also be dynamic.

Clearly it's going to take a demo, it will be a while before I produce it though. I'm not keen on demos with one quad and a dinosaur, this'll take substantially more effort, I need some infrastructure and I don't have copious spare time (despite outward appearances). Any good demo would have to have a few options to show some of the problems mentioned by you and peterpan & see how they are handled.


[This message has been edited by dorbie (edited 06-01-2002).]

zed
06-01-2002, 01:40 PM
dave i uploaded it here, thanks http://tyrannen.starcraft3d.net/free/index.php
(weisst du im not talking about the shadow in the picture)

edit- has anyone a link to the demo i still havent seen it ive found lionks to 40mb+ files but downloading them is a bit to depressing (message box 10hours left till download finished http://www.opengl.org/discussion_boards/ubb/smile.gif) ideally links to the demo split up into 5mb pieces would be great.
http://www.doom-3.net/E3/36.jpg sort of captures everything ppl are discussing right?, ie soft shadow on the arm, monitor glow on the face, personally i feel i could do an accurate impression of this, not bragging or anything but from the looks of the screenshot this uses techniques ive used before (keep in mind i havent seen it in action, whichll prolly blow my socks off)


[This message has been edited by zed (edited 06-01-2002).]

dorbie
06-01-2002, 03:44 PM
zed, yes this captures it. The main effect missing in the still is that the lights flicker independently (independent modulation of "light maps"). So one grille texture will flicker differently, at it's simplest it'd be a simple light color modulation, but there may be more to it.

As the demon walks down the corridor there is some detailed building or window cross hatching shadow effect cast on the floor with a semi transparent occultation over part of it (i.e. not just a grille) as if it's illuminated through glass (or something). There are railings which appear on the right (similar to the railing on the left rear), which cast sharp stencil shadows over this soft "light modulating texture", just as the demon does on the floor and the wall.

There are two other interesting sequences on the video. One shows a moving light in a rest room but no soft shadows/textured lighting, only stencil shadows. The swinging light causes dramatic stencil shadow animations.

The other interesting shot is where the rest room monster jumps over a railing like the ones in the static image you just posted and it deforms and crushes realistically under it's weight. There's some large flame/glowing/explosion effects in the background.

The shot you posted is the only sequence with clear & obvious evidence of textured structure in the illumination, aside from intro shots (of which this may be one we can't tell).

davepermen
06-01-2002, 11:51 PM
just looking at this pic. imho, the lightsource of the "texture-shadows" are somewhere rightabove the screen, not? why does the shadow then appear to the wall in the background wich faces to the left.

that would not appear on real shadow algos. so its just a projected texture.

or from where does this light come from?

dorbie
06-02-2002, 10:05 AM
Something we both seem to have spotted.

By dorbie page 3 end of one of the posts about half way down:
"On top of this there is evidence of some other types of light in the scene...[snip]...There's the flickering grille texture on the right wall cast from the left but only stencil shadows from the dominant right light source are casting,(maybe it doesn't cast that low)."

In the video the texture you mention on the right wall texture flickers with a different brightness from other textured illumination. I think this is significant, it means it is a different light source. I have speculated that that light is not a full shadow caster. It's impossible to tell for sure on available evidence, I'm tending towards a full light but maybe with a limited spot cone now, we'd need the demon to take a few steps back to know.

P.S.

I almost thought we agreed on this but, the inevitable additive nature of the lighting means that many of textures on the wall and the floor must be illuminating only within the beam tree of the stencil casting light source. Requardless of how they are applied (they may be modelled, projected, cubemap projected or whatever) they are modulating a single source that is also being stencil tested. The apparent effect will be that they are cast from that source. The only way of making this look right on intervening objects is to project from the source (how that projection is implemented is another issue), the correct shading on the demon suggests this is indeed what's happening. Other solutions would be physically wrong, but the results may not look obviously incorrect. So they may as you say be getting projected from elsewhere, but for those that modulate the light within a specific stencil volume they should be projected from the source to be correct.


[This message has been edited by dorbie (edited 06-02-2002).]

zed
06-02-2002, 11:01 AM
>>why does the shadow then appear to the wall in the background wich faces to the left.<<

from the monster?? i dont see it.
i do see a reflection someones face in the screen if i turn the gamma up, did someone video this from a monitor screen? sounds not legal, if so i suppose this is uite good evidence.

>>As the demon walks down the corridor there is some detailed building or window cross hatching shadow effect cast on the floor with a semi transparent occultation over part of it (i.e. not just a grille) as if it's illuminated through glass (or something).<<

sounds like theyre using the same noise textures of quake3, were there any parts of the video where 'outside' was shown?

status on my demo. its cruising along quite nicely, should be done today (day off work today some mothers birthday or someit http://www.opengl.org/discussion_boards/ubb/smile.gif )

angus by flickering lights i take it u mean strobe lights (like they use in horror movies to coverup the fakeness of the models), i added this but its painful to watch i hope doom3's not gonna be full of stuff like that (does it bring on epiletic fits)

davepermen
06-02-2002, 11:40 AM
as the room got dark because the sun went down, i now see the face in the pic as well.. scary, not? someone is watching you while playing!

never thought such a good quality pic can be a real fotograph, but well, there we see someone else is watching the movie as well http://www.opengl.org/discussion_boards/ubb/wink.gif

for the rest.. well.. i see
1) one stencil shadow. casted from the monster
2) i see another stencil shadow, casted from the yellow thingy on the left (very little)
3) i see some projected textures wich gets modulated by.. well.. dunno wich part of the multipassimage (but not the final one.. its a modulation per light)
4) i'm just thinking from where those lightsources come from.. i guess one is from the top left front, wich have a grid projected, wich gets on my right wall facing to the left (the one i mentoyed above)
5) the monitors ARE illuminating, but only the monster as far as i can tell.

between one and 5 of these things do NOT have to be true in the final game, and they dont have to be true in this picture even. i know now since longer time that you can interpret much too much into pics. for example i remember zelda64, from where i had pics from the final game. when running, the stuff looked in fact the same, but during the time i knew only the pic i thought its something completely different, and done completely different.

so.. don't interpret too much from a pic..

dorbie
06-02-2002, 11:57 AM
The face is in the video, it starts with a fade from Kevin Cloud being interviewed, so that's who the mysterious face in the capture belongs to.

I have a still form the video but ftp is giving me problems. I'll email it. It's only 38K, you can upload it where you like. It shows the semi-transparent 'shadow' on the floor and the modulation of the monster by the projection.

Yes this is all just screenshot speculation. Many of the other sequences do not show any evidence of these effects.

davepermen
06-02-2002, 12:01 PM
well yeah, its from the fade http://www.opengl.org/discussion_boards/ubb/wink.gif

but you know what? i scared myself now.. i've reconstructed the face from this picture..

here it is: http://tyrannen.starcraft3d.net/free/files/seeit.JPG

some seconds of work (most the time booting up the picture-editor)

and well.. could be used to find out who it is yet very well. i'm scared what police can do with the right power...

davepermen
06-02-2002, 12:06 PM
got the mail
here's the pic: http://tyrannen.starcraft3d.net/free/files/D3one[1].jpg

first statement: cool pic, like the shadows http://www.opengl.org/discussion_boards/ubb/smile.gif

davepermen
06-02-2002, 12:36 PM
well.. as this is part of a cut-scene in the game, there could be another solution:
you don't see much geometry of the level there, do you? actually just some walls and the monster, and a floor and some screens and thats more or less it.

well.. that would not look cool. and not at all scary.. so they simply added those shadows.. this is wellknown in computer animations.. adding some non-existing environment on the picture to have more detail than existing.. sort of environmental shadow mappings this time http://www.opengl.org/discussion_boards/ubb/wink.gif seen this before at other places..

i guess its this (as there are no softshadows with real occluders..)

zed
06-02-2002, 02:47 PM
http://uk.geocities.com/sloppyturds/d1.jpg
also d2,d3
yes no shadow from player yet, ive just had a backwards brainfart.
i believe i might be able to do realtime soft selfshadowing http://www.opengl.org/discussion_boards/ubb/smile.gif

dorbie
06-02-2002, 02:49 PM
Geometry is more of a problem for stencil. Texture resources would make shadow texture projection possible.

Once again I've never insisted on this option, but it is still wide open, using a cubemap to project a texture into the scene does not prevent you rendering real occulters to that cube map. When you do that you don't have to tolerate aliasing in the texture filter you associate with depth map testing (which can be texture filtered BTW)

P.S. when Ron pointed out that "disco lights" were in no way shadows it was a non sequitur. I'd listed many options that might explain what I saw.


[This message has been edited by dorbie (edited 06-02-2002).]

dorbie
06-02-2002, 02:56 PM
Zed, they don't allow deep links from bulletin boards. You need to supply an html URL.

If anyone wants to see this just cut 'n paste the URL to a browser.


[This message has been edited by dorbie (edited 06-02-2002).]

knackered
06-02-2002, 03:47 PM
Looks very good, zed.

dorbie
06-02-2002, 05:49 PM
Yea, it looks promising. I hope you get the stencil in soon. How about some semi-transparent occultation? I tried to email the image to you but it bounced. daveperemen posted it 6 posts above, you can see it has a mix of glass and building structure in it. Just draw glass before everything else as light grey to the shadow texture with the zbuffer writes off (if you have them on, there's no need) instead of black. If you're really bold you could use a color texture and draw a stained glass window to the texture, it'll be inkeeping with your chosen theme :-).

---late edit & image tag test:-)

http://tyrannen.starcraft3d.net/free/files/D3one[1].jpg


One suggestion (and it's not intended as a criticism). You need to modulate the direct illumination to zero (black) with the shadow texture for the illumination pass and THEN optionally add ambient modulated by a diffuse map. The bump mapped area in shadow looks strange because it has a strong directional component to the ambient term even though it is in shadow.

I think you'll find that the result will look more like Doom3 if you do this with no ambient getting added in.

BTW I see no occulter in the image! You must've hand painted it. :-)

Scratch that last remark, I just saw the second shot, it was a joke anyways.


[This message has been edited by dorbie (edited 06-05-2002).]

SirKnight
06-02-2002, 07:14 PM
That's pretty cool Zed. Could you (or anyone else) tell me how this is done?

-SirKnight

dorbie
06-02-2002, 07:38 PM
!!!!

He renders the occulter (the ceiling) as viewed from the light to a texture then projects that as a texture from the light source over the illuminated scene to modulate the scene.

What zed has proposed he do next is combine this with a stencil shadow effect on the character. When this is done he'll have something approximating the lighting effect in Doom3 for a single light.

The stencil shadow will require that he modulates the shadow texture to black and starts with a black scene since the stencil test will cull fragments entirely from the illumination pass. If he wants ambient & other effects like emissive material he could add it in the depth pass for the stencil test then accumulate the lights, from there multiple light sources is a simple progression.

SirKnight
06-02-2002, 09:55 PM
He renders the occulter (the ceiling) as viewed from the light to a texture then projects that as a texture from the light source over the illuminated scene to modulate the scene.


Omg, after i posted my question i thought about it for a bit and that is exactly what i came up with, i just wasnt sure if that would work, guess so. http://www.opengl.org/discussion_boards/ubb/smile.gif Thanks for verifying that. http://www.opengl.org/discussion_boards/ubb/wink.gif

-SirKnight

zed
06-02-2002, 10:28 PM
>>How about some semi-transparent occultation? I tried to email the image to you but it bounced. daveperemen posted it 6 posts above, you can see it has a mix of glass and building structure in it. Just draw glass before everything else as light grey to the shadow texture with the zbuffer writes off (if you have them on, there's no need) instead of black. If you're really bold you could use a color texture and draw a stained glass window to the texture, it'll be inkeeping with your chosen theme :-).<<

the third screenshot 'd3.jpg' does that, doesnt it? the red is meant to be the clouds of mars

>>What zed has proposed he do next is combine this with a stencil shadow effect on the character<<

im gonna try out one thing beforehand ( ive just been preparing the groundwork for the last 4 hours http://www.opengl.org/discussion_boards/ubb/frown.gif )

>>One suggestion (and it's not intended as a criticism). You need to modulate the direct illumination to zero (black) with the shadow texture for the illumination pass and THEN optionally add ambient modulated by a diffuse map. The bump mapped area in shadow looks strange because it has a strong directional component to the ambient term even though it is in shadow.<<

thanks for the idea angus, ill stick it on my TODO list http://www.opengl.org/discussion_boards/ubb/smile.gif

AndersO
06-02-2002, 10:36 PM
So.. Everyone agrees on that its something more than stencil shadowing going on in doom3?

Then what happened with the unified approach?

dorbie
06-03-2002, 12:22 AM
Zed,

Oh, awesome! I never noticed the color gradient in the light, it's too low frequency to make it obvious, but now that you point it out I see it clearly. Color translucent shadow textures!

I have one other minor suggestion. The occulter is a soft edged alpha texture, this kind of cheats when it comes to soft shadows. For evaluation you may want to try some hard edged geometry. Then you can see if you need to jitter the light, antialias the rendering or convolve the texture (or all of the above) when generating the shadow texture for a given texture resolution. It will address an inevitable criticism before it's made, or did I just do that :-).


[This message has been edited by dorbie (edited 06-03-2002).]

davepermen
06-03-2002, 12:40 PM
http://www.virtualray.ru/eng/news.html

for dorbi. about the raytracing topic we had.. its running at 15fps on my p3 500 sometimes.. (the demo1.zip, the one with the bumpmaps it is) and its even quite smooth on 800x600. would love to test this on a p4 or athlonXP..

zed
06-03-2002, 08:34 PM
classic http://www.opengl.org/discussion_boards/ubb/smile.gif http://www.virtualray.ru/eng/shots.html
dont tell me theyre doing a book entitled
'1001 uses for a sphere'

i was gonna say this after ild finished the doom3 demo but i suppose now is a good a time as any,
IMHO direct lighting methods eg stencil, shadowmap, raytracing (standard), projected textures are all dying eg what did carmack say with doom3 something along the lines of 'doom3 level makers have to be careful with the number of lights they use'
indirect lighting methods are the future (maybe theyre not practical today) not only do they look better but WRT lighting using 1 or 1000 lights is gonna run practically at the same speed

peterpan
06-04-2002, 12:47 AM
Few days ago jwatte said something about possibility of alpha buffer usage in Doom3.

I tried to figure out how to perform diffuse lighting computations by using no more than FOUR texture operations (on GF3). (Specular computations can be performed in other pass, so I ignore them yet).

Results (good quality rendering only): without alpha buffer - FIVE texture operations. with alpha buffer - FOUR texture operations.

So, if we need to obtain good quality result on GF3, then we need to use alpha buffer.

So, questions are:
1) Any ideas about FOUR-texture diffuse ligthing (may be I overlooked a good method)?
2) Can we use alpha buffer (destination alpha)? Is it works on GF/Radeon?
3) Any Carmack-related info about alpha buffer?

Julien Cayzac
06-04-2002, 01:13 AM
Originally posted by AndersO:
So.. Everyone agrees on that its something more than stencil shadowing going on in doom3?

Then what happened with the unified approach?

Why has the unification process to be at OpenGL level ? What Carmack said simply means everything passes thru the same pipeline, not thru the same *OpenGL* pipeline.

My guess is he simply abstracted the whole thing (I've heard he somewhat recently discovered OO-programming http://www.opengl.org/discussion_boards/ubb/smile.gif )

Julien.

dorbie
06-04-2002, 02:53 AM
Dave, that's a software ray tracer. It won't alter the fact that the hardware to make the earlier papers interesting doesn't exist.

You only raised this topic to try to say I don't understand current hardware & you do.

Let it go.

.......impress me with something you've written.


[This message has been edited by dorbie (edited 06-04-2002).]

dorbie
06-04-2002, 03:12 AM
Peterpan,

on the need for destination alpha, I think I have a reasonable theory. I was thinking about the accumulation of multiple light sources when you need more texture units than you have in a single pass and must modulate the final contribution from a SINGLE light using two passes without affecting the contributions of other lights.

It seems to me that to get the modulation correct you must write some of the lightsource modulating values to destination alpha, (probably shadow texture and attenuation [range attenuation may also be required remember]). This then leaves you the illumination term to apply on the second pass modulated by destination alpha and stencil tested.

So I think that the destination alpha is required on platforms which must multipass because they support fewer that the total texture fetches required by each light in a single pass. Basically destination alpha is used to allow a multiplication of the results from two passes because the color buffer must hold the results of other lighting contributions.

It would also mean that platforms with fewer textures would be stuck with monochrome light modulation effects for certain terms where an ATI could have color modulation. In particular I'm wondering if the blue tint on the translucent shadow texture (through glass) on the hallway floor will be possible on an NVIDIA card. I suspect not unless it can be shifted to the second pass. I don't see how you could do that without applying the same modulation to both passes, and add them independently to destination color and that would waste texture fetches and very probably take extra passes too. So destination alpha would be the sensible choice. You can do color modulation on the first light drawn I think, but that's nixed if you do anything special like add emission & ambient in the initial depth buffer write pass.

The need to have hardware support for multiple alpha buffers which support color is clear (secondary color buffer?).


[This message has been edited by dorbie (edited 06-04-2002).]

davepermen
06-04-2002, 06:04 AM
Originally posted by dorbie:
Dave, that's a software ray tracer. It won't alter the fact that the hardware to make the earlier papers interesting doesn't exist.

You only raised this topic to try to say I don't understand current hardware & you do.

Let it go.

.......impress me with something you've written.


[This message has been edited by dorbie (edited 06-04-2002).]

i just wanted to show it to you, thought you like it. doesn't have to do anything to blame you or something. impressing you.. well.. i'll check if i have something that could impress you, but i guess no. its only the normal stuff, implementing stencil shadow volumes like in the nvidia paper, implementing fft-water like in some other paper, implementing perpixellighting with help of some papers with an own equation for one pass on gf2mx (you know the link i'm sure http://www.opengl.org/discussion_boards/ubb/smile.gif)

i'm working on some skyroads revival and i hope this will work, cause i guess you'll all like it http://www.opengl.org/discussion_boards/ubb/wink.gif

peterpan
06-04-2002, 06:21 AM
Originally posted by dorbie:
Peterpan,

It seems to me that to get the modulation correct you must write some of the lightsource modulating values to destination alpha, (probably shadow texture and attenuation [range attenuation may also be required remember]). This then leaves you the illumination term to apply on the second pass modulated by destination alpha and stencil tested.


I think, alpha buffer can contain [range] attenuation factor only. It allows us to use FOUR (instead of FIVE) textures to compute diffuse (or specular) color. It's good for GF3+ cards which have 4 textures only.

So, as Carmack said, we have 2 or 3 (depending on "number of color components" as he said) passess per light on GF3 cards. First pass: alpha, second pass: diffuse, third pass: specular. If an object have no specular, then third pass is not required.
Comments?

Possibly a method exists allowing to render in 2 passes (instead of 3) on GF3, but I can't figure it out. Any ideas?

davepermen
06-04-2002, 06:22 AM
Originally posted by dorbie:
The need to have hardware support for multiple alpha buffers which support color is clear (secondary color buffer?).


[This message has been edited by dorbie (edited 06-04-2002).]

well.. i thought about this myself yet and thought its quite a cool idea. but as long as we dont have it, a secondary color buffer is simply a WGL_RENDER_TEXTURE_RECTANGLE.. first do the whole diffuse term into a texture, then the whole specular one in another and done.

dorbie
06-04-2002, 06:25 AM
Fair enough, I was just puzzled by the link after the dissonant post it seemed to follow up on.

This may interest you, although frankly I don't know where I first saw this it may have been posted by you for all I know. http://www.openrt.de/

I look forward to seeing your demo. A URL in your profile would keep your stuff is a mouse click away, you used to have one.

peterpan
06-04-2002, 06:25 AM
Originally posted by davepermen:
well.. i thought about this myself yet and thought its quite a cool idea. but as long as we dont have it, a secondary color buffer is simply a WGL_RENDER_TEXTURE_RECTANGLE.. first do the whole diffuse term into a texture, then the whole specular one in another and done.

Do you think we MUST render to textures? Why? I don't understand. (I mean GF3, not GF2).

davepermen
06-04-2002, 06:28 AM
Originally posted by peterpan:
Possibly a method exists allowing to render in 2 passes (instead of 3) on GF3, but I can't figure it out. Any ideas?

well.. if i think about it: say you have a glass wall, wich is fully transparent. the specular is independend of this transparency, it only cares about the glossiness/specularity how ever called http://www.opengl.org/discussion_boards/ubb/smile.gif so this means:

final = ambient + diffuse*transparency + specular

and as ambient is taken out (at least in doom3 i think it is really all black http://www.opengl.org/discussion_boards/ubb/wink.gif)

final = blend(transparency,diffuse,destcolor) + specular

thats two simple passes..

diffuse pass needs: normalmap,colormap+transpacency,normalisationcubem ap,lightcolormap (cube or projected) => 1 pass possible

specular pass needs:
normalmap,glossmap (can be normalmap-alpha),normalisationcubemaps 2 times (i'm thinking about phong, not blinn) => 1 pass possible

_could_ be done i guess..

dorbie
06-04-2002, 06:37 AM
That's a lot of rendertotexture.

It would work for sure. I'm not sure you need to break it down the way you did, I suppose any which way would do, as long as the arithmetic worked out.

If you were doing that I suspect you wouldn't need to render to texture for all passes. I might try to render to texture for one pass and possibly project that back into the scene from the eye on another pass. It depends on available texture units. I'm not sure it's worth trying to beat the full lighting equation out of a 2 texture card. I think on older cards the shading quality will be reduced. They don't have the memory or functionality required for fast render to texture anyway.

Peterpan,

could you elabourate? Do you understand the issue of combining passes without modulating the existing lights in the destination color buffer? All terms, both specular and diffuse must be modulated by shadows & attenuation, so you can't get by with modulating just some of the results in one pass and adding another.

rendertotexture buys you color modulation across passes without trampling over your destination color buffer.


[This message has been edited by dorbie (edited 06-04-2002).]

peterpan
06-04-2002, 06:46 AM
Originally posted by davepermen:
final = blend(transparency,diffuse,destcolor) + specular

thats two simple passes..

diffuse pass needs: normalmap,colormap+transpacency,normalisationcubem ap,lightcolormap (cube or projected) => 1 pass possible

specular pass needs:
normalmap,glossmap (can be normalmap-alpha),normalisationcubemaps 2 times (i'm thinking about phong, not blinn) => 1 pass possible

_could_ be done i guess..

Let's talk about diffuse component.
You forget attenuation map in your list of textures. So, there is FIVE textures, not FOUR.

dorbie
06-04-2002, 06:48 AM
You must also worth considering that the render to texture is an additional overhead and texture ultimately used on each fragment. You'd weigh that against modulation of all passes if it was a viable option and you insisted on color. Destination alpha looks attractive, at least as an option.

davepermen
06-04-2002, 06:57 AM
well.. if we only do stencil shadows and light-color-maps (your projected ones).. i'll suggest this way:

clear to ambient color (doom3:black)
for every light {
fill stencil with shadow-volumes
make sure you only draw into unshadowed region
add diffuse of this light (with the 4 textures i mentoied above)
add specular of this light (with the 4 textures i mentoied above)
}

done.

that way works. it has only one problem: you have lost the power of doing free shaders on the geometry (means the stuff q3 had, animated computer screens, rotating textures over other textures etc..)

to do that, render those shaders into a texture first, and bind this instead of the colormap you normally use for diffuse shading.

that means then like this:

texture shaders = render_texture(screensize);
texture normalalpha = texture2d(normalmap,transparency)
texture normalizationcube = procedural(cubemap,normalizationfunc)
texture lightcolormap = cubemap/projected texture

rendertarget = shaders
render q3 style shaders (with up to 4 passes in q3 http://www.opengl.org/discussion_boards/ubb/wink.gif) into shaders.rgb, and glossiness into shaderrs.alpha

rendertarget = screen
clear to ambient
for every light {
2 passes: shadowvolumes
pass3 {
texture0 = shaders
texture1 = normalalpha
texture2 = normalizationcube(point_to_light)
texture3 = lightcolormap

framebuffer += texture0*texture1.alpha*(texture1 dot texture2)*texture3
}
pass4 {
texture0 = shaders
texture1 = normalalpha
texture2 = normalizationcube(point_to_light)
texture3 = normalizationcube(point_to_eye)

framebuffer += lightspecularcolor*texture0.alpha*(reflect(texture 1,texture2) dot texture3)^exponent
}
}

if i have no typo, this should work on a gf3/4 without bigger problems..

peterpan
06-04-2002, 06:57 AM
Originally posted by dorbie:
Peterpan,

could you elabourate? Do you understand the issue of combining passes without modulating the existing lights in the destination color buffer? All terms, both specular and diffuse must be modulated by shadows & attenuation, so you can't get by with modulating just some of the results in one pass and adding another.

rendertotexture buys you color modulation across passes without trampling over your destination color buffer.

Any problems? http://www.opengl.org/discussion_boards/ubb/smile.gif

Do you see any "modulating the existing lights in the destination color" below?
(I hope "destColor += destAlpha * srcColor" is valid operation)

Note: destination color contains results of previous passes

First pass:
destination ALPHA <= range attenuation

Second pass:
(stencil test is ON!)
destColor += destAlpha * dffuseLightingResult(decall, lightNormal, normal bump map, projectedLightTexture)

Third pass:
(stencil test is ON!)
destColor += destAlpha * specularLightingResult(gloss, halfVector, normal bump map, projectedLightTexture)

What do you think?

peterpan
06-04-2002, 07:03 AM
Originally posted by davepermen:
...
pass3 {
texture0 = shaders
texture1 = normalalpha
texture2 = normalizationcube(point_to_light)
texture3 = lightcolormap

framebuffer += texture0*texture1.alpha*(texture1 dot texture2)*texture3
}
...
if i have no typo, this should work on a gf3/4 without bigger problems..

Once again: where is attenuation map?

Possibly we can include attenuation into projective light texture (I guess) by using 3D 9instead of 2D) texturing, but it's waste of texture memory.

dorbie
06-04-2002, 07:08 AM
Sorry peterpan, I missed your initial followup.

Interesting. You can certainly multiply range attenuation with a shadow / light map in the first pass.

The terms for specular and diffuse cannot globally modulate so that does put the kybosh on throwing much else in there.

For monochrome surface color again you could apply that in the alpha in the first pass which is perhaps the pass difference between monochrome and color come in. Much depends on what you can model for the surface material. All independent lighting component textures have to be applied in the second pass. I see that you almost have to separate diffuse and specular in independent passes after that because you the only remaining + in the rest of equation is between those two major terms.

davepermen
06-04-2002, 07:12 AM
Originally posted by peterpan:
Once again: where is attenuation map?

Possibly we can include attenuation into projective light texture (I guess) by using 3D 9instead of 2D) texturing, but it's waste of texture memory.

hm well.. put this into the normalisationcubemap. by extending it to a procedural(texture3d,rgb=normalized(texcoord),alph a=dst_att(texcoord))

about this.. i can't tell how it really looks, cause i dont have a gf3, but i know from some others that they like it.. and it works reasonably fast, and well.. a 64x64x64 tex should be enough, they told me.. they don't see much difference for the rest (else we can renormalize in the combiners, thats easy.. http://www.opengl.org/discussion_boards/ubb/smile.gif)

dorbie
06-04-2002, 07:20 AM
Simplifying this (too many textures, my head's spinning :-))

Attenuation * Shadow_texture * (diffuse_map * diffuse + (optional_gloss_map * specular)

Attenuation * Shadow_texture * mono_diffuse_gloss_map * (diffuse + specular)

Whether diffuse is monochrome or not determines if you can place any additional terms in the first pass. But if you did you'd be stuck with the same modulation of specular subsequently. So a diffuse map would also be a gloss map if you did this.

Feel free to assign textures to diffuse and specular calculations to determin passes with & without the diffuse texture color multiplied in destination alpha.

[This message has been edited by dorbie (edited 06-04-2002).]

davepermen
06-04-2002, 07:23 AM
framebuffer += texture0*texture1.alpha*(texture1 dot texture2)*texture3

that one (in pass3) should of course be

framebuffer = blend(texture1.alpha,texture0*(texture1 dot texture2)*texture3,framebuffer)

and the diffuse term there in like that is:

diffuse = texture0*(texture1 dot texture2)*texture3

wich will be for attentuation extendet to

diffuse = texture0*(texture1 dot texture2)*texture3*texture2.alpha

about this..

dorbie
06-04-2002, 07:25 AM
The minor gotcha is that the shadow texture looked color in the screenshot, but that was on an ATI.

davepermen
06-04-2002, 07:36 AM
Originally posted by dorbie:
Attenuation * Shadow_texture * mono_diffuse_gloss_map * (diffuse + specular)


the mono_diffuse_gloss_map is a fancy stupid term imho.. i dont see any point in this yet http://www.opengl.org/discussion_boards/ubb/smile.gif

and attentuation does not affect specular imho as well..

diffuse = lightcolormap/shadowmap * ( normalmap dot normalized_map[point_to_light] ) * distance_attentuationmap * colormap/decalmap/diffusemap

specular = lightcolormap/shadowmap * ( normalmap dot normalized_map[halfangle] )^exponent(-map on radeon http://www.opengl.org/discussion_boards/ubb/smile.gif) * glossmap

the lighting equation (2 passes)

framebuffer = blend(transparency,diffuse,framebuffer)
framebuffer = add(framebuffer,specular)

diffuseterm incl transparency do have to be 4 textures:

normalmap => tex0rgb
lightcolormap/shadowmap => tex1rgb
normalized_map[point_to_light] => tex2rgb
distance_attentuationmap => tex2alpha
colormap/decalmap/diffusemap =>tex3rgb
transparency => tex3alpha

into tex0alpha you can store glossiness as well.. for the specular pass afterwards..

in this case tex0 is texture2drgba
tex1 is projectedtexture/cubemaprgb
tex2 is 3dtexturergba
tex3 is texture2drgba

that SHOULD work.. (you have to z-sort http://www.opengl.org/discussion_boards/ubb/wink.gif) so split between transparent geometry and not transparent geometry, as always.. (but specular does not care on transparency => tipp (OKAY if you take fresnel..))

peterpan
06-04-2002, 07:39 AM
Originally posted by davepermen:
framebuffer += texture0*texture1.alpha*(texture1 dot texture2)*texture3

that one (in pass3) should of course be

framebuffer = blend(texture1.alpha,texture0*(texture1 dot texture2)*texture3,framebuffer)

and the diffuse term there in like that is:

diffuse = texture0*(texture1 dot texture2)*texture3

wich will be for attentuation extendet to

diffuse = texture0*(texture1 dot texture2)*texture3*texture2.alpha

about this..

Thanks.

Carmack said something about three passes on GF3 (per object?). I don't know it's "stencil, specular, diffuse" or it's (stencil not counted) "specular, diffuse, something else(alpha buffer?)". I remember, he said something about two normalizations, 7 texture acceses, 6 texture modules. If so, I don't know for what is sixth texture exists (if we have no separate attenuation map texture).

So, here is list of textures:
Decal, Gloss, NormalBump, ProjectedLight, 3DNormalizationWithAttenuation, MAGICAL_SIXTH_TEXTURE. http://www.opengl.org/discussion_boards/ubb/smile.gif

Hm... Vote for destination alpha buffer pass! http://www.opengl.org/discussion_boards/ubb/smile.gif

dave, Carmack will say (after reading your message) in an interview "I have an idea. Now I have FIVE textures instead of SIX" http://www.opengl.org/discussion_boards/ubb/smile.gif.