"Geometry.cpp
Make sure number of normals match number of vertices when lit or
vertex-normal pairs are separated when geometries are merged by the
optimizer.
Ancillary.cpp
Improved support for multitexture effect field and use texture
environment from .attr file.
PaletteRecords.cpp
Use search path when looking for shader files.
PrimaryRecords.cpp
Added preset uniforms "TextureUnit0", "TextureUnit1", "TextureUnit2"
and "TextureUnit3" for GLSL shaders."
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."
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."
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.
"
