20,741
edits
OSGText Issues: Difference between revisions
Jump to navigation
Jump to search
m
https://sourceforge.net/p/flightgear/mailman/message/37157742/
m (https://sourceforge.net/p/flightgear/mailman/message/37157742/) |
|||
| Line 8: | Line 8: | ||
It’s a fairly large number of aircraft: the text animation has been around for a long time, prior to Canvas for example. | It’s a fairly large number of aircraft: the text animation has been around for a long time, prior to Canvas for example. | ||
The problem is not us keeping 3.4.x around : it would be nice to switch to 3.6 everywhere, but we support both today. | The problem is not us keeping 3.4.x around : it would be nice to switch to 3.6 everywhere, but we support both today. | ||
Some cockpits have 50 of these (each MCP window, each radio numerical field, etc, etc). There’s at least one CDU impl where each line is two text items. (One for big, one for for small)<ref>https://sourceforge.net/p/flightgear/mailman/message/37157742/</ref> | |||
The text issue has existed with OSG 3.6 for many years, without anyone stepping up to fix it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37149210/</ref> | The text issue has existed with OSG 3.6 for many years, without anyone stepping up to fix it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37149210/</ref> | ||
| Line 79: | Line 81: | ||
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> | ||
The ‘right’ way is to to render osgText into a texture / FBO, and then apply that to the model using an Effect. Then effects will work as normal on text. | |||
This could be hacked using the Canvas but I think that will be: | |||
* wasteful of resources (for rarely-changing text) | |||
* create a lot of property tree noise | |||
* hard to make it backwards compatible (which is very important) | |||
So I think we want a little <code>text > a texture</code> helper (implemented using osgText) which then locates the resulting texture quad at *exactly* the same location, as the quad osgText ‘would have built anyway’. And then applies an effect to it (which previously, was not done, so we need a a default effect close to the old fixed-function)<ref>https://sourceforge.net/p/flightgear/mailman/message/37157687/</ref> | |||
It would be very good to add the generated text-textures into an atlas, if that can be done safely. And it’s also why we don’t want an entry under canvas/ for each one. So we would have a little manager to track in-use areas of the atlases, map an animation to UVs within the atlas, etc. Definitely an optimisation, but probably a friendly one for cockpits with many text elements. (Which I think is the 737, the 747, the 777….)<ref>https://sourceforge.net/p/flightgear/mailman/message/37157742/</ref> | |||
== Ideas == | == Ideas == | ||