Hi, me and my coleague have developed number of Shadow Volume shadow algorithms and we would like to contribute them one day to OSG.
To mention the reason for Shadow Volumes: They are often used in CAD, etc. as they work in screen space, thus they do not suffer with aliasing/resolution problems of Shadow Map-based algorithms. Surely, you pay the quality by the speed. But sometimes, you simply can not tolerate shadow artifacts and performance of shadow volumes on today graphics cards is basically excellent (in my eyes). My questions (probably on Robert) to best fit with OSG design: - My implementation covers number of methods (7-10 planned, 2 in developement, 4 finished) starting from simple cpu implementations and finishing by geometry shader and OpenCL implementations (silhouette based approaches). Thus I have family of classes like Occluder, OccluderGroup, ShadowDataBuilder, CpuSilhouetteDataBuilder, OpenCLSilhouetteOccluder.... (12 at the moment, and more on the way). I was considering to append them to osgShadow library, but I am worrying about some name clashes as, for instance, "Occluder" or "ShadowDataBuilder" are too general names and developers of Shadow Maps might (1) want to use them or (2) they might cause some confusion as there is already, for instance, OccluderGeometry class. Would you prefer to: (a) do not worry about clashes and simply use Occluder name as it is still not in use in osgShadow (the same with all other classes). (b) to create namespace osgShadowVolume and make ecosystem of classes of shadow maps and shadow volumes distinct - they really does not have much in common and probably only share just two abstract base classes: osgShadow::ShadowedScene and osgShadow::ShadowTechnique. Having two separate namespaces may make even doc more understandable because when looking for a particular class, I will look into the appropriate namespace and not to the mix of both shadow approaches. (c) prepend Occluder by a prefix SV, e.g. SVOccluder, SVOccluderGroup (d) prepend Occluder by ShadowVolume prefix, e.g. ShadowVolumeOccluder, ShadowVolumeVertexExtrusionDataBuilder, ShadowVolumeGeometryShader2DManifoldSilhouetteOccluder. I am just not sure if some names would not lost readability - 4 words in class name seems acceptable to me but adding two more seems too much. And surely, I would need to think how to make the longest names a little bit shorter - the last class still does not exist, but its full name would not be acceptable. (e) postpone the decision I am refactoring my code now so any suggestions welcomed. John _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
