Re: [osg-users] per-facet normals for flat facets
Butler, Lee Mr CIV USA USAMC wrote: 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. There are separate index arrays for each vertex attribute (setVertexIndices(), setNormalIndices(), etc), but there are two problems with this: First, as you've noticed, the OBJ loader plugin won't do this for you, so at the very least you'd have to modify it. (This should be really easy to do because of the way the OBJ format is laid out). Second, using the index lists will force you to use OpenGL immediate mode (glBegin, glEnd), which is terribly slow. This interface has even been removed from OpenGL 3. If you really have so much data to display that you're having trouble fitting it in memory, I doubt you'll get so much as 0.1 frames per second using immediate mode. Maybe this isn't a problem for your particular application, I don't know. Most of OSG takes great pains to avoid immediate mode, but it's there if you need it. Hope this helps... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] per-facet normals for flat facets
Butler, Lee Mr CIV USA USAMC wrote on Monday, June 01, 2009 1:55 PM:
I'm looking for ways to efficiently store/display geometry with flat
facets. That is to say, I want all creases (no interpolated
normals).
I'm reading some hefty geometry (10-20M polys) for display (Currently
in
OBJ format). There are only hundreds of unique normals. The OBJ
loader
tristrips everything and computes per-vertex normals.
Since I'm bumping up against the memory address limit on 32bit
machines
when using this geometry, I'd *really* like to recoup the storage for
all those (redundant) normals. I think using short ints for 'normal
indexes' instead of per-vertex normals would buy me a fair bit of
space.
Can anyone offer any pointers/guidance?
Lee
Hi Lee,
I don't know anything about the OBJ loader except what 'osgconv --format
obj' tells me. Do the 'noTesselateLargePolygons' or 'noTriStripPolygons'
help?
$ osgconv --format obj
Plugin osgPlugins-2.9.5/osgdb_obj.dll
{
ReaderWriter : Wavefront OBJ Reader
{
features : readNode writeObject writeNode
extensions : .objAlias Wavefront OBJ
format
options: AMBIENT=unit Set texture unit for
ambient texture
options: BUMP=unit Set texture unit for
bumpmap texture
options: DIFFUSE=unit Set texture unit for
diffuse texture
options: DISPLACEMENT=unit Set texture unit for
displacement texture
options: OPACITY=unit Set texture unit for
opacity/dissolve texture
options: REFLECTION=unit Set texture unit for
reflection texture
options: SPECULAR=unit Set texture unit for
specular texture
options: SPECULAR_EXPONENT=unitSet texture unit for
specular exponent texture
options: noRotation Do not do the default
rotate about X axis
options: noTesselateLargePolygonsDo not do the default
tesselation of large polygons
options: noTriStripPolygons Do not do the default
tri stripping of polygons
}
}
HTH,
--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] per-facet normals for flat facets
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] per-facet normals for flat facets
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
