TerraGear roadmap: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 20: Line 20:
The marking shader needs to know the underlying pavement origin.  To do this, the .BTG file needs to support multiple texture coordinates.  1 primary set to look up the line texture in the texture atlas, and another set relative to the origin of the pavement.  i4dnf would also like to add dirty / tire marks to the runways.  To do this, he needs to know where in the runway polygon, the thresholds are.  In openGL, a vertex attribute would be passed to the shader to relay the information.  The btg format should be expanded to allow vertex indices (of a triagle) to have attributes.
The marking shader needs to know the underlying pavement origin.  To do this, the .BTG file needs to support multiple texture coordinates.  1 primary set to look up the line texture in the texture atlas, and another set relative to the origin of the pavement.  i4dnf would also like to add dirty / tire marks to the runways.  To do this, he needs to know where in the runway polygon, the thresholds are.  In openGL, a vertex attribute would be passed to the shader to relay the information.  The btg format should be expanded to allow vertex indices (of a triagle) to have attributes.


The second idea is to use multiple tcs to allow landclass shaders to know where in a tile they are located.  If we have a per tile raster image with the landclasses encoded, then the borders between landclasses can be smoothed / modified by the shaders.
The second idea is to use multiple tcs to allow landclass shaders to know where in a tile they are located.  If we have a per tile raster image with the landclasses encoded, then the borders between landclasses can be smoothed / modified by the shaders.  We could also encode regional definitions into the same raster image to support irregular shaped region encoding.  probably 8 bits for landclass, and 8 bits for region is enough.


It would be nice to have all landclass images and this single per tile image to all have the same resolution, so we could use a texture array.  This allows us to draw an entire tile (other than linear road / rail / stream ) in one openGL draw call.
It would be nice to have all landclass images and this single per tile image to all have the same resolution, so we could use a texture array.  This allows us to draw an entire tile (other than linear road / rail / stream ) in one openGL draw call.
Line 46: Line 46:
|-
|-
| hgtchop || support arbitrary tile sizes / directory structure || {{pending}}
| hgtchop || support arbitrary tile sizes / directory structure || {{pending}}
|-
| imgchop || new tool to support per tile raster images based on a global image.  Could be used to chop i4dnf's ocean depth image || {{pending}}
|-
|-
| hgtfit || support arbitrary tile sizes / directory structure || {{pending}}
| hgtfit || support arbitrary tile sizes / directory structure || {{pending}}
Line 56: Line 58:
|-
|-
| tgconstruct || generate per tile raster image of landclass data || {{pending}}
| tgconstruct || generate per tile raster image of landclass data || {{pending}}
|-
| tgconstruct || generate per tile raster image of region data ( can be combined with landclass image to use just 1 texture unit) || {{pending}}
|-
|-
| tgconstruct || generate landclass triangles with geodetic texture coordinates and per tile origin coordinates || {{pending}}
| tgconstruct || generate landclass triangles with geodetic texture coordinates and per tile origin coordinates || {{pending}}
129

edits

Navigation menu