On Thu, Sep 2, 2010 at 11:59 PM, Frank Sullivan <knarf.navil...@gmail.com>wrote:
> Hi, > > I am working on an ocean water effect that basically consists of a > tessellated plane that undulates in a wave-like motion. It's just a flat > plane, but it has a vertex shader that creates the wave motion by adding a > few sine waves together. > > And this is working perfectly well, but my problem is that I want this > ocean water surface to be about 2km^2, and I can't have that entire plane > heavily-tessellated, or I'll run into trouble. =) > > Not to mention extending out to the horizon... > So I need to make sure that only the parts of the water near the camera are > heavily-tessellated, and that the parts of the water further away are > less-heavily-tessellated. Pretty basic stuff for some of you pros, I'm sure. > =) > > So what I've decided to do is divide the water surface up into a grid of > cells, and give each cell a different tessellation level. A top-down view of > it might look something like this: > > http://imgur.com/cVR5T.gif > > As you can see, the closer a grid cell is to the camera, the more > heavily-tessellated it is. Also, note that if two cells of different > tessellation levels are adjacent to one another, the cell with the > lower-tessellation will have a special seam. Finally, the cells that are > shaded in gray should not be drawn, because they are not in the viewing > frustum. > > I don't want to totally re-compute the geometry for this each frame, so > I've precomputed a set of 36 cell meshes, which covers 6 levels of > tessellation, and 6 seam types for each level. Each of these pre-computed > meshes is an osg::Geometry object. I've done this so that, each frame, all I > have to do is decide which grid cells are in the frustum, and which of the > precomputed meshes to draw at each visible grid cell location. > > I'm not quite sure how best to do this within the OSG paradigm, though. I > thought about maybe creating an OceanGeode class that, during the cull > traversal, wipes out its list of drawables, and then calculates how the grid > should be laid-out, and then re-adds these Geometry objects back to its > drawables list. However, I'm not sure if I can add the same Geometry object > more than once, and even if I could, I'm not sure how I could instruct each > drawable to draw in a different location, because if I recall correctly, > drawables don't have their own transformation matrices. > > You can do this, but it involves some hairy interaction with OSG's draw code. You would first need to study the code for osgUtil::CullVisitor::apply(Geode&) and understand it. At this level you can, in fact, specify a different matrix for each Geometry, and you can also choose which Geometry objects to add to the rendering list with addDrawableAndDepth(). You would need to make sure that OceanGeode does the right thing in calculating the bounding volume of the patch. > To solve the last problem, I could pass down a grid coordinate to the > shader and have the vertex shader transform it to the correct place. That is > a possibility. > > Alternately, I could assign each pre-computed Geometry object to a separate > Geode, and then give each of these Geodes 0 or more MatrixTransform parents. > Then, each of those MatrixTransforms would share a single WaterNode parent > that manages them all. > > I've taken a similar approach in the Seamless terrain engine I'm working on. There, my Patch node keeps an array of geodes and dispatches the cull traverse to the appropriate ones based on the LOD calculations. The whole Patch sits under a MatrixTransform instead of assigning a MatrixTransform to each Geode. > Or perhaps I should make my own WaterDrawable! But that would require > knowing a great deal more about the whole rendering process in OSG than what > I currently know (but I'm willing to read up on it if it is documented > somewhere). > > That is probably a waste of time for you at this point. > Does anyone have any advice on this? Even if it's just to point me towards > an example or tutorial, that would be a huge help. I checked the Instancing > example, but in that example, the number of instances is decided at Geometry > creation time, and the positions of each of the instances is determined from > the InstanceID, which is not what I'm looking for. I looked at the > Precipitation example, which seems to have a similar scheme involving > drawing the same geometry over and over in different grid cells, but I found > it a bit difficult to understand. > > You can look at my evolving source code for the Seamless engine at http://gitorious.org/seamless. > And help would be greatly appreciated. > > Cheers, > Frank > Tim
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
