class to encapsulate the pixel coords, SceneView and picking operations in prep for
making the code more general purpose, and less reliant on classes like osgUtil::SceneView and osgUtil::IntersectVisitor.
Vivek's email to osg-submissions:
"I'm happy to release the osgdragger nodekit to the OSG community. I
implemented the nodekit for my company, Fugro-Jason Inc., and they
have kindly agreed to open source it.
The nodekit contains a few draggers but it should be easy to build new
draggers on top of it. The design of the nodekit is based on a
SIGGRAPH 2002 course - "Design and Implementation of Direct
Manipulation in 3D". You can find the course notes at
http://www.pauliface.com/Sigg02/index.html. Reading pages 20 - 29 of
the course notes should give you a fair understanding of how the
nodekit works.
The source code also contains an example of how to use the draggers."
structure of scene graphs. I only considered the case of DEEP_COPY_NODES,
but it is sufficient for me. It is not the most elegant way -- I used
a map to list all the already cloned nodes with multiple parents, to be
looked up whenever such a node is revisited. The good part is, it works."
From Robert Osfield, fixed build problems under Linux 64 due to use of int's to store Node*
in internal maps used in above custom CopyOp. Added ref_ptr<> usage to main to
prevent memory leaks
The issue was caused by the mutex in the ViewerDoubleBufferRenderingOperation being released even though they were not owned. This was causing the underlying critical section object lock count values becoming negative; the next time the lock was acquired it would block because of that."
as to not conflict with the program database file generated by the core
osgViewer library. This change allows for both the application and library
to be used in debugging mode within Visual Studio. This change has been
tested with Visual Studio 2005 (VS8)."
some of the files, the function readInt() would return
a 0 size. While linux will happily continue on,
creating 0 sized arrays, Windows immediately
blows up, with sparks sometimes flying out the
side of the machine!
I added a simple check for zero size in
each of the functions that allocates arrays
based on the size variable, and I thought
I'd pass it along. Now the program will
not die if it encounters an ive file with bad
data."
> I put this at the end of realizeImplementation; someone with better knowledge
> of Carbon programming may see a more appropriate place for the call.
I moved your code into the ctor of the OSXCarbonWindowingSystemInterface
so it get called only once. Can you test it again, if it works on your side?
I also disabled multithreaded-rendering because it slowed down the
rendering on my machine by a factor of 3. Perhaps we can make it
optional to test it on other machines.
I had some problems implementing pbuffer-support for os x and stopped it
for now until I have more time to investigate the issues.
"
