new shader based InfoTexture (faster, shinier & modular)

new shader based InfoTexture (faster, shinier & modular)

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

new shader based InfoTexture (faster, shinier & modular)

Post by jK »

Last edited by abma on 04 Jan 2015, 20:57, edited 3 times in total.
Reason: changed topic title
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: cookies! now!

Post by gajop »

Image
So what does this mean?
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: cookies! now!

Post by PicassoCT »

That means, that you have bitmaps available as shadder programmers that contain the info on Metallmap, Los map and so on and so forth.

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
Basically another big step to unroot graphicsstuff from enginecore..
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: cookies! now!

Post by jK »

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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: cookies! now!

Post by PicassoCT »

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 Image
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
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: cookies! now!

Post by hoijui »

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! :-)
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: cookies! now!

Post by Anarchid »

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.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: cookies! now!

Post by Silentwings »

Image
200,000 cookies. (And some railways tracks, modern art...)
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: cookies! now!

Post by FLOZi »

Thought it was awesome work then read
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.
At which point I totally lost control and squeed. :oops:


Squeeeeeeee! :mrgreen:
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: cookies! now!

Post by knorke »

updates all infotextures continuously even when not selected right now (so lua can access it for example).
Nice!
Image
User avatar
Tim Blokdijk
Posts: 1242
Joined: 29 May 2005, 11:18

Re: cookies! now!

Post by Tim Blokdijk »

www.fortunecookiemessage.com wrote:You have a flair for adding a fanciful dimension to any story.
Should have said "to Spring engine."
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: cookies! now!

Post by abma »

@jk:

wow, sounds awesome! nice refactory/new feature!

whats your address/which cookies do you like? :D
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: cookies! now!

Post by Google_Frog »

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.
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: cookies! now!

Post by jK »

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.
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: cookies! now!

Post by raaar »

that's great!

if I understood it correctly, it seems in the near future we'll have better fog-of-war in spring games.
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: cookies! now!

Post by jK »

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.
Also you can create your own shader (just copy one of the shaders/GLSL/info*.lua) and then use:

Code: Select all

/toggleinfo shaders/GLSL/myInfoView.lua
Post Reply

Return to “Engine”