Where Tds Went Wrong

[sparhawk]

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.

 

This is definitely wrong. You can easily verify it yourself. Create two rooms which are not connected at all and then create a big light that covers both. If you switch off the shadow casting for the light, both rooms are lit, which is exactly the reaons why the lightgem can NOT simply switch off at some point, because a light can cover the entire level (in theory) if it makes sense.

[sparhawk]

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

 

If you would IGNORE Orbweaver and ask the only authorative source, then you would already see that this is WRONG!!! Just try it for yourself. Doom 3 is the final authority on what it can do or not, so stop posting theoritcal considerations and go try it.

[sparhawk]

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.

 

The bits are only to ensure that it is a power of 2 number and not some arbitrary value (like 666). Maybe there are some optimization in the renderengine based on power of two numbers.

[Ishtvan]

Yeah, I could be wrong, but I wouldn't say GENTITYNUM_BITS is part of a larger bitfield.

[OrbWeaver]

The bits are only to ensure that it is a power of 2 number and not some arbitrary value (like 666). Maybe there are some optimization in the renderengine based on power of two numbers.

 

If that is the case, then it would be dangerous to increase the number of bits without access to the render code. If the number is significant and it is increased, this could cause performance drops or even unresolvable bugs down the line.

[Domarius]

If you would IGNORE Orbweaver and ask the only authorative source, then you would already see that this is WRONG!!! Just try it for yourself. Doom 3 is the final authority on what it can do or not, so stop posting theoritcal considerations and go try it.

Hey I kept asking about this and I kept getting ignored. Thanks for finally answering though.

 

Don't all lights have a bounding box that defines the extent their light reaches?

 

Can it then be possible to detect what visportals they intersect, and then store that information during map compile time?

[sparhawk]

If that is the case, then it would be dangerous to increase the number of bits without access to the render code. If the number is significant and it is increased, this could cause performance drops or even unresolvable bugs down the line.

 

If that value would have been fixed, they would not have included it in the SDK. We should assume that we can change everything, what is contained in the SDK, otherwise it doesn't make sense to include it in the first place. At least if this would be so important, then I would expect a comment to say so.

[sparhawk]

Hey I kept asking about this and I kept getting ignored. Thanks for finally answering though.

 

I didn't know ith either, but I finally simply TRIED it.

 

Don't all lights have a bounding box that defines the extent their light reaches?

 

Lights don't have a bounding box. They have a box, but it defines how big the light is. This is not used as a bounding box though.

 

Can it then be possible to detect what visportals they intersect, and then store that information during map compile time?

 

Forget it. I already explained that the lightcaclulation is inherently flawed if you try to recode it unless you recreate the entire system invovled with light manipulation. You can specualte about ever increasing detailes, but this wont change.

[Domarius]

When Renz was placing lights, he showed me how he made sure their bounding boxes never intersected so that the actual lightwaves never crossed, since overlapping lights increase performance.

 

I was thinking that if this same bounding box information was present at runtime, you could use it in the way I described. Is it not acessable?

[sparhawk]

