From Thomas Hogarth, "Attached is a small build fix for PointSprite when compiling under GLES2 (r13788)

GL_POINT_SPRITE_OES does not exist in GLES2, instead you just draw using GL_POINTS then use gl_PointSize in a vertex shader to set the size."
From Adrien Grandemange, "On Windows 7 and 8, mouse messages are generated in addition to touch messages, which leads to duplicate PUSH, DRAG and RELEASE events in OSG. Besides, the mouse and touch messages referring to the same user input are not necessarily sent at the same time, due to gesture translation done by Windows by default, such as double-tap => double-click and long-push => right-click.
The delay between the 2 types of messages is more noticeable on Windows 8 and leads to serious disruptions in our application.

Mouse messages generated by touch input are only present for legacy support. I think they should be filtered out by OSG (real click events originating from a physical mouse will of course still go through).

This is what this patch does, according to this suggestion: http://msdn.microsoft.com/en-us/library/dd693088%28v=VS.85%29.aspx (third issue in this page)."
From Christopher Baker, submitted by Alberto Luacas, "there is a bug report in the Ubuntu tracker that points to a bug when
loading multiple VRML files in parallel.  Christopher R. Baker has
detected this bug and crafted a patch.  In addition, libcoin has to be
also built with the "--enable-threadsafe" option.

I copy here his report, extracted from
(https://bugs.launchpad.net/ubuntu/+source/openscenegraph/+bug/1211993)
and attach his fix.  All credit is due to him:

«
There are three instances of a classical method-local-static
multithreaded initialization bug in the Inventor plugin for OSG that
trigger various memory faults when reading multiple VRML files in
parallel via osgDB::readNodeFile. These bugs are of the form:

static std::map<Stuff,OtherStuff> myHandyMap;
static bool once = true;
if(once) { ...fill myHandyMap; once = false }
... use myHandyMap;

To repeat: try loading multiple VRML files from multiple threads. The
liklihood of the bug depends on many factors, but my application, which
parallel-loads some dozens of small (<100K) VRML files on startup,
triggers this problem 25% of the time or more.

The attached patch (inventor-plugin-multithread.patch) rectifies this
problem by:

1 - Inheriting MyHandyMap from std::map, then
2 - Moving the map initialization into the derived constructor, which
3 - Is intrinsically protected from multithread issues by g++ (and is
part of the C++ standard), unless you pass -fno-threadsafe-statics,
which is strongly discouraged by the man page.
»
"
From Björn Blissing, "I propose making the following outputs a little bit more silent. In my mind it would suffice with OSG_DEBUG (compared to OSG_NOTICE) for these information messages."
From Aurelien Albert, "I'm working with OSG and a customer low-level OpenGL library.

To make easier "lazy apply" on the customer OpenGL shaders, the easiest way was to add an accessor to current OSG state's UniformMap.

I've also added accessors for modes and texture, since it could be usefull in the same way.

All methods are const, so I think there is no side-effects."
Updated ChangeLog in prep for dev release
Updated AUTHORS files
Fixed build with no automatic ref_ptr<> conversion
From Björn Hein, "it seems that for generating "per vertex normals" as stated in the
comment, two of them are missing. This results in wrong display of
STL-files regarding normals. Following simple fix seems to work:

Index: ReaderWriterSTL.cpp
===================================================================
--- ReaderWriterSTL.cpp    (Revision 13797)
+++ ReaderWriterSTL.cpp    (Arbeitskopie)
@@ -108,6 +108,8 @@
                     ++itr)
                 {
                     perVertexNormals->push_back(*itr);
+                    perVertexNormals->push_back(*itr);
+                    perVertexNormals->push_back(*itr);
                 }

                 geom->setNormalArray(perVertexNormals.get(),
osg::Array::BIND_PER_VERTEX);
"
Re-ordered the public/protected sections to keep the public section all together
From Dmitry Marakasov, "These are FreeBSD bits for src/osgPlugins/osc/osc/OscHostEndianness.h,
required to build newever OSG on this OS. Also corrects file name
in the error message - I was confused not to find OSCHostEndianness.h
after I've got this error.

Tested by successfully building OSG 3.2.0 with this patch on FreeBSD
9.1."
From Colin McDonald and Robert Osfield, "When a serializer shared library is loaded it registers all of
the wrappers it contains.  The registration creates a prototype
object for all of the wrapped classes.  For some of the higher-level
classes this can be a bit heavy.

I noticed a problem with a model which required a single class from
osgSim.  When osgdb_serializers_osgsim.so was loaded it registered
wrappers and created prototype objects for all of the osgSim classes,
including osgSim::ScalarBar.  The constructor for that class creates
several drawables, and loads arial.ttf using the freetype plugin.  I
don't need that, and don't even ship the font or plugin with my
application, resulting in an unexplained warning message loading
the model.

I've modified the ObjectWrapper class to defer the prototype object
creation until if & when actually required."
From Jan Peciva, RayIntersector implementation
Fixed errors in Contributors list
Updated version number after 3.3.0 dev release
Added createObject() interface
Added support for Lua 5.2 and osg::Object creation from within Lua scripts.
Moved code across to use lua_userdata to manage pointer to osg::Object that is ref()/unref()
Added support for automatically select Lua 5.2 is it's available, then falling back to checking for Lua 5.1 otherwise.
Cleaned up line endings