20,741
edits
Canvas development: Difference between revisions
Jump to navigation
Jump to search
→Internals
| Line 129: | Line 129: | ||
== Internals == | == Internals == | ||
It's a conventional OSG texture that is allocated. | |||
The main difference is that certain OSG parameters are exposed in the form of properties, by setting properties using a certain name, type/value, it will call the corresponding OSG machinery to update the texture internally.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=298178#p298178 | |||
|title = <nowiki> Re: Dirty airplanes?? </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Nov 5th, 2016 | |||
|added = Nov 5th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
However, the Canvas image element already supports texture mapping, i.e. you can treat a raster image (including another Canvas) as the source for a raster image, and only get a portion out of it: [[Howto:Using raster images and nested canvases#Texture Maps]] | |||
Once you stop manipulating a Canvas in the tree (and especially its child elements), it's all native C++ code that is running - i.e. no Nasal or property overhead once the corresponding data structures are set up, but that only holds true until the next "update", at which point everything is removed, re-parsed and updated/re-drawn.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=298124#p298124 | |||
|title = <nowiki> Re: Dirty airplanes?? </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Nov 5th, 2016 | |||
|added = Nov 5th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
For instance, for Rembrandt, that would require additional hooks, because things like the internal texture format are not currently configurable via "Canvas properties", i.e. it's a hard-coded thing - however, Rembrandt makes extensive use of different kinds of buffers and in-memory representations, probably for pretty much the same reasons that you have in mind regarding the first question you asked. | |||
I guess, to answer your first question, we would need to look at the way Rembrandt is setting up, and managing, its buffers and compare that to the standard Canvas FBO - but I really think that it's not doing anything fancy at all, because that would introduce hard-coded assumptions that may fail under certain circumstances. | |||
Basically, what you are suggesting would require some way to encode the internal representation using a configurable lookup. | |||
What is really taking place behind the scenes, is that the Canvas system is built on the old FGODGauge code, Tom ended up rewriting it from scratch basically, but it's still using the same mechanism that hard-coded "owner-drawn" (OD) gauges like the agradar/navdisplay were using. | |||
The allocation (OSG setup) can be found here: https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/ODGauge.cxx#l218 | |||
The internal representation/format is a hard-coded thing: https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/ODGauge.cxx#l255 | |||
And even the cameragroup stuff is using the same hard-coded assumption: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/CameraGroup.cxx#l994 | |||
Rembrandt, and effects (simgear), are much more flexible (for now), e.g. see: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderingpipeline.cxx#l164 | |||
https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer.cxx#l769 | |||
<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=298178#p298178 | |||
|title = <nowiki> Re: Dirty airplanes?? </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Nov 5th, 2016 | |||
|added = Nov 5th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
== Elements == | == Elements == | ||