Hi Robert,
See my comments below:
Robert Osfield wrote:
Hi John,
Perhaps a Terrain::init() or update() method would be appropriate -
one that goes through all the tiles registered with
the terrain and calls init() on them.
As for 16 seconds, this is looooooong time. I am only seeing around a
second of time update on a database
that is getting on 10TB in size, the trick is it's a paged database
and only what is loaded is updated.
Please excuse my ignorance, but osgdem produces pagedLOD databases per
default, doesn't it? At least, the top node of my terrain database start
out like this:
CoordinateSystemNode {
name "osgTerrain_globe.ive"
nodeMask 0xffffffff
cullingActive TRUE
Format "WKT"
CoordinateSystem "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS
84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9108\"]],AXIS[\"Lat\",NORTH],AXIS[\"Long\",EAST],AUTHORITY[\"EPSG\",\"4326\"]]"
EllipsoidModel {
RadiusEquator 6378137
RadiusPolar 6356752.3142
}
num_children 1
PagedLOD { <<< This must means model is a pageLOD db, right?
nodeMask 0xffffffff
cullingActive TRUE
Center -3963 0 0
Radius -1
RangeMode DISTANCE_FROM_EYE_POINT
RangeList 2 {
1.43452e+08 1e+10
0 1.43452e+08
}
NumChildrenThatCannotBeExpired 0
FileNameList 2 {
""
osgTerrain_globe_root_L0_X0_Y0/osgTerrain_globe_L0_X0_Y0_subtile.ive
}
1 sec. vs. 16 sec. makes a big difference! OK, I am running my tests on
a laptop, but it has the following specs: Intel Duo T7300, GeForce 8600m
GT 512MB, 2GB Memory, running CentOS 4.6 (a.k.a RHEL 4). So unless
you've spent a fortune on hardware, I don't think hardware differences
alone can explain the difference.
What could potentially contribute to this difference in update time. Any
ideas?
FYI, the thing that will be taking all the time in the generation will
be the display lists/texture object update. Making osgTerrain a bit
more intelligent about it's updates it would be possible to just
update the existing vertices and normals when changing the scale,
something that would be much cheaper. The dirty/update mechinism
would have to be alot more sophisticated though. Long term this is
where osgTerrain is heading, right now its very much in its infancy.
Thanks, this is very useful information. I'll see what I might figure
out when, and if, I get the time. But I'll certainly keep a watchful eye
on any VPB svn updates;)
Best regards,
John Vidar
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
