Author Topic: ok so go over again why we can only have a tiny amount of lights viewable??  (Read 1825 times)

OpenGL is a graphics API.
hmm. ok. but it feels weird to call it that, for me anyway, cus of the way I see API used, like, in the context of websites like imgur or whatever, specifically
whatever though
is it possible to change rendering clientsided?
all rendering is on the client side. and some people like port have managed to change things about the way it renders
but idk about stuff like lights

hmm. ok. but it feels weird to call it that, for me anyway, cus of the way I see API used, like, in the context of websites like imgur or whatever, specifically
whatever though

In computer programming, an application programming interface (API) specifies how some software components should interact with each other.

In computer programming, an application programming interface (API) specifies how some software components should interact with each other.
yes. I know what API means
I probably just don't know what openGL is (and saying it is an API will not be helpful)

OpenGL is what makes rendering stuff easy:

Code -> OpenGL -> amd or nvidia drivers -> hardware

it's kind of like a high level language compared to assembly

its the gay brother of directx

its the gay brother of directx

stop right there criminal scum


Sun.delete();

Oh look. No more sun.
Wh-

What have you done?! *freezes*

Badspot

  • Administrator
In fixed function openGL, you can only have 8 lights.  You can get around this by setting up different lights for different pieces of geometry before you render them - we tried this and it works, but you get all sorts of ugly splits in the lighting where it changes from one chunk of a build to another.  Also the overhead of searching for nearby lights starts to add up - the data structure might have to be refined or replaced.

With shaders, we're calculating our own lighting values with some vector calculations.  So you can theoretically have as many as you want to calculate.  The problem is glsl shader compiling is done by the driver, so the compatibility between cards is stuff.  It took quite a bit of fiddling just to get something that would work most places, including some insane stuff like the unrolled lighting array because some drivers just can't do arrays or loops for no reason.  

I'd have to make a script that would piece together the shader based on your settings and what kind random failings your card/driver has and that sounds like a big pain in the ass.  

In fixed function openGL, you can only have 8 lights.  You can get around this by setting up different lights for different pieces of geometry before you render them - we tried this and it works, but you get all sorts of ugly splits in the lighting where it changes from one chunk of a build to another.  Also the overhead of searching for nearby lights starts to add up - the data structure might have to be refined or replaced.

With shaders, we're calculating our own lighting values with some vector calculations.  So you can theoretically have as many as you want to calculate.  The problem is glsl shader compiling is done by the driver, so the compatibility between cards is stuff.  It took quite a bit of fiddling just to get something that would work most places, including some insane stuff like the unrolled lighting array because some drivers just can't do arrays or loops for no reason. 

I'd have to make a script that would piece together the shader based on your settings and what kind random failings your card/driver has and that sounds like a big pain in the ass. 

okay. thanks baddy. maybe one of the users could make something if they had the time.

locking.