Hi Robert, hi folks, >> The input data I currently have is a regular grid with holes. At the >> moment support for irregular meshes is not needed. All mesh >> manipulationa will be based on the regular grid. Do you have a hint >> how to efficiently triangulate this regular grid with holes? > > Are you able to store the data as a height field with z values set a no data > values? Yes I could do this in a preprocessing step.
> One avenue I would explore would be to be to tile the whole grid, with each > tile something like 100x100, and then position them down in the vertex > program using the height field of each tile being read from a texture and > place into the right place in 3D and tag the non data values so that in the > geometry shader you can discard all triangles that have a non data value at > a corner. I think this is a good idea, since I get rid of the need to triangulate a mesh with non-simple polygon holes and I can apply a simple (and fast) triangulation of the regular mesh. I still have to consider the irregular boundaries of this mesh, but this should not be a problem. Do you think it would be beneficial to extend the mesh at its borders with "empty triangles" (which will be discarded by the geometry shader), to create a rectangular area? Most probably this is easier than to consider the different cases (especially when building a LOD hierarchy. > The approach would be about minimizing the amount of geometry data you pass > to the GPU, you could also balance the load by passing the tile mesh at a > lower or higher density. > > One thing to note is that you a mesh of 1000x1000 that fills the whole > screen will have roughly on vertex per pixel, with through even more data > than this will do nothing more for the visual effect other than overload all > your CPU + GPU memory, buses and processing. This means you should be able > to decimate your data pretty aggressively without affecting the visual > results if you chose your LOD scheme well. This is one of the crucial points. As far as I have seen, the domain experts often look at the complete mesh and then zoom in and investigate interesting regions. Therefore, I need a way to reduce the complexity of the data. Has anybody experience with an specific algorithm or can suggest one? To make things more interesting, the mesh, hence all of its LODs must be editable during runtime. Bummer. One idea would be to precompute the hierarchy at startup and change the different tiles of the LOD at runtime. Has anybody experience with this? > Personally I wouldn't chase up a CLOD scheme as it'll just overload the CPU > and buses between the CPU and GPU. You could look into using the GPU to do > CLOD, but I'd guess that efficiently storing the data will be the critical > thing rather than fine grained LOD. You are right. The efficient storage of the data is the most critical part. For the time beeing I will stick to LOD. I like the idea to use the GPU to perform a continuous LOD, but my priority now is to be able to display such huge grids with holes at interactive framerates and be able to manipulate (e.g. cut holes) them. Thanks for your input! Cheers, David _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
