LightStateCreator seams random

Everytime I call resortLightsFor() for a Spatial the result looks different. How come?

Err, that LightStateCreator class is actually quite strange. I think it does not currently make any sense what it does actually :-o (Sorry Badmi)

There is a method named quickSort that does not quick sort (not even sort). Additionally that 'sort' is not stable - that's why you get different results each time, Rik.

Guess someone needs to reimplement that sorting…  :expressionless:

Thanks, I could have lost alot more time trying to figure it out.

How would one go about to find out which is the most relevant light for a spatial?

LightStateCreator is designed to overcome the 8 light limits by finding the 8 closes lights and attaches them to the spatial. Basically it would come in handy when you have a dynamic program with many lights and Spatials.

The code was designed to put speed before accuracy. It was much more important the sorting function gave a quick answer then a perfectly correct answer. It was also meant to only be called once every few frames in updating spatials. The lights therefore did not have to be the same each time they were sorted.

The code fulfils the objectives that it was designed for. I spent a large amount of time using test program to verify that it was working correctly. If you look at the lights in the program you will fined that the spatals are lit, for the most part, by the nearest lights.

That being said if you tell me the specific problems you have with the LightStateCreator, tell me and I will try to fix it.   

Hm, for how many light did you intend this class to be used Badmi?

jME can sort several thousand trimeshes each frame and still get decent FPS. I think it could handle a few lights… just implement a Comparator and use Arrays.sort . It uses some pretty damned fast (and stable) merge sorting. Or you could make it an option…

I applied the LightStateController on some objects, all individual lightstates. I must have done something wrong because the results can’t be this different?:

I made my own really ugly sorting method using java.util.Vectors and stuff (I’ll optimize it later }:-@), also based on the distance between the spatials boundingvolumes center and the light positions. It returns a correct result and doesn’t seem to affect the fps.

It also has an option that could be very useful: max lights per spatial. Haven’t tried it so much but it could help keeping the fps up. This way you can have as many lights as you want in the scene but only say 4 per spatial. If you use (like me) many similar lights in the scene to create an even light perhaps each spatial doesn’t need to be lit by 8 lights.

Making my own sorting method, I had some trouble with the boundingvolumes center being local, returning a wierd result when calling the distanceTo method. I solved it by first calling updateGeometricState on the spatials. I makes me think I should have done that while using LightStateCreator .

I think it works quite well using the distance to the light to judge it worthy of attachment to my spatial but there must be some other aspects that could be taken into account? Any ideas?

Yeah that sort seems to be a little too unstable… don't you agree Badmi? :smiley:

Maybe direction? When the lightsource is occluded by the Spatial, then you won't see any of the lighting on that object. However, occlusion testing isn't always simple or fast…

llama said:

Yeah that sort seems to be a little too unstable.. don't you agree Badmi? :D

I am working on stabilizing the code, and have maid some progress but it may take some time.

Occlusion testing would probably be two slow for some games. We can always create a class that overloads the

I fixed that sorting by using Collections.sort. It is stable now and is even faster than before.

thank you irrisor.  :slight_smile: