Canvas scenery overlays: Difference between revisions

Jump to navigation Jump to search
Line 45: Line 45:


== Applications ==
== Applications ==
In regard to the cray city texture stretching on the mountain, this is something that seems like a fundamental flaw in our texture coordinate calculations.  We only calculate them in 2-D ( lon, lat ), so any cliff, steep slope stretch the texture out.  The landclass shader mitigates this programatically, but with just plain textures, it looks awful. <ref>{{cite web
In regard to the cray city texture stretching on the mountain, this is something that seems like a fundamental flaw in our texture coordinate calculations.  We only calculate them in 2-D ( lon, lat ), so any cliff, steep slope stretch the texture out.  The landclass shader mitigates this programatically, but with just plain textures, it looks awful. Ideally, city textures would be just gravel, etc, and could be done procedural, then random / osm building could be placed on top.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=295728#p295728
  |title  =  <nowiki> Re: When FGFS could be like this? </nowiki>
  |author =  <nowiki> psadro_gm </nowiki>
  |date  =  Sep 29th, 2016
  |added  =  Sep 29th, 2016
  |script_version = 0.40
  }}</ref>
<ref>{{cite web
   |url    =  https://forum.flightgear.orgviewtopic.php?p=295728#p295728  
   |url    =  https://forum.flightgear.orgviewtopic.php?p=295728#p295728  
   |title  =  <nowiki> Re: When FGFS could be like this? </nowiki>  
   |title  =  <nowiki> Re: When FGFS could be like this? </nowiki>  
Line 51: Line 59:
   |date  =  Sep 29th, 2016  
   |date  =  Sep 29th, 2016  
   |added  =  Sep 29th, 2016  
   |added  =  Sep 29th, 2016  
  |script_version = 0.40
  }}</ref>
City textures are unlikely to work too well on slopes, i.e. they're usually made with the assumption that they're taken from a bird's eye-view (straight  down), so applying them to a slope would require dealing with that assumption in a sane way, which would probably require some fairly fragile heuristics (basically changing the projection of  the texture at runtime, which is unlikely to look that good, because the re-projection would need to extrapolate texels because it is lacking most relevant information, such as the color of a wall, because it only knows the color of the roof-top).
Probably, it would be best to move away from static city textures and decompose the whole thing into its components and then re-add those procedurally, like you say. We already have most parts for this in place, they're just not very well integrated at the moment (think materials, effects, shaders, photo-scenery/texture draping, FBOs/canvas)
For instance, if/when the Canvas system is extended to allow arbitrary Canvas textures to be registered as "materials" (in the Scenery/SimGear sense), that would make effects/shaders automatically available to Canvas textures, and the only other addition required is allowing a Canvas texture to be draped onto the terrain mesh, e.g. by using a customied subset of the existing photo-scenery patches.
This may not be the most elegant, or the fastest, option - but it would provide for a truly generic toolbox to conduct various scenery/texturing related experiments without requiring major C++ changes apart from two entirely self-contained additions that would be useful even regardless of this particular use-case.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=295856#p295856
  |title  =  <nowiki> Re: When FGFS could be like this? </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Oct 1st, 2016
  |added  =  Oct 1st, 2016
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>

Navigation menu