Where Tds Went Wrong

[sparhawk]

Oh, so that's what the render pipe is for.

 

Correct. I thought this were obvious.

[OrbWeaver]

It's obvious to anybody who knows the inner workings and limitations of the D3 engine along with the technique behind the lightgem. To an outsider the natural reaction is "A pipe? For render data? WTF?"

[sparhawk]

Well, in the literature it is called "the render pipe" after all.

[DopeFishhh]

Well i made that guess based on that it's nice and simple and with a little physics knowledge it would provide you with a method of determining how much light would be reaching an object. The line of sight test to check if the light can shine on you and a distance check to determine the brightness of the light at the distance it is away from you. Of course you'd probably have to do this multiple times for different sections of the body so the head can get a seperate lumination result from the foot. Also you'd need to factor in ambient lighting too.

 

It seems that it is how it's done in your simple yet innacurate version, so i'm partially right, perhaps if multiple measurements were taken you could improve it's accuracy and reduce load. T1/T2 never had dynamic shadowing, there pretty much isn't any other way to determine how lit up something is in those engines. Also TDS had horrible framerates, using dynamic shadowing would fuck em over even more, though i guess it may be possible that they used the TDM accurate method (which could be why the framerates suck ass).

 

I hope you noted that i asked sparhawk to provide more info dave, I was never sure about any of that nor did I say I was, so go read non existant meanings into someone elses post please.

[Ishtvan]

It seems that it is how it's done in your simple yet innacurate version, so i'm partially right, perhaps if multiple measurements were taken you could improve it's accuracy and reduce load.

 

