Paul, My CAD data comes to me as a triangle "soup" without surface normals. Right now it comes to me as wavefront OBJ format.
Item 1: I would rather not display any "smoothing". That looks like it will take mods to the obj plugin to avoid the smoothing (unless someone can point me at something else). Item 2: The majority of normals point along one of the 6 major axis directions (or a small number of other directions). I could easily quantize to byte (not float) normals and be quite happy. But I think that gets me writing shaders, which I was hoping to avoid. I had thought there was a way to tell OpenGL to use an index indirection table for elements. My thought was I could load a small array of normals, an array of vertexes, and an array of indexes which maps the vertex index to the normal index. Alas, I don't seem to be able to figure out the nuance of this in OSG (or OpenGL) at the moment. Lee PS. If I could afford an NVIDIA Quadro FX 5800 for all my systems I'd just load the geometry onto the graphics card and be happy. On Mon, 2009-06-01 at 14:15 -0600, Paul Martz wrote: > Your problem seems to stem from having to repeat vertices multiple times so > that each can have its own vertex. For example, let's say you need to repeat > each vertex 4 times because it is shared by 4 different facets. This means > you have xyz vert/norm (24 bytes) * 4 * 20M = ~2GB. Do I understand the > issue correctly? > > You don't want to specify the normal once per facet because that will send > you down the OpenGL slow path (setting normal binding to > BIND_PER_PRIMITIVE). But this would be the easiest change and fastest course > of action, and with display lists on, this could still produce acceptable > performance. > > There are normal compression schemes. I patented one while at HP that is > lossy but allows you to specify a variable amount of compression. In our > work, we found that a 6:1 compression ration (store the normal as a 2-byte > short) still produced pretty good visual results. If you search for my name > in any patent search engine you can find more info. This algorithm was > storage-efficient but not computationally efficient. > > For a computationally efficient algorithm, try representing the xyz > components as 10 bit signed ints stored in a single word and then unpack > them in a shader. > > Special data types allow other types of normal compression. For example, > bump maps, or normals for heightfield data, only need two components. The > third can always be derived. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
