A while back, i asked everyone to send me thier VRML space locations, and
a LAT/LONG for thier physical location. I am building a VRML planet, on which
i will have links to all the VRML sites i know about. I only recieved two
responses, one from Lightscape, and one from IUMA in Santa Cruz. I have added
the cave, SDSC, and UCLA. I know of other supposed sites, but can never
successfully get there. I hesitate to put those sites on for that reason
The planet is a simple green sphere with the
coastlines draw in as lines. Each VRML site is represented by a sphere at
the location on the globe where the site is. The simple coastlines-only globe
is not the most graphically cool thing in the world, but the camera in
webspace rotates the scene quickly on my indy. I will add levels of detail
as it becomes necessary given the volume of links on the globe.
If people will e-mail me thier VRML's http address and the city they
want it to be associated with on my globe, i can get Lat/long info from
the city. If you wanna look at the globe as it stands right now
(under construction, but it does work) check out:
http://www.gwha.com/~jym/VRMLWorld.wrl.
Please don't turn this into another discussion about coordinate systems.
Just send me your info if ya wanna be on the globe.
My home page is still under construction, so you'll have to go directly to
the globe. I'm still building a couple other globes. When they are done,
i will announce my home page to the world.
One of those globes has small rectangles that represent areas for which
i have elevation data. Click on a rectangle and get a 3D model for of
the terrain in that area. I just have to optimize my conversion of Digital
Elevation Model files to VRML, and that globe will be complete. A couple
things
to think about if you are working on any software that generates VRML:
1) Don't generate normals unless you absolutely have to. Let the browsers
generate normals automatically. For large surfaces with PER_VERTEX normals,
this will make your VRML files much smaller, reducing download time. This begs
the question of wether we can expect all viewers to generate normals if they
are not present. Is there a document which describes what minimal set of
functionality can be expected from a VRML viewer?
2) Optimize coordinate lists and material lists. Since coordinates and
materials are indexed from the shape nodes(in particular the IndexedFaceSet),
we need to only generate one copy of each material, and one copy of each
coordinate. So if you have a surface that is a 10 by 10 grid of points,
you should only have to generate 100 vertices, and share those vertices among
the four polygons that will use each one.
3) Use cubes, spheres, cones and cylinders whenever possible. This will
make you VRML files smaller than if you were to generate polys for each
of these shapes.
Finally, the discussion of Avatars, portals, etc. is all very important,
but i think we need to talk about what we can do in 1.x or 2.0 to improve
performance and decrease network usage. One of the requirements of VRML is:
"Ability to work well over low-bandwidth connections". In the spirit of
decreasing the network load generated by VRML i propose the following node:
Gridded Surface {
fields [ SoSFLong numRowValues, SoSFLong numColumnValues,
SoSFFloat rowStartValue, SoSFFloat columnStartValue,
SoSFFloat rowDelta, SoSFFloat columnDelta, SoMFFloat elevations
]
}
numRowValues - the number of elevation values in each row.
numColumnValues - the number of elevation values in each column.
rowStartValue - the x value for the first value in each row.
columnStartValue - the y value for the first value in each column
rowDelta - the delta for x as you go accross the surface.
columnDelta - the delta in y as you go down the surface.
elevations - one elevation value for each point on the surface.
Consider the savings in network usage of this kind of a surface over an
IndexedFaceSet. If you have a 100 by 100 point surface, and you represent it
with an IndexedFaceset, at minimum you will pass the
following accross the net:
100 * 100 * 3 floating point values for the coordinates.
if you generate 4 sided polygons for the surface:
100 * 100 * 4 long values for the indices
Using the node i described above, you would use:
100 * 100 floating point values for the elevations
1 value for each of the 6 other fields in the node.
It seems to me that alot of VRML spaces will want to have a surface that
describes the terrain the space is in. We could really cut down on network
traffic for those terrain surfaces with a node like the one i have proposed.
jim terhorst (MountainTop::Computing) [email protected]