Hi Robert and J-S, thanks for suggestions. The namespace trick seems interesting. I will try to lead our code in this direction. John
On Friday 01 of February 2013 09:05:47 Robert Osfield wrote: > Hi Johan and J&S, > > My inclination would be towards using a nested namespace as suggest by > J-S, this will avoid wider namespace pollution with generic names, but > still allow the implementation to use the short hand and end up with > more readable code. Another twist on this is to use the class as a > namespace, so have the support classes nested within the > ShadowTechnique implementation. > > Robert. > > On 1 February 2013 00:38, Jean-Sébastien Guay <[email protected]> wrote: > > Hi John, > > > > One suggestion, you could use nested namespaces, and then abbreviate > > locally so it's easier to read. For example: > > > > > > namespace osgShadow > > { > > > > namespace ShadowVolume > > { > > > > class Occluder { ... } > > > > } > > > > } > > > > // then in some .cpp file where you need to use it: > > > > namespace osgsv = osgShadow::ShadowVolume; > > > > void someFunction() > > { > > > > osg::ref_ptr<osgsv::Occluder> occluder = new osgsv::Occluder; > > > > } > > > > That way we don't need a new separate "top-level" namespace, it shows it's > > clearly a shadow technique so it's in osgShadow, yet it's separate from > > the > > other osgShadow code so you prevent name clashes. And using the > > abbreviated > > name locally helps with code that would become really verbose and hard to > > read, while not being ambiguous like "using namespace ..." in the case > > some > > classes have the same name eventually. > > > > Just a suggestion, I don't know if Robert will like this style, he may > > prefer one of your other suggestions but this is another alternative to > > add > > to the mix. > > > > J-S > > > > On 31/01/2013 5:21 AM, PCJohn wrote: > >> 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 > > > > -- > > ______________________________________________________ > > Jean-Sebastien Guay [email protected] > > > > http://whitestar02.dyndns-web.com/ > > > > _______________________________________________ > > 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
