Introduced a new FindFileCallback to Registry to compliement the existing ReadFileCallback and WriteFileCallback.
Added support for assign Find, Read and WriteFileCallbacks to osdDB::Options to enable plugins/applications to override the callbacks just for that
read/write call and any nested file operations
Converted Present3D across from using libxml2 to using the new osgDB::XmlNode/XmlNode::Input classes from Xml Parsing.
This changes removes the dependency on libxml2, and allows the present3D application and p3d to work on all platforms.
This fix reverses the vertex order and sets up proper OpenGL facing. I didn't notice this problem until I started using the plug-in in my own code (osgviewer seems to not enable backface culling)."
"Attached is the osg-plugin for reading ply ( Stanford Triangle Format ) file. I have written the plugin according to OSG standard and have also added cmake build system. The plugin is working fine on both Linux and Windows and should behave similarly on other OS as well."
"I developed this plugin while working on a project based on Equalizer. So VertexData which I am using is taken from equalizer and modified to make them work as separate OSG plugin.
Before contributing this plugin to OSG community, I asked project manager of Equalizer project Stefen regarding potential licensing issues and this is what he has said
"The kd-Tree (VertexBuffer*) is LGPL-licensed, and the base ply loader (ply*) is BSD. As long as you leave the copyright notices intact, there is no issue."
so I think using these files in OSG should not be a problem.
As far as author of ReaderWriterPLY.cpp is concerned I am the author. I am working for Darshan3d which is a subsidiary of VizExperts thats why I have put VizExperts copyright."
From Robert Osfield, refactor of the above code to retain a bit more of the original funcionality, and to avoid the need to hand maintained XCode projects from being updated.
(http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg23098.html)
Background: when you access a file over HTTP, you cannot rely on a file extension being present; instead the file's mime-type is conveyed in the HTTP Content-Type response header. This facility adds a mime-type-to-extension map to the registry to handle this.
There are two new osgDB::Registry functions which are pretty self-explanatory:
void addMimeTypeExtensionMapping( mime-type, extension )
ReaderWriter* getReaderWriterForMimeType( mime-type )
I also added the file osgDB/MimeTypes.cpp which houses a hard-coded list of built-in types. I took the list from here (http://www.webmaster-toolkit.com/mime-types.shtml) and then pared it down to include mostly image and video types, editing them to map to existing plugins where possible.
In addition, I updated the CURL plugin to a) install a set of built-in mime-type mappings, and b) use them to look up an extension in the event that the target filename does not have an extension.
Here is a test case. This URL pulls down a JPEG (without a file extension):
osgviewer --image "http://us.maps3.yimg.com/aerial.maps.yimg.com/ximg?v=1.8&s=256&t=a&r=1&x=0&y=0&z=2"
"
It adds two options:
Accuracy(x) - ensures the polyline will be within x units from the ideal arc/curve
ImproveAccuracyOnly - do not use the given accuracy 'x', if it would result in a worse curve than with the previous (2.8.0) implementation for a particular arc/curve.
As an added bonus there was a small bug in the existing implementation whereby the primitives were line strips but the vertices generated were actually suitable for GL_LINES, so the improved accuracy doesn't even have to come at a performance cost :-)"
to make is easier to write code that can work on DrawElementUByte, UShort or UInt.
Changed the osgTerrain::GeometryTechnique so that it automatically chooses
the use of DrawElementUShort or DrawElementsUInt accordining to the size of the tile.
