I understand your feeling about the example, it was just for preliminary test...
If you want I'm working on a TransformFeedBackGeometry that integrate better in
osg
(As interleaved_attribs is not allowed in osg it only works for separate_buffer
feedback mode:
the only difference with a normal Geometry is that all vecArray are stored in a
differents buffers.
)
But I face the problem that one could want to generate partially their
geometry( for ex: generate vertexcoord but keep texcoord), so i may add
properties for it.
robertosfield wrote:
> Hi Julien,
>
>
> Thanks for porting the changes to svn/trunk.
>
> I have now merged the changes with svn/trunk, albeit with a some tweaks to
> parameter usage and addition/removal of spacing to make the code more
> consistent with the rest of the OSG and more readable. I have also updated
> the code to better use the new GLExtensions access, and put the new
> serializer additions within a version checked block whilst updating the
> SO_VERSION to pick up on this new version of the API.
>
>
> I have reviewed the osgtransformfeedback example and have checked it in with
> a few formatting tweaks but otherwise left as is. I'm not entirely happy
> with the way the example is constructed. I'm hopeful that a cleaner way of
> integrating the transform feedback functionality is possible but don't yet
> have enough familiarity with extension to feel comfortable diving in a
> re-factoring.
>
> My initial feeling is that osgtransformfeedback example could be improved by:
>
> from a C++ perspective the C pointers usage is something I feel needs
> removing as this the way it's done in the example could lead to
>
> other users copying poor C++/OSG practices
>
>
> There subclassing from osg::Geometry that look to me like they would be
> better replaced with something more generic, perhaps using a
>
> DrawCallback and usage of osg::StateSet.
>
>
> The draw order isn't controlled in the example, so it would there is
> nothing stopping the two osg::Geometry being passed to OpenGL in
>
> the wrong order. The OSG has lots of different ways to control render
> order, but which is most appropriate will depend on the needs of
>
> the application. One can do high level control via placing the
> pre-render stage into a subgraph below an osg::Camera and set it's
> RenderOrder to pre render, a lower level way would be to use the
> StateSet::setRenderBin("RenderBin", -1) to make sure it renders first.
>
>
>
> The Uniform callback seems a bit overkill too - one can compute time
> based variables all the vertex shader, this would be simpler and
>
> faster.
>
>
> I will leave further refinement of this example till others or yourself chip
> in, or for when I get a chance to reflect more on how to better set up
> transform feedback codes in the scene graph. The important thing right now
> is we now have some working transform feedback code and example that can be
> built upon going forward.
>
>
> Thanks,
>
> Robert.
>
> ------------------
> Post generated by Mail2Forum
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62247#62247
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
