Unreal 3.0 and Dynamic Radiosity Lighting

[Scali]

and are sealed off from all sides, and the roof is replaced with a skydome.

What engine has open spaces that are not sealed off from all sides and doesn't use a skybox?

Okay wiseguy, "Sealed off from all sides within only a few metres".
The average outdoor game will allow you to walk hundreds of metres around in any direction.
If you didn't understand that's what I meant, you're obviously not smart enough to follow this discussion, so please stay out of it.
If you did understand it, stop trolling, you're wasting posts.

 

[Scali]

If you want my idea of unified, I guess the average raytracer is a nice example. You can feed any object, and any light type, and it will just light and shadow properly. Even with opacity maps. Spotlights can simply be done by modeling a spotlight... namely a pointlight with a hemisphere surrounding it. Ofcourse you could do that in Doom3 aswell, but obviously the cost of the shadowvolume created this way, is not acceptable. Hence we drop the uniform model and precalc a hack, as usual.
As far as non-pointlight sources, Doom3 cannot handle those at all. All lightsources are considered pointlights as far as the stencilshadows are concerned. And calculating anything other than pointlights directly in a shader is troublesome aswell.

It is the other way around!!! :?

Most lights in Doom3 are spotlights!!!! And specialy because of shadows, simply to the fact that a spotlight frustum is very small compared to a pointlight frustum, thus the optimizations for the shadows are huge.

Check the shaders, most lights require a spotlight map for the lightning, except of course point lights....

In fact, the only pointlight I noticed playing Doom3 is the light from the Imp!

READ!

 

[KimB]

As you say, you need to modify it to make it perform well. Get it?
As soon as you modify the engine, it is no longer the Doom3 engine.

Um, what game in history has used an licensed engine and not modified it somewhat?

 

[SteveHill]

They are special cases of pointlights. As are spotlights, obviously. Just pointlights with a cone-shaped range.
I meant significantly different lights, like different shapes of light. Not points, but spheres, cylindrical shapes, boxes etc.

It's data driven; using your definition, every individual diffuse texture is a special case. I believe fans, for instance, are just rotating lighting sources with a fan-mask 2D falloff (as opposed to attenuation) texture.

A single, parameterised interaction path is fairly "unified" in my book.

 

[Scali]

Um, what game in history has used an licensed engine and not modified it somewhat?

I don't think the suggested modifications are in line with the modifications to most licensed engines in games.
So you are over-simplifying the point.

 

[Scali]

They are special cases of pointlights. As are spotlights, obviously. Just pointlights with a cone-shaped range.
I meant significantly different lights, like different shapes of light. Not points, but spheres, cylindrical shapes, boxes etc.

It's data driven; using your definition, every individual diffuse texture is a special case. I believe fans, for instance, are just rotating lighting sources with a fan-mask 2D falloff (as opposed to attenuation) texture.

A single, parameterised interaction path is fairly "unified" in my book.

No, I meant the SHAPE of the light, not a limited range on what is essentially still a pointlight. And I meant in relation to shadowvolumes. Shadowvolumes are always calculated from a single point. Especially the rectangular lights in Doom3 are a considerable hack because of this.

My definition of a unified path is no different from yours, and as I mentioned already, the shading itself is 'unified', but the lights and shadows aren't. It's not just a case of "Feed lights and geometry to engine". Take your own example... A fan is a rotating lightsource with a texture? Isn't a fan supposed to be geometry? What does the lightsource have to do with the fan geometry? Why is it precalced into a texture? What if I want to move the fan separately from the lightsource? And as I said before, I don't believe that the fan 'lightsources' actually cast shadows on anything, other than the shadows encoded inside the texture itself. The flashlight on the other hand, DOES cast shadows (again not correctly, since a flashlight is not just a pointlight, there is a reflector behind the lightbulb, which effectively makes it some kind of area light. The projected lightmap simulates this, the shadows do not)...
I find it hard to just say this is a "data-driven unified" lighting system. If this is unified, then why isn't a lightmap on static world geometry considered unified? After all, it is no different from the fan-thing in Doom3, if you ask me. Whether you actually render it with all with the same interaction-path or not, is just an implementation-detail. This implementation wasn't very viable until recently. What's the big deal? The precalcing and the hacks are still there. I'd rather not have a single shader, but a system that as a whole is unified, which means I no longer have to precalc certain things, because everything actually IS lit and shadowed in the same unified way, and it can all be done in realtime. Where my rectangular lights actually light and shadow as if they are rectangular, and not act as a pointlight which happens to have the (precalced) range of the rectangular light.
And to take that idea further... yes, in the ultimate renderer, there would not be any textures, since every surface and colour interaction would be modeled accurately, not by a precalced 2d map that is projected onto the surface.

 

