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.
"
changes I made:
+ put a warning in the console if a nonexistant screen is requested
+ add getters for the aglcontext and pixelformat -- I need access to
them in my own code.
"
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."
files got messed up, most notiably the Nib and also the Localized
strings file. I didn't notice the latter until now so Martin is
missing this file.
Anyway, the attached tar contains all new versions of all the
necessary files. There are cleanups and fixes to a lot of things.
Martin did a good job porting the thing to osg::Viewer so most of the
code changes I made address other areas.
Two things I noticed in the new port you might want to consider as
feedback. First, there might be a bug with osgViewer when the view
size goes to 0. If you play with the splitviews in this program and
shrink the view until it is closed, and then re-expand it, the model
doesn't come back, not even after a home() call. SimpleViewer didn't
have this problem.
Second, a more minor thing, this program has a
take-screenshot--and-copy-to-clipboard feature via Cmd-C (or Menu
item). I achieve this by using osg::Camera to render to an FBO and
then copy the contents to Cocoa. To insert the camera, I manipulate
the scenegraph so I can get the camera node in and out. I end up
calling setSceneData at the end of eveything to restore everything to
the original state before I started mucking with the scenegraph. This
unfortunately, triggers a home() reset. So in this particular case, it
make Copy look like it's changing the scene. The old SimpleViewer had
the same problem, but I was able to work around it by directly
invoking the underlying SceneView's setSceneData so the home()
mechanism was bypassed. The viewer design seems to protect this data
more carefully so the bypass trick won't work. My feedback is that
maybe a flag or extra parameter can be introduced so a reset is not
triggered if not desired.
I have checked in a ton of Xcode fixes for the entire build process in
general so once this piece gets checked in, hopefully everything will
build cleanly."
the declaring file for a given type via the new member function
osgIntrospection::Type::getDeclaringFile. This information is useful
in order to know what header to include when auto-generating wrappers
for a given type.
During the C# wrapper generator development I've been keeping the
declaring file configuration state up-to-date manually with changes
to OSG, and it's proven to require substantial effort. So it would be
extremely valuable to get this change in before 2.0 to reduce maintenance
during the lifetime of the release. It'll also be equally useful to
others looking to create wrapper generators using osgIntrospection.
This is a fairly simple change and was tested with a fresh rebuild of the
entire suite of osgWrapper libraries, so it should be relatively low risk
(fingers crossed)."
- Adding missing header files and making sure they are marked public.
- Support to copy headers in Viewer/api into the proper location in framework
- Internalized OpenThreads build so cross-project dependency is not needed. Can now delete copy of OpenThreads project. Frameworks use native Xcode linking mechanism. Plugins/Examples still use explicit -framework OpenThreads. Could potentially be problem is old OpenThreads is on the system. This can be changed to use native mechanism too, but requires some patience because it is tedious to change.
- Lots of fixes to osgViewerCocoa (something got messed up pretty badly...files are missing from repo). Another submission will need to readd these files back.
libraries listed under TARGET_EXTERNAL_LIBRARIES.
The removed libraries are not needed when linking the plugin, they are
loaded during runtime by Performer.
The modified file is attached."
