Hi Robert,
Thanks for fixing the bug. I've now unzip your package and see the
layout. If I am to go ahead with integration we'll need to refactor
the code so that it's in the appropriate form and namespace. It also
looks like the existing ShadowMap implementation is effectively
deprecated. Personally I'd rather avoid have lots of different
ShadowMap versions that do almost exactly the same thing. Which
existing classes do you think could be replaced by yours?
I think the only equivalent is ViewDependenShadow::StandardShadowMap which
corresponds to ShadowMap functionality. But it can't be removed because it
serves as base class for other MinimalXXXShadowMap classes.
StandardShadowMap::ViewData::Cull and methods calls there defines steps
performed by all derived techniques.
Clearly this merge won't be a straight forward copy in the files and
recompile so this either means I will have to do the refactoring, and
reworking of coding style work myself or others will have to dive in.
I may do the neccessary refactoring to osgShadow. I am also ready to
implement or assist in other rearangments if you see such purpose.
Do this extent of changes this close to a 2.6 also seriously concerns
me, but if functionality I dearly love to have check in as it looks to
move osgShadow further along the road to having fully featured
shadowing.
This also concerns me. I would prefer smoother transition. Ie, first maybe I
will make advanced example, wait and see how its accepted by comunity, maybe
fix some issues that appear. Then after the dust settles move it into
osgShadow. But if you decide its worth to risk its inclusion, I am eager to
help.
Btw, at this stage I did not expect that we will make this final moveto
osgShadow. At first I merely wanted to hear your opinion and comments.
Robert.
On Thu, Jul 24, 2008 at 10:53 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
Hi,
Could you chase up this crash, if you can sort it then I'll do areview
of the submission and consider it for merge with SVN before
2.6.
Fixed version attached. Problem was related to some static switch I added
to
prevent recursive checks and displaying redundant warnings when solving
ConvexHull coherency issues. Of cource this backfired when program was ran
mulithreaded and two different ConvexHull operations were done
simultaneously. Since I mostly developed the code on single core machine
at
home I have not noticed this earlier.
Cheers,
Wojtek
On Wed, Jul 23, 2008 at 5:55 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
Hello Wojtek,
SingleThreaded and CullDrawThreadPerContext seem to not show this
assert.
Hm, interesting.
So I must admit this issue could have stayed unnoticed for some time. I
will take another look at this tomorrow.
It was not present in the previous version you had sent to osg-users, but
as
far as I can tell, the relevant code is completely different
(ConvexHull::extrude()). So that doesn't tell you much.
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
