OSGText Issues: Difference between revisions

Jump to navigation Jump to search
m
→‎Investigation: https://sourceforge.net/p/flightgear/mailman/message/36627559/
m (https://sourceforge.net/p/flightgear/mailman/message/37042335/)
m (→‎Investigation: https://sourceforge.net/p/flightgear/mailman/message/36627559/)
Line 28: Line 28:


Richard said on Discord that another option was creating a Canvas for each text animation, but creating a FBO for every small piece of text doesn't sound very performance-friendly. This is also worsened by the fact that canvas cameras are scene-graph level cameras and are being rendered multiple times (once per viewer slave camera).<ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref>
Richard said on Discord that another option was creating a Canvas for each text animation, but creating a FBO for every small piece of text doesn't sound very performance-friendly. This is also worsened by the fact that canvas cameras are scene-graph level cameras and are being rendered multiple times (once per viewer slave camera).<ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref>
== Ideas ==
=== Mapping to Canvas ===
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.
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>


== References ==
== References ==
{{Appendix}}
{{Appendix}}

Navigation menu