[Sigma]

I find your ignorance quite amusing indeed.

Mine?!
Please, do carry on...

After all, it is no different from the fan-thing in Doom3, if you ask me.

Oh darn! Another example of geometry faked with textures... How can someone keep up with you?

But check this out! You really shouldn't fake geometry with textures, right? But, since you're using a geometry based shadow solution, no problem with faking the shadow too! There! Because the engine is unifed, once you fake something, you have to fake it along the engine's pipeline. Even faking is unified... You fake one, fake the other. Otherwise it all works nicely: just place a light and your geometry casts a shadow. But beware! If you fake the geometry, you must fake the shadow, because the engine is unified... And bla bla bla bla...

 

[Scali]

I find your ignorance quite amusing indeed.

Mine?!
Please, do carry on...

After all, it is no different from the fan-thing in Doom3, if you ask me.

Oh darn! Another example of geometry faked with textures... How can someone keep up with you?

But check this out! You really shouldn't fake geometry with textures, right? But, since you're using a geometry based shadow solution, no problem with faking the shadow too! There! Because the engine is unifed, once you fake something, you have to fake it along the engine's pipeline. Even faking is unified... You fake one, fake the other. Otherwise it all works nicely: just place a light and your geometry casts a shadow. But beware! If you fake the geometry, you must fake the shadow, because the engine is unified... And bla bla bla bla...

FYI even though there is an 'if' in unified, there should be no if-statements in unified code. A unified path is exactly that, one path that unites all operations. An if-statement means there are two paths, hence not unified.
Thank you for demonstrating your ignorance once again, always a pleasure.

 

[SteveHill]

No, I meant the SHAPE of the light, not a limited range on what is essentially still a pointlight. And I meant in relation to shadowvolumes. Shadowvolumes are always calculated from a single point. Especially the rectangular lights in Doom3 are a considerable hack because of this.

Ah yes, apologies, I rush-read what you said.

I don't think you can do Doom3 down for not handling area lights correctly -- that's a technological limitation. You can think of the soft projected shadow examples as first-order approximations of area lighting with a close-to-light occluder.

What does the lightsource have to do with the fan geometry? Why is it precalced into a texture?

Maybe for performance, artistic reasons (see above), or both.

What if I want to move the fan separately from the lightsource?

I understand your point, but this is still artist controlled. Perhaps the difference here is that I'm looking at things from a development point of view, not a theoretical one.

And as I said before, I don't believe that the fan 'lightsources' actually cast shadows on anything, other than the shadows encoded inside the texture itself.

Seeing as there is a flag to control whether a light casts hard shadows, I expect it's turned off for these lights in question.

The flashlight on the other hand, DOES cast shadows (again not correctly, since a flashlight is not just a pointlight, there is a reflector behind the lightbulb, which effectively makes it some kind of area light. The projected lightmap simulates this, the shadows do not)...

Right, there is a bit of a jar between the projected map and the shadows, which could be one reason why the other lights you mentioned have stencil shadows disabled. With the torch, on the other hand, it's kind of nice to wave it over a grating, for example, and see shadows moving about, likewise for NPCs carrying torches, etc.

I find it hard to just say this is a "data-driven unified" lighting system. If this is unified, then why isn't a lightmap on static world geometry considered unified? After all, it is no different from the fan-thing in Doom3, if you ask me.

Well, from a pipeline and/or rendering perspective, lightmaps in conjunction with other lighting systems is not a unified approach. One can be purist (pedantic?) with the interpretation of "unified" and demand a single shadow system but, as I have put forth, there are different areas to which this term can be applied and justified.

Edit: Scali, you should have just posted another message rather than butchering the existing one.

 

[Scali]

I don't think you can do Doom3 down for not handling area lights correctly -- that's a technological limitation. You can think of the soft projected shadow examples as first-order approximations of area lighting with a close-to-light occluder.

True ofcourse, but it doesn't really jive with the whole 'unified' idea that you can create non-pointlight lightsources, but these only affect certain parts of the rendering system, other parts still pretend it's a pointlight.
I can understand why Doom3 adds these hacks ofcourse, it makes the game look better. But selling the whole thing off as 'unified', or 'no precalc required', or 'no more hacks', or whatever else I've heard so far... no, I do not agree at all.

