Light Range is messed up

Blitz3D Forums/Blitz3D Programming/Light Range is messed up

xmlspy(Posted 2006) [#1]
Hey, I just noticed that the light range is not like the docs say

The range of a light is how far it reaches. Everything outside the range of the light will not be affected by it.


I have set my range to be 5, however I'm at about 20 units away from the light source and I'm still getting light. Anyone notice it?


Bobysait(Posted 2006) [#2]
You'd better read the whole doc !
=> "The value is very approximate, and should be experimented with for best results"


xmlspy(Posted 2006) [#3]
15 or more units away is not an "approximate" I am using a point light.


Bobysait(Posted 2006) [#4]
lightrange can be altered by ambientlight, as lightrange is really approximate and not really easy to view in realtime !
Sometimes , you 'll have vertexlightning on mesh and the light is 100 units distant, and lightrange setted to 10 .

I think, LightRange is a factor, maybe not a real distance,and that fallof at Range distance.
But you're right, it's not clear.


Mustang(Posted 2006) [#5]
There was a discussion about lights year or two ago... the formula is such that light falloff really never goes to zero. And this is DX "problem", not Blitz3D:


"At least that's what it does in C++/DirectX and the Blitz Docs state..."

The Blitz docs are wrong, and Blitz's lights work just like DirectX. I know this for a fact because I researched it thouroughly when developing my shadow system after I noticed that my shadows were not matching up with the falloffs of the hardware lights which were illuminating the world.

Here are the comments in my shadow system on the whole thing about how the lights work. And this is based on information straight from Mark, and the Direct 3D docs, and asking other 3D programers on Flipcode.

; DX7 Lighting equation:
; Attenuation = 1.0 / (C0 + C1*D + C2*D*D)
;
; In Blitz:
; C0,C2 = 0. C1=1
;
; So the revised lighting equation is:
; A = 1.0 / D
;
; With this equation, when D=1, A=1.
;
; Now in Blitz, a light has a radius, which defines where the light BEGINS to fall off.
; At this radius, A will equal 1.
; Inside this radius, A is greater than 1, reaching infinity when D = 0.
; Outside this radius the light falls off exponentially.
;
; So we change the equation to read like so:
; A = R / D
;
; And then all we need to do once we calculate A is multiply the light's color by it, and we get the
; color of our vertex at a distance of D.
;
; It is interesting to note that multiplying the light's color by a factor equal to the radius will
; give us the same results. That means that rather than thinking about radius as a mininium radius at
; which the light is fullbright, you can think about the radius as a brightness mutliplier instead.
;
; However, it is more useful to consider it as the radius inside of which the light is fullbright.


"The value is very approximate, and should be experimented with for best results."


Yeah I'll say it's very approximate. It's off by like 5000 units! :-)



"There appears to be a cutoff point, above which hardware lights give a very slight performance hit"

That drop there was just caused by the fact that 1000fps means each frame takes 1ms, and 500fps means each frame takes 2ms. Not a cuttoff point. Just the fact that your millisecond timer isn't precise enough to see the difference between the first two. The second is probably like 750fps but you cna't have 1.5ms.



"How do hardware lights work?"

http://www.blitzbasic.com/Community/posts.php?topic=25291


Danny(Posted 2006) [#6]
Subdividing your model can help in some cases. This won't 'fix' the range issues (as clearly pointed out in previous post) but can help create a better fall off.

If you for example have a 50 meter long corridor, subdivide it in 5 meter sections. Yes, this will add more poly's but when balanced properly often gives slightly better lighting results....

Vertex lighting is a much better option, and better control over exact ranges, etc.
D.