key, but it didn't pick up the initial state. So, if NumLock was on for
the OS at startup (LED on), it was still off for OSG. And the first
keypress turned the LED off, and NumLock on for OSG. The attached fix
picks up the state on every FocusIn, just like it was done in the last
commits for CapsLock. The difference is, that the NumLock mask isn't
standardized (e.g. 0x10 for Linux, and 0x80 for AIX), so we have to do
a reverse lookup (::rescanModifierMapping()).
Note that I could not reproduce the problem on my system, but someone
else confirmed it twice on his, and the patch fixed it for him.
Changed files:
./include/osgViewer/api/X11/GraphicsWindowX11
./src/osgViewer/GraphicsWindowX11.cpp
"
and a new scheme for computing the scaling when using autoscale that introduces smooth
transitions to the scaling of the subgraph so that it looks more natural.
help manage the scaling of particles, whether they should be relative to the
local coordiante frame of the particle system, or be in world coordinates.
It sets osgGA's keymask when restoring keys on FocusIn, according
to the state values of XKeyEvent and XCrossingEvent. (These are
the only source for X11's current capslock state that avoids
pulling in the XKB extension.)
"
1) Full DOS paths are now correctly opened by OpenVRML. A URL containing
a DOS path should be "file:///C:data/blah" rather than "file://C:data/blah".
2) The last primitive defined in "coordIndex" is now added if the
"coordIndex" is not terminated by -1.
3) Smoothed normals are computed if no normal field is provided.
Currently, there is no support for "creaseAngle", so all edges (even the
ones sharper than the creaseAngle) are smoothed. I might add this in the
future if demand rises.
4) If an IndexedFaceSet contains only triangles or quads then the
primitive type is set to TRIANGLES or QUADS, and the primset becomes
DrawArrays rather than DrawArrayLengths.
Question: I noticed that for DrawArrays you can still provide an index
array. Would the rendering be faster if I'd create DrawElements primsets
rather than DrawArrays? Phrased differently, what is the benefit of
using DrawElements over DrawArrays, as there is clearly not a one-to-one
mapping of these concepts to their OpenGL counterparts?
5) Objects are added to the transparent bin and blend mode is enabled
only if the transparency is nonzero. Rendered transparent objects no
longer write the depth buffer."
"texture" paths. This is to drop absolute paths that some
3d editors export (even AC3D itself!). But this also strips
directories of relative paths, which is wrong and contradicts
the ac3d reference implementation. (The reference implementation
doesn't strip anything, though, and so takes the absolute paths
as they are. Definitely not what we want.)
The attached solution checks absolute paths and only strips
those:
(1) A:\\foo\\bar.png -> bar.png (as before)
(2) /foo/bar.png -> bar.png (as before)
(3) foo/bar.png -> foo/bar.png (new)
(4) ../foo/bar.png -> ../foo/bar.png (new)
"
The files are:
include/osgSim/ObjectRecordData -- The new class. Derives from Object to support .osg IO.
src/osgPlugins/OpenFlight/PrimaryRecords.cpp -- Reads data into that class.
src/osgPlugins/osgSim/IO_ObjectRecordData.cpp -- .osg IO support."
From Robert Osfield, made the OpenFlight read object record data optional via the -O readObjectRecordData ReaderWriter option.