I understand your point, but this is still artist controlled. Perhaps the difference here is that I'm looking at things from a development point of view, not a theoretical one.

Well ofcourse, as said above, it all makes sense for a developer. The hacks make the game look better and/or faster, and that's what we all want. But I've heard people say a lot of things that Doom3 simply is not.
Ofcourse you COULD do everything truly unified with an engine like Doom3's. You could actually model the torch like a pointlight with a reflector behind it. You could ditch all the opacity maps and use real geometry, so everything would cast stencil shadows. You could create a large array of pointlights to approximate area lights quite accurately, etc etc...
But none of this will work in realtime. So we use hacks. Which makes Doom3 no better than any game before it, and most probably any game since Doom3 for a long time to come.

Seeing as there is a flag to control whether a light casts hard shadows, I expect it's turned off for these lights in question.

Yes, that's another not-so-unified thing. If it is truly unified, then every light and object would be treated the same. So either everything casts a shadow, or nothing does. Either everything requires precalc, or nothing does.

Well, from a pipeline and/or rendering perspective, lightmaps in conjunction with other lighting systems is not a unified approach. One can be purist (pedantic?) with the interpretation of "unified" and demand a single shadow system but, as I have put forth, there are different areas to which this term can be applied and justified.

Well, as I tried to say before... The shading part is unified, since there is only one light/surface interaction shader used for everything. But there is more to Doom3's lighting/shadowing system than just that interaction shader, and that's where you won't find a lot of unification.

So yes, if we're purist, Doom3 does not have a unified lighting model.
And yes, as developers we all know why this is, and why hacks have been applied since day 1 in graphics. The ancient Chinese art of Chi-Ting.
So I find it rather odd that people go around saying that Doom3's engine is the best thing since sliced bread.

 

[Sigma]

FYI even though there is an 'if' in unified, there should be no if-statements in unified code. A unified path is exactly that, one path that unites all operations. An if-statement means there are two paths, hence not unified.
Thank you for demonstrating your ignorance once again, always a pleasure.

Oh oh! I get it!

But does that include while and for loops? I am really confused here because any loop must have a condition to exit, right? An explicit 'if' statement of some sort... Meaning that a unified code cannot have loops! Damn, this talk is making me smarter by the minute! Wwweeee....

What if I want to move the fan separately from the lightsource?

I understand your point, but this is still artist controlled. Perhaps the difference here is that I'm looking at things from a development point of view, not a theoretical one.

Aren't we all looking at it from a developer point of view?

The thing is, this kind of hack for the fan is basicly incorrect. What if the fan stopped? The texture would have to stop rotating. What if the light moved? ...
Obviously, the artist used an incorrect aproach that gives nice results and gains speed. If the fan would for example stop or change speed, this hack would not work and the fan would have to be made out of geometry. The artist took advantage of the fact that a light can have a projected texture to project an imitation of the shadow. Simply like you said it: "artist controlled". They did what artists are supose to do: to use the engine the best way they see fit...

 

[Scali]

Oh oh! I get it!

No you don't, actually. Either you don't want to get it, because you hate me, or you are in love with Carmack, or something... or you really are this ignorant... anyway...

Your suggested if-statement is like this:

if (fake)
RenderMethodA( precalcedLightmap );
else
RenderMethodB();

Obviously we have two mutually exclusive renderpaths. A and B do not have the same input. They can in no way be unified.
Which is no different from:

if (world)
RenderMethodA( precalcedLightmap );
else
RenderMethodB();

And this is what we know from Quake and such.
Method A itself is unified, and method B is unified... but you cannot unify them both into a single rendering method, because they're simply not doing the same thing. Method A requires precalced maps, and method B doesn't. And the precalced maps require the geometry to remain static, while method B doesn't. So you cannot unify these. Simple, no?

Aren't we all looking at it from a developer point of view?

Developer point of view, or not... it's not unified. That doesn't change.

The thing is, this kind of hack for the fan is basicly incorrect. What if the fan stopped? The texture would have to stop rotating. What if the light moved? ...
Obviously, the artist used an incorrect aproach that gives nice results and gains speed. If the fan would for example stop or change speed, this hack would not work and the fan would have to be made out of geometry. The artist took advantage of the fact that a light can have a projected texture to project an imitation of the shadow. Simply like you said it: "artist controlled". They did what artists are supose to do: to use the engine the best way they see fit...

So now you agree that it's a hack, so it can't be unified.

 

[Anteru]

