20,741
edits
OSGText Issues: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Stub}} | {{Stub}} | ||
{{infobox subsystem | |||
|name = Osgtext + effects | |||
|started = 11/2020 | |||
|description = Make text animations work correctly with the Effects framework | |||
|status = discussions | |||
|developers = {{Usr|Scttgs}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37157550/</ref> | |||
}} | |||
The OSGText animation (README.osgtext) doesn't play nice with shaders.<ref>https://forum.flightgear.org/viewtopic.php?f=87&t=37429&p=376110#p376110</ref> | The OSGText animation (README.osgtext) doesn't play nice with shaders.<ref>https://forum.flightgear.org/viewtopic.php?f=87&t=37429&p=376110#p376110</ref> | ||
Another way to describe the bug is ‘make text animations work correctly with the Effects framework’. Because osgtext always uses a shader (now), and shaders cannot be combined, we have to find a smarter way to do that. But the fact that osgtext didn’t work correctly with Effects has always been there. So there is no upstream fix possible: we have to change what we’re doing on our side, but that will risk some aircraft compat issues. The patch we’re applying is to restore things to how they looked before, but it was still broken, just less obviously.<ref>https://sourceforge.net/p/flightgear/mailman/message/37150030/</ref> | |||
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 90: | ||
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> | ||
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. | |||
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 == | ||