OSGText Issues: Difference between revisions

Jump to navigation Jump to search
m
Line 64: Line 64:


== Ideas ==
== Ideas ==
James wondered if we could do a hack in <animation> XML parsing to at least support emissive use - then we have an easy update route for those people, people doing panel legends would need to use canvas text manually?<ref>https://sourceforge.net/p/flightgear/mailman/message/36627559/</ref>
=== Mapping to Canvas ===
=== Mapping to Canvas ===
{{See also|Unifying the 2D rendering backend via canvas}}
{{See also|Unifying the 2D rendering backend via canvas}}
Line 77: Line 79:
The problem is supporting emissive would be doable as a few-lines tweak and quite safe. Supporting ambient/diffuse will require the same solution as ‘making the text work with effects’, i.e a custom text shader I thin, and I don’t know if we could do that (or integrate it with the effects framework)
The problem is supporting emissive would be doable as a few-lines tweak and quite safe. Supporting ambient/diffuse will require the same solution as ‘making the text work with effects’, i.e a custom text shader I thin, and I don’t know if we could do that (or integrate it with the effects framework)


As for mapping to Canvas, James also is not sure how that would work - Canvas Text is also ‘just osgText’ but it seems works for Canvas because the output texture is applied to the cockpit and then effects are applied on top? Doing a safe transformation of osgText-animation to Canvas would mean working out the required canvas extent and somehow mapping it to the correct panel location (and UVs), which he’d be nervous about both the reliability and complexity of.
As for mapping to Canvas, James also is not sure how that would work - Canvas Text is also ‘just osgText’ but it seems works for Canvas because the output texture is applied to the cockpit and then effects are applied on top? Doing a safe transformation of osgText-animation to Canvas would mean working out the required canvas extent and somehow mapping it to the correct panel location (and UVs), which he’d be nervous about both the reliability and complexity of. <ref>https://sourceforge.net/p/flightgear/mailman/message/36627559/</ref>


James wondered if we could do a hack in <animation> XML parsing to at least support emissive use - then we have an easy update route for those people, people doing panel legends would need to use canvas text manually?<ref>https://sourceforge.net/p/flightgear/mailman/message/36627559/</ref>
There have been some recurring discussions to fix/port or rather retarget the osgtext animation so that the core implementation uses a canvas fallback internally.
So far, the main concern here has been that allocating one FBO per animation (panel legend) would be rather wasteful.
Another idea disussed previously was to use a single Canvas FBO to serve as a cache texture and allocate all strings inside that, while registering an effect/shader that merely gets a handle to the canvas SUB-TEXTURE - which is an approach already used elsewhere (namely the Canvas SymbolCache).<ref>https://forum.flightgear.org/viewtopic.php?f=87&t=37429&start=75#p376118</ref>


== References ==
== References ==

Navigation menu