20,741
edits
Canvas scenery overlays: Difference between revisions
Jump to navigation
Jump to search
m
→Canvas Integration: pm preservation ...
m (→Canvas Integration: pm preservation ...) |
|||
| Line 165: | Line 165: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
One of the more straightforward ways to have our cake and eat it, would be providing a custom Canvas element type, implemented in C++, that renders generic vector data to a raster image (think ESRI-like stuff) - but then again, that's quickly approaching what osgEarth is already good at, like James mentioned. | |||
However, that's the kind of stuff for which osgEarth is using GDAL/OGR already ... so it would not make sense to reinvent the wheel here - osgEarth-enabled builds will have gdal/ogr support included anyway | |||
it could be pretty useful to allow a Canvas texture (aka the raster image created by a Canvas FBO) to be registered with the material cache (SGMaterialLib), i.e. in the form of a custom "material" - that would then automatically imply that all effects/shader infrastructure code be used "as is", without any additional C++ plumbing needed. | |||
C++ wise that would mainly mean making a call to SGMaterialLib::insert() to register an arbitrary Canvas texture with the material library (as per $SG_SRC/scene/material/mat*.cxx) | |||
Draping a texture onto the terrain mesh is a different beast though and will require integration with the PagedLOD changes, most of the original code was written long before that - so is out of date; fortunately, the photoscenery patches (wiki) are not exactly huge, i.e. it's pretty self-contained actually. | |||
In its current form it will just look for <tilename>.dds files and drape them over the tile using 2 modified effects/shaders, and a patched obj.cxx that exposes the corresponding lat/lon tuples to shader space. | |||