Author Topic: A New Lighting System that runs as an addon.  (Read 2260 times)

Sort of how we got Static Maps, the alternative save system...why not make a new lighting system that runs as an addons.


Sort of how you enable say...System_NewLighting and that whenever you spawn a light it runs like that instead of the default lighting system, if this is even possible.

Either ways possible or not, I feel this has to be possible somehow, regardless of how hacky it can be.

So you mean dynamic lights that cast shadows or something?

static maps is literally just loading in raw .dts shapes like old v0002 days to create environments (which was intentionally abandoned for fxDTSBrick because it sucks on a large scale)

we are not superheroes and we cannot use magic mind wooblers to erect entirely new rendering concepts to the engine (besides through what can be done with shaders). torquescript cannot do this any reasonably non-ridiculous way

static maps is literally just loading in raw .dts shapes like old v0002 days to create environments (which was intentionally abandoned for fxDTSBrick because it sucks on a large scale)

we are not superheroes and we cannot use magic mind wooblers to erect entirely new rendering concepts to the engine (besides through what can be done with shaders). torquescript cannot do this any reasonably non-ridiculous way
Its ok, and to be more specific I meant a lighting system that is extremely similar to the one currently in use, however it works in a way that allows handling more than 9 lights(I think thats the limit?)

Its ok, and to be more specific I meant a lighting system that is extremely similar to the one currently in use, however it works in a way that allows handling more than 9 lights(I think thats the limit?)
It's 9, but the sun counts as 1, so it's technically 8.

Its ok, and to be more specific I meant a lighting system that is extremely similar to the one currently in use, however it works in a way that allows handling more than 9 lights(I think thats the limit?)
that is an opengl limitation and, again, we are not wizzards that can zap in engine code

well i mean we can be but that's obviously frowned upon cus of the massive abuse potential

that is an opengl limitation and, again, we are not wizzards that can zap in engine code

well i mean we can be but that's obviously frowned upon cus of the massive abuse potential
Damn if only we still had Direct 3D...wait nvm it was more outdated...but what if we had DX10 or DX11 Support?

Damn if only we still had Direct 3D...wait nvm it was more outdated...but what if we had DX10 or DX11 Support?
if you're talking about engine changes it would likely be easier to just implement the improved lighting you're talking about than write entirely new rendering methods

directx support was intentionally removed for being dumb

It's technically 9, but the sun counts as 1, so it's 8.
fixed

I mean, it would be great, but yeah no that's impossible.

Essentially the main reason for the light limit was that Badspot decided to manually unroll the light calculation loop in the fragment shader files. You could have virtually any number of lights (as large as you wanted to make the light data array) if that wasn't the case.

Essentially the main reason for the light limit was that Badspot decided to manually unroll the light calculation loop in the fragment shader files. You could have virtually any number of lights (as large as you wanted to make the light data array) if that wasn't the case.

why this, it looks very ugly with this limit

why this, it looks very ugly with this limit
He's stated before that a more dynamic approach led to goofy-looking cutoffs in light sources.

I'm making a thread about Direct X support considering that can improve multiple things.


Locking.