20,741
edits
OSGText Issues: Difference between revisions
Jump to navigation
Jump to search
m
→Investigation
m (→Investigation) |
m (→Investigation) |
||
| Line 102: | Line 102: | ||
That’s completely doable but means hooking an effect into the <text> element, which is certainly some work to get correct, since the shader also needs to interact correctly with the osgText source texture (containing the glyphs and offsets)<ref>https://sourceforge.net/p/flightgear/mailman/message/36740020/</ref> | That’s completely doable but means hooking an effect into the <text> element, which is certainly some work to get correct, since the shader also needs to interact correctly with the osgText source texture (containing the glyphs and offsets)<ref>https://sourceforge.net/p/flightgear/mailman/message/36740020/</ref> | ||
Fernando has been investigating this for a while now and it has proven to be a lot less trivial that he initially thought. His first approach was to ust transform the osgTexts into EffectGeodes, but this isn't so elegant as the general rules of effects don't apply to animations (we can't use <inherits-from>, model-default doesn't get applied automatically as it isn't considered a model, etc). | Fernando has been investigating this for a while now and it has proven to be a lot less trivial that he initially thought. His first approach was to ust transform the osgTexts into EffectGeodes, but this isn't so elegant as the general rules of effects don't apply to animations (we can't use <inherits-from>, model-default doesn't get applied automatically as it isn't considered a model, etc). | ||
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> | ||
For details, see [[Post_FlightGear_2020.2_LTS_changes#Canvas]]. | |||
If someone wants to hack around in this area, you’re going to want to copy the ‘generate the quad’ part of osgText into a new simgear/Scene, (to get the sizing / position right) which internally renders a texture created using an FBO-camera via ‘new’ osgText. The issue is going to be deciding what color to pass to new osgText; where an <emissive> value is supplied that should work directly, the problem case is things like logo/callsign text on exteriors and panels. For that, using the diffuse color will probably work as a starting point, and then apply the standard aircraft model effect. and … show how bad it looks. <ref>https://sourceforge.net/p/flightgear/mailman/message/37149302/</ref> | If someone wants to hack around in this area, you’re going to want to copy the ‘generate the quad’ part of osgText into a new simgear/Scene, (to get the sizing / position right) which internally renders a texture created using an FBO-camera via ‘new’ osgText. The issue is going to be deciding what color to pass to new osgText; where an <emissive> value is supplied that should work directly, the problem case is things like logo/callsign text on exteriors and panels. For that, using the diffuse color will probably work as a starting point, and then apply the standard aircraft model effect. and … show how bad it looks. <ref>https://sourceforge.net/p/flightgear/mailman/message/37149302/</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. | 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 | This could be hacked using the Canvas but that might be: | ||
* wasteful of resources (for rarely-changing text) | * wasteful of resources (for rarely-changing text) | ||
| Line 120: | Line 120: | ||
* hard to make it backwards compatible (which is very important) | * hard to make it backwards compatible (which is very important) | ||
So | So we might 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 | It would be very good to add the generated text-textures into a texture 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 == | ||