will bring the change in line with what is done on other OSes (Linux)
and works in all tested cases.
For reference, this was tested with:
osgviewer <file>.wrl (file in current directory)
osgviewer <dir>\<file>.wrl (file in child directory, relative)
osgviewer .\<dir>\<file>.wrl (file in child directory, specify current)
osgviewer <drive>:\<dir>\<file>.wrl (absolute path)
"
OpenVRML 0.14.3 and is without the Boost dependency.
The changes:
- - Fixed loading of textures and normals when no corresponding indices
are specified. It uses vertex indices now, compliant with the VRML spec.
- - Added colour per vertex support.
- - Added group node support.
- - Changed the code to use osg::ref_ptr instead of naked pointers to
avoid memory leaks.
- - Fixed breakage for loading files specified by relative path."
Attached a modification that read the HeigthField position and X,Yintervals.
I also removed the limitation to 1024*1024 to 4096*4096, because when you are preprocessing your data with OSG, it can be useful to read large images/heigthfields. Is there a reason (other than hardware limitations for textures) for this limit ?"
various operating system differences between socklen_t and int have
broken the FreeBSD build. Change was to add __FreeBSD__ to the list of
defines that are checked."
of the source file:
The "delete [] path" appears before the "osg::notify", causing the data pointed to by
"filename" to be deleted before access causing an access violation.
...
I have put a comment on
line 521 where I have moved the "delete []path" below.
"
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
COLLADA modules STLDatabase, LIBXMLPlugin and stdErrPlugin are
statically included in the main COLLADA library on Linux and shouldn't
be linked separately - those libraries do not exist in the default Linux
build and the compilation will fail.
Second issue - the current version of the COLLADA plugin (both current
HEAD in Subversion and the one in stable 2.0) do not work right with the
stable COLLADA DOM 1.4.1. I am getting the following error:
"
is not the usual OpenGL BOTTOM_LEFT orientation, but with the origin TOP_LEFT. This
allows geometry setup code to flip the t tex coord to render the movie the correct way up.
R3G3B2, R5G6B5, A1R5G5B5, X1R5G5B5, A4R4G4B4, X4R4G4B4, R8G8B8 (now
without swaping of red and blue), A8R8G8B8 (also w/o swapping),
X8R8G8B8, A8B8G8R8, X8B8G8R8, A2R10G10B10, A2B10G10R10, L4A4 (not work
on my machine), L16A16, L16, A16B16G16R16, A16B16G16R16F,
Q16W16V16U16, R32F, R16F and A32B32G32R32F.
And these ones are correctly detected, but prints "unsupported" using
osg::notify(osg::WARN) and are not loaded:
A8R3G3B2, G16R16, G16R16F, G32R32F and CxV8U8.
Also added checking of not supported DDPF_BUMPDUDV (V8U8, V16U16,
Q8W8U8L8, A2W10U10V10 etc.) and DDPF_BUMPLUMINANCE (L6V5U5, X8L8V8U8,
etc.) pixel formats.
Mipmap handling is slightly modified and now support all additional formats.
"
old loader, but appear very, very wrong with the new one. I traced the
problem to the handling of the palette override flags in the external
reference records. The current behavior for handling the palette
override flags for external references has different offsets for
different OpenFlight version (2 bytes for 14.2-15.1 and 4 bytes for 15.2
and later). However, I believe this behavior is incorrect.
I know that the original 14.2 OpenFlight spec (dated April 1995)
specifies 2 bytes between the filename and the override flags, and the
15.4 and later specs specify 4 bytes. However, I also found a 14.2.4
OpenFlight spec (dated January 1996) that changes the specification to 4
bytes. Also, the databases in question were created using an old IRIX
version of MultiGen II, which wrote OpenFlight 14.2 files natively.
These files also have 4 bytes between the filename and flags.
Furthermore, these databases have always worked properly under earlier
versions of OSG, under Performer, and in every MultiGen product we've used.
This leads me to believe that the original 14.2 spec was incorrect (the
14.2.4 spec corrected this error), and there should be 4 bytes between
the filename and flags for all OpenFlight files version 14.2 and later.
The attached fix modifies the OpenFlight loader to behave in this way."
Currently, if the texture attribute file doesn't explicitly specify an
internal format, the loader will force it to use GL_RGB, which keeps
translucent textures (eg. GL_RGBA textures) from showing up properly.
This patch changes the default behavior to simply use the image's format
instead of forcing a particular format."
