So Kloot invested some time a while ago to fix what's necessary to make normal mapping possible and e.g. Argh already succeeded in actually using it. I now would like to ask for a general way of adding this effect to units. It should be possible to simply reuse Argh's shader which he also tested with both NVIDIA and ATI cards so those nuts already are cracked I guess. I'd prefer if this feature would actually get included into the engine itself rather than using Lua for it while also adding a basic LoD system that switches to the regular way of rendering units when the camera has reached a certain distance. The engine then should deliver a tag for the unit script which gives the normal map's name just as a tag to activate normal mapping for that unit so for a game developer it's just about giving Spring the needed files and it works...
As a second, minor request I'd like to ask as to where we recently are when it's about maps and normal mapping. It works in sm3 maps but completing / redoing this format seems to have little priority at the moment. I guess the smd format lacks the needed structure to "simply" plug it in like for the s3o units?
Normal Mapping
Moderator: Moderators
Re: Normal Mapping
We don't want to put it into the engine. The whole point of the UnitRendering system is to finally free us from engine constraints. If we put it into the engine, we're just going to want to replace it again pretty shortly as hardware advances... but, oops, it's in the engine, let's wait another 5 years.
The system uses tags. It's almost entirely idiot-proof. It involves one Lua file, two tags in a UnitDef, and of course you need a normalmap.
Spring supports LODs. Nobody uses them, because of the time-cost in terms of executing multiple models, and the dubious performance advantages, not because we don't have them.
SM3 maps have normalmaps, kinda, but they are still fubar, due to not using the correct lighting angle. SSMF is actually better-looking in most circumstances by a substantial margin, and performs better, too.
Moreover, with SSMF and the movement to multitextured map rendering, one of the benefits is that the stock GLSL shader can be overridden by a custom implementation, allowing maps to implement many new effects, within certain limitations (currently, the cubemap isn't being sent, so no reflections, no timehack's being sent, so no animated shaders).
We want LuaJIT to speed up the unsynced code for Unit shaders to operate as fast as possible, but that's a side issue.
The system uses tags. It's almost entirely idiot-proof. It involves one Lua file, two tags in a UnitDef, and of course you need a normalmap.
Spring supports LODs. Nobody uses them, because of the time-cost in terms of executing multiple models, and the dubious performance advantages, not because we don't have them.
SM3 maps have normalmaps, kinda, but they are still fubar, due to not using the correct lighting angle. SSMF is actually better-looking in most circumstances by a substantial margin, and performs better, too.
Moreover, with SSMF and the movement to multitextured map rendering, one of the benefits is that the stock GLSL shader can be overridden by a custom implementation, allowing maps to implement many new effects, within certain limitations (currently, the cubemap isn't being sent, so no reflections, no timehack's being sent, so no animated shaders).
We want LuaJIT to speed up the unsynced code for Unit shaders to operate as fast as possible, but that's a side issue.
Re: Normal Mapping
LuaJIT runs on the cpu, shaders run on the gpu. Once compiled they have little to do with lua
Re: Normal Mapping
No, actually a lot of load is caused by CPU-side stuff that needs to happen, per Unit. And for things like P.O.P.S., most of the real load, under most circumstances, is CPU-side.
Re: Normal Mapping
erm Argh, AF is right ...
Re: Normal Mapping
The original post, just for posterity.Argh wrote:Please don't talk about things you clearly don't understand, thanks.
Re: Normal Mapping
Well, I preferred to make that a bit softer, so "thanks".
Re: Normal Mapping
It's just cause you do it wrong. The API allows you to make it run in 100% c++ code.Argh wrote:No, actually a lot of load is caused by CPU-side stuff that needs to happen, per Unit. And for things like P.O.P.S., most of the real load, under most circumstances, is CPU-side.
Re: Normal Mapping
Check my CustomUnitShader gadget.
It's normal mapping doesn't cause any lua-callbacks, only the shark animation needs a callback to upload the current frame_num and speed vector to the gpu.
It's normal mapping doesn't cause any lua-callbacks, only the shark animation needs a callback to upload the current frame_num and speed vector to the gpu.
Re: Normal Mapping
Well, as I said earlier, it won't run Kloot's shader, so I'm rather stuck atm.
I would be more than happy to use it if that wasn't the case, but you've left me in a chicken-and-egg scenario, and since I don't know what's borked, I can't justify the time spent to return to this issue.
On the broader issue of whether LuaJIT would speed up graphical stuff done through Lua, though, the answer's "yes", and even 5% speedups would be very welcome.
I would be more than happy to use it if that wasn't the case, but you've left me in a chicken-and-egg scenario, and since I don't know what's borked, I can't justify the time spent to return to this issue.
On the broader issue of whether LuaJIT would speed up graphical stuff done through Lua, though, the answer's "yes", and even 5% speedups would be very welcome.
-
Master-Athmos
- Posts: 916
- Joined: 27 Jun 2009, 01:32
Re: Normal Mapping
Well to my mind something like normal mapping is an engine feature and should be handled by the engine. If nobody wants to do that for whatever reasons there may be I'd also be fine with a Lua solution. Still I'd then like an "official" solution that like comes bundled with Spring in terms of being an "engine feature" (and that actually would be fixed in a reasonable time frame once a future Spring version breaks something again)...
So please choose whatever widget / gadget is very good and doesn't need to include half of some game specific files in order to run at all and release it as an "official" add-on or whatever you want to call it...
So please choose whatever widget / gadget is very good and doesn't need to include half of some game specific files in order to run at all and release it as an "official" add-on or whatever you want to call it...
Re: Normal Mapping
If Lua JIT speeds up the graphical component of your code, this is not because LuaJIT improves things, but because there is something fundamentally wrong with your shader code.
Do you know why I am right Argh? Please tell me how I would get a Lua VM running on a gpu? I've never heard of a lua interpreter written in GLSL, or HLSL, or even Cg! There certainly isnt one being used in spring
Your shaders execution performance should not be tied to the lua code running on the cpu, if anything they should be self contained. The only exception being reading constants, and sicne these constants are on the GPU already, you should still have your shaders executing just as fast.
If your shaders require data be passed back and forth between the cpu and the shader a lot in such a way that performance is impacted by a slowdown in your gadgets, then your either attempting+ hefty GPGPU or you've architected your code in a very bad way.
As far as your code is concerned, theres a shader thing executing somewhere else, that you dont know anything about, and every now adn again you take a few constants and throw them in its general direction then forget about it until you need to change them.
Do you know why I am right Argh? Please tell me how I would get a Lua VM running on a gpu? I've never heard of a lua interpreter written in GLSL, or HLSL, or even Cg! There certainly isnt one being used in spring
Your shaders execution performance should not be tied to the lua code running on the cpu, if anything they should be self contained. The only exception being reading constants, and sicne these constants are on the GPU already, you should still have your shaders executing just as fast.
If your shaders require data be passed back and forth between the cpu and the shader a lot in such a way that performance is impacted by a slowdown in your gadgets, then your either attempting+ hefty GPGPU or you've architected your code in a very bad way.
As far as your code is concerned, theres a shader thing executing somewhere else, that you dont know anything about, and every now adn again you take a few constants and throw them in its general direction then forget about it until you need to change them.
Re: Normal Mapping
LuaJIT isn't going to have any effect on code that uses OpenGL
Re: Normal Mapping
But, as I've explained, it's not the shaders that are the issue. In fact, I've never said that at all.
Sure, the Lua callouts are mirrored in C++, but for a lot of things, we require logic steps along the way. It's not like we just run some OpenGL in a vacuum- these aren't tech demos, they have to be flexible and responsive to a lot of conditions. Any speedup there is a big deal, in terms of aggregate performance in a complex game.LuaJIT isn't going to have any effect on code that uses OpenGL
Re: Normal Mapping
Argh wrote:We want LuaJIT to speed up the unsynced code for Unit shaders to operate as fast as possible, but that's a side issue.
Re: Normal Mapping
I can see how you'd read it that way, but that's not what I meant.
Re: Normal Mapping
Argh, explain to me what visuals you want to do that need heavy calculation.