Hi Marcel, Your work sounds really interesting. I don't have time right now to dive in and have a look at the project - I have a backlog of submissions to deal with before I can play. I will try and chip with providing some thoughts on your questions.
On 19 April 2014 19:15, Marcel Pursche <marcel.purs...@student.hpi.uni-potsdam.de> wrote: > 1. I'm currently using custom PopDrawElements classes that inherit from > DrawElementsUByte, *UShort, or *UInt. The only difference is that they > support a start offset and end. So let's say a DrawElements contains 3000 > indices I can set the start and end so that only the first 300 are drawn. > Because this is only a very small extension to the original DrawElements > classes I would put that code directly into these classes. I think that > shouldn't break existing apps, because setting these additional parameters is > optional. It sounds a bit like you want to have lots of separate DrawElements* that share the same index data buffer, but index it with different offsets, kinda like a proxy method. Sharing the data could actually be down if the DrawElements share the same ElementBufferObject, then the DrawElements* objects would all populate the same data buffer and provide the existing support buffer object support would handle the offsets for you. Are you PopDrawElements computed on the fly? > 2. The naming of the classes is a bit odd, because they describe how the > functionality was implemented and not what the classes do. Instead of > PopGeometry I would rename it to LodGeometry. Any objections or better names? PopGeometry is a bit mis-leading as push/pop have particular means in OpenGL and C++ etc, it would lead one to think you are push and popping Geometry. It's less confusing if you know about the 3DDOM POP Buffers paper, but most won't be. LODGeometry or LevelOfDetailGeometry might be better. > > 3. I'm not quite sure in which namespace the classes would belong. The > PopGeometry/LodGeomtry would probably fit best in the osg namespace and the > visitor in osgUtil. Is this a good idea? osgUtil is for utility classes rather than scene graph objects. osgSim or osgTerrain might be appropriate, or in core OSG if it's something that lots of users would utilize. Whether they might I can't say as I'm not familiar with the approach. > 4. My conversion visitor currently only supports the BIND_PER_VERTEX option > for vertex attributes, so there is still some work to do. What binding > options are still relevant? BIND_OVERALL and BIND_PER_PRIMTIVE_SET? Or do I > need to integrate BIND_PER_PRIMITIVE support as well for older models and > applications? You can safely ignore BIND_PER_PRIMITIVE it's long been deprecated and loaders should no longer create objects with this type, and old files will automatically converted. The other types are all valid thought. > 5. Because the technique depends on the usage of a vertex shader I would add > two static methods one returns a basic osg::Program with phong shading and > another one only returns the shader code with the necessary uniforms and a > vertex quantization function that should be used in the shader. I don't know the code so can't comment on the low level specifics of how to manage the shaders for it. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
