Hi Robert I know in our case we use vertex index arrays out of need, we have so much vertex data and have to share that many times that in our use cases we simply cannot have duplicate data , we simply cannot afford the memory bloat this would cause
While understand for many using osg::DrawElements*() is the best approach, that should not preclude others that need The older functionality. I certainly for one would not want this removed from osg::Geometry this is simply a critical need for us Gordon __________________________________________________________ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __________________________________________________________ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 03, 2008 7:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index out ofrangeinVertexPaletteManager Hi Andreas, I don't know if it fits what you require, but the osg::DrawElements*() primitive set types provide index support that is fully supported by OpenGL so works with the fast paths. The index support works for all per vertex attributes at the same time, so it's quite as flexible as vertex index arrays, so you may have to duplicate some vertex data that you previously didn't have to. Robert. On Wed, Dec 3, 2008 at 12:17 PM, Andreas Goebel <[EMAIL PROTECTED]> wrote: > Hi Paul & Robert, > > thanks for your explanations. I started with osg 0.96 and use 1.2 for > my software at the moment. At least in those versions I could not find > any deprecated-warnings. Also I did not chose osg for > performance-reasons primarily, but for it´s clean object orientated > interface. Performance is mostly uncritical for me, as I do not use very > large scenes. > > Those index arrays were useful for me, as my program allows to change > the geometries dynamically, and it is not guaranteed that all vertices > exist at all times (depending on what the user does). So it was very > easy to keep the > vertex- and normal arrays the same size all time and just add or > remove the indices depending on if a certain vertex exists or not. > > I will do the following: > - revert my changes to my own geometry not to use vertex and normal > indices anymore > - code geometries for shapes like sphere, cylinder, box, cone and > maybe some others. > > I don´t feel fit to replace the ShapeDrawables with a geometry-based > design, but I will be happy to post an example where those shapes are > rendered as geometries. I think this would be a useful example, as > some people tend to have problems with the math involved. > > One more question regarding the flt-exporter: I use the RT 3d Model > viewer plugin for firefox to display flt-files in a browser. The > background is black here. I don´t know if this is an error of that > plugin, or if the GL_CLEAR_COLOR is not yet exported by the exporter. > > Regards, > > Andreas > > Robert Osfield schrieb: >> >> Hi Paul, >> >> On Tue, Dec 2, 2008 at 8:57 PM, Paul Martz <[EMAIL PROTECTED]> wrote: >> >>> >>> You are correct that code can access ShapeDrawable primitive/vertex >>> data using the PrimitiveFunctor. Let me explain my thinking in more >>> detail... >>> ... >>> >> >> Thanks for the explanation. >> >> >>> >>> ... (I think there's a notify message when a Geometry takes the slow >>> path; perhaps we should bump up its verbosity to WARN.) >>> >> >> Perhaps this is something the Optimizer could do - have a warning >> pass, or just a conversion pass that generates all the osg::Geometry >> without indices - there is a method in osg::Geometry that does this >> already: >> >> bool suitableForOptimization() const; >> >> void copyToAndOptimize(Geometry& target); >> >> >>> >>> However, it seems to me that coding time would be better spent >>> optimizing one's data to not use sub-optimal rendering features. >>> >> >> It's curious how often I have strongly made the point about not using >> vertex indices for performance reasons, the comment in osg::Geometry >> next to all the vertex indices code is pretty clear too: >> >> /** deprecated - forces OpenGL slow path, just kept for backwards >> compatibility.*/ >> >> Yet users still want to use it. With the coming of OpenGL 3.0 and >> OpenGL ES and the lack of display lists and slow path support this is >> becoming even more of an issue. >> >> Something I've been planning on doing for a while is to move all >> vertex index support out of osg::Geometry to prevent this type of >> misuse of deprecated feature. Perhaps it's time for me to do it - >> support for reading old data files will be the awkward part. >> >> Robert. >> _______________________________________________ >> 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 _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
