OSGText Issues: Difference between revisions
(long-standing issue: https://forum.flightgear.org/viewtopic.php?f=87&t=37429&p=376110#p376110) |
m (https://sourceforge.net/p/flightgear/mailman/message/36703340/) |
||
| Line 14: | Line 14: | ||
The breaking change was introduced with OSG 3.6.5, and was also recently merged into OSG 3.7.<ref>https://sourceforge.net/p/flightgear/mailman/message/36732917/</ref> | The breaking change was introduced with OSG 3.6.5, and was also recently merged into OSG 3.7.<ref>https://sourceforge.net/p/flightgear/mailman/message/36732917/</ref> | ||
== Background == | |||
For the time being, we don’t (often) use OSG 3.6 - looking at the code on master (which became 3.6), there isn’t a single commit we can revert - Robert evidently did a lot of incremental improvements to the text code, adding support for other features and improving the shader support. Then at some point he collected a subset of those changes and back-ported them to 3.4 branch, which is what we revert in the commit on my fork on GitHub. | |||
This means for OSG 3.6 we need to find a solution on our side, which likely means updating aircraft or making some guesses based on the <text> animation element in our XML files, because the set of colouring options supported by the new osgText implementation is more restrictive than what worked before. | |||
(The text animation assumes that setting all of emissive/ambient/diffuse/specular works on an osgText, and it no longer does - for some cases we could map the emissive color to the text color, but this would break some other cases…. and text still won’t receive normal lighting in that case)<ref>https://sourceforge.net/p/flightgear/mailman/message/36703340/</ref> | |||
== References == | == References == | ||
{{Appendix}} | {{Appendix}} | ||
Revision as of 10:52, 11 November 2020
| This article is a stub. You can help the wiki by expanding it. |
we need to do some Real Work (TM) to support Canvas with osgText 3.6 and upwards, unfortunately.[1]
OSGText doesn't play nice with shaders.[2]
some developers have switched to canvas /because/ of the always white OSGText problem[3]
The OSGText issue is more that the world is moving forwards, and our text-animation element has not. (Shaders required, can’t rely on OpenGL 1.1 built-in lighting)[4]
It’s caused by OSG using a shader to render text now, but this bypasses the built-in emissive/diffuse/ambient material properties, which is what our <text> animation uses to set colours of text.
It should happen ‘everywhere’ that a shader is used to render text - Canvas doesn’t care about it since it sets the text color directly.[5]
The breaking change was introduced with OSG 3.6.5, and was also recently merged into OSG 3.7.[6]
Background
For the time being, we don’t (often) use OSG 3.6 - looking at the code on master (which became 3.6), there isn’t a single commit we can revert - Robert evidently did a lot of incremental improvements to the text code, adding support for other features and improving the shader support. Then at some point he collected a subset of those changes and back-ported them to 3.4 branch, which is what we revert in the commit on my fork on GitHub.
This means for OSG 3.6 we need to find a solution on our side, which likely means updating aircraft or making some guesses based on the <text> animation element in our XML files, because the set of colouring options supported by the new osgText implementation is more restrictive than what worked before.
(The text animation assumes that setting all of emissive/ambient/diffuse/specular works on an osgText, and it no longer does - for some cases we could map the emissive color to the text color, but this would break some other cases…. and text still won’t receive normal lighting in that case)[7]