I worked with a osg::Constraint and found strange part of code:
class OSGMANIPULATOR_EXPORT Constraint : public osg::Referenced
{
public:
...
virtual bool constrain(ScaleUniformCommand& command) const { return constrain((MotionCommand&)command); }
virtual bool constrain(const Rotate3DCommand& command) { return constrain((MotionCommand&)command); }
...
If i use osgManipulator::Rotate3DCommand then method Rotate3DCommand::accept(const Constraint& constraint) calls Constraint::constrain(MotionCommand&) instead Constraint:: constrain(const Rotate3DCommand&).
If you replace
virtual bool constrain(const Rotate3DCommand& command) { return constrain((MotionCommand&)command); }
on to
virtual bool constrain(Rotate3DCommand& command) const { return constrain((MotionCommand&)command); }
then all works correctly.
"
I tested it with clang 3.1 and it seems that clang is enforcing the use of the same type for all parameters in this builtin. Looking at the function declaration [1]
bool __sync_bool_compare_and_swap (type *ptr, type oldval type newval, ...)
it seems to be doing the right thing: here the same type is used for *ptr, oldval and newval.
[1] http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#g_t_005f_005fsync-Builtins
"
and TabPlaneDragger.cpp:
TabPlaneDragger(float handleScaleFactor=20.0f);
The reason for this is that the default OSG tab sizes are way bigger than
those we used in our application so far. And since handleScaleFactor_
is already a (constant) class member, I see no objection against making
it user defined."
My previous patch for Atomic Counter Uniform provide new template implementation
of Matrix{2,3,4}x{2,3,4}{fd}. This new implementation use Column-Major Matrix.
Original code define matrix as Row-Major matrix like other Matrix in OSG, and
my matrix implementation break compatibility with previous code.
For example osg_normalMatrix define in osg::State report by Roland Hill.
Thanks to Paul Martz to spot me when the bug appear."
- add non square matrix
- add double
- add all uniform type available in OpenGL 4.2
- backward compatibility for Matrixd to set/get an float uniform matrix
- update of IVE / Wrapper ReadWriter
implementation of AtomicCounterBuffer based on BufferIndexBinding
add example that use AtomicCounterBuffer and show rendering order of fragments,
original idea from geeks3d.com."
I have also made changes to the RotateCylinderDragger to provide a cylinder ring with a thickness. It is totally optional, but IMHO makes the default behavior work better than a solid cylinder (which typically obscures the geometry you are trying to drag). Gives it a bit more to grab, especially in the case where eyepoint and cylinder axis are near parallel.
"
* If the eyepoint and cylinder axis are close to parallel (given some tolerance), then it uses a plane perpendicular to the cylinder axis.
* Otherwise it uses a plane parallel to the cylinder axis oriented towards the eyepoint (previous behavior). This gives decent behavior and is the only path that was taken in the previous code. I kept with previous behavior and that allowed a good bit of code to be removed, simplifying things. There is now no need for the _onCylinder flag, but since there is a public accessor, I wasn't sure how to handle it for backwards compatibility, so I left it in. NOTE - there is no default initialized value, so if it is kept in, it should be set to 'false' to keep same behavior as before. I am not quite sure how the _onCylinder case was supposed to behave as even forcing that path gave undesirable behavior, even with carefully controlled dragging.
"
in osg::Program::PerContextProgram :
typedef std::vector<UniformModifiedCountPair> LastAppliedUniformList;
should be
typedef std::map<unsigned int, UniformModifiedCountPair> LastAppliedUniformList;
Intel driver can use index uniform value > 200000.
With a std::vector, this index uniform value generate an out of memory error
Nothing in OpenGL or GLSL specification define index uniform value rules.
And all other implementation that deal with uniform index in osg::Program
use a std::map.
This fix could have a little performance impact but this is the cost
to pay to work with
all driver."
