I need to maintain my focus on developing my app, so I'm not sure when I
could get to it. My small temporary fixes are enough to get me by
satisfactorily for the time being. It may not be worth me personally
spending time on, since ultimately my app will load content through other
channels than obj files(network mostly). I wanted to at least mention it so
someone that has a bigger stake at the obj file support might be interested
in improving it.. I happened to notice it when my code that constructs the
GUI hierarchy tree view ground to a halt trying to populate the tree with
191k items for each individual face.
On Sun, Jan 25, 2015 at 4:01 AM, Robert Osfield <robert.osfi...@gmail.com>
wrote:
> Hi Jeremy,
>
> I just had a quick look at the code. It's rather dated.
>
> I'd be inclined to replace almost all the code in the
> ReaderWriterOBJ::convertElementListToGeometry() method to one that uses
> DrawElementsUShort/UInt, and GL_TRIANGLES when handling the POLYGON, with
> the local method breaking up the polygons. One could possible use the glu
> tesselation routes if the POLYGON has concavities.
>
> Feel free to scalpel to it and we can then discuss the results :-)
>
> Robert.
>
>
>
> On 25 January 2015 at 05:30, Jeremy <jswig...@gmail.com> wrote:
>
>> I am working on a visualization/debugging UI and in the process of
>> displaying the scene graph to a tree view in my gui, I noticed that there
>> appears to be an issue with the .obj file loader that could be improved
>> significantly.
>>
>> The first problem I came to is seeing that the resulting osg::Geometry
>> node that comes from loading the obj had 191,000+
>> osg::Geometry::getNumPrimitiveSets(). Turns out, the obj reader creates
>> a osg::DrawArrays for each individual face of the model, and my particular
>> model 191639 faces.
>>
>> Not a huge deal I thought, I'll add a quick option to the reader to
>> optimize it before returning it, as I'm not so comfortable butchering up
>> the ReaderWriterOBJ::convertElementListToGeometry code as of yet.
>>
>> if ( localOptions.mergeMeshes )
>> {
>> osgUtil::Optimizer opt;
>> opt.optimize( node, osgUtil::Optimizer::MERGE_GEOMETRY );
>> }
>>
>> Surprisingly, this didn't work, and the culprit I found is that the
>> optimizer cannot merge geometry forTRIANGLE_FAN, which is what was being
>> used in ReaderWriterOBJ::convertElementListToGeometry for triangles.
>> Changing this to TRIANGLES allowed the optimizer to merge this huge number
>> of primitive sets down to 1.
>>
>> Here's a shot of the UI after my fixes where the model has been merged as
>> desired.
>>
>> https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
>>
>> Hopefully someone on the dev side can at least change the TRIANGLE_FAN
>> part trivially, though it would be nice if the reader didn't create such
>> bad primitive sets up front.
>>
>> Thanks
>> Jeremy
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
