attached code adds this, along with a member variable to keep track of
the setting. It is based on the latest subversion version, and was
tested by creating a new text object with the same axis alignment as an
existing one (e.g.
new_text->setAxisAlignment(old_text->getAxisAlignment()); )."
From Robert Osfield, " I originally didn't add a getAxisAlignment()
as all setAxisAlignment does is set the Rotation member variable, and
potentially one could apply user defined Rotation setting after the
setAxisAlignment() which would bring it out of sync with the
setAxisAlignment.
Rather than reject your submission on the ground of potentially
getting out of sync and therefore misleading users I've added a
USED_DEFINED_ROTATION to AxisAlignment enum, and set this in the
serRotation and then override this setting of _axisAlignment in the
setAxisAlingment method. I've also removed the lazy updating
optimization you've added to the top of setAxisAlignment to avoid
potential problems as well."
I've done some additional small modification regarding constness in ReaderWriter and added
mutable on _pluginData so passing data back would be possible too.
Have updated the collada plugin (ReaderWriterDAE.cpp) to use the map to handle options and
have attached the changes.
The stuff in daeReader.h and daeWriter.h are just cosmetic changes to get rid of a warning."
"This is a fix for the issue reported by Anders a week ago (see \u201c[osg-users] BUG?: mouse coordinate changes after window move\u201d discussion thread on Sept. 20). The issue was that the initial implementation added a few months back was not converting the window coordinates to client-area coordinates resulting in a slight offset each time a decorated window was moved (caused by the window border). This was also causing windows to move out of their assigned screen."
and
"Attached is a fix for the taskbar repaint issue that occurs when a graphics window is toggled from full-screen mode to windowed mode (as identified by Gert van Maren a couple of weeks ago).
Also included is a fix derived from the \u201cEvents from the past\u201d discussion thread that took place on July 11."
(a) some objects behind the camera can cast shadow
(b) object aboive the camera can cast shadow
then i fixed the shadow map orientation, now screen x coordinate alinged which improve the quality"
- GL2Extensions, Program and Program.cpp
Features:
- Support for fragment output binding. (e.g. You can now specify in the fragment shader varying out vec3 fragOut; fragOut = vec3(1,0,1); to write to the fragOut variable. In your program you call glBindFragDataLocation(program, 1, "fragOut") to bind the fragOut variable with the MRT 1 - GL_COLOR_ATTACHMENT1_EXT)
- new methods Program::add/removeBindFragDataLocation Program::getFragDataBindingList
"
- Implementation of integer textures as in EXT_texture_integer
- setBorderColor(Vec4) changed to setBorderColor(Vec4d) to pass double values
as border color. (Probably we have to provide an overloading function to
still support Vec4f ?)
- new method Texture::getInternalFormatType() added. Gives information if the
internal format normalized, float, signed integer or unsigned integer. Can
help people to write better code ;-)
"
Futher changes to this submission by Robert Osfield, changed the dirty mipmap
flag into a buffer_value<> vector to ensure safe handling of multiple contexts.
local function pointer to avoid compiler warnings related to case void*.
Moved various OSG classes across to using setGLExtensions instead of getGLExtensions,
and changed them to use typedef declarations in the headers rather than casts in
the .cpp.
Updated wrappers
"A new texture class Texture2DArray derived from
Texture extends the osg to support the new
EXT_texture_array extensions. Texture arrays provides
a feature for people interesting in GPGPU programming.
Faetures and changes:
- Full support for layered 2D textures.
- New uniform types were added (sampler2DArray)
- FrameBufferObject implementation were changed to
support attaching of 2D array textures to the
framebuffer
- StateSet was slightly changed to support texture
arrays. NOTE: array textures can not be used in fixed
function pipeline. Thus using the layered texture as a
statemode for a Drawable produce invalid enumerant
OpenGL errors.
- Image class was extended to support handling of
array textures
Tests:
I have used this class as a new feature of my
application. It works for me without problems (Note:
Texture arrays were introduced only for shading
languages and not for fixed function pipelines!!!).
RTT with Texture2DArray works, as I have tested them
as texture targets for a camera with 6 layers/faces
(i.e. replacement for cube maps). I am using the array
textures in shader programming. Array textures can be
attached to the FBO and used as input and as output."
