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 <jean_...@videotron.ca> 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
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> ______________________________________________________
> Jean-Sebastien Guay jean_...@videotron.ca
> http://whitestar02.dyndns-web.com/
>
>
> _______________________________________________
> 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
