[osg-users] Does pure GL3 context work with default camera manipulator ?
Hello community, I compiled osg for GL3, and created a glContextVersion( 3.3 ) GL context. In my simple test application Camera Manipulation and MatrixTransforms are working as usual without me writing any transformation shader. Is this possible ? As I have doubts about this I guess that I have setup the GL context in a wrong way, so how does one set it up properly ? My way: osg::GraphicsContext::Traits * traits = new osg::GraphicsContext::Traits() ; int width = 1920 , height = 1200 ; traits - x = 0 ; traits - y = 0 ; traits - width = width ; traits - height = height ; traits - windowDecoration = true ; traits - doubleBuffer = true ; traits - glContextVersion = std::string( 3.3 ) ; traits - windowDecoration = false ; osg::GraphicsContext * graphicsContext = osg::GraphicsContext::createGraphicsContext( traits ) ; osg::Camera * cam = new osg::Camera() ; cam - setGraphicsContext( graphicsContext ) ; cam - setViewport( 0 , 0 , width , height ) ; cam - setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ; cam - setClearColor( osg::Vec4( 0.0 , 0.0 , 0.0 , 1.0 ) ) ; cam - setProjectionMatrixAsPerspective( 30.0f , ( float )width / ( float )height , 1.0 , 1000.0 ) ; viewer.setCamera( cam ) ; viewer.setSceneData( xform.get() ) ; viewer.realize() ; return viewer.run() ; Thank you Cheers, PP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does pure GL3 context work with default camera manipulator ?
Hi -- A simple search of the source code shows that glContextVersion is parsed in only one place: GraphicsContextWin32.cpp, line 1678. Set a breakpoint there in the debugger and step through the following lines of code to ensure you're getting the right context. -Paul On 10/11/2011 1:32 AM, PP CG wrote: Hello community, I compiled osg for GL3, and created a glContextVersion( 3.3 ) GL context. In my simple test application Camera Manipulation and MatrixTransforms are working as usual without me writing any transformation shader. Is this possible ? As I have doubts about this I guess that I have setup the GL context in a wrong way, so how does one set it up properly ? My way: osg::GraphicsContext::Traits * traits = new osg::GraphicsContext::Traits() ; int width = 1920 , height = 1200 ; traits - x = 0 ; traits - y = 0 ; traits - width = width ; traits - height = height ; traits - windowDecoration = true ; traits - doubleBuffer = true ; traits - glContextVersion = std::string( 3.3 ) ; traits - windowDecoration = false ; osg::GraphicsContext * graphicsContext = osg::GraphicsContext::createGraphicsContext( traits ) ; osg::Camera * cam = new osg::Camera() ; cam - setGraphicsContext( graphicsContext ) ; cam - setViewport( 0 , 0 , width , height ) ; cam - setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ; cam - setClearColor( osg::Vec4( 0.0 , 0.0 , 0.0 , 1.0 ) ) ; cam - setProjectionMatrixAsPerspective( 30.0f , ( float )width / ( float )height , 1.0 , 1000.0 ) ; viewer.setCamera( cam ) ; viewer.setSceneData( xform.get() ) ; viewer.realize() ; return viewer.run() ; Thank you Cheers, PP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT and new color_buffer binding per frame.
Hi folks, additional observation: In case, where for each frame in the update-callback the color-buffer attachment is bound to new Image instance, and all outcoming pictures are all gray, except the first one -- I now store the reference to the initial color-buffer bound image, and write it's content together with the newly created per frame images. The per frame created and bound images are still gray, but the initial image receives the frame content instead. So the unbind and bind to new image in the update callback seems not to work, here: Code: // in update callback cam-detach( osg::Camera::COLOR_BUFFER); cam-attach( osg::Camera::COLOR_BUFFER, mImage.get()); Only the first bound image receives the frame content, independent of rebinding the color_buffer. Can anyone help with some idea, what is goin wrong? Cheers, Alexej -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43314#43314 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT and new color_buffer binding per frame.
Hi, Alexej
Try this callback as cull callback on your camera, call reset() after you
change attachments
class CameraResetCallback: public osg::NodeCallback
{
public:
CameraResetCallback():m_resetFlag(true){}
void operator() (osg::Node* node, osg::NodeVisitor* nv)
{
if (m_resetFlag)
{
osg::Camera* fboCam = dynamic_castosg::Camera*( node
);
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
if ( fboCam cv)
{
cv-getCurrentRenderBin()-getStage()-setFrameBufferObject(NULL);
cv-getCurrentRenderBin()-getStage()-setCameraRequiresSetUp( true );
m_resetFlag = false;
}
}
traverse(node,nv);
}
void reset(){m_resetFlag = true;}
private:
bool m_resetFlag;
};
11.10.2011, 18:02, Alexej Fink dk...@gmx.net:
Hi folks,
additional observation:
In case, where for each frame in the update-callback the color-buffer
attachment is bound to new Image instance, and all outcoming pictures are all
gray, except the first one -- I now store the reference to the initial
color-buffer bound image, and write it's content together with the newly
created per frame images. The per frame created and bound images are still
gray, but the initial image receives the frame content instead. So the unbind
and bind to new image in the update callback seems not to work, here:
Code:
// in update callback
cam-detach( osg::Camera::COLOR_BUFFER);
cam-attach( osg::Camera::COLOR_BUFFER, mImage.get());
Only the first bound image receives the frame content, independent of
rebinding the color_buffer.
Can anyone help with some idea, what is goin wrong?
Cheers,
Alexej
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43314#43314
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT and new color_buffer binding per frame.
Hi hybr, yes, it works now! I was already on finding out, how can I change RenderStage::_cameraRequiresSetUp per frame. You've shorten this a lot! Many thanks for your help!!! Cheers, Alexej -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43316#43316 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
Hi Paul,
Thanks for the replies.
I wasn't using Materials initially, but I tried adding them to see if they
would make a difference. The two geometries are still showing up as the same
color, but it didn't seem to be because of the Materials being the same.
Here's another .osg file with some better color coding:
Code:
Camera {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Viewport {
UniqueID Viewport_1
x 0
y 0
width 2046
height 2048
}
textureUnit 0 {
}
textureUnit 1 {
}
textureUnit 2 {
}
textureUnit 3 {
GL_TEXTURE_GEN_S OVERRIDE|OFF
GL_TEXTURE_GEN_T OVERRIDE|OFF
GL_TEXTURE_GEN_R OVERRIDE|OFF
GL_TEXTURE_GEN_Q OVERRIDE|OFF
TexGen {
mode OBJECT_LINEAR
plane_s 1 0 0 0
plane_t 0 1 0 0
plane_r 0 0 1 0
plane_q 0 0 0 1
}
}
}
referenceFrame ABSOLUTE
clearColor 0 0.4 0 1
clearMask 0x100
Use Viewport_1
transformOrder PRE_MULTIPLY
ProjectionMatrix {
0.000977517 0 0 0
0 0.000976563 0 0
0 0 -0.002002 0
-0 -0 -1.002 1
}
ViewMatrix {
1 0 -0 0
-0 1 -0 0
0 0 1 0
0 0 -500 1
}
renderOrder PRE_RENDER
renderTargetImplementation FRAME_BUFFER_OBJECT
renderTargetFallback PIXEL_BUFFER_RTT
drawBuffer 0
readBuffer 0
bufferComponent COLOR_BUFFER {
internalFormat 0
Texture2D {
UniqueID Texture2D_2
DataVariance DYNAMIC
wrap_s CLAMP
wrap_t CLAMP
wrap_r CLAMP
min_filter LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_USER_DEFINED_FORMAT
internalFormat GL_RGBA
resizeNonPowerOfTwo TRUE
}
level 0
face 0
mipMapGeneration FALSE
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
20.46 0 0 0
0 20.48 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode DIFFUSE
ambientColor 0.2 0.2 0.2 1
diffuseColor 1 1 0 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0 1 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode DIFFUSE
ambientColor 0.2 0.2 0.2 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
-0.92388 0.382683 0
-1 1.22465e-016 0
-0.92388 -0.382683 0
-0.707107 -0.707107 0
-0.382683 -0.92388 0
-1.83697e-016 -1 0
0.382683 -0.92388 0
0.707107 -0.707107 0
0.92388 -0.382683 0
1 0 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_12 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_13 Vec4Array 1
{
1 0 0 1
}
}
}
}
}
Re: [osg-users] [vpb] Large VPB Database build fails without
I was seeing a similar (perhaps the same) problem a while back. I was also trying to build a database without imagery (just DTED only). I got sidetracked with other tasks so I wasn't able to chase down the problem. I was running an older version of OSG (2.9.8 I believe) and VPB on a Fedora core 13 machine. Resources were not a problem with this machine (12GB RAM, 16T disk space, Nvidia 9800 GTX card) so I doubt that was the problem. I too would be interested to find out what's causing the build failure you're seeing... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Torben Dannhauer Sent: Sunday, October 09, 2011 5:12 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] [vpb] Large VPB Database build fails without Hi, I try to build a database with DEM but without textures. After 317 tasks it fails and has still 1595182 tasks pending. After the fail it blacklists the one machine and so finishes the run. The log file of one of these tasks is the following: Code: 0.129: Adding terrainTile 5.253: getTaskName(5,33,0) no nest, 6 12 5.253: DataSet::_run() 6 12 17.588 : started DataSet::createDestination(13) 17.637 : Time for after_reproject 0.049001 17.686 : local_extents = xMin() -180.00 180.00 17.686 : yMin() -60.00 60.00 17.686 : AR=3.00 C1=3 R1=1 17.686 : createNewDestinationGraph 17.926 : Time for _destinationGraph-computeMaximumSourceResolution() = 0.00 17.926 : Time for createDestinationGraph 0.240480 17.926 : Time for after_computeNeighbours 0.10 17.926 : completed DataSet::createDestination(13) 17.926 : Error: no destination graph built, cannot proceed with build. 17.926 : Time to write out DatabaseRevision::FileList - FilesAdded terrain_subtile_L5_X33_Y0/terrain_L5_X33_Y0.osgb.task.0.added, 0 17.926 : Time to write out DatabaseRevision::FileList - FilesRemoved terrain_subtile_L5_X33_Y0/terrain_L5_X33_Y0.osgb.task.0.removed, 0 17.926 : Time to write out DatabaseRevision::FileList - FilesModified terrain_subtile_L5_X33_Y0/terrain_L5_X33_Y0.osgb.task.0.modified, 0 17.926 : Elapsed time = 17.926306 The situation is the same if i resume the build with Code: vpbmaster --tasks build_master.tasks It reloads all tasks from file and than again fails on the identical tasks. I don't know why osgdem complains about the missing destination graph with Code: Error: no destination graph built, cannot proceed with build. Any idea why it fails? my system is: Kubuntu 10.04 64 bit. Kernel 2.6.38-11-generic 12GB RAM OSG and VPB from trunk last week. Thank you for your help, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43278#43278 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Extend LineSegmentIntersector : where to start ?
Hi, I've implemented picking in my application using pView-computeIntersection(...) which use a LineSegmentIntersector In my scene, I have some custom geometry and one of these custom geometry is made of lines, like this : Code: p_geode = new osg::Geode() p_geometry = new osg::Geometry(); p_vertices = my vertices array; p_primitive = new osg::DrawArrays(); p_primitive-setMode(osg::PrimitiveSet::LINE_STRIP); p_primitive-setFirst(0); p_primitive-setCount(p_vertices-size()); p_geometry-setVertexArray(p_vertices); p_geometry-addPrimitiveSet(p_primitive); p_geode-addDrawable(p_geometry); This geode is never intersected by the LineSegmentIntersector. If I use a PolytopeIntersector, this geode can be picked. In my company, we have C++ code which compute segment-segment intersection, so, as a personal training, I would like to extend LineSegmentIntersector to intersect the lines geode with our code. Could someone show me where to start ? Regards, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43319#43319 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does pure GL3 context work with default camera manipulator ?
Hi Paul, thanks, but unfortunately this does not help as the method GraphicsWindowWin32::createContextImplementation() does not get called at all, and the glContextVersion does not get parsed ( at my site ). This brings me back to my doubts and original question, probably I use the wrong way to create the GL3 context, so what is the right way ? I am sorry, I am getting lost in the osg code here. Have no idea what to do to get this particular method called. Thank you Cheers, PP Hi -- A simple search of the source code shows that glContextVersion is parsed in only one place: GraphicsContextWin32.cpp, line 1678. Set a breakpoint there in the debugger and step through the following lines of code to ensure you're getting the right context. -Paul On 10/11/2011 1:32 AM, PP CG wrote: Hello community, I compiled osg for GL3, and created a glContextVersion( 3.3 ) GL context. In my simple test application Camera Manipulation and MatrixTransforms are working as usual without me writing any transformation shader. Is this possible ? As I have doubts about this I guess that I have setup the GL context in a wrong way, so how does one set it up properly ? My way: osg::GraphicsContext::Traits * traits = new osg::GraphicsContext::Traits() ; int width = 1920 , height = 1200 ; traits - x = 0 ; traits - y = 0 ; traits - width = width ; traits - height = height ; traits - windowDecoration = true ; traits - doubleBuffer = true ; traits - glContextVersion = std::string( 3.3 ) ; traits - windowDecoration = false ; osg::GraphicsContext * graphicsContext = osg::GraphicsContext::createGraphicsContext( traits ) ; osg::Camera * cam = new osg::Camera() ; cam - setGraphicsContext( graphicsContext ) ; cam - setViewport( 0 , 0 , width , height ) ; cam - setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ; cam - setClearColor( osg::Vec4( 0.0 , 0.0 , 0.0 , 1.0 ) ) ; cam - setProjectionMatrixAsPerspective( 30.0f , ( float )width / ( float )height , 1.0 , 1000.0 ) ; viewer.setCamera( cam ) ; viewer.setSceneData( xform.get() ) ; viewer.realize() ; return viewer.run() ; Thank you Cheers, PP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget complex widgets
Hi, I'm experimenting with replacing an existing widget set with versions based on osg::Widget. I hope to create most items by composition, eg a scrollbar as two end buttons, plus a 'track' and 'thumb', each an osgWidget::Frame or similar, arranged in a layout. I was wondering if anyone had any open-source examples of this to share? I need to create many standard widgets (such as scrollbars, spinboxes, sliders), and unfortunately text-editing widgets as well. The osgWidget demos give me everything I strictly *need*, but seeing what other people have done would make me more comfortable I'm on a good path :) Regards, James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extend LineSegmentIntersector : where to start ?
Hi Aurelien, You can't computationally intersect infinitely thin lines with with infinitely thin line segments so what you are asking specifically isn't possible. What you are probably after is intersecting a scene with a cone or cylinder rather a line segment. Is is that you are implementing screen picking? What exactly you trying to achieve will affect what approach you will want to take. Robert. On Tue, Oct 11, 2011 at 5:16 PM, Aurelien Albert aurelien.alb...@alyotech.fr wrote: Hi, I've implemented picking in my application using pView-computeIntersection(...) which use a LineSegmentIntersector In my scene, I have some custom geometry and one of these custom geometry is made of lines, like this : Code: p_geode = new osg::Geode() p_geometry = new osg::Geometry(); p_vertices = my vertices array; p_primitive = new osg::DrawArrays(); p_primitive-setMode(osg::PrimitiveSet::LINE_STRIP); p_primitive-setFirst(0); p_primitive-setCount(p_vertices-size()); p_geometry-setVertexArray(p_vertices); p_geometry-addPrimitiveSet(p_primitive); p_geode-addDrawable(p_geometry); This geode is never intersected by the LineSegmentIntersector. If I use a PolytopeIntersector, this geode can be picked. In my company, we have C++ code which compute segment-segment intersection, so, as a personal training, I would like to extend LineSegmentIntersector to intersect the lines geode with our code. Could someone show me where to start ? Regards, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43319#43319 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
Your Materials have color mode set to DIFFUSE. In OpenGL parlance, this enables
GL_COLOR_MATERIAL and causes the diffuse lighting component to come from the
primary color instead of the material diffuse color.
Remove the color mode setting (or leave it set to default OFF) and you will see
the Material diffuse color used when lighting is enabled.
-Paul
On 10/11/2011 9:34 AM, Dan West wrote:
Hi Paul,
Thanks for the replies.
I wasn't using Materials initially, but I tried adding them to see if they
would make a difference. The two geometries are still showing up as the same
color, but it didn't seem to be because of the Materials being the same.
Here's another .osg file with some better color coding:
Code:
Camera {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Viewport {
UniqueID Viewport_1
x 0
y 0
width 2046
height 2048
}
textureUnit 0 {
}
textureUnit 1 {
}
textureUnit 2 {
}
textureUnit 3 {
GL_TEXTURE_GEN_S OVERRIDE|OFF
GL_TEXTURE_GEN_T OVERRIDE|OFF
GL_TEXTURE_GEN_R OVERRIDE|OFF
GL_TEXTURE_GEN_Q OVERRIDE|OFF
TexGen {
mode OBJECT_LINEAR
plane_s 1 0 0 0
plane_t 0 1 0 0
plane_r 0 0 1 0
plane_q 0 0 0 1
}
}
}
referenceFrame ABSOLUTE
clearColor 0 0.4 0 1
clearMask 0x100
Use Viewport_1
transformOrder PRE_MULTIPLY
ProjectionMatrix {
0.000977517 0 0 0
0 0.000976563 0 0
0 0 -0.002002 0
-0 -0 -1.002 1
}
ViewMatrix {
1 0 -0 0
-0 1 -0 0
0 0 1 0
0 0 -500 1
}
renderOrder PRE_RENDER
renderTargetImplementation FRAME_BUFFER_OBJECT
renderTargetFallback PIXEL_BUFFER_RTT
drawBuffer 0
readBuffer 0
bufferComponent COLOR_BUFFER {
internalFormat 0
Texture2D {
UniqueID Texture2D_2
DataVariance DYNAMIC
wrap_s CLAMP
wrap_t CLAMP
wrap_r CLAMP
min_filter LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_USER_DEFINED_FORMAT
internalFormat GL_RGBA
resizeNonPowerOfTwo TRUE
}
level 0
face 0
mipMapGeneration FALSE
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
20.46 0 0 0
0 20.48 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode DIFFUSE
ambientColor 0.2 0.2 0.2 1
diffuseColor 1 1 0 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0 1 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode DIFFUSE
ambientColor 0.2 0.2 0.2 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
Re: [osg-users] Does pure GL3 context work with default camera manipulator ?
You are on Windows, right? And I assume you built OSG for GL3 (changed all the CMake setting from their default GL2 values)? -Paul On 10/11/2011 10:25 AM, PP CG wrote: Hi Paul, thanks, but unfortunately this does not help as the method GraphicsWindowWin32::createContextImplementation() does not get called at all, and the glContextVersion does not get parsed ( at my site ). This brings me back to my doubts and original question, probably I use the wrong way to create the GL3 context, so what is the right way ? I am sorry, I am getting lost in the osg code here. Have no idea what to do to get this particular method called. Thank you Cheers, PP Hi -- A simple search of the source code shows that glContextVersion is parsed in only one place: GraphicsContextWin32.cpp, line 1678. Set a breakpoint there in the debugger and step through the following lines of code to ensure you're getting the right context. -Paul On 10/11/2011 1:32 AM, PP CG wrote: Hello community, I compiled osg for GL3, and created a glContextVersion( 3.3 ) GL context. In my simple test application Camera Manipulation and MatrixTransforms are working as usual without me writing any transformation shader. Is this possible ? As I have doubts about this I guess that I have setup the GL context in a wrong way, so how does one set it up properly ? My way: osg::GraphicsContext::Traits * traits = new osg::GraphicsContext::Traits() ; int width = 1920 , height = 1200 ; traits - x = 0 ; traits - y = 0 ; traits - width = width ; traits - height = height ; traits - windowDecoration = true ; traits - doubleBuffer = true ; traits - glContextVersion = std::string( 3.3 ) ; traits - windowDecoration = false ; osg::GraphicsContext * graphicsContext = osg::GraphicsContext::createGraphicsContext( traits ) ; osg::Camera * cam = new osg::Camera() ; cam - setGraphicsContext( graphicsContext ) ; cam - setViewport( 0 , 0 , width , height ) ; cam - setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ; cam - setClearColor( osg::Vec4( 0.0 , 0.0 , 0.0 , 1.0 ) ) ; cam - setProjectionMatrixAsPerspective( 30.0f , ( float )width / ( float )height , 1.0 , 1000.0 ) ; viewer.setCamera( cam ) ; viewer.setSceneData( xform.get() ) ; viewer.realize() ; return viewer.run() ; Thank you Cheers, PP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget complex widgets
On Tue, 2011-10-11 at 17:32 +0100, James Turner wrote: Hi, I'm experimenting with replacing an existing widget set with versions based on osg::Widget. I hope to create most items by composition, eg a scrollbar as two end buttons, plus a 'track' and 'thumb', each an osgWidget::Frame or similar, arranged in a layout. I was wondering if anyone had any open-source examples of this to share? I need to create many standard widgets (such as scrollbars, spinboxes, sliders), and unfortunately text-editing widgets as well. The osgWidget demos give me everything I strictly *need*, but seeing what other people have done would make me more comfortable I'm on a good path :) I really, really, really wish I could help the community more with this sort of thing. I've wanted to do more osgWidget development for a long time, but the bills must be paid. :( And, unfortunately, my real job has absolutely nothing to do with graphics programming, so I have very little time to work with OSG. Maybe one day that will change, but in the interim you're always welcome to add me on Googletalk and bug me there (cubic...@gmail.com) Best of luck... Regards, James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does pure GL3 context work with default camera manipulator ?
Yes I am on Windows, sorry for not mentioning. And yes I turned off all GL features but GL3 in the cmake built, as explained in other posts. Cheers, PP You are on Windows, right? And I assume you built OSG for GL3 (changed all the CMake setting from their default GL2 values)? -Paul On 10/11/2011 10:25 AM, PP CG wrote: Hi Paul, thanks, but unfortunately this does not help as the method GraphicsWindowWin32::createContextImplementation() does not get called at all, and the glContextVersion does not get parsed ( at my site ). This brings me back to my doubts and original question, probably I use the wrong way to create the GL3 context, so what is the right way ? I am sorry, I am getting lost in the osg code here. Have no idea what to do to get this particular method called. Thank you Cheers, PP Hi -- A simple search of the source code shows that glContextVersion is parsed in only one place: GraphicsContextWin32.cpp, line 1678. Set a breakpoint there in the debugger and step through the following lines of code to ensure you're getting the right context. -Paul On 10/11/2011 1:32 AM, PP CG wrote: Hello community, I compiled osg for GL3, and created a glContextVersion( 3.3 ) GL context. In my simple test application Camera Manipulation and MatrixTransforms are working as usual without me writing any transformation shader. Is this possible ? As I have doubts about this I guess that I have setup the GL context in a wrong way, so how does one set it up properly ? My way: osg::GraphicsContext::Traits * traits = new osg::GraphicsContext::Traits() ; int width = 1920 , height = 1200 ; traits - x = 0 ; traits - y = 0 ; traits - width = width ; traits - height = height ; traits - windowDecoration = true ; traits - doubleBuffer = true ; traits - glContextVersion = std::string( 3.3 ) ; traits - windowDecoration = false ; osg::GraphicsContext * graphicsContext = osg::GraphicsContext::createGraphicsContext( traits ) ; osg::Camera * cam = new osg::Camera() ; cam - setGraphicsContext( graphicsContext ) ; cam - setViewport( 0 , 0 , width , height ) ; cam - setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ; cam - setClearColor( osg::Vec4( 0.0 , 0.0 , 0.0 , 1.0 ) ) ; cam - setProjectionMatrixAsPerspective( 30.0f , ( float )width / ( float )height , 1.0 , 1000.0 ) ; viewer.setCamera( cam ) ; viewer.setSceneData( xform.get() ) ; viewer.realize() ; return viewer.run() ; Thank you Cheers, PP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
OK, I was misunderstanding how the setColorMode method worked. I changed that
to setColorMode( osg::Material::OFF ), but the first geometry is still using
the color from the color array (green), and the second geometry is using that
same color.
Here's my updated scenegraph in case it helps:
Code:
Camera {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Viewport {
UniqueID Viewport_1
x 0
y 0
width 2046
height 2048
}
textureUnit 0 {
}
textureUnit 1 {
}
textureUnit 2 {
}
textureUnit 3 {
GL_TEXTURE_GEN_S OVERRIDE|OFF
GL_TEXTURE_GEN_T OVERRIDE|OFF
GL_TEXTURE_GEN_R OVERRIDE|OFF
GL_TEXTURE_GEN_Q OVERRIDE|OFF
TexGen {
mode OBJECT_LINEAR
plane_s 1 0 0 0
plane_t 0 1 0 0
plane_r 0 0 1 0
plane_q 0 0 0 1
}
}
}
referenceFrame ABSOLUTE
clearColor 0 0.4 0 1
clearMask 0x100
Use Viewport_1
transformOrder PRE_MULTIPLY
ProjectionMatrix {
0.000977517 0 0 0
0 0.000976563 0 0
0 0 -0.002002 0
-0 -0 -1.002 1
}
ViewMatrix {
1 0 -0 0
-0 1 -0 0
0 0 1 0
0 0 -500 1
}
renderOrder PRE_RENDER
renderTargetImplementation FRAME_BUFFER_OBJECT
renderTargetFallback PIXEL_BUFFER_RTT
drawBuffer 0
readBuffer 0
bufferComponent COLOR_BUFFER {
internalFormat 0
Texture2D {
UniqueID Texture2D_2
DataVariance DYNAMIC
wrap_s CLAMP
wrap_t CLAMP
wrap_r CLAMP
min_filter LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_USER_DEFINED_FORMAT
internalFormat GL_RGBA
resizeNonPowerOfTwo TRUE
}
level 0
face 0
mipMapGeneration FALSE
}
num_children 2
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
20.46 0 0 0
0 20.48 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 1 0 1
diffuseColor 1 1 0 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0 1 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 0 1 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
-0.92388 0.382683 0
-1 1.22465e-016 0
-0.92388 -0.382683 0
-0.707107 -0.707107 0
-0.382683 -0.92388 0
-1.83697e-016 -1 0
0.382683 -0.92388 0
0.707107 -0.707107 0
0.92388 -0.382683 0
1 0 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_12 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_13 Vec4Array 1
{
1 0 0 1
}
}
}
}
}
Thanks,
Dan
--
Read this topic
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
On 10/11/2011 11:20 AM, Dan West wrote: OK, I was misunderstanding how the setColorMode method worked. I changed that to setColorMode( osg::Material::OFF ), but the first geometry is still using the color from the color array (green), and the second geometry is using that same color. I copied your .osg file and replaced the Camera with a Group so I could load it into osgviewer. It renders with the Material colors for me. You should be able to verify this yourself. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extend LineSegmentIntersector : where to start ?
Hi, You can't computationally intersect infinitely thin lines with with infinitely thin line segments so what you are asking specifically isn't possible. We use an algorithm with a intersection distance parameter : if minimum distance between the two lines (or segment, or line/segment) is below this minimum, we consider that the lines intersect. It acts like intersecting cylinders (infinite or not) with a little diameter. This algorithm is currently used by several scientific softwares developped by my company. What exactly you trying to achieve will affect what approach you will want to take. I'm trying to extends LineSegmentIntersector with new features. There are different goals : - personal training - test our algorithm in a OSG context (actually all rendering is done in pure OpenGL, all computation in standard C++) - use this algorithm on a standard OSG scene to do some computations (like in our actual software) - maybe use this algorithm for screen picking Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43329#43329 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
Hi Paul,
I changed my camera to a group, but I'm still seeing both geometries as
green. Here's my modified .osg file (i had to remove some of the texture
binding and projection stuff for it to behave like a normal group).
Code:
Group {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
referenceFrame ABSOLUTE
num_children 3
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
20.46 0 0 0
0 20.48 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 1 0 1
diffuseColor 1 1 0 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0 1 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 0 1 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
-0.92388 0.382683 0
-1 1.22465e-016 0
-0.92388 -0.382683 0
-0.707107 -0.707107 0
-0.382683 -0.92388 0
-1.83697e-016 -1 0
0.382683 -0.92388 0
0.707107 -0.707107 0
0.92388 -0.382683 0
1 0 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_12 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_13 Vec4Array 1
{
1 0 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
30.6717 0.81368 163.731 1
}
num_children 1
Geode {
UniqueID Geode_14
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_15
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 0 1 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_16 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
-0.92388 0.382683 0
-1 1.22465e-016 0
-0.92388 -0.382683 0
-0.707107 -0.707107 0
-0.382683 -0.92388 0
-1.83697e-016 -1 0
0.382683 -0.92388 0
0.707107 -0.707107 0
0.92388 -0.382683 0
1 0 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_17 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_18 Vec4Array
Re: [osg-users] Extend LineSegmentIntersector : where to start ?
HI Aurelien, On Tue, Oct 11, 2011 at 7:08 PM, Aurelien Albert aurelien.alb...@alyotech.fr wrote: We use an algorithm with a intersection distance parameter : if minimum distance between the two lines (or segment, or line/segment) is below this minimum, we consider that the lines intersect. It acts like intersecting cylinders (infinite or not) with a little diameter. If it walks like a duck and quacks like a duck it's a duck :-) I would suggest that you call your class CylinderIntersector and set it up as such, it will do what you need an keep things clear it what it implements. I'm trying to extends LineSegmentIntersector with new features. I wouldn't recommend extended LineSegmentIntersector, rather implement your own subclass from the base class osgUtil::Intersector. A Cylinder intersections have different properties than a Line intersections, including the data you'd put into the Intersection objects that describe your hits. I would recommend look at how the PolytopeIntersector and LineSegmentIntersector are similar and differ to see how to go about a CylinderIntersector. There are different goals : - personal training - test our algorithm in a OSG context (actually all rendering is done in pure OpenGL, all computation in standard C++) - use this algorithm on a standard OSG scene to do some computations (like in our actual software) - maybe use this algorithm for screen picking From screen picking with an orthographic view a CylinderIntersector would be appropriate, but for a perspective view a ConeIntersector would be more appropriate to handle the fact the as you move further away from the eye point an one screen pixel occupies a greater area in the object coordinates. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
I'm still seeing the Material colors being used. I can only imaging that you
*don't* get the Material colors because you have somehow turned off lighting. To
make sure lighting is enabled, on your top-level group (or camera), do this:
getOrCreateStateSet()-setMode( GL_LIGHTING,
osg::StateAttribute::ON|osg::StateAttribute::PROTECTED);
I have no idea why you are seeing your TRIANGLE_FANs rendering in the same color
as the QUAD.
-Paul
On 10/11/2011 12:09 PM, Dan West wrote:
Hi Paul,
I changed my camera to a group, but I'm still seeing both geometries as
green. Here's my modified .osg file (i had to remove some of the texture
binding and projection stuff for it to behave like a normal group).
Code:
Group {
UniqueID Camera_0
nodeMask 0x
cullingActive FALSE
referenceFrame ABSOLUTE
num_children 3
MatrixTransform {
UniqueID MatrixTransform_3
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
20.46 0 0 0
0 20.48 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_4
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_5
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 1 0 1
diffuseColor 1 1 0 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays QUADS 0 4
}
VertexArray UniqueID Vec3Array_6 Vec3Array 4
{
0.5 0.5 0
-0.5 0.5 0
-0.5 -0.5 0
0.5 -0.5 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_7 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_8 Vec4Array 1
{
0 1 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1
}
num_children 1
Geode {
UniqueID Geode_9
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_10
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 0 1 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_11 Vec3Array 18
{
0 0 0
1 0 0
0.92388 0.382683 0
0.707107 0.707107 0
0.382683 0.92388 0
6.12323e-017 1 0
-0.382683 0.92388 0
-0.707107 0.707107 0
-0.92388 0.382683 0
-1 1.22465e-016 0
-0.92388 -0.382683 0
-0.707107 -0.707107 0
-0.382683 -0.92388 0
-1.83697e-016 -1 0
0.382683 -0.92388 0
0.707107 -0.707107 0
0.92388 -0.382683 0
1 0 0
}
NormalBinding OVERALL
NormalArray UniqueID Vec3Array_12 Vec3Array 1
{
0 0 1
}
ColorBinding OVERALL
ColorArray UniqueID Vec4Array_13 Vec4Array 1
{
1 0 0 1
}
}
}
}
MatrixTransform {
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
30.6717 0.81368 163.731 1
}
num_children 1
Geode {
UniqueID Geode_14
DataVariance DYNAMIC
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_15
DataVariance DYNAMIC
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
ColorMode OFF
ambientColor 1 0 1 1
diffuseColor 1 0 1 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
}
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawArrays TRIANGLE_FAN 0 18
}
VertexArray UniqueID Vec3Array_16 Vec3Array 18
{
0 0 0
1 0 0
Re: [osg-users] [vpb] Large VPB Database build fails without
Hi Shayne, thanks for your feedback! In my case it's also definitly no my machine. Currently it builds a database with a bluemarbleNG texture as workaround and that build is scheduled for another two days. Then I can go on chasing the bug with roberts/your? help. I also added a single output line to the Taskmanager.cpp to make it more verbose. I'll send it as a submission asap. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=4#4 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Viewer thread safety question
Ok, so I have the unenviable task of rewriting software from the mid 1980's for our virtual reality/cave environment and while I'm rewriting all of this software I must make sure that it works with the older software so that operations can continue as before; yes, welcome to my world. The system consists of over twenty different units each of which communicates with each other constantly via UDP and the first of these things to go is the viewer that was written using OSG .9x. My viewer must request a dump of all file names and then wait for an end of dump message before I start rendering the scene. However, since this is UDP and since there is no telling what the older software is doing (the older code uses void* like the fire department uses water) it ends up sending the packet with the file name to the wrong computer, fails to send the packet, or UDP just fails to make that left turn at Albuquerque and the packet is lost forever. So, now I need to request a resend and load all of the missed data into an actively running scene graph where every node is a leaf (I'm working on getting them to fix that part). My viewer runs its own update loop in which it will computer inputs, compute other changes in the scene, and then check for any new nodes that have been received before calling the frame() function. Since the root node of the scene may constantly change I was just thinking of making its variance DYNAMIC. Of course that has been touted as very inefficient and I agree with that. I had looked at inheriting from osg::Drawable::UpdateCallback but figure that I'd have to make the varience DYNAMIC anyhow so it wouldn't matter. So, my question is, would there be a better way to make this thread safe other than setting the root node to DYNAMIC to avoid crashing when adding another node to the root? And just in case you're wondering, I'm replacing the viewer first because it crashes the most of all of the other systems. Thanks, soulsabr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43336#43336 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Open Flight characteristic not reflected in the current OSG
Greetings Paul! Yea, I came to the same conclusion also! That is why I went to the second choice. Oh! I goofed when I gave you that last corrected code segment. It should be: Code: colors-push_back(osg::Vec4(_PrimaryColor.r(), _PrimaryColor.g(), _PrimaryColor.b(), 1.0 - getTransparency())); Thank you! David David Glenn --- D Glenn Computer Graphics amp; Media Systems. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43337#43337 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Colors bleeding between ShapeDrawables and Geometries
Sweet, I got it working. For some reason our scene must be doing something weird with the lighting. Both stateSet()-setMode( GL_LIGHTING, osg::StateAttribute::ON|osg::StateAttribute::PROTECTED ); and stateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED); did not fully enable or disable lighting for the node (or for some reason the colors were still bleeding strangely). I managed to figure out another spot I could set up my camera that worked correctly. Thanks so much for the help! ~ Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43338#43338 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Large VPB Database build fails without
Torben, When I get around to it, I will try to debug things on my end. I've been swamped with other priorities. I just wanted to inform you that I've seen the same problem when trying to build a database with DTED only (no imagery). If I add the imagery, things work fine as you have said... Regards, -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Torben Dannhauer Sent: Tuesday, October 11, 2011 1:41 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] [vpb] Large VPB Database build fails without Hi Shayne, thanks for your feedback! In my case it's also definitly no my machine. Currently it builds a database with a bluemarbleNG texture as workaround and that build is scheduled for another two days. Then I can go on chasing the bug with roberts/your? help. I also added a single output line to the Taskmanager.cpp to make it more verbose. I'll send it as a submission asap. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=4#4 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
Hi ?, How frequent of an occurrence is the need to add/remove portions of the scene graph? And what kind of performance are you looking for as it happens? If it is infrequent, could you simply stop threading on the viewer, modify your scene graph structure however you need to, and start threading again (and your frame loop) after you're done? I've used an UpdateCallback in the past to add/replace nodes while the viewer is running. It wouldn't be particularly difficult to go this route (subclass from NodeCallback, use whatever threadsafe mechanism you want within the class to synchronize with your incoming data, and when needed add a child to a group node which has the callback attached). You could test the performance of it in your application, which is more important than what anyone can speculate about. Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43341#43341 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
On 10/11/2011 2:00 PM, Joshua Cook wrote: Since the root node of the scene may constantly change I was just thinking of making its variance DYNAMIC. Of course that has been touted as very inefficient and I agree with that. I had looked at inheriting from osg::Drawable::UpdateCallback but figure that I'd have to make the varience DYNAMIC anyhow so it wouldn't matter. So, my question is, would there be a better way to make this thread safe other than setting the root node to DYNAMIC to avoid crashing when adding another node to the root? Well, it's somewhat inefficient if you run the viewer multithreaded, but the way that it's inefficient is kind of irrelevant in your situation since it seems like you'll have to incur that inefficiency no matter what because your graph is potentially dynamic on every frame. Basically, in my mind, no trick will ever avoid the fact that you have to wait for rendering to completely finish before modifying the graph. There might be some devious trick that could allow otherwise (maybe two copies of the graph and you stagger the accesses and the visibility of them?) but premature optimization is the root of lots of bad things. Just do it the proper way now, and see if the performance is really a problem or not, and deal with it then if it is. And just in case you're wondering, I'm replacing the viewer first because it crashes the most of all of the other systems. Wise choice. Thanks, soulsabr -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
On 10/11/2011 2:00 PM, Joshua Cook wrote: the wrong computer, fails to send the packet, or UDP just fails to make that left turn at Albuquerque Ooo! A Bugs Bunny reference. :-) Since the root node of the scene may constantly change I was just thinking of making its variance DYNAMIC. Of course that has been touted as very inefficient and I agree with that. I had looked at inheriting from osg::Drawable::UpdateCallback but figure that I'd have to make the varience DYNAMIC anyhow so it wouldn't matter. So, my question is, would there be a better way to make this thread safe other than setting the root node to DYNAMIC to avoid crashing when adding another node to the root? Honestly it sounds like you have a lot worse things to worry about right now than efficiency. If I were in your shoes, I'd get it working and working right first, then tune later. I'm pretty sure that setting osgViewer::Viewer::setThreadingMode(osgViewer::ViewerBase::SingleThreaded) will allow the draw thread to complete before Viewer::frame() returns, which should allow you to add/remove nodes to/from your scene graph. Give that a try. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
Hi Joshua, I'm wondering, have you tried just adding / removing nodes in your graph before calling frame() on your viewer? The Draw traversal, which may still be running when the previous frame() returns, should theoretically not care about changes in the graph. That's because the cull traversal gathers statesets and drawables into its own lost, stored in ref_ptrs, and then the draw phase dispatches the draw calls for those based on the list gathered during cull. But when frame() returns, cull is finished, and update for the next frame hasn't started yet, so it should be safe to modify the graph at that point. Any nodes you remove from the graph don't matter since draw has stored all the drawables and statesets (that it needs) in ref_ptrs. And no other traversals are running (draw is not technically a traversal, since it has its own list and doesn't traverse the graph), so no iterators will be invalidated by adding or removing children in your graph. The DYNAMIC data variance only applies to drawables and statesets, for that same reason. It's those things that the draw traversal may be using at the same time as another thread, so it's those things that need to be dispatched before frame() returns. The things that need special care are adding / removing views in a CompositeViewer, or replacing the graphics context on a camera, or things like that. For those, you'll generally have to stopThreading() before, then startThreading() after the operation, to make sure no draw threads are running when you do them. But changing the graph can safely be done between calls to frame(), that shouldn't be a problem. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
