light problem

i have a light problem, i can only have 9 lights in 1 sceen, if i have 9 lights in a sceen and add 1 light one of the other light get dark, is taht a known bug :frowning:

##i have blender publisher 2.25

No, itā€™s a feature. :-? Most OpenGL implementations only allow 8 lights. Itā€™s somehow a legacy thing.

mmm, thats not good :expressionless:
ok, thank you for posting so fast kEinStein [!]

is there a way to change this ā€˜featureā€™ :wink:

Hey Nor.J, nope I donā€™t think so. But you can make shadows and lights without realtime lamps.

  • make a map
  • place lamps
  • hit an button somewhere in the edit buttons
  • you will notice you see the map turned shaded.
  • remove lamps and place them where you want to show the models that arenā€™t static like character, be shaded with light.

I thought z3ro_d explained that, itā€™s mist be somewhere in this topic. :slight_smile:

ā€˜VertCol->Makeā€™ in the edit buttons. :wink:

[quote=ā€œkEinSteinā€]

ā€˜VertCol->Makeā€™ in the edit buttons. ;)[/quote]
yeah, thank you, but in this situation i need static light :wink: ā€¦
well, then i think i know what i wanned.

only 8 static lights at the time(but i can have 9 lights thoā€¦ lol :wink: )
but use VertCol to have fake lights(sort of l0l)

ok thanks againā€¦

You can have as many lights as you want (well I suppose there is a practical limit somewhere in the code) but only 8 will show up. If you create 9 lights, the 1st one you created will not illuminate anything.

I remember looking this up beforeā€¦wasnā€™t that an openGL thing that was changing? I recall someone mentioning that newer versions of openGL would have more than 8ā€¦maybe Iā€™m just imagining things :-?

Yep. The reason is that (not so) early SGI hardware was only able to do 8 light sources in hardware calculation - the rest had to be done in software, which was really slow - I guess other OpenGL implementations just limited it for the same (or compatibility) reasons. shrugs

The number of lights depends on your graphics card. All OpenGL implimentations support at least 8 lights. (Even my crappy Intel card supports 16.)

I think Blender just uses a maximum of 8 lights without actually checking how many are available. This makes it more compatible with older cards, but doesnā€™t use the full potential of newer cards.

ok, Thats good, so if i make a game, then all the other people will see the game exact as i made it(withe lights) :slight_smile:

ok, Thats good, so if i make a game, then all the other people will see the game exact as i made it(withe lights) :)[/quote]

Nooā€¦ I said Blender does not check if more lights are actually available on the hardware, it just assumes an 8 light limit and ignores any extra lights.

Although this is annoying for people whoā€™s hardware supports more than 8 lights, it guarantees the game will look exactly the same on older hardware that really does have an 8 light limit.

It seems that blenderā€™s game engine really needs some new features. Maybe a complete new lightning system, advanced physics, like enabling ragdoll physics, culling and a lot of speed increase. If I was a guru at coding, I really would do this all right now to code such systems. Iā€™m still learning more python and such, but I doesnā€™t look like I can do that within 3 years. :frowning:
Is there really no one that could make the game engine a lot better by hardcoding some new features in it?? :-?

I can agreeā€¦

such as?

uhh, I would argue it is possible now with python. I havenā€™t really got started yet, and will not spoil my technique for a week at nleast.

certainly portal culling, but bsp and similar methods are not possible without restrictions on the environment or long calculation time

where is blender slow?

actually, I can answer that, drawing takes a lot longer than it should for a few reasons. 1: textures are sent to the graphics card in real colors, even if they are indexed, and 2: the draw order is not likely near to far to allow the zbuffer to do its thing, and relive the graphics card of drawing over one pixel several times

the blender source is pretty daunting, Iā€™m trying to get into it

I think a lot of the game engine stuff needs to be rebuild in the back end. Logic bricks are nice, but everything else I find a bit awkward. That isnā€™t to say you canā€™t do a lot of things, but material settings, dynamic settings, python api and the like could do some work.

there are trivial graphics improvements I would like to see, and some that would require some thought (what would the interface to a means of multitexturing look like? how would it be implemented? would we still be limited to 1 uv coord per vert in a face?


back on the topic:
I guess I have nothing to say, time to figure out how exactly ghost and blender handle user input so that I can put a breakpoint on the line of the release of the middle mouse button for panning the 3d window to see which call takes so longā€¦


other engines I know of never have more than 8 hardware lamps on a mesh, it is never a necesity [humans will not notice much], and for the rest it can be approximated with another texture or some tweaking of vertex colors. [lighting does put demands on the graphics cards too, more lamps are slower]

so, the area the character is in specifies the location and direction on lights on it. If there are more lights than that that need to be on the character, the rest are summed in some manner and approximated. Unfortunately I donā€™t see an ideal way to do this in blender, but I havenā€™t looked much

You can use 8 Lamps for each Layer. Your Scene has 20 Layers ā€¦ that makes 160 Lamps per Scene! I think thatā€™s enough.
Convert the Lamps to VertexColors, and You can use as many Lamps You want per Layer!
Doc

but if you ahve overlay sceens it just mes up the lights :wink: