Hi Tanguy, Thanks for chipping in. Could you point me at the latest rev your tri-stripper code.
One thing we will need to do is report your tri-stripping code to all the compilers/platform that the OSG users put it through, as we've had to merge quite a few build fixes over the years. For the OpenGL ES port I also had to remove the use of throw/catch from the tristripper code. It would be good to roll these changes back into your tri-stripper code. Good luck with your release, Robert. On Tue, Nov 24, 2009 at 11:52 AM, Tanguy Fautre <[email protected]> wrote: > Hi Emmanuel, Robert, > > I think most of the points have already been covered by you two guys, so I > won't come back on them. > > I'll however pick up on the fact that OSG is using a very old TriStripper > release (1.00 Beta 5). I'd heavily recommend updating to 1.10 B5. Compared to > 1.00 B5, there have been a lot of bug fixes (the most important being > segmentation faults and invalid iterators fixes) plus speed improvements (10% > to 50% faster depending on the platform). See the changelog for the full > details. > > I'd recommend updating OSG with the latest version. > > As the author of TriStripper, I'm guilty of not doing it myself. I sincerely > apologize for it. But as I'm currently responsible for managing the next > release of our product, I don't have time to do it in the near future. > > Roberts, note that if no-one has volunteered after a few weeks, just give me > some serious whipping and force me to do it. > > > Regards, > > Tanguy > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Robert > Osfield > Sent: 23 November 2009 2:30 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] TriStripVisitor issue > > Hi Manu, > > The TriStripVisitor shouldn't change anything in the data apart form > re-organize it. Adding in tolerances to the vertex comparisons would > require the vertex data to modified to collapse adjacent vertices's > onto the same position in space. > > Would could add such functionality as an extra pass to > TriStripVisitor, but the default would have to be not to do this. > Personally I'd suggest having a separate visitor do this operation of > collapsing nearby vertices on to one another, and then pre-process the > data before tri-stripping it. > > Robert. > > > > On Mon, Nov 23, 2009 at 2:25 PM, Emmanuel Roche > <[email protected]> wrote: >> Okay, >> >> more details on this: >> >> the problem comes from the helper structure "VertexAttribComparitor" >> >> in the function VertexAttribComparitor::compare(unsigned int lhs, unsigned >> int rhs) we call the template array compare(unsigned int lhs, unsigned int >> rhs) function, and there we just use regular comparisons: >> >> virtual int compare(unsigned int lhs,unsigned int rhs) const >> { >> const T& elem_lhs = (*this)[lhs]; >> const T& elem_rhs = (*this)[rhs]; >> if (elem_lhs<elem_rhs) return -1; >> if (elem_rhs<elem_lhs) return 1; >> return 0; >> } >> >> here we don't take any "precision" into account at all... whereas my >> vertices are given in meter units and may have a little resolution of about >> 0.1 millimeter ! >> >> So this implementation won't fit for my needs (and I think there is an high >> chance it may not fit the needs for many other people no ?) maybe we should >> add a "precision" parameter at some point, but for now I just don't have the >> time to deal with this properly :-) >> >> Cheers, >> Manu. >> >> >> 2009/11/23 Emmanuel Roche <[email protected]> >>> >>> Hi Robert, >>> >>> Actually, I've noticed that the problem doesn't come from the underlying >>> tristripper library: >>> >>> instead, it seems that the indice array generated from my vertices is >>> incorrect: I suspect that the comparison function to find if too vertices >>> are the same or not is too precise in my case. Do you have a clear idea >>> where this is done ? (otherwise, I will just read more code and find it...) >>> >>> cheers, >>> >>> Manu. >>> >>> >>> >>> 2009/11/23 Emmanuel Roche <[email protected]> >>>> >>>> Actually, I also noticed that OSG v2.8.1 uses version 1.0 of the >>>> tristripper library. >>>> >>>> As I'm quite in an hurry, I think I will re-implement my own >>>> tristripvisitor with the latest version of tristripper and check if this >>>> makes a difference. Will let you know what's the result of this test. >>>> >>>> But I believe this could really be a generic issue (it happens with all >>>> the models I tested) and thus would mean many people are currently using >>>> "not so well tri-stripped" geometries if they use this optimiser feature ! >>>> (it is the case for instance in the OSGExp export plugin for 3DS max as >>>> I've >>>> noticed this issue there for the first time). >>>> >>>> regards, >>>> Manu. >>>> >>>> >>>> >>>> 2009/11/23 Robert Osfield <[email protected]> >>>>> >>>>> Hi Manu, >>>>> >>>>> If the tristripper doesn't connect the triangles together well then it >>>>> can result on few tristrips and lots of unconnected traingles that it >>>>> has to put into a single list of triangles to avoid lots of separate >>>>> primitive calls. >>>>> >>>>> As to why your model is not being stripped well I can't say. We've >>>>> used 3rd party code to do the tri-stripping so I'm not best placed to >>>>> answer the low level questions, but... the original author of the cdoe >>>>> Tanguy Fautre is now an OSG user and I believe still on the list so >>>>> perhaps he'll be able to chip in ;-) >>>>> >>>>> Robert. >>>>> >>>>> On Mon, Nov 23, 2009 at 11:08 AM, Emmanuel Roche >>>>> <[email protected]> wrote: >>>>> > Hi everyone, >>>>> > >>>>> > I have a strange problem with the TryStripVisitor: >>>>> > >>>>> > When I use it on a model (with about 6000 triangles, described as >>>>> > TRIANGLES >>>>> > [thus using 18000 vertices]) I get trip strip primitive sets >>>>> > indeed.... BUT >>>>> > actually I get a few TRIANGLE_STRIP primitive sets with 4 vertices in >>>>> > each, >>>>> > and then a single big TRIANGLES primitive set with about 17950 >>>>> > vertices !!!! >>>>> > >>>>> > So, most of the model is just not stripped at all ! any idea what I >>>>> > could be >>>>> > doing wrong ??? >>>>> > >>>>> > Moreother, I've noticed that the geometry is then transformed as an >>>>> > indexed >>>>> > geometry... correct me if I'm wrong but indexed geometries are slower >>>>> > that >>>>> > simple vertices ordered arrays. If there a way to switch this or am I >>>>> > on my >>>>> > own on this ? >>>>> > >>>>> > Regards, >>>>> > Manu. >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>> >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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
