Hi Tanguy,
It's several years since I wrote the below code, but from looking at
it now it looks like I was experimenting with adding a tolerance value
to account for numerical errors. In this case the tolerance is set to
0.0 so in effect the n1 = cos(acosf(n1)) will cancel out to not change
the n1 value so this line is in effect superfluous and could be
removed.
My work on shadow volumes never came to fruition, as I got swamped by
other work before I could resolve all the issues of handling awkward
geometry cases - i.e. it works for well conditioned data but fails on
imperfectly conditioned data. Elements like the non optimized code is
an illustration that the code is still rather in the dev phase rather
than production phase. When I get some quiet time my plan is to
revisit this code and complete the job, or perhaps just deprecate it
as these days there are better ways of doing shadows than shadow
volumes.
Cheers,
Robert.
On Mon, Oct 12, 2009 at 5:47 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Hi,
I need to check whether an object occludes another object behind it. To do
so, I currently use a class derived from osgShadow::OccluderGeometry to
compute the occlude silouhette from the camera point of view, and create an
osg::Polytope from that silouhette.
Going through osgShadow::OccluderGeometry code, I noticed that the
silouhette is computed via two odd looking functions. For example:
inline bool isLightPointSilhouetteEdge(const osg::Vec3 lightpos, const
Edge edge) const
{
if (edge.boundaryEdge()) return true;
float offset = 0.0f;
osg::Vec3 delta(lightpos-_vertices[edge._p1]);
delta.normalize();
float n1 = delta * _triangleNormals[edge._t1] + offset;
float n2 = delta * _triangleNormals[edge._t2] + offset;
float angle_offset = 0.0f;
n1 = cos(acosf(n1) + angle_offset);
n2 = cos(acosf(n2) + angle_offset);
if (n1==0.0f n2==0.0f) return false;
return n1*n2 = 0.0f;
}
What puzzles me is the double calls to cos() and acosf(), as this is very
expensive. Having worked a long time ago on stencil shadows, I looked back
at my old code. It appears I was using the triangles plane equation and then
doing a dot product with the light position. Since the plane equations need
only to be computed once, this was a very fast way of doing it (and works
for both directional and point light). I wonder what are the advantages of
the current osg implementation.
My old code looked something like this:
void ComputeVisibility()
{
for (size_t i = 0; i m_Planes.size(); ++i) {
const plane_eq Plane = m_Planes[i];
double Side = 0.0;
Side += Plane.a * LightPosition[0];
Side += Plane.b * LightPosition[1];
Side += Plane.c * LightPosition[2];
Side += Plane.d * LightPosition[3];
if (Side 0)
m_Triangles[i].mark();
else
m_Triangles[i].unmark();
}
}
Cheers,
Tanguy
Note:
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. THIS COMPANY NAME and any of its subsidiaries each reserve the
right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender,
except where the message states otherwise and the sender is authorized to
state them to be the views of any such entity.
Thank You.
___
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
