Shadows

Zaldron, what's better?

Light subdivision or shadow volumes?
The first requires more "light" volume polys, but it can be stopped in a very early stage of subdivision. The second has to be made for all faces which are in the shadow volume.
Maybe a hybrid algo?

Maybe something like a shadow subdivision algo?

My cat's breath smells like cat food.

Does it? Does it really?

I drink sand.

S./

If I am not wrong here then I think shadow volumes are better...
Zaldron can you confirm?

Shadows are a minor issue, and an easy one to get out of the way.

Make an ellipse with width equal to how thick the model is, and length equal to how wide the model is (shoulder width essentially).

This ellipse is the border between what is considered ambient brightness and the shadow. Inbetween the border and 50% of the way to the center of the ellipse there is a gradual reduction in brightness down to 50% of the ambient brightness. Any closer than 50% of the way to the center will be at 50% standard ambient brightness.

So, in other words (english), the shadow is fuzzy, always elliptical (unless the model is a sphere), and is always 1/2 as bright as the surrounding area.

For the purpose of explosions and other effects that brighten the area you take the darker offset and reduce it by 1/2 to make the shadow as dark as possible.

If the model loses contact with the ground (jumps), then the shadow is reduced in strength, all values divided by 2 for every <insert map distance equivalent of 3 feet> units off the ground.

This is really simple, and thus shouldn't be considered for use of casting shadows on walls or anything completly dynamic like that. It is meant to cut corners is times of desperation (when the video card is being maxxed out, or when they want to lower the system requirements).

just an idea

I don´t think we´re gonna see any kind of triangle tesselation in DooM engine. That´s for games like Severance, where they use tesselation to archieve lightmap-like vertex ilumination, and for shadows projection.

Now, we don´t know what system JC´s planned for the shadows. The ilumination system is pretty easy to code, and it doens´t have to be included over the models, standard vertex illumination will be enough. But shadows are a mistery. We suppose that there´s some kind of raycaster object that calculates the final lighting intensity over each triangle collision. But how the brush/poly system cooperate?

1) The shadows system is solely brush-based
2) The shadows system is brush/poly based

The first case is obviously the easiest one. The average amount of calculations is much lower than in 2). Imagine, a standard Quake 3 pic could display 500, 600 triangles (low use of NURBSs, of course). Now, we suppose that Carmack´s system is pretty sharp, each triangle under light exposition will cast a shadow over other triangles. But what happen when we add models into the shadowing?
The 500, 600 average boosts rapidly into the 6000 polys area. Imagine how hard for the system would be to handle 10x calculations. Cause were under raycasting, the system is affected by each triangle size. As bigger, more pixels to draw. So the 10x is obviously bigger than what it should be, perhaps a 4x increase is the choice.
Now, you could ask, how does Severance do?
That´s a lot simplier than this. Severance chooses the triangles who´s normals point to the semi-space where the selected light is. This roughly means 50% of the models and 80% of the brushes.
New triangles are created in over each brush, tesselating the plane with the "model shape" a little of Gourad coloring then makes the shadows darker and influentied by distance.
DooM´s engine is a total mistery. For the little we heard, it´s completely revolutionary. I think the easiest way to describe it is by talking about more refined lightmaps that changes in real-time.

If i were programming that engine, i would add :

1. Shadow quality slider. As you said, lightmaps are 1/8, 1/16 of real resolution.

2. Shadowing on models LOD. Ranging from poly based to skeletal bounding boxes.


I can´t really answer you. Im not sure what´re we gonna see in the future. To my eyes, all this stuff is yet impossible to handle in enviroments even more complex than Q3A. I guess we should hope that JC´s founded a way to optimize things.

sirgalahadwizar said:

For those of us interrested in realistic shadows, it isn't that simple.

SoKatH said:

Does it? Does it really?

I drink sand.

S./

I drink Windex™... it keeps me from streaking.

deadnail said:

My cat's breath smells like cat food.

the only thing me and my friends talk about at school is the simpsons or a series of stories we write caled the adventures of cheezman..you tok that line from the simpsons's ralph right?

Yep. It was episode #230948740957163450987345 in which a new girl in 2nd grade showed up Lisa and eventually became her friend. Ralph's line was toward the end, right after he said, "I bent my wookie."

So you think you're a Simpson's buff, eh? Then in what episode was the message "FRINK RULES" placed?

sirgalahadwizar said:

That´s Serious Sam method.
Anyway, what PainElemental meant by "shadows" was the whole new lighting scheme.

Zaldron said:

Hey, that's a cool idea. I didn't think about it. A real-time raytracer, which uses coldet for light calcs! Of course, every brushside has to have a pointer to the face it lies on. Then the lightmaps are calcd in a very easy way!

Thanx man, I'll try to implement it in my Q3A engine...

PainElemental said:

Thanx man, I'll try to implement it in my Q3A engine...

What´s that supposed to mean?

Your Q3A engine? What are you, John Carmack!?

You didn't understand me. I meant the engine I'm currently working on that's based upon the Q3A engine(if you're interested in screenshots, visit:
cyberdemon.hit.bg/screenshots.html
Don't laugh man..:-)

I've already implemented the ray collision detection routines. The main problem is that you've to test a single ray against all the brushes contained in the bounding box of the light. I'm not sure but I've got the feeling that the algo's going to be terribly slow. I've ideas for little optimizations but they wouldn't change very much the speed coldet is performed with. I think that the main thing I've to optimize are the two dot products that are needed in order to compute the collision point(really I can't sleep because of the 3 MULs, 2 ADDs and the one SUB operation). By the way, do you have any suggestions about that?

The advantages of this method is that soft shadows are computed very easily unlike all the subdivision methods. One more problem is that the models(I'm speaking of the models used for weapons and so, not the BSP models) have many polys and I have to compute the lightmaps for each one(maybe computing the LMs only for the bounding box of the models and then calcing the texture coordinates for each poly will do the trick?-that's something like the cube environment mapping).

However, I'll try something...