new shader based InfoTexture (faster, shinier & modular)
Moderator: Moderators
new shader based InfoTexture (faster, shinier & modular)
Last edited by abma on 04 Jan 2015, 20:57, edited 3 times in total.
Reason: changed topic title
Reason: changed topic title
Re: cookies! now!
So what does this mean?
Re: cookies! now!
That means, that you have bitmaps available as shadder programmers that contain the info on Metallmap, Los map and so on and so forth.
Basically another big step to unroot graphicsstuff from enginecore..
Code: Select all
//Heightmaps as texture
shaders/GLSL/infoHeight.lua
//LineOfSight as texture
+ shaders/GLSL/infoLOS.lua
//metallmap as texture
+ shaders/GLSL/infoMetal.lua
//pathing map as texture (dont know if unit dependant)
+ shaders/GLSL/infoPath.lua
Re: cookies! now!
It's even a bit more than just that.
It's a total rewrite of how the infotexture works. Before all data was generated on the CPU and then send to the GPU to render it. Pako already noticed that the interpolating/upscaling of the los data on the cpu is slow as hell and that uploading the raw data in unprocessed to the GPU and upscaling it there would be much faster.
This new infotexture system is now a rewrite with modern rendering in mind (do as less on the CPU and do as much on the GPU with as less sync points as possible).
So all data in the infotextures is now separated and gets their own textures (and cpp-file). So there are textures for los, airlos, radar+jammer, metal-distribution, metal-extraction, path, height ... and all those are available to lua via i.e. gl.Texture("$info:los"). And in all cases it's optimized for optimal upstream performance (reduce CPU time as much as possible), so the data is often uploaded as total raw data (comparable with a memcpy instead of a for-loop), and when there is a processing needed (scaling into 0..1 range) it happens on the gpu.
So the new system takes the ~same load as the old one, but updates all infotextures continuously even when not selected right now (so lua can access it for example). Meaning the LOS view is now realtime and gets updated with 30Hz.
The final infotexture views (F1, F2, F3, [L]) are now merges of all those subtextures, for that there is a "Combiner" infotexture. But instead of hardcoding those views, even that stage is totally modular. So there are new `lua-shaders`: engine loads a lua-file which contains all shader stages, uniform data AND texture bindings.
So the shader defines the final result you see and you can mix any textures you want.
As an example the los view:
https://github.com/spring/spring/blob/d ... nfoLOS.lua
Also it allows to post-process the texture data (so the data isn't just upscaled, it's smoothed) and to add blending effects.
For the future even lua infotextures are planned, so you could register a luaui texture and then access it via gl.Texture("$info:myluainfotexture"). This way e.g. you could code in lua a dominance map where terrain gets teamcolored and then use the engine's infotexture infrastructure to bind that new view to F2.
It's a total rewrite of how the infotexture works. Before all data was generated on the CPU and then send to the GPU to render it. Pako already noticed that the interpolating/upscaling of the los data on the cpu is slow as hell and that uploading the raw data in unprocessed to the GPU and upscaling it there would be much faster.
This new infotexture system is now a rewrite with modern rendering in mind (do as less on the CPU and do as much on the GPU with as less sync points as possible).
So all data in the infotextures is now separated and gets their own textures (and cpp-file). So there are textures for los, airlos, radar+jammer, metal-distribution, metal-extraction, path, height ... and all those are available to lua via i.e. gl.Texture("$info:los"). And in all cases it's optimized for optimal upstream performance (reduce CPU time as much as possible), so the data is often uploaded as total raw data (comparable with a memcpy instead of a for-loop), and when there is a processing needed (scaling into 0..1 range) it happens on the gpu.
So the new system takes the ~same load as the old one, but updates all infotextures continuously even when not selected right now (so lua can access it for example). Meaning the LOS view is now realtime and gets updated with 30Hz.
The final infotexture views (F1, F2, F3, [L]) are now merges of all those subtextures, for that there is a "Combiner" infotexture. But instead of hardcoding those views, even that stage is totally modular. So there are new `lua-shaders`: engine loads a lua-file which contains all shader stages, uniform data AND texture bindings.
So the shader defines the final result you see and you can mix any textures you want.
As an example the los view:
https://github.com/spring/spring/blob/d ... nfoLOS.lua
Also it allows to post-process the texture data (so the data isn't just upscaled, it's smoothed) and to add blending effects.
For the future even lua infotextures are planned, so you could register a luaui texture and then access it via gl.Texture("$info:myluainfotexture"). This way e.g. you could code in lua a dominance map where terrain gets teamcolored and then use the engine's infotexture infrastructure to bind that new view to F2.
Re: cookies! now!
So significant speedup as candy on top?
You are killing us via diabetus mellitus..
:)
But having those textures available in shadders will be neat..
I for once find the idea of a geo-logical shadder
Basically display metall like they allready do oil- and other ressources today- lots of transparent layers and 3d modells made by extrusion from the metallmap..
Neato
You are killing us via diabetus mellitus..
:)
But having those textures available in shadders will be neat..
I for once find the idea of a geo-logical shadder
Basically display metall like they allready do oil- and other ressources today- lots of transparent layers and 3d modells made by extrusion from the metallmap..
Neato
Re: cookies! now!
is this possibly going to be a problem for low end systems with those cheap GPUs that simulate stuff on the CPU? (or did get get even this wrong?)
just thinking about the real-time updating you mention.. that is synced, right? so has to be done by all participants in a game.
... but of course.. cool shit!
just thinking about the real-time updating you mention.. that is synced, right? so has to be done by all participants in a game.
... but of course.. cool shit!
Re: cookies! now!
I think "physical" los maps were updated per-frame anyway. You can see this in older versions with fast units moving into range at which they can see enemies. Enemies do not wait for the visual LoS texture to update, they frequently appear on "dark" tiles.
Anything uploaded to shader is almost by definition unsynced (but can be based on sync data).
I was unable to find a sufficiently great cookie. I'll keep looking.
Anything uploaded to shader is almost by definition unsynced (but can be based on sync data).
I was unable to find a sufficiently great cookie. I'll keep looking.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: cookies! now!
200,000 cookies. (And some railways tracks, modern art...)
Re: cookies! now!
Thought it was awesome work then read
Squeeeeeeee!
At which point I totally lost control and squeed.For the future even lua infotextures are planned, so you could register a luaui texture and then access it via gl.Texture("$info:myluainfotexture"). This way e.g. you could code in lua a dominance map where terrain gets teamcolored and then use the engine's infotexture infrastructure to bind that new view to F2.
Squeeeeeeee!
Re: cookies! now!
Nice!updates all infotextures continuously even when not selected right now (so lua can access it for example).
-
- Posts: 98
- Joined: 22 Sep 2014, 20:29
- Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
Re: cookies! now!
Should have said "to Spring engine."www.fortunecookiemessage.com wrote:You have a flair for adding a fanciful dimension to any story.
Re: cookies! now!
@jk:
wow, sounds awesome! nice refactory/new feature!
whats your address/which cookies do you like? :D
wow, sounds awesome! nice refactory/new feature!
whats your address/which cookies do you like? :D
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: cookies! now!
Is there a way to make the previous view disappear faster? I am asking for a way to configure how long it takes for a view to merge into another view and for a view to forget previous data more rapidly.
Re: cookies! now!
The blending is quite slow (alpha=0.05), so it takes some time.
But increasing that doesn't make the los view any faster. Esp. in case of a flying radar plane the sim update rate is quite visible. It might that be the los update rate is less 30 frames per seconds (but I can't see anything that indicates so in the source code) or 30fps are still too less when you got >60 video fps.
Also you can always override/extend the shader with new options, for now I would wait till it reached a final state.
But increasing that doesn't make the los view any faster. Esp. in case of a flying radar plane the sim update rate is quite visible. It might that be the los update rate is less 30 frames per seconds (but I can't see anything that indicates so in the source code) or 30fps are still too less when you got >60 video fps.
Also you can always override/extend the shader with new options, for now I would wait till it reached a final state.
Re: cookies! now!
that's great!
if I understood it correctly, it seems in the near future we'll have better fog-of-war in spring games.
if I understood it correctly, it seems in the near future we'll have better fog-of-war in spring games.
Re: cookies! now!
Also you can create your own shader (just copy one of the shaders/GLSL/info*.lua) and then use:Google_Frog wrote:Is there a way to make the previous view disappear faster? I am asking for a way to configure how long it takes for a view to merge into another view and for a view to forget previous data more rapidly.
Code: Select all
/toggleinfo shaders/GLSL/myInfoView.lua