20,741
edits
Canvas scenery overlays: Difference between revisions
Jump to navigation
Jump to search
→Canvas Integration
| Line 127: | Line 127: | ||
== Canvas Integration == | == Canvas Integration == | ||
it does make sense to delegate as much power, and flexibility, to fgdata space (effects, shaders) as possible - the Canvas system would just seem like one of the most obvious candidates to be extended to support geo-referenced placements and let its textures to be used in conjunction with various effects and shaders, as both, the input buffer but also the output buffer. | it does make sense to delegate as much power, and flexibility, to fgdata space (effects, shaders) as possible - the Canvas system would just seem like one of the most obvious candidates to be extended to support geo-referenced placements and let its textures to be used in conjunction with various effects and shaders, as both, the input buffer but also the output buffer. | ||
Basically a Canvas is just a FBO/RTT after all, and we do have the notion of arbitrary "placements" - thus, coming up with a new mode for geographic placements would not be very much work given the code/patches we have already. | |||
This is not necessarily a suitable long-term strategy (see the PagedLOD comments),but it would provide for a very solid prototyping platform to come up with a proof-of-concept so that people can tinker with different approaches, without requiring tons of C++ changes (or familiarity with SG/TG). | |||
Like psadro stated on the devel list, a 4096x4096 texture would be sufficient for most needs - but for markings etc specifically, it would be insufficient. However, it would be possible to apply markings using a different/additional overlay, i.e. that just applies to airports, taxiways and roads etc | |||
James mentioned recently that said vector information would come in handy for many modern cockpit display - and as you can see in various MFDs/dialogs, we are already able to obtain /some/ vector information and turn that into a raster image. | |||
The same raster image could be overlaid onto terrain tiles using geo-referencing, but it would also be possible to use such a texture as the input, or output buffer, for an arbitrary effects/shader pass - which is to say that the 4096x4096 sheet could be used for photo-imagery, and another texture could be merged with that using effects/shaders to apply markings etc selectively. | |||
This approach provides a straightforward mechanism to allow others to explore different routes without having to dedicate months, or years, of C++ coding to see if something is a dead-end or not. | |||
Realistically, we already have most components in either SG or FG (or some topic branches), it's just that these features are poorly integrated currently (think effects not being able to a Canvas and vice versa). | |||
But as soon as the Canvas system provides support for geo-referenced terrain overlays, and has some integration with effects, our eye candy folks would basically be unstoppable, without having to know much about TerraGear or C++ at all. | |||
we are already able to create a texture representation of arbitrary airport features like runways, taxiways etc - even in Nasal/Canvas space using a handful of APIs (navdb), which works using the Canvas::Map element to project lat/lon tuples of arbitrary Canvas::Path segments to the texture<ref>{{cite web | we are already able to create a texture representation of arbitrary airport features like runways, taxiways etc - even in Nasal/Canvas space using a handful of APIs (navdb), which works using the Canvas::Map element to project lat/lon tuples of arbitrary Canvas::Path segments to the texture<ref>{{cite web | ||