VTP Software Status:
Feature Requests and Other Desirable Improvements
- Interactive creation: not very useful until we can apply building styles.
- Vegetation: load at runtime
- more options on chain-link, should allow top & middle poles
- 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.
- 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.
- 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
- 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)
- 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
- 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
- option to render rivers/water bodies into a bitmap for export
- 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
- 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
- It's not clear how an efficient UI could handle this,
without numerous new dialogs for each possible building property.
- 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
- 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
- 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)
- 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
- 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
- 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
- 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.
- Re-enable polygonal Xfrog vegetation (assuming we ask Greenworks' permission)
- automatically create single billboards (imposters) from the polygonal
- automatically create multiple-view billboards from the polygonal
- Sky Dome: should use correct moon/stars declination based on
- 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
- 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.
- 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
- 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
- this may be possible by leveraging the GPS3D code (see
- 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."
- Re-enable airplanes (should be extension of vehicle functionality);
Efficiency and Speed Optimization
- 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.
- 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