Serious Problem with Point Lights!!!
Blitz3D Forums/Blitz3D Programming/Serious Problem with Point Lights!!!
| ||
| In every sdk I have used, the radius of point lights = the END of the light falloff. In blitz this isn't the case, and even a tiny radius will go on and on, way beyond the radius. This makes DX light-reuse techniques virtually USELESS in blitz3d. I will have to move to another language to solve this issue if a solution cannot be found!! I believe it's a bug as well the radius should equal the limit of the light's effect It DOES EVERYWHERE ELSEWITH GOOD REASON and that reason is LIGHT RE-USE! Ion. |
| ||
| hmm, it seems to work when I export lights from 3dsmax with pipeline using inverse falloff and start range as the range the lights don't seem to be infinite. We had the same problem your discussing in Aerial antics thoough which were done in code. I wonder what the difference is? I havent checked that the lights truly disappear but when I use pipeline I do get a correct falloff which matches what isshown in the max viewports. An example of it in use can be seen in market value where the red flashing light at the end of the timer flashes with a short range at the end of each round. The falloff is clearly visible as it only reaches about halfway across the gameplay area and doesn't light all the gameplay pieces on the board. Actually just realised I have a screenshot on our web page of the light I'm talking about  if you look at the TV's you can clearly see the falloff working (only the ones closer to the point light are lit) If you don't use pipeline it might be worth asking pudding, or checking out the extensions and seeing how exactly the falloff ranges are being read from max. |
| ||
| Yeah, I can remember SSwift having something to say about this a while back. With Blitz, the radius is the point at which the falloff begins, not ends. No idea why, but as you say, it's not the case with pretty much every other SDK. |
| ||
| Make sure you have turned off ambient lighting, otherwise your whole scene may be lit to the point you can not make out your point light or where it ends. AmbientLight(0,0,0) Point lights DO work (I just double checked), but as Sybixsus mentioned, the LightRange is the start of the falloff (and yes, I learnt this from sswifts shadow system). So, you have to experiment a bit to get it right, but it does work. Hope you get it sorted Ion-Storm :) |
| ||
| You can specify a max light range in code, but it does mean hacking the light structure, which does expose this parameter (or at least it did in 1.87). Easy enough to do but probably a bit of a last resort though, so maybe a feature resquest for an appropriate function would be worthwhile, and maybe one that also gives extended control of the other attenuation parameters (specifying a LightRange is a simplification of these), not I suppose they would be used much, but in for a penny... |
| ||
| I don't understand why you're asking for this. That is... I don't understand how being able to limit the falloff of a light will imrpove the situation any. The problem as I see it is that you only have X number of hardware lights, and if you add any more than that then those lights won't affect an object. I'm not sure if Blitz chooses the X hardware lights closest to an object and uses only those, but when you're talking about a level that's a moot point if the level is all one object everywhere, like a big terrain. It seems to me that there is a deeper problem that can't be solved by just changing the falloff. If I was going to try to get lights to work better in Blitz and couldn't muck about with internal strucutres or DirectX hacks, then what I would do is first consider what needs to be lit. And the answer to that is only stuff that is close to the camera, because that's all that can be seen at a particular time. So what I would consider doing is making a system which calculates the X closest lights to the camera and enables those and disables all others. Furthermore I might go so far as to make lights fade out as I walk away from them so that I don't have lights on in the distance which might be turned off suddenly when I run out of lights after using them for what is up close. Of course this solution might not fit your specfic case. I'm not sure exactly what you are trying to accomplish and whether or not changing the falloff would help with that. But if what you are worried about is turning off lights suddenly and seeing that affect the local objects, then you could possibly help that by forcing lights to fade out before they are turned off, and/or altering the lights falloff parameter as it receedes from the camera. I dunno if that'll be of any help to you, but that's all the ideas I have for improving the lights with what you're given in Blitz. |
| ||
| I don't think it's a strange request. He just wants to control how far a light will shine. By the way you can enter negative values for the range to reduce the length. |
| ||
| "He just wants to control how far a light will shine." Not so... He also said: "and that reason is light re-use!" He doesn't jsut want to control light falloff for aesthetic reasons, he wants to control it in some way which he thinks will allow him to, in effect, use more lights in his app. |
| ||
| @Sswuift I already try to create more than 8 lights and move their. Blitz manage the light with a 'list' if you destroy a light and you have create more than x, it's new light after 8 is create automaticly, you have nothing to do .. |
| ||
| Hi. Phil your correct, sswift, Let me explain further.. I am already sorting lights but because blitz light falloff goes on for nearly forever.. It makes light re using in this manner very problematic and it should be fixed so falloff is the end of the light. I hope you can undertand. Thanks. |
| ||
| Just a thought Can you create more than 8 even if the others don't work? Does HideEntity, ShowEntity make the 8 that are showing work? |
| ||
| Another thing, 8 lights can be slow. Would fake lights work? I'm also thinking, If you're doing a space shooter, that you could make some interesting quad filter effects for lights. I wonder if you placed a geosphere around an object with a filtered texture aligned to the light sources. sort of a reverse environment effect. |
| ||
| I don't see what the problem is really, since you can dynamicly trigger the nearest #of lights in your scene if you like. Did that in Aerial antics. At the time we didn't know how to control the falloff so visually it was a bit weird as we had wll over 8 lights and they would keep switching on and off as you passed through the level. But it shoudl be a piece of cake now. since if it's not visible you shoudln't need to have the light on at all. One thing I'd like to have is the ability to have the lights only effect meshes that you want them too. So that only animated objects that move through a level are lit. |
| ||
| hmmm..Evak I was only just today thinking the same thing about how to limit lights to certain objects only!!...Would one of those crazy 'render this then render that next' routines do the job? Uh - also has anybody tried a minus falloff value?...as the falloff is not strictly working logically this may work. However to get around my problems of overlapping fallofs that switch on and off I rigged the lights to adjust their brightness depending on player distance - it was a less noticable problem then. |
   |