Board index FlightGear Development Effects and shaders

Dirty airplanes??

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: Dirty airplanes??

Postby Thorsten » Mon Nov 07, 2016 6:21 am

No, I'm not aware of any other use case, it's just something that occurred to me as 'might be interesting to try one day'.
Thorsten
 
Posts: 9159
Joined: Mon Nov 02, 2009 8:33 am

Re: Dirty airplanes??

Postby Hooray » Mon Nov 07, 2016 8:45 pm

I was wondering about this, and I think we're really talking about the internal representation of the texture itself, i.e. because you talk about saving memory ?
The thing is, no matter if we can coax Canvas (effects or whatever else) into using a custom lookup function ("sampler") - sooner or later, you will probably want to deal with the whole thing as a conventional OpenGL texture (e.g. so that you can access it from GLSL), at that point the whole memory/time trade-off would be kinda moot, wouldn't it ?

For instance, I've gone through a handful of possible strategies to implement a piece of code for your use-case - e.g. by telling a Canvas to set up a 512x512 texture, put your artwork/imagery into that and then implement a custom lookup function in C++ space to selectively return the actual texture or some "sane" default value for the untextured stuff - that would work, even without too much work - but it would inevitably have to be turned into an actual texture at some point, wouldn't it ?

To be fair, I am not familiar with the effects/glsl side of any of this - but we can already set up a Canvas using configurable dimensions, and we can make it load a texture sheet from disk and put that into the Canvas texture, and we can also get a partial texture out of the whole thing using a property-configurable sub-texture (treating the Canvas as a texture map).

So, what is really happening behind the scenes, that the corresponding OpenGL machinery to "cut out" the sub-texture is configured via a few properties that define the corresponding rectangle, at that point it should -arguably- also be possible to hook into such code and extend it to deal with the "untextured" part of your 16kx16k texture (i.e. by returning default values).

But somewhere down the road, you'll want to use the whole shebang to texture the EarthView sphere, right ?
And isn't it then that the whole thing would have to be turned into an actual OpenGL texture, meaning a conventional texture that is no longer "procedural" ?

(sorry if my terminology is a bit off ...)

I think what you're really hinting at isn't unlike your re-discovery of "procedural texturing" a few years, back when you didn't even know the term existed - just with a focus on the actual in-hardware representation ?

EDIT: Thinking about it a little more, this is touching on the whole "Canvas Instancing" issue we've been talking about for years - in the case of the NavDisplay we have the use.case where we have a 1024x1024 MFD, and need to show N identical symbols in different places (on different "layers"). What we end up doing is still having one 1024^2 texture, but it is populated by texture map lookups referring to another texture that gets the 32x32 symbols out of it, so that there is only ever a single texture looked up (the "SymbolCache").

Basically, it's a poor man's "texture atlas" (The Canvas system isn't really integrated with OSG's atlas machinery (yet)).

http://wiki.flightgear.org/Canvas_Devel ... Instancing
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11002
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Effects and shaders

Who is online

Users browsing this forum: Google [Bot] and 1 guest