- 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."
stereo format to work. It's a good thing I tested these on a TV
before submitting them since I did indeed have a bug. One thing I
did not test was to see how this would work in windowed mode. Does
the interlaced stereo code have support for 'absolute' positions?
For example a given pixel on the screen is always shown in a given
eye no matter where the graphics context is placed?
"
geometrytechnique in submethods to made more easy the inheritance
between the user and osg-class. This is a first step to add more
functions in osgTerrain. Maybe the subdivision of the method have to
be in the terraintechnique because is the base class of
GeometryTechnique. If Robert or anyone think that this is better i
change this class too."
"I have adapted to osgShadow the soft shadow map technique described in "Efficient Soft-Edged Shadows Using Pixel Shader Branching" by Yury Uralsky, Chapter 17 of GPU Gems 2 (Matt Pharr ed. Addison-Wesley).
Here is my code in attachment: basically, it works in the same way as osgShadow/ShadowMap (core code is copied from it) but implements a specific GLSL shader for the soft rendering of penumbra.
I have tested it under Linux with a NVidia graphic card, but there should be no dependency on platform nor on the graphics driver (as far as they support GLSL 2). Screenshots attached show the current results (frame rate bound to v-sync, but the shader takes actually not much time)."
to the view to be done during syncronous updateTraversal().
This feature can be used for doing things like merging subgraphs that have been loaded
in a background thread.
I just add ReinterpretCastConverter in the Reflector to convert void* in T* and T* in void*
files joint :
OpenSceneGraph/include/osgIntrospection/Reflector // modified file
OpenSceneGraph/src/osgIntrospection/Reflector.cpp // modified file
"
multiple GraphicsWindows, this singleton is accessable via GUIEventEvent::getAccumulatedEventState().
Added use of this new singleton in GraphicsWindow* implementations.
Added WindowSizeHandler to osgkeyboard to help with debugging of event state
between windows.
Created a new GraphicsThread subclass from OperationThread which allows the
GraphicsContext specific calls to be moved out of the base OperationThread class.
Updated the rest of the OSG to respect these changes.
Added and cleaned up DeleteHandler calls in osgViewer to help avoid crashes on exit.
Changed DatabasePager across to dynamically checcking osg::getCompileContext(..)
Updated wrappers.
"
Found in the join file the fix for the bug found by Rafa.
Problem :
osgIntrospection::Value grp(new osg::Group);
osgIntrospection::ValueList vlcall;
vlcall.push_back(osgIntrospection::Value("toto"));
const osgIntrospection::MethodInfo *m =
grp->getType.getCompatibleMethod("setName", vlcall, true);
if (m)
{
m->invoke(grp, vlcall); // ** SEGFAULT here
}
Algorithm explanation :
The "invoke" method try to convert "grp", which reflect an
"osg::Group*", in a
"osgIntrospection::Value", which reflect a "osg::Node*".
This because
the "setName(const char *)" method found by
"grp->getType.getCompatibleMethod"
is an "osg::Object" type method.
When osgIntrospection do this conversion it try :
- to found a "osgIntrospection::Converter" to convert
from "osg::Group*" to "osg::Node*"
- to found a chain of "osgIntrospection::Converter" to convert
from "osg::Group*" to "one or many type" to "osg::Node*"
- to converte an Enum to int or unsigned int
- to convert the value in its "value string representation",
then converte this string in the destination value
Else it throw a "TypeConversionException".
Bug :
1)
When osgIntrospection try to found a chain of
"osgIntrospection::Converter"
It could do any downcast or (Type to SuperType) or upcast
(SuperType to Type).
This mean the the chain could be :
osg::Group to osg::Transform to osg::Camera to
osg::CullSettings to osg::CullStack to
osg::CollectOccludersVisitor to
osg::NodeVisitor to osg::Referenced to osg::Object
During the convertion with this chain, A METTRE failed and
the pointer in
"grp" is set NULL. But the "grp" is always a valid
"osgIntrospection::Value"
and so, osgIntrospection accept the conversion. Then it try
to use this pointer
to call the "setName" function. And Bing SEGFAULT.
2)
In "bool Reflection::accum_conv_path( ... )"
the convection path isn't accumulate in the recursive loop.
this cause multi request of a conversion path, and a
slowdown in the
conversion algorithm.
3)
Use of the last conversion way in a conversion from
pointer to pointer
this mean you can do this :
"osg::Node*" to " value string representation" to "osg::Material*"
What a bad thing !!!
Solution :
1)
Introduce the concept of dynamic_cast and static_cast.
now, to do a conversion, osgIntrospection does this :
- to found a "osgIntrospection::Converter" to convert
from "osg::Group*" to "osg::Node*"
- to found a chain of "osgIntrospection::Converter" to convert
from "osg::Group*" to "one or many type" to "osg::Node*"
only with static_cast, downcast (Type to SuperType)
- to found, if the source and the destination are two pointer,
a chain of "osgIntrospection::Converter" to convert
from "osg::Group*" to "one or many type" to "osg::Node*"
only with dynamic_cast, upcast (SuperType to Type)
- to convert an Enum to int or to unsigned int
- to convert the value in its "value string representation",
then convert this string in the destination value
Else it throw a "TypeConversionException".
Add the "enum CastType" to distinguish the static_cast or
dynamic_cast converter.
Add file OpenSceneGraph/include/osgIntrospection/CastType
2)
add a line to accumulate converter in converter Path.
3)
add a line to check if source and destination are pointer.
"
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.
Stephan: "attached you'll find some modifications to the GraphicsWindow-class and
their platform-dependant implementations.
The problem:
setWindowRectangle and setWindowDecoration do not update the
traits-object, so, if you call setWindowRectangle on a
not-realized-window it will open with another size when realized later.
getWindowRectangle reports possible wrong sizes if setWindowRectangle
called before.
My solution:
split the implementation in two parts:
GraphicsWindow::setWindowRectangle will update its traits-object and
call afterwards the virtual method setWindowRectangleImplementation
(which is implemented by the derived platformspecific classess). For
setWindowDecoration I am useing a similar mechanism.
I hope you'll find the submission useful, the Win32 and X11 changes are
not tested but should work."
Changes to this made by Robert are call of resized in setWindowRectangle
instead of setting of Traits, and use of a bool return type.
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.
"
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)."
