VTP Software Status:

Feature Requests and Other Desirable Improvements

• Enviro
  • Buildings
    • Interactive creation: not very useful until we can apply building styles.
  • Vegetation: load at runtime
  • Fences:
    • more options on chain-link, should allow top & middle poles
  • Raw
    • Javier in Spain writes: "Any point [feature] could be linked to any file (just as a HTML hyperlink does).  A hyperlink icon that was displayed every time you passed your mouse over a text label of a point data in the Enviro screen. By clicking, a new window would be displayed showing a picture of that place, or a text file.."
  • Utility Lines:
    • Should be able to delete structures (Luis Neves)
    • The structure dialogue should hold the last structure type between mode toggles. (Keltie)
    • Start/end in creation of Utility structures (Keltie)
    • Editing of Utility structure properties (Keltie)
    • The material properties of the wires could be exposed. I often use a shiny, mostly opaque, dull grey that is shaded and lit. (Keltie)
    • A global LOD control for wire segments could remove them when a single pixel line is way too thick for their representation perhaps. (Keltie)
  • Panoramic rendering
    • Flaxman: Enviro could produce a panoramic rendering of the terrain, which could then be used as the skydome for another terrain.
  • Navigation
    • The Grab-Pivot navigation is too awkward for general use (and not gimbal-locked). Needs a stable, smooth implementation that behaves like Google Earth's grab-navigation, because of all the people that have grown use to that one.
  • Roads
    • Interactive creation. Interactive editing. Need to apply many constraints to prevent the user from creating bad geometry.
      • Snap to nodes and closest point on link.
    • Possibly, class intersections into numbered-type based on situation.
  • Elevation
    • osgEarth surface, e.g. TMS grid
    • There's no good reason NOT to support multiple elevation surfaces, and several cool reasons to do it.
      • (Even multiple types, i.e. one tileset, one elevation grid, and several TINs)
• Enviro - Earth View
  • runtime control of the size of point data
  • ability to page in higher-resolution earth texture, ala BMV (Geoff Osborn)
• VTBuilder
  • Vegetation
    • Allow extraction of green areas from DRGs, for use as a single-valued bitmap vegetation layer
    • There should be a way to unselect a species or biotype file in VTBuilder without closing and reopening the program (Flaxman)
    • "Why not make the biotype (layer) optional? The default could be a type picked from a popup menu of biotypes, which would be applied to all polygons. This would work well for many GIS layers that have a single feature (i.e. woodlands). An option in the dialog box would be to specify veg biotype by shape file attribute field from a popup list. A second option would be density by attribute." (Flaxman)
    • ability to use multiple vegetation-type layers (e.g. LULC) (might be working already, should test)
    • generation of vegetation should avoid putting trees on other features (roads, buildings, water bodies..)
      • either implicitly, or by explicitly subtracting a no-plant area for each feature from the density layer
  • Roads
    • option to render roads into a bitmap for export
    • export road geometry somehow to MAX, perhaps even via VRML, so that artists can model custom buildings around them
  • Water
    • option to render rivers/water bodies into a bitmap for export
  • Buildings
    • ground carving/flattening under buildings
    • "turn" buildings so that their "front" faces the nearest road - optionally with a "setback" which defines minimum distance from the road/sidewalk's edge
      • difficulty: this would require a way to indicate which side is the "front" of each building
    • Set properties across multiple buildings, e.g. roof type.  (Paul Unterweiser)
      • It's not clear how an efficient UI could handle this, without numerous new dialogs for each possible building property.
  • Elevation
    • Option to load only the header from BT/DEM/other formats
      • Would allow fast manipulation of large datasets.  Similar to how GDAL caches large images, but for elevation.
    • Display name of elevation/image layer under the mouse, as the mouse moves.
      • this info (and much else) could go into a new "report" window under the layer list view
    • In the Profile Tool, saving the cross sections as a any format that can be easily imported to Excel file would be great, because excel has many useful statistic tools to analyze slopes, slope trends etc. (Daniel Mege)
    • Ability to change, in-place, the data type of elevation layers (float <-> short)
  • Images
    • Solve the zooming-in offset limitation. Difficult due to the stretch/mask problem.  Maybe solvable with TransparentBlt
  • Area Tool
    • Could have a modeless dialog for the values, so you can see the values changing as you drag the area (Flaxman)
  • USGS
    • Option to display the USGS 7.5-minute grid
    • Look up and display USGS data availability - how? connect to a WFS server for this?
    • Allow user to indicate area of interest, then automatically find, download and import the USGS data from their online repository
  • Raw Import
    • Could get rid of VTBuilder "import points from table" and just make it a feature of import raw. and expose CSV too.