I don't intend to go in circles. I already explained that lights don't have bounding boxes in that sense, even if you refer to them as such (doesn't really matter much). If you want you can take a look at the weak lightgem code to see what it does.

[Domarius]

Don't see this as challenging your code, I'm just trying to understand, sometimes it helps to have other people thinking about things.

 

Renz told me the bounding boxes were the actual range of the light. When you resize the box bigger, the light travels further. I naturally expect this info to be available at runtime since the game must use it.

 

If it's hidden away in the rendering code, and inacessable, I can understand that.

[sparhawk]

I don't see it as a challenge, but it gets tiresome because I explained this already, and I'm pretty sure that I considered everything. And I'm well aware that I can access the 'bounding box' of a light, but as I already said, this doesn't help a bit, because rewriting the light calculation is an inherent problem and no amount of optimization will change that.

[Domarius]

Do you need to know the actual distance of the light, or wether or not its light range reaches the player?

 

If you actually need to know the distance of something, bounding box collision is no good, but if you just need to see if the bounding box of the light overlaps the player, this would be faster than a distance check.

[sparhawk]

The distance check is faster, because otherwise the check is much more complicated. For the actual calculation the distance is irrelevant because I need to calculate the intersection of the lightcone with the player to get the coordinates of the falloff texture.

 

To properly calculate the lightvalue, I would then have to loop over the intersection are of the player, and calculate the average. I didn't implement this anymore though, because it will not work anyway. In order to get the correct values, the animation also would have to be taken into account. Once we have the sourcecode this should be easy, because we could preserve this information somehwere, but currently this information is lost, and we would have to reconstruct it, which means, that we would have to implement the full lightscripting language. So we would need a parser for that, and then we would need to run it in sync with the engine to ensure that it returns the same values as the renderengine would. Of course it is possible, but it would be a lot of overhead. In the end it would not even be faster, because it also would need to do object culling to determine wether parts of the players are in shadow or not. It means that we would have to write our rendercode just to get at the value. And this doesn't even include light effects resulting from particles, so it would get more and more complicated and the endresult would be, that we wont even need Doom 3 anymore, because we already would have rewritten a big chunk of the renderengine.

[Domarius]

So the biggest loss is due to animated lights?

 

I'm really thinking about the "have to check ALL lights in the level" part, because this means the check will be increasingly slower depending on the size and complexity of the level.

 

This may still be irrelevant, but what if we made our own light entity that inherits a real Doom 3 light, but also provides the additional information we need to cull out the lights that don't affect the player?

[sparhawk]

I don't get it. You seem to discuss this as if the lightgem were still under development. It isn't. Unitll we have access to the renderengine this topic is closed and doesn't need to be performance optimized, because there is nothing to optimize.

[Domarius]

I was just offering suggestions, because we don't really know how long we'll have to wait for access to the render code.

[sparhawk]

I already said that such suggestions are useless because we are not even using that code anymore and we are certainly not rewriting it again and again.

[Domarius]

This optimisation can most likely help avoid checking every light every frame;

http://forums.thedarkmod.com/index.php?s=&sh...indpost&p=49600

(This is an anchored link, let the page load completely so that it auto-scrolls down to the relevent post.)

 

In this thread you said you would check it out, what do you think of it? I don't think you really need to read the doc - just the post I made, to get the gist of it. I think the doc might have useful equasions though.

[Ishtvan]

I think the point is it still won't be able to read off animated textures or take into account objects blocking the light cones, so its accuracy would be limited to unacceptable levels.

[New Horizon]

I think the point is it still won't be able to read off animated textures or take into account objects blocking the light cones, so its accuracy would be limited to unacceptable levels.

 

Indeed, the current lightgem is damn near perfect.

[Domarius]

All I know is that its checking every light in the level, that is a big problem IMO because as the level size increases, so does the load on the lightgem code. The size of a game level shouldn't impact the framerate like this because the culling techniques avoid doing things that don't matter.

 

This is a way of culling out the lights that don't matter.

 

I'm not concerned about any other aspects such as animated textures, I'm sure Spar will find a way around that. I'm just focusing on the "every light in the level check".

[New Horizon]

All I know is that its checking every light in the level, that is a big problem IMO because as the level size increases, so does the load on the lightgem code. The size of a game level shouldn't impact the framerate like this because the culling techniques avoid doing things that don't matter.

 

This is a way of culling out the lights that don't matter.

 

I'm not concerned about any other aspects such as animated textures, I'm sure Spar will find a way around that. I'm just focusing on the "every light in the level check".

 

Will it really make a huge impact on performance to do this though? My system is fairly low end by todays standards, but I only see an increase of maybe 1 frame/ second when I switch the lightgem off.

[Ishtvan]

All I know is that its checking every light in the level, that is a big problem...

 

The old method is actually checking no lights right now, because that method isn't used anymore. Sparhawk tried for months to match what D3 was doing with shaders and animated textures, but he's said we can't do that without access to the renderer code, or rewriting the renderer ourselves, and I'm inclined to believe him. He did find a way around it with the render snapshot though, which is 100% accurate, thus rendering the old method obsolete and no longer used.

[Domarius]

@NH - as long as some sort of load increases with the level size, your computer will slow down the bigger the level gets. Ideally, the size of the level should have almost zero impact on the performance since the culling techniques deactivate anything that's not being used. To the best of my knowlege no one has made a fully fledged Thief 2 style DarkMod level yet with all the lights they will require. And of course this is without AI and other workload that we haven't even made yet. So your frame rate experiment doesn't show much at this stage.

 

@Ishtvan - Are you saying the render snapshot method doesn't check every light in the level?