I think it's more like RenderLight (optional Lightmap), i.e. you choose whether you want it or not. That makes the difference, in all major engines before the engine has put Lightmap on for you, and you had no choice. Same goes for texture, bump map and all other maps. The choice is in your hands, and no special shader is used, all handled by the same system.

 

[Scali]

I think it's more like RenderLight (optional Lightmap), i.e. you choose whether you want it or not. That makes the difference, in all major engines before the engine has put Lightmap on for you, and you had no choice. Same goes for texture, bump map and all other maps. The choice is in your hands, and no special shader is used, all handled by the same system.

Wrong wrong wrong wrong wrong!
In case you STILL don't get it... Using a lightmap means you cannot move the geometry and light anymore. So you cannot just choose whether you want a lightmap or not. You need to lock the light and geometry in place, toggle shadowgeneration flags, precalc the lightmap and all that.
It is just as much a choice as there is a choice for using a lightmap on the walls of Quake or using vertex lighting. Both are 'handled by the same system' (what is a system anyway? if the system is the engine, then obviously every game has a system that handles the game you throw at it, which again makes it a completely useless statement) , but unless you precalced that lightmap, you can't use it. And if you choose to use a lightmap on something that moves, it doesn't work.
So no, there is no free choice. There are distinct cases where distinct ways of rendering are applied, and they cannot be freely chosen, because they will fail in cases they weren't designed for.
How hard is it to understand? Geez!
Is everyone intoxicated by Carmack's stupid little outdated game and his stupid WRONG buzzword talk? It disgusts me.

 

[KimB]

Maybe because the game is not outdated and is actually capable of superb graphics without the preprocessing that other games rely upon so heavily?

 

[Diplo]

Is everyone intoxicated by Carmack's stupid little outdated game and his stupid WRONG buzzword talk? It disgusts me.

What exactly is your problem? Is this some kind of jealousy that Carmack is rich, succesful and you are... well, a no-one who constantly resorts to insulting people on bulletin boards? Get a grip.

 

[Scali]

Maybe because the game is not outdated and is actually capable of superb graphics without the preprocessing that other games rely upon so heavily?

As said before, there is still preprocessing required.
And it is not outdated if you haven't seen the new stuff yet, I suppose.
But Doom3 doesn't do anything that couldn't and hasn't been done on a GeForce256, which is well... 3 generations ago.

 

[Scali]

Is everyone intoxicated by Carmack's stupid little outdated game and his stupid WRONG buzzword talk? It disgusts me.

What exactly is your problem? Is this some kind of jealousy that Carmack is rich, succesful and you are... well, a no-one who constantly resorts to insulting people on bulletin boards? Get a grip.

You are insulting here...
But where exactly did I insult?
And just because you don't know who I am doesn't mean I am a no-one or know nothing, etc. Get a grip.

In case you didn't get what my 'problem' is... Read the thread and conclude that people think Doom3 has a complete unified light/shadow system and doesn't require preprocessing, and that Doom3 is the ultimate 3d engine ever.
Which are all obviously wrong, for reasons explained in this thread. The most annoying part is that people STILL insist, even though everything has been laid out before them. I don't understand why. Are these people really that stupid, or do they just have a blind trust in Carmack's words or something? Well, actually that would be stupid aswell. Always think for yourself, don't just accept what others are saying without giving it any thought.

 

[Sigma]

Which are all obviously wrong, for reasons explained in this thread.

Your reasons?!

Is there a diference between a spotlight projected texture and a lightmap?
Is it possible to simulate a lightmap with the spotlight?

This is the best thread EVER.

 

[dksuiko]

Read the thread and conclude that people think Doom3 has a complete unified light/shadow system and doesn't require preprocessing, and that Doom3 is the ultimate 3d engine ever.
Which are all obviously wrong, for reasons explained in this thread.

How is such an extreme position like that any different from your extreme position of Doom 3 being total garbage, or in your words, a "stupid little outdated game"? I don't think anybody claimed that Doom 3 is the "ultimate 3d engine ever" in the sense that no compromises have been made, but rather in acknowledgment of how much of a step forward Doom 3's engine is. A stark contrast to your position, who discredits Carmack of anything.

Hell, why stop there - why don't you complain that the Doom 3 engine isn't 3D at all, it's on a damn 2D display. Damn that Carmack, calling his engine 3D when it really isn't. Fool. And fuck off to Jack-in-the-Box as well, they're naturally cut fries aren't naturally cut.. somebody or something cut them as they obviously can't cut themselves! Argh!