The accuracy of the "inaccurate version" is fundamentally limited by what Sparhawk posted above: It cannot take into account animated light textures, like faked fan blade shadows, and other "light shaders." The only way to know about those things along the surface of the player would be to have access to the renderengine (which we don't), or take a snapshot of the scene (which we do). Taking more measurements would not help with that.

 

I don't see how taking more measurements would decrease the load either, usually adding computations increases the load. Unless you mean interleave the measurements in time, which we are also doing.

[sparhawk]

It seems that it is how it's done in your simple yet innacurate version, so i'm partially right, perhaps if multiple measurements were taken you could improve it's accuracy and reduce load.

 

The simple version works like that, but there is a inherent problem (actually several).

 

First of all, I can not know which lights contribute to the world, so I have always test all the lights in the world and do a distance check, which is already expansive. The reason is, that lights have no limits. And some lights are used as ambient and spread over a pretty big region. If such a light is very bright, it would look strange if the player sees a very bright gameworld but the lightgem tells him he is invisible. I found this always very confusing in Thief FMs when the author used to much ambient light. I remember one FM wheer the map lookd really like daylight but the lightgem told me I was well hidden. The consequence was that I couldn't concentrate on gameplay anymore, because I always had to rely on the lightgem instead of the gameworld as seen on the screen.

Another problem is that Doom 3 can create light without lights (so to speak). You can create a light with a pretty low lightlevel, and put a texture on it. The result is that the light can get brigther or darker, but the lightlevel always stays the same. I actualy wrote code to also take this into account. So I'm loading these textures and include them in may calculation. This works pretty good. Where it gets complicates though, is that you can animate these textures. At this point it doesn't make sense to reprogramm this, because it means that I would have to rewrite the entire lightgenerator to factor in animated textures. In fact I would reproduce a big part of the renderengine if I have to do that. Since this would be very complicated and timeconsuming I devised another way to do this, which is more straightforward and will also run with any changes to the renderengine. My new method will work even if the renderengine will be modified and new stuff is added.

[sparhawk]

I don't see how taking more measurements would decrease the load either, usually adding computations increases the load. Unless you mean interleave the measurements in time, which we are also doing.

 

Well, the calculation is still much less expansive than teh rendering process. So even if we added several testpoints, it would still be much faster than doing the rendertest. But the inherent problems are the real reason to not do it this way, because no matter how much time you spend on tweaking it, you will always get wrong results in many situations.

[SneaksieDave]

I hope you noted that i asked sparhawk to provide more info dave, I was never sure about any of that nor did I say I was, so go read non existant meanings into someone elses post please.

Bah, it's all in fun, c'mon.

 

(tee hee, I see the guys are doing some schoolin' though!)

[Domarius]

Hey Spar, what about visportals? Surely lights cannot shine outward from deactivated visportals, because for the visportal to be deactivated, everything contained in it can't be visible to the player.

 

And if you are outside and there is one huge light lighting everything (as you described) then that would all be one visportal anyway.

[Ishtvan]

I think those huge ambient lights can still cast light even if they're outside the player PVS (i.e., separated by solid geometry or an inactive visportal).

[sparhawk]

And if you are outside and there is one huge light lighting everything (as you described) then that would all be one visportal anyway.

 

I don't think so, but I could test it. The geometry has not to be rendered, but it still needs to render it's effect, otherwise there would be no point in creating such a light. And IMO this was even used in the original maps to provide some ambience.

 

Also this would be yet another argument to not code this, because it would get more complicated again. We would have to locate and take into account the visportals as well.

[OrbWeaver]

As far as portalling is concerned, it is not the light's origin that is important but its bounding box (the pink box).

 

If ANY PART of a light volume extends into a given portal area, the light is active when that portal area is visible.

[Domarius]

So can you filter out the lights that are not active Spar?

[sparhawk]

That doesn't help much, because most lights will be active.

[Domarius]

Not the way I understand it. Only the lights whos boundaries enter the PVS will be active. On huge levels this would be a huge saving, if you didn't check every light in the level.

[DopeFishhh]

Well that would still depend on the layout of the map. Anyway if you are using the rendering engine to check the players visibility wouldn't it already do the culling?

 

And how big can doom 3 maps get? is it a hard limit or a limitation of the hardware? and could you through clever design exceed what would normally be very taxing on a system?

[Gildoran]

The main limitation that comes to mind is that you can only have about 4096 entities on the map. So a larger map may require entities to be more sparsely used, if you get near that cap.

[Ishtvan]

Anyway if you are using the rendering engine to check the players visibility wouldn't it already do the culling?

There's some confusion here, they're talking about the "mathematical" version of the lightgem where we were basically trying to rewrite the render code ourselves, because we do not have access to the renderer. They were discussing not using the render engine, in an effort to increase performance. We do indeed use the render engine to take a snapshot and analyze it for the current lightgem, but doing it that way has a performance penalty.

 

As for the 4096 entity limit, I think we have access to that limit in the SDK, and could increase it if we really wanted:

 

In gameLocal.h :

#define	GENTITYNUM_BITS			12
#define	MAX_GENTITIES			(1<<GENTITYNUM_BITS)

[sparhawk]

Not the way I understand it. Only the lights whos boundaries enter the PVS will be active. On huge levels this would be a huge saving, if you didn't check every light in the level.

 

I have thought this through in detail when I coded it, and there is no way I can determine which lights contribute, because they can be arbitrary big. There is no point in revisiting this every few months.

[Domarius]

But if Orbweaver is right, the engine deactivates lights - so you're checking them for nothing.

 

And it makes sense - doesn't matter how big a light is outside the building - if you're in a room with no connecting visportals to the outside area, you will not see the effect of the light.

[Ishtvan]

I think Spar means that because lights can be arbitrarily big, there's no easy way to check if they extend into the PVS, you have to actually check each light to see if it intersects with the bounds of the PVS.

[Domarius]

Iif you don't entirely ignore OrbWeaver; apparently D3 deactivates lights for you when they are outside of your PVS!

[Ishtvan]

Okay, but how to we detect this deactivation? Is there a boolean that's set on the SDK portion that we can access? Just because the renderengine gets info about which lights are active doesn't mean we can access that data.

[OrbWeaver]

To be honest I don't know exactly to what extent they are "deactivated" if they are in a non-visible portal zone. I was primarily addressing the question "how can a light shine through a portal behind you if the portal is closed", to which the answer is "if the light is shining through the portal, it's bounding box MUST extend into the current portal zone".

 

The code the handles whether a polygon is within a light volume may or may not take account of visportals, you would need to contact a developer to confirm this.

[OrbWeaver]

As for the 4096 entity limit, I think we have access to that limit in the SDK, and could increase it if we really wanted:

 

In gameLocal.h :

#define	GENTITYNUM_BITS			12
#define	MAX_GENTITIES			(1<<GENTITYNUM_BITS)

 

That looks worrying. If it is a bit field you cannot arbitrarily extend it since you don't know what the other bits are used for - maybe it is the lower 12 bits of a 16-bit WORD value for example, with the other 4 bits being used for something else.