• VTBuilder / vtdata
  • Support for floating-point GeoTIFF as an elevation format
    • There has been some indication on the GeoTIFF mailing list that GeoTIFF may supports this
    • Current status: we can already import and export to 16-bit integer GeoTIFFs.  Apparently Global Mapper will read and write floating-point values from GeoTIFFs, although this is surely outside the TIFF standard.
  • Buildings (vtBuilding) could allow a 2D vector which indicates which way the "front" of the building is, which would have several uses, such as styling it differently
• Enviro / vtlib library
  • Rivers / Streams / Water bodies
    • Sofia of VHLab - CNR-ITABC - reports:
    • "Perhaps the best solution for us is to create an integrated object. If we have a SHP file, for instance, (a line representing a river) in VTBuilder
      • we have to create something like a dialog box to insert the 'width' of the entire line and the 'depth' (from the terrain downwards)
      • the elevation should be now reprocessed in order to lower the terrain (following the given indications of width and depth)
      • the river banks should have a certain angle
      • finally we can texturize the bottom, creating a polygonal that follows the original shape, but at the level of the bottom of the river..."
  • Building3d: Support more building and roof styles.
    • One example is the "hip-gable" roof for rectangular buildings; hip with gable in the center.  This doesn't fit in the current scheme, because there are roof planes which do not correspond to a roof edge.  Multiple edge lines meet at a single point on the roof footprint.  It's not clear how to encode such a thing (without just going to full polygonal representation.)  A closely related subject is dormers.
    • Should we move away from the pseudo-fixed-length representation to a full, arbitrary length building description language?
    • Round buildings and curved walls are currently very poorly supported (and inefficient), it would be good to allow some indication of this kind of geometry in the VTST file.
  • Vegetation
    • Re-enable polygonal Xfrog vegetation (assuming we ask Greenworks' permission)
    • automatically create single billboards (imposters) from the polygonal vegetation
    • automatically create multiple-view billboards from the polygonal vegetation
  • Sky Dome: should use correct moon/stars declination based on latitude.
    • status: currently, only Sun location is correct.
  • Structure Materials
    • Materials in the Fences and Buildings panel still continue to show in English, despite the rest of the UI in i18n.  Materials are read from an .xml file; perhaps languages could be added there, just like plants do in species.xml?
• vtdata library
  • ECW support (through GDAL), out of core, for producing tilesets from it; or could we even make the tile on the fly?
  • Read/write utility structures (vtUtilityMap)
    • No format yet exists to save/load them - do we have to invent one?  The only 'standard' in existence seems to be the ESRI data model for the power industry, but that is massively over-complex.
    • Import from OpenStreetMap.
    • Import from USGS DLG MT.
  • Read/write GPX files - does OGR already do it?
  • Vegetation: as above, real serialization for biotypes.
  • Roads:
    • Import/Export OSM (OpenStreetMap).
• vtui library
  • The Plant dialog could/should be shared between Enviro and VTBuilder, by putting it in vtui
• Network loading
  • Ideally, every single kind of data should be loadable from a URL; the first time it is loaded, it is cached locally, then read from there, so file readers don't have to be re-written, they just need a front-end which transfers the file with CURL, displays progress to the user, and maintains the cache.
  • After that's working, then the next step would be to make a version of Enviro that's a Firefox plugin
• Hardware
  • GPS direct access
    • currently you can import data from Garmin's utility program's format into VTBuilder, but it would be better to support reading data directly from GPS devices
    • this may be possible by leveraging the GPS3D code (see Potential Libraries)
• File Formats - Biotype
  • Flaxman: "Stems per square meter is a pretty awkward unit for everyone except herb ecologists... how about stems per Hectare instead?"
  • Flaxman: "The biotype file probably should get upgraded to XML (from txt). At that point, it would be nice to add biotype names, and sanity check the file on load."
• Vehicles
  • Re-enable airplanes (should be extension of vehicle functionality); leverage FlightGear?

Efficiency and Speed Optimization

• Forests
  • To speed up tree billboard rendering, try using Alpha-Testing instead of Alpha-Blending. Is depth-sorting of the blended trees the largest bottleneck or not?
  • Test forest draw speed by using a single opaque material for all trees: how dependent is speed on state change?
  • If texture state change is the bottleneck, automatically merge all the tree textures in a single texture (or smaller number of textures) to avoid (or minimize) the state-change between tree appearances.
• Overhaul LOD grid usage - try a hierarchical tree of LOD nodes instead
  • How would this handle objects of varying LOD distance, such as the simple and full-representation of building models?  Could objects be placed at different levels of the tree depending on LOD distance?  Perhaps try a sphere-nesting approach ala Jonathan Blow.

Long-term

•  Use SLD for persisting Raw layer stylings?
• 'Coverage' layer type in VTBuilder/vtdata, which encodes ground cover type (grass/gravel/pavement etc.)  Polygonal?
• Create an English command grammar for representing scene editing instructions, implement first as a text-console, with possibility to use with voice input.  Ref: VTP long-term goals.

Functionality Matrix

• this is maintained as an HTML Table.