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
