Re: [osg-users] Render to Texture
Hi Robert Delport, I have the setup with 4 cameras: 1st camera - the slave camera that inherit the master camera's relative frame and render the scene to 2 textures with color attachments. One of the texture remains as it is and other texture is left for further operation. 2. 2nd camera - the camera is hung under the 1st switch which does some operation over the one of texture specified above. The result of the operation is rendered to another texture using the camera. 3. 3rd camera - the camera is hung under the 2nd switch that does some further operation over the last result done in step 2. The result is rendered to the texture which was the input texture in step 2. 4. 4th Camera - is the HUD camera to visualize the output of the either of the above operation in step 2 / step 3. Since step 2 and 3 are Switches i make them only one enable at a time. The concepts are pretty simple as you can imagine. They have been picked from osgdistortion, osgprerender,osgstereomatch and osggameoflife. During the first pass , i make the first switch enabled with the keypress event and can visualize the scene. With the next key press event, i flip the texture for further pass over the result of the last operation, But the screen freezes without showing the result of the operation in the HUD camera. I need some hint on what might have gone wrong. If need more elaboration please ask. Thank you! Regards Sajjadul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34754#34754 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hello guys, Sorry for my late reply, I had a very busy weekend. :) What I actually want is to traverse the whole graph 3 times. (that's why I have three cameras). And each time to draw a different submesh (see the nodes at the bottom). Each time I traverse the graph I want nothing to be cleared. I don't want the camera to clear anything, or render somewhere else. Or do anything special. I just using it because of the culling mask. All the three submeshes belong to the same viewport/scene. I want this rendering order: Camera01-osg::Group-Pass1-ClipNode-MainModel-SubmeshNode1 Camera01-osg::Group-Pass2-ClipNode-MainModel-SubmeshNode1 Camera01-osg::Group-Pass3-ClipNode-MainModel-SubmeshNode1 Camera02-osg::Group-Pass1-ClipNode-MainModel-SubmeshNode2 Camera02-osg::Group-Pass2-ClipNode-MainModel-SubmeshNode2 Camera02-osg::Group-Pass3-ClipNode-MainModel-SubmeshNode2 Camera02-osg::Group-Pass1-ClipNode-MainModel-SubmeshNode3 Camera02-osg::Group-Pass2-ClipNode-MainModel-SubmeshNode3 Camera02-osg::Group-Pass3-ClipNode-MainModel-SubmeshNode3 I also uploaded a screenshot of the strange effect I get. Each of the two balls is a different submesh. They have different depth (the bigger one is closer to the camera) but when you align them on the depth axis looks like the depth buffer does not work as it should. (But it doesn't look like the depth test is just disabled because in such case one of the balls should overlap the other completely). Thanks for your time. George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34756#34756 Attachments: http://forum.openscenegraph.org//files/osg_strange_effect_169.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
Hi, On 13/12/10 10:15, Sajjadul Islam wrote: Hi Robert Delport, I have the setup with 4 cameras: 1st camera - the slave camera that inherit the master camera's relative frame and render the scene to 2 textures with color attachments. One of the texture remains as it is and other texture is left for further operation. 2. 2nd camera - the camera is hung under the 1st switch which does some operation over the one of texture specified above. The result of the operation is rendered to another texture using the camera. 3. 3rd camera - the camera is hung under the 2nd switch that does some further operation over the last result done in step 2. The result is rendered to the texture which was the input texture in step 2. Why the input texture of 2? Are your cameras pre-render? What order? 4. 4th Camera - is the HUD camera to visualize the output of the either of the above operation in step 2 / step 3. I assume you switch the texture the HUD is viewing? How do you do it? Maybe you can save your scene as .osg file and inspect it to see if something is missing. jp Since step 2 and 3 are Switches i make them only one enable at a time. The concepts are pretty simple as you can imagine. They have been picked from osgdistortion, osgprerender,osgstereomatch and osggameoflife. During the first pass , i make the first switch enabled with the keypress event and can visualize the scene. With the next key press event, i flip the texture for further pass over the result of the last operation, But the screen freezes without showing the result of the operation in the HUD camera. I need some hint on what might have gone wrong. If need more elaboration please ask. Thank you! Regards Sajjadul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34754#34754 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hi, how do you set the clearmask of the cameras? jp On 13/12/10 11:43, George Bekos wrote: Hello guys, Sorry for my late reply, I had a very busy weekend. :) What I actually want is to traverse the whole graph 3 times. (that's why I have three cameras). And each time to draw a different submesh (see the nodes at the bottom). Each time I traverse the graph I want nothing to be cleared. I don't want the camera to clear anything, or render somewhere else. Or do anything special. I just using it because of the culling mask. All the three submeshes belong to the same viewport/scene. I want this rendering order: Camera01-osg::Group-Pass1-ClipNode-MainModel-SubmeshNode1 Camera01-osg::Group-Pass2-ClipNode-MainModel-SubmeshNode1 Camera01-osg::Group-Pass3-ClipNode-MainModel-SubmeshNode1 Camera02-osg::Group-Pass1-ClipNode-MainModel-SubmeshNode2 Camera02-osg::Group-Pass2-ClipNode-MainModel-SubmeshNode2 Camera02-osg::Group-Pass3-ClipNode-MainModel-SubmeshNode2 Camera02-osg::Group-Pass1-ClipNode-MainModel-SubmeshNode3 Camera02-osg::Group-Pass2-ClipNode-MainModel-SubmeshNode3 Camera02-osg::Group-Pass3-ClipNode-MainModel-SubmeshNode3 I also uploaded a screenshot of the strange effect I get. Each of the two balls is a different submesh. They have different depth (the bigger one is closer to the camera) but when you align them on the depth axis looks like the depth buffer does not work as it should. (But it doesn't look like the depth test is just disabled because in such case one of the balls should overlap the other completely). Thanks for your time. George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34756#34756 Attachments: http://forum.openscenegraph.org//files/osg_strange_effect_169.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hey, I just use: mycamera-setClearMask(0); for all the cameras. I don't do any other 'special' initialization. You can also check the attached source if it helps. Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34759#34759 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hi, On 13/12/10 12:03, George Bekos wrote: Hey, I just use: mycamera-setClearMask(0); for all the cameras. I don't do any other 'special' initialization. You can also check the attached source if it helps. attached? jp Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34759#34759 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New to OSG, few simple questions.
Hi everybody, I'm new to OSG and from what I can see I regret I havent come here sooner. Before I start, I have a few questions. 1. Is OSG free to use in commercial software? 2. How does OSG handle windows? Is it built in or requires 3rd party sw? 3. Any experience and/or thoughts of using Qt with OSG? Thank you! Cheers, Zoran -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34755#34755 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hey, Hmm.. maybe there is something wrong with the cpp file I attached. Anyway, here is the code: http://pastesite.com/20651 Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34761#34761 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
Hi Delport,
Reasons for rendering the scene to two textrues
With key press event i may want to show the texture using the HUD that have not
gone through any operation. If i do any post processing on the texture the
initial texture value is lost. I want to preserve it. This is why i render the
same scene to two texture.
One Texture that contains the main scene and other texture also contains the
main scene but will go through further operation.
All the rendering are in PRE_ORDER except the HUD camera. HUD camera is using
the NESTED_RENDER.
When the HUD camera is viewing any texture it is accessing the texture as
follows:
***'
..
//the scene is passed to the followng class
bp = new BlurPass(subgraph,clearColour);
distortionNode-addChild(bp-getRoot().get());
...
//the following function is accessing the texture by checking first the active
switch node
stateset-setTextureAttributeAndModes(0,
bp-getOutputTexture().get(),osg::StateAttribute::ON);
...
osg::ref_ptrosg::Texture2D BlurPass::getOutputTexture() const
{
int out_tex = _ActiveBranch;
return _ProcessPass[out_tex]-getOutputTexture();
}
//inside the BlurPass class i call the following function that make one switch
enables while making the other disabled - in other words flip fllop
void BlurPass::activateBranch()
{
//GET THE current activate branch
int onb = _ActiveBranch;
osg::notify(osg::NOTICE) on bit onb std::endl;
//get teh current inactive branch
int offb = (onb == 1) ? 0 : 1;
osg::notify(osg::NOTICE) off bit offb std::endl;
//make the active switch on
_BranchSwitch[onb]-setAllChildrenOn();
//make the inactive switch off
_BranchSwitch[offb]-setAllChildrenOff();
}
void BlurPass::flip()
{
_ActiveBranch = (_ActiveBranch == 1) ? 0 : 1;
osg::notify(osg::NOTICE)active branch _ActiveBranch std::endl;
activateBranch();
}
BlurPass::BlurPass(osg::Node *scene, const osg::Vec4 clearColor)
:_SubGraph(scene),
_ClearColor(clearColor)
{
//pre-define the texture
//width and height, the very same size
//we preserve all over the scene
_TextureWidth = 1280;
_TextureHeight = 1280;
//initially the shader is inactive
shaderFlag = false;
_RootGroup = new osg::Group;
//initialize the texture where we
//shall render the initial scene
createInputTexture();
//initialize the 2 output textures
//which will be flipped with keypress
//for multipass blurring
createOutputTextures();
//camera renders the scene to the 0-indexed texture
//that will be goiing through the blur phase in the process pass
setupCamera();
//create two switch to do the flip-flop
_BranchSwitch[0] = new osg::Switch;
_BranchSwitch[1] = new osg::Switch;
//add the camera and the two switches
//camera that renders the scene to the texture
_RootGroup-addChild(_Camera.get());
_RootGroup-addChild(_BranchSwitch[0].get());
_RootGroup-addChild(_BranchSwitch[1].get());
//initialize the active switch
_ActiveBranch = 0;
//activate the switch based on the
//current active branch flag
activateBranch();
//we have both input and output textures initialized and
//the _InOutTextureBlur[0] get the scene rendering that will
//going through the blur operation
_ProcessPass[0] = new
ProcessPass(_OutTextureBlur[0].get(),_OutTextureBlur[1].get(),
_TextureWidth,_TextureHeight);
_ProcessPass[1] = new
ProcessPass(_OutTextureBlur[1].get(),_OutTextureBlur[0].get(),
_TextureWidth,_TextureHeight);
_BranchSwitch[0]-addChild(_ProcessPass[0]-getRoot().get());
_BranchSwitch[1]-addChild(_ProcessPass[1]-getRoot().get());
}
//setup the render to texture camera
//the following function renders the initial scene to 2 textures
void BlurPass::setupCamera()
{
_Camera = new osg::Camera;
_Camera-setClearColor(_ClearColor);
_Camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
//just inherit the main cameras view
_Camera-setReferenceFrame(osg::Transform::RELATIVE_RF);
_Camera-setProjectionMatrix(osg::Matrixd::identity());
_Camera-setViewMatrix(osg::Matrixd::identity());
//set the viewport according to the value texture width and texture height
_Camera-setViewport(0,0,_TextureWidth,_TextureHeight);
//RENDER to texture before the main camera
_Camera-setRenderOrder(osg::Camera::PRE_RENDER);
//USE THE frame buffer object where supported
_Camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
//the camera with the relative frame renders to the input texture - index 0
//this texture will be input for the process pass
_Camera-attach(osg::Camera::COLOR_BUFFER0,_InputTexture.get());
Re: [osg-users] Render to Texture
Hi,
On 13/12/10 12:26, Sajjadul Islam wrote:
Hi Delport,
Reasons for rendering the scene to two textrues
With key press event i may want to show the texture using the HUD
that have not gone through any operation. If i do any post processing
on the texture the initial texture value is lost. I want to preserve
it. This is why i render the same scene to two texture.
One Texture that contains the main scene and other texture also
contains the main scene but will go through further operation.
yes, I understand this, it's OK.
All the rendering are in PRE_ORDER except the HUD camera. HUD camera
is using the NESTED_RENDER.
OK, I just wanted to make sure you are not creating a loop and expecting
OSG to figure out the render order based on how you connect input and
output textures. OSG just traverses your cameras in the order you attach
them to the scene (in the simplest case).
When the HUD camera is viewing any texture it is accessing the
texture as follows:
***'
..
//the scene is passed to the followng class bp = new
BlurPass(subgraph,clearColour);
distortionNode-addChild(bp-getRoot().get());
...
//the following function is accessing the texture by checking first
the active switch node stateset-setTextureAttributeAndModes(0,
bp-getOutputTexture().get(),osg::StateAttribute::ON);
...
osg::ref_ptrosg::Texture2D BlurPass::getOutputTexture() const {
int out_tex = _ActiveBranch;
return _ProcessPass[out_tex]-getOutputTexture(); }
//inside the BlurPass class i call the following function that make
one switch enables while making the other disabled - in other words
flip fllop
void BlurPass::activateBranch() { //GET THE current activate branch
int onb = _ActiveBranch;
osg::notify(osg::NOTICE) on bit onb std::endl;
//get teh current inactive branch int offb = (onb == 1) ? 0 : 1;
osg::notify(osg::NOTICE) off bit offb std::endl;
//make the active switch on _BranchSwitch[onb]-setAllChildrenOn();
//make the inactive switch off
_BranchSwitch[offb]-setAllChildrenOff(); }
void BlurPass::flip() { _ActiveBranch = (_ActiveBranch == 1) ? 0 :
1;
osg::notify(osg::NOTICE)active branch _ActiveBranch
std::endl;
activateBranch(); }
BlurPass::BlurPass(osg::Node *scene, const osg::Vec4clearColor)
:_SubGraph(scene), _ClearColor(clearColor) { //pre-define the
texture //width and height, the very same size //we preserve all over
the scene _TextureWidth = 1280; _TextureHeight = 1280;
//initially the shader is inactive shaderFlag = false;
_RootGroup = new osg::Group;
//initialize the texture where we //shall render the initial scene
createInputTexture();
//initialize the 2 output textures //which will be flipped with
keypress //for multipass blurring createOutputTextures();
//camera renders the scene to the 0-indexed texture //that will be
goiing through the blur phase in the process pass setupCamera();
//create two switch to do the flip-flop _BranchSwitch[0] = new
osg::Switch; _BranchSwitch[1] = new osg::Switch;
//add the camera and the two switches
//camera that renders the scene to the texture
_RootGroup-addChild(_Camera.get());
_RootGroup-addChild(_BranchSwitch[0].get());
_RootGroup-addChild(_BranchSwitch[1].get());
//initialize the active switch _ActiveBranch = 0;
//activate the switch based on the //current active branch flag
activateBranch();
//we have both input and output textures initialized and //the
_InOutTextureBlur[0] get the scene rendering that will //going
through the blur operation _ProcessPass[0] = new
ProcessPass(_OutTextureBlur[0].get(),_OutTextureBlur[1].get(),
_TextureWidth,_TextureHeight);
_ProcessPass[1] = new
ProcessPass(_OutTextureBlur[1].get(),_OutTextureBlur[0].get(),
_TextureWidth,_TextureHeight);
_BranchSwitch[0]-addChild(_ProcessPass[0]-getRoot().get());
_BranchSwitch[1]-addChild(_ProcessPass[1]-getRoot().get());
}
//setup the render to texture camera //the following function renders
the initial scene to 2 textures void BlurPass::setupCamera() {
_Camera = new osg::Camera;
_Camera-setClearColor(_ClearColor);
_Camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
//just inherit the main cameras view
_Camera-setReferenceFrame(osg::Transform::RELATIVE_RF);
_Camera-setProjectionMatrix(osg::Matrixd::identity());
_Camera-setViewMatrix(osg::Matrixd::identity());
//set the viewport according to the value texture width and texture
height _Camera-setViewport(0,0,_TextureWidth,_TextureHeight);
//RENDER to texture before the main camera
_Camera-setRenderOrder(osg::Camera::PRE_RENDER);
//USE THE frame buffer object where supported
_Camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
//the camera with the relative frame renders to the input texture -
index 0 //this texture will be input for the process pass
Re: [osg-users] TexGen for screen coordinates.
chrisd wrote:
Paul Martz wrote:
On 12/10/2010 5:21 AM, Chris Denham wrote:
I've been trying to apply a 2d texture to an object where I want the UVs
to correspond to screen position. A bit like using EYE_LINEAR texgen, but
with the texture projected 'orthographically' through the screen.
What I want would in effect be like applying the texture so it always
spans the window, but without applying the perspective of the camera. I
guess, a bit like using the texture as a stencil.
I've tried using EYE_LINEAR, and that very nearly does what I want, but I
want to remove the effect of perspective on the way the texcoords are
calculated.
In other words, I think I want calculated texture UV's to be something
like:
texcoord.x = (worldPosition * (projectionMatrix * modelViewMatrix)).x
texcoord.y = (worldPosition * (projectionMatrix * modelViewMatrix)).y
What's the best way to implement this without using stencil buffer or
shaders?
Is there a way to do it by adjusting the texture matrix object to remove
the perspective projection?
Or would it be better to recalculate texCoords on geometries prior to
each frame?
Hope this makes some kind of sense.
With those restrictions, it seems like the texture matrix is your only path
to a
solution, though I couldn't type it here off the top of my head. It would
take
some dev time to get it right.
What you want to do would be trivial with a shader. Is there a reason why
you've
ruled out use of shaders for this problem?
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
Thanks Paul,
I may use a shader if it comes down to it, but I was trying (if possible) to
get a solution that works on Joe Public's bargin basement laptop that
probably has poor (if any) shader support.
I have experimented with texmat object to get the projection right, but I
can't seem to get the matrix right (probably cos of my flakey maths). Maybe
I'll post a cut down example an someone can see if they spot the problem.
I've had some success with recalculating the texcoords on geometries and
assigning them with UVs based on screen coords. It's very nearly what I want
but I'm getting some odd distortions due to uv interpolation (I think).
Possibly a result of the texture mapping perspective correction, though I
tried switching that off with GL_PERSPECTIVE_CORRECTION_HINT = GL_FASTEST to
no avail :(
Ho hum maybe as you say, a shader is the answer, well, if I can make it
fail tidy on old craptops.
Cheers
Chris.
Well... I gave up on trying to do it that hard way, and as Paul suggested, it
was fairly trivial to do in a shader. e.g.
Code:
osg::Program* programShader = new osg::Program();
stateSet-setAttribute(programShader, osg::StateAttribute::ON);
stateSet-addUniform(new osg::Uniform(viewport, osg::Vec4(0, 0, 800, 600)));
stateSet-addUniform(new osg::Uniform(screen_texture, 0));
stateSet-addUniform(new osg::Uniform(tinge, osg::Vec4(0.9, 0.9, 0.9, 1.0)));
stateSet-setUpdateCallback(new ViewportTracker(pViewer-getCamera()));
osg::Shader *frag = new osg::Shader(osg::Shader::FRAGMENT);
frag-setShaderSource(
uniform sampler2D screen_texture; \
uniform vec4 viewport; \
uniform vec4 tinge; \
void main() \
{ \
vec2 origin = vec2(viewport[0], viewport[1]); \
vec2 size = vec2(viewport[2], viewport[3]); \
vec2 coord = (gl_FragCoord.xy - origin) / size; \
vec4 color = texture2D(screen_texture, coord); \
gl_FragColor = color * tinge; \
if (!gl_FrontFacing) gl_FragColor = tinge; \
});
programShader-addShader(frag);
Though I did wonder if there was a better way to get or convert to normalized
screen units because otherwise I have to put in a callback to track the
viewport definition and transfer it to the Uniform attribute?
Not a big issue, but any ideas on how to avoid needing to do that?
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34765#34765
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hi, the strangeness ito depth disappeared when I added: camera01-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); camera02-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); So, I think the auto compute of near/far is breaking your depth buffer consistency. Set the near/far manually. What effect are you trying to achieve? rgds jp On 13/12/10 12:19, George Bekos wrote: Hey, Hmm.. maybe there is something wrong with the cpp file I attached. Anyway, here is the code: http://pastesite.com/20651 Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34761#34761 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
It worked! Thank you so much! What I am trying to achieve is the following: I have a mesh with multiple submeshes and I have a clipping plane cutting them in random place. I want to place a cap on every submesh cut, so they will look solid. In order to do this I do the following: * Draw geometry backfaces to the stencil buffer and INCR stencil values * Draw geometry frontfaces to the stancil buffer and DECR stencil values -- This way I get a mask which is the pixels of the cap I have to draw. Then: * Draw a plane parallel to the clipping plane with a selected texture ONLY where I have a non-zero value at the stencil buffer. * Draw the final submesh with lighting enabled. I could do this without multiple cameras, BUT each submesh has different cap texture. So I have to repeat the above procedure for all my submeshes. (or at least as many times as the difference cap textures). I will continue working on this now. Thanks again for solving my problem! Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34768#34768 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG and GTK+
Dear all,
I'm writing a plugin for a software whose command prompt is in inside a
GTK+ GUI. My plugin is a set of C functions, most of them are supposed
to do computational stuff and one is supposed to create a GTK+ window
with an OSG drawing area for visualization. These functions are
collected in a shared library which is dynamically linked to the main
software (that one with the prompt inside a GTK+ GUI) at run-time (i.e.
the classical plugin functioning).
Now, I'm new to GTK+ development and the GUIs in general --I choose GTK+
because the main software itself uses GTK+, so I can avoid additional
dependencies for the GUI-- and also I'm moving my first steps in OSG.
Thus, as first thing, I've taken a look at osgviewerGTK and it works
very well: if I use gtk_main() as last instruction of the GUI build
function, all works fine.
However, gtk_main() starts a main loop for my visualization window and
this makes the command prompt of the main software unavailable to the
user, until the window is destroyed. So, I've changed gtk_main() to
while (gtk_events_pending())
gtk_main_iteration();
This would return the control to the prompt, but I then get a segfault:
Program received signal SIGSEGV, Segmentation fault.
0x00618c65 in gtk_widget_grab_focus () from /usr/lib/libgtk-x11-2.0.so.0
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x01417ae4 in osgGA::EventQueue::getTime (this=0x2)
at /usr/include/osgGA/EventQueue:183
183double getTime() const { return
osg::Timer::instance()-delta_s(_startTick,
osg::Timer::instance()-tick()); }
I'm working on Ubuntu 10.04 32bit and I've used the following ld options
in my makefile: -losg -losgViewer -losgGA -losgDB -lpthread.
The first SIGSEGV occurs in libgtk and it seems to suggest that my
approach (changing gtk_main() with gtk_main_iteration()) is wrong.
However, I've tried the GTK+ Hello World described at
http://library.gnome.org/devel/gtk-tutorial/2.90/c39.html#SEC-HELLOWORLD
and it has worked as expected. Also I've tried to use VTK and the
GTK-VTK interface at http://vtkgtk.sourceforge.net/ in place of OSG and
apart from a problem with the drawing area (I got the same error by
using both gtk_main() and gtk_main_iteration(), so I think the interface
itself has some issue...) it also has worked as expected: no segfaults
and buttons up, running and responding. However I still would prefer to
use OSG instead of VTK.
IMHO there is a problem in the osgviewerGTK example class which appears
to be unusable unless it is used in classical GTK+ app. where gtk_main()
is required. If someone could give some advices on how to modify the class
OSGGTKDrawingArea to work in the situation described above, it would be
greatly appreciated.
Thanks in advance for those who have read until here :)
Regards,
--
Matteo
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New to OSG, few simple questions.
On 12/13/2010 2:35 AM, Zoran Hranj wrote: Hi everybody, I'm new to OSG and from what I can see I regret I havent come here sooner. Before I start, I have a few questions. http://www.vis-sim.com/osg/osg_faq_1.htm 1. Is OSG free to use in commercial software? Yes. 2. How does OSG handle windows? Is it built in or requires 3rd party sw? Hard to tell if you mean Microsoft Windows or just window management in general. Both are included. 3. Any experience and/or thoughts of using Qt with OSG? Works pretty well, from what I understand. -- 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] New to OSG, few simple questions.
Hello Zoran, I'll just add a few details over what Chris said. 2. How does OSG handle windows? Is it built in or requires 3rd party sw? I agree with Chris that your question may mean 2 things. - We use OSG on MS Windows all the time, it's our primary platform. We try hard to make sure that OSG always builds cleanly and runs well on multiple platforms, major ones being Linux, Windows and OS X. - Native window system integration is generally done using the osgViewer library (included in OSG), which has classes for integration into Windows, X11 and Carbon/Cocoa (and now IOS). If want to integrate into a widget toolkit (GTK, Qt, etc.) there are examples in the OSG examples directory, they all start with osgViewer*, but be advised that in some cases these use the GraphicsWindowEmbedded class which means that the widget/window system is in charge of context management and will generally prevent you from using OSG's threading capabilities to their full potential. 3. Any experience and/or thoughts of using Qt with OSG? There are two ways of using OSG with Qt, both of which have examples in the examples directory. The first way is to embed OSG in a Qt widget. See osgViewerQT, osgViewerQtViewer and osgViewerQtContext for examples of this. The second way is the opposite, rendering Qt widgets in your OSG 3D scene (as a HUD or on top of a quad in 3D space). See osgQtWidgets and osgQtBrowser for examples of this. Please search the archives or the forum for more details. I haven't had time to polish the latter set of examples lately, but would like to, in addition to adding a bit of documentation about them on the wiki. But reading the code should help you get started. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with Multiple Cameras drawing in the same viewport.
Hi, On 13/12/10 14:05, George Bekos wrote: It worked! Thank you so much! What I am trying to achieve is the following: I have a mesh with multiple submeshes and I have a clipping plane cutting them in random place. I want to place a cap on every submesh cut, so they will look solid. In order to do this I do the following: * Draw geometry backfaces to the stencil buffer and INCR stencil values * Draw geometry frontfaces to the stancil buffer and DECR stencil values -- This way I get a mask which is the pixels of the cap I have to draw. Then: * Draw a plane parallel to the clipping plane with a selected texture ONLY where I have a non-zero value at the stencil buffer. * Draw the final submesh with lighting enabled. I could do this without multiple cameras, BUT each submesh has different cap texture. So I have to repeat the above procedure for all my submeshes. (or at least as many times as the difference cap textures). Sounds cool, I initially thought it was something transparency related. I will continue working on this now. Thanks again for solving my problem! enjoy jp Cheers, George -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34768#34768 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Curves/splines
Hi Paavo, i hope that this link could help you: http://code.google.com/p/osgmodeling/ Cheers, Jagovic Hi I'd like to use curves, particularly simple 2d control point based splines to drive variables of scene graph objects over time. I'd also like to use both linear and cubic interpolated curves. So for example the curve could be sharp sawtooth, a cubic curve with smooth knee/shoulder, etc. A smooth curve could be used to control the fade-in or fade-out of a text object for example. Is there a (fast) library for doing this? Or is there another approach for doing this? ... Thank you! Cheers, Paavo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Curves/splines
Thanks for the link jago, osgModeling certainly looks comprehensive! For the time being, I implemented the Catmull-Rom spline, which serves my purposes ok. Regards, - PM -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34781#34781 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniform array naming problem
How about just trimming off any invalid characters from the name returned by
glGetActiveUniform?
e.g.
_extensions-glGetActiveUniform( _glProgramHandle,
i, maxLen, 0, size, type, name );
for (GLsizei j = 0; j maxLen name[j]; ++j)
{
if (!isalnum(name[j]) name[j] != '_')
{
name[j] = '\0';
break;
}
}
On 9 December 2010 18:46, Glenn Waldron gwald...@gmail.com wrote:
Hi Robert,
I would like to re-raise the issue of uniform array naming, now that it is
affecting me personally :)
To recap:
I have a uniform array in a shader defined as:
uniform bool positions[1];
osg::Program calls glGetActiveUniform() to build a mapping of compiled
uniforms by name. On some systems, the name returned is positions and on
others it is positions[0]. When the latter happens, a corresponding
osg::Uniform named positions will fail since it cannot find a matching
uniform location in the mapping (since it's filed under positions[0]).
I am not convinced that this is a driver bug. It seems more like an
ambiguity. The docs say that the 'uniform location for positions and
positions[0] are the same; they point to the first element of the array.'
(opengl.org/wiki/G...http://www.opengl.org/wiki/GLSL_Uniform#Uniform_management).
I don't see anything that says the value returned from glGetActiveUniform()
must be one or the other.
If both names are valid and equivalent, shouldn't we account for both
possibilities in osg::Program? I suppose you could just alter
getUniformLocation(...) to check for both variations.
Here are the past threads on the topic. The issue crops up on both ATI and
NVIDIA systems.
http://markmail.org/thread/5mans4howfbu2qtg
http://forum.openscenegraph.org/viewtopic.php?t=1828
System: WinXP 32, ATI HD5550/10.11, OSG SVN.
Thanks.
Glenn Waldron : Pelican Mapping
___
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] VBO possible leakage
Hi,
Using the gDEBugger I found some VBO leaks on application exit.
For example the leak could be easily seen if we add useVertexBufferObjects
TRUE into cessna.osg and will try to render it via standard osgviewer.
OSG calls releaseGLObjects before exit for the loaded tree and for Geometry it
calls releaseGLObjects for ArrayList and DrawElementsList.
For DrawElementsList everything is ok. But for Array there is no special
releaseGLObjects implementation and the
empty Object::releaseGLObjects is called.
So should something like
virtual void releaseGLObjects(State* state=0) const
{
if (_vbo.valid()) _vbo-releaseGLObjects(state);
}
be added to Array header?
Thank you!
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34783#34783
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO possible leakage
Hi George,
I have just reviewed the relevant code Array's are no implementing the
releaseGLObjects(State*) as they should be. The solution is to add a
resizeGLObjectBuffers(uint) and releaseGLObjects(State*) to BufferData
and this automatically call the appropriate method on
osg::BufferObject if one is attached to the BufferData.
I have now checked in these changes. Could you please try our
svn/trunk to see how things perform.
Thanks,
Robert.
On Mon, Dec 13, 2010 at 3:58 PM, George Sarkisyan
george.sarkis...@kongsberg.com wrote:
Hi,
Using the gDEBugger I found some VBO leaks on application exit.
For example the leak could be easily seen if we add useVertexBufferObjects
TRUE into cessna.osg and will try to render it via standard osgviewer.
OSG calls releaseGLObjects before exit for the loaded tree and for Geometry
it calls releaseGLObjects for ArrayList and DrawElementsList.
For DrawElementsList everything is ok. But for Array there is no special
releaseGLObjects implementation and the
empty Object::releaseGLObjects is called.
So should something like
virtual void releaseGLObjects(State* state=0) const
{
if (_vbo.valid()) _vbo-releaseGLObjects(state);
}
be added to Array header?
Thank you!
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34783#34783
___
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] Render to Texture
Hi Delport, I am sorry that i did not get much from your last reply asking how am i changing the texture when i switch the branches. Do i have to explicitly specify the texture? Even it is i believe that it is done as follows: stateset-setTextureAttributeAndModes(0, bp-getOutputTexture().get(),osg::StateAttribute::ON); bp-getOutputTexture() is retrieving the correct texture based on the value of the _ActiveBranch. With key press event i have a function that flips the switch node that turns one switch's input to other switch's output. If i have to call this function again where should the call go into? It seems that the state is dynamic and do i have to implement a state change callback ? Thank you! Regards Sajjadul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34786#34786 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture subloads
Hi All! I have very specific problem which I don't know how to solve with OSG. I want to create very large texture atlas (4096x2048) which consists of small subtextures (128x64, so there are 32x32=1024 subtextures). Each of small textures should contain some textual/symbol information which is supposed to be frequently updated in the runtime. I use Qt to compose QImage with rendered text/symbols and I want to update some subtexture (given by offsets in x and y with constant size) of the the texture atlas with prerendered data. I know how to achieve this with pure OpenGL (using PBO and glTexSubImage2D), but I can't figure out if there is a way do this with OSG? Maybe subclassing osg::Texture2D or something? Thank you! Best regards, Yurii Monakov ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Switch , UpdateCallback not being dissabled
Hi, Tedzini You r right. First level children invoke their updatecallback, but furtur level of children doesn't invoke their. Have you found the solution? I try to solve also. If something solved, i'll make reply Thank you! Cheers, SC -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34752#34752 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Memory Usage
Hi Robert, I took a look into this again and I think I know what the issue is although I'm not sure about the solution. In GLBufferObjectManager::getGLBufferObjectSet a new GLBufferObjectSet is created each time b/c the number of verts generated on each frame is different so the profile doesn't match. This means that no reuse is happening and it also means that all the GLBufferObjectSets are sticking around forever b/c the _glBufferObjectSetMap is never cleared out or has items erased from it so it just keeps growing and growing. Is there a way we could go through periodically and check to see if a GLBufferSet in the glBufferObjectSetMap hasn't been used in a while and delete it once some maximum number of sets has been reached? Thanks, Jason On Mon, Oct 4, 2010 at 9:13 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Jason, On Mon, Oct 4, 2010 at 2:07 PM, Jason Beverage jasonbever...@gmail.com wrote: Just pinging again to see if you have any thoughts on this. No rush, just wanted to make sure it didn't get lost. I haven't had a chance to look into the issue yet. My guess is that the texture object pool is keeping the GL texture objects around in case they can be reused but as the sizes are never compatible it never achieves this and has to allocate new ones. What will need to happen is for there to be an automatic scheme for deleting texture objects when new ones are needed and there memory has already hit the specific texture pool limits. I do recall thinking about this particular issue when I implemented the code, and there might even be code that already attempts to do this. Go have a look at the code to see if you can see what's going on. Robert. ___ 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] Error Compiling OSG GL3 on Win7/VS 2008
Hi, I tried to compile OSG withGL3 on windows and VS 2008 fo testing purposes. I disabled the other GL options as describte in an other thread. VS failed to compile in Matrix_implementation.cpp: Code: if (fabs(length2) = std::numeric_limitsdouble::min()) ... The error output is about the min macro and invalid token right to '::' (line 70+) Does anyone know what this error could be about? Has anyone used GL3 successfully on a windows machine? Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34789#34789 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error Compiling OSG GL3 on Win7/VS 2008
Hi Torben, The error output is about the min macro and invalid token right to '::' (line 70+) Does anyone know what this error could be about? Has anyone used GL3 successfully on a windows machine? I haven't built OSG with GL3, but when MSVC complains about min/max, it's usually because someone somewhere included windows.h without first defining WIN32_LEAN_AND_MEAN or NOMINMAX (the former implies the latter). This happens because somewhere in the headers included by windows.h, min and max are defined as macros. So anywhere code uses the names min or max after that, it will be replaced by the preprocessor and then anything before (like std::numeric_limitsdouble:: in the line you quoted) will cause a compiler error. I guess you'll have to find where windows.h was included (any of the headers included in Matrix_implementation.h, and headers included by those, etc.) and add the appropriate define to stop it from defining the min and max macros. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG problem with multiple cards
Hi, I would like to update the discussion we started back in October regarding an apparent problem scaling OSG to multiple windows on multiple graphics cards. For full details on the previous discussion search the email archive for problem scaling to multiple cards. Summary of the problem: We have a multi-threaded OSG application using version 2.8.3. (We also ran the same tests using version 2.9.9 and got the same results.) We have a system with four Nvidia FX5800 cards (an immersive cave like config) and 8 cores with 32 GB memory. Since the application is parallel drawing to independent cards using different cores, we expect the frame rate to be independent of the number of cards in use. However, frame rate is actually X/N where N is the number of cards being used. For example if the frame rate is 100 using one card, the frame rate drops to 50 for 2 cards and 25 for 4 cards in use. If the application worked properly, the FPS would be 100 in all cases. We have tried a number of things to isolate the problem: * We can run four copies of the test program each drawing to a different card, using a different core, and get the expected FPS. In this case, 4 copies run the same speed as 4, 3 or 1 copies. * We have created a pure OpenGL threaded application which draws to 1, 2, 3, or 4 cards. There is no OSG involved. This application runs properly, no degradation in FPS for multiple cards. * When we set OSG_SERIALIZE_DRAW_DISPATCH to OFF (default is ON) the total FPS actually drops. Watching the graphical statistics, the DRAW is clearly running in parallel, but is actually a bit slower than when the DRAW is serialized. While this behavior is consistent with the messages posted by Robert in August 2007 (search for OSG_SERIALIZE_DRAW_DISPATCH), its not what one would think should happen. Specifically, it seems counter-intuitive that serialized DRAW is faster than parallel DRAW. * We have created a separate system using two Nvidia FX4600 cards and experienced the same mis-behavior. * We have tried numerous Nvidia drivers, from the most recent to older drivers with the same mis-behavior. * We have configured a system using two ATI Radeon HD 3450 cards and get the same mis-behavior. This test eliminates the Nvidia driver and OpenGL libraries as a source of the problem. * We tried a version of the test program that uses separate copies of the scenegraph for each camera, to eliminate contention on the data in the scenegraph, but got the same results. Looking at the results of our tests, its seems to indicate there is some OSG problem preventing multi-threaded applications from running properly on systems with multiple graphics cards (and multiple cores). OSG is a critical component to our immersive virtual reality environment. Our scientific visualization applications are continuing to demand more and more performance. We need multi-threading to work properly. What experiences are others with multiple cards having regarding multi-threading? If anyone is interested, we can send our test program. We would very much appreciate any help or suggestions on solving this problem anyone can offer. Thanks, Steve Satterfield, st...@nist.gov John Kelso, ke...@nist.gov ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Inventor not working with GLES1.x?
I've got a problem with compiling OSG for GLES1.1 on Ubuntu. I have the Imagination GLES1.x emulator installed, but I'm having some problems compiling OSG. I've followed the guidelines on /wiki/Community/OpenGL-ES and I've succesfully compiled for GLES2.0 before on this very system (also have Imagination GLES2.0 emulator). However, with GLES1.x there seems to be a problem with the Inventor or ive plugin, which seems to be using the regular OpenGL headers for some reason. Anyway, this is the error I get: Code: [ 67%] Building CXX object src/osgPlugins/ive/CMakeFiles/osgdb_ive.dir/DrawElementsUShort.o In file included from /usr/include/Inventor/system/gl-headers.h:40, from /usr/include/Inventor/system/gl.h:38, from /usr/include/Inventor/C/glue/gl.h:33, from /usr/include/Inventor/nodes/SoShaderObject.h:33, from /usr/include/Inventor/nodes/SoVertexShader.h:27, from /home/user/OpenSceneGraph-2.9.9/OpenSceneGraphGLES1/src/osgPlugins/Inventor/ConvertFromInventor.cpp:64: /usr/include/GL/glext.h:7232: error: expected ‘,’ or ‘...’ before ‘*’ token /usr/include/GL/glext.h:7233: error: ‘GLclampd’ has not been declared /usr/include/GL/glext.h:7233: error: ‘GLclampd’ has not been declared /usr/include/GL/glext.h:7243: error: expected ‘,’ or ‘...’ before ‘*’ token /usr/include/GL/glext.h:7244: error: ‘GLclampd’ has not been declared /usr/include/GL/glext.h:7244: error: ‘GLclampd’ has not been declared In file included from /usr/include/Inventor/system/gl-headers.h:40, from /usr/include/Inventor/system/gl.h:38, from /usr/include/Inventor/C/glue/gl.h:33, from /usr/include/Inventor/nodes/SoShaderObject.h:33, from /usr/include/Inventor/nodes/SoVertexShader.h:27, from /home/user/OpenSceneGraph-2.9.9/OpenSceneGraphGLES1/src/osgPlugins/Inventor/ConvertFromInventor.cpp:64: /usr/include/GL/glext.h:9550: error: variable or field ‘glDepthBoundsEXT’ declared void /usr/include/GL/glext.h:9550: error: ‘GLclampd’ was not declared in this scope /usr/include/GL/glext.h:9550: error: ‘GLclampd’ was not declared in this scope /usr/include/GL/glext.h:9552: error: typedef ‘PFNGLDEPTHBOUNDSEXTPROC’ is initialized (use decltype instead) /usr/include/GL/glext.h:9552: error: ‘GLclampd’ was not declared in this scope /usr/include/GL/glext.h:9552: error: ‘GLclampd’ was not declared in this scope make[2]: *** [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertFromInventor.o] Error 1 make[1]: *** [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/all] Error 2 Can anyone shed some light on this? I just finished GLES2.0 compiling and that worked fine, but GLES1.x doesn't seem to work :S. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34727#34727 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Cannot make target:
When I'm building OSG on a BeagleBoard in Angstrom Linux I get this error: make[2]: *** No rule to make target `/usr/lib/libpng.so', needed by `lib/osgPlugins-2.9.11/osgdb_png.so'. Stop. make[1]: *** [src/osgPlugins/png/CMakeFiles/osgdb_png.dir/all] Error 2 make: *** [all] Error 2 I've checked libpng.so and it is there. Even reinstalled it, also the dev and dbg versions of the lib, to no avail. It has compiled successfully before, so I got no idea what is wrong here. I've retried three times already (which is a real pain as compiling takes 10 hours, since I didn't manage to set up a cross compiling environment), everytime downloading again from SVN trunk. But everytime I get this error. Hope you can help me with this ;). Thank you in advance for your help! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34746#34746 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Cannot make target:
Sorry fixed it already myself. Somehow the symlinks were broken, although they worked before :S. But the reference was wrong now. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34792#34792 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] non-virtual thunk errors with 2.9.9, 2.9.10
Hi, When I try to link my executables using osg-2.9.9 or osg-2.9.10 I get messages like: libiris.so: undefined reference to `non-virtual thunk to osgViewer::Viewer::setSceneData(osg::Node*)' I'm using CentOS and gcc 4.1.2. I googled a bit and found this problem mentioned when using one optimization level for a building a library and a different optimization level when compiling programs that link with the library. The executable, and the programs comprising libiris.so, are compiled with whatever's the default optimization. I built osg-2.9.9 and osg-2.9.10 just before building libiris.so, so I'm using the same compiler, system libraries and so forth. I don't get this error on a freshly rebuilt osg-2.8.3. I also didn't specify any optimization level when building OSG. osgviewer builds and runs. Any ideas about how to start tracking this problem down? More gory details on request. Many thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] non-virtual thunk errors with 2.9.9, 2.9.10
I saw a similar error when upgrading from Fedora 13 to Fedora 14, which uses a different version of gcc. In my case the solution was to remove the contents of my .ccache directory. More generally, I think this problem comes from mixing object files produced by different g++ versions. Tim On Mon, Dec 13, 2010 at 10:36 PM, John Kelso ke...@nist.gov wrote: Hi, When I try to link my executables using osg-2.9.9 or osg-2.9.10 I get messages like: libiris.so: undefined reference to `non-virtual thunk to osgViewer::Viewer::setSceneData(osg::Node*)' I'm using CentOS and gcc 4.1.2. I googled a bit and found this problem mentioned when using one optimization level for a building a library and a different optimization level when compiling programs that link with the library. The executable, and the programs comprising libiris.so, are compiled with whatever's the default optimization. I built osg-2.9.9 and osg-2.9.10 just before building libiris.so, so I'm using the same compiler, system libraries and so forth. I don't get this error on a freshly rebuilt osg-2.8.3. I also didn't specify any optimization level when building OSG. osgviewer builds and runs. Any ideas about how to start tracking this problem down? More gory details on request. Many thanks, John ___ 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] Error Compiling OSG GL3 on Win7/VS 2008
Hi J-S, you are right using NOMINMAX avoids the problem. I tracked it down to osg/GL and the inclusion of gl3.h: Code: #elif defined(OSG_GL3_AVAILABLE) #define GL3_PROTOTYPES 1 #include GL3/gl3.h #ifndef GL_APIENTRY #define GL_APIENTRY APIENTRY #endif // GL_APIENTRY #else With definintion NOMINMAX in front of the include it works, defining NOMINMAX after the gl3.h include, it failed. In the gl3.g it checks for win and defines WIN32_LEAN_AND_MEAN. In my case this is not enough, only with defining NOMINMAX, it compiles (at least the osg module, some plugins still fail but I will test that tomorrow.) To avoid modifications in gl3.h i modified my osg/GL: Code: ... #elif defined(OSG_GL3_AVAILABLE) #ifdef WIN32 #ifdef NOMINMAX #define NOMINMAX #endif #endif #define GL3_PROTOTYPES 1 #include GL3/gl3.h #ifndef GL_APIENTRY #define GL_APIENTRY APIENTRY #endif // GL_APIENTRY #else ... Is this a valid fix ready to submit, or is it to much hack to be ready for merging? In the next days I hope to solve the confict between tesselator and unit to solve this GL3 issue for the next dev release. Thanks for your help, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34795#34795 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] non-virtual thunk errors with 2.9.9, 2.9.10
Hmmm... I can't seem to find any .ccache directory or file... I *thought* I recompiled and reinstalled everything in OSG and my software, but I'll do so one more time. Any other ideas out there? Thanks, John On Mon, 13 Dec 2010, Tim Moore wrote: I saw a similar error when upgrading from Fedora 13 to Fedora 14, which uses a different version of gcc. In my case the solution was to remove the contents of my .ccache directory. More generally, I think this problem comes from mixing object files produced by different g++ versions. Tim On Mon, Dec 13, 2010 at 10:36 PM, John Kelso ke...@nist.govmailto:ke...@nist.gov wrote: Hi, When I try to link my executables using osg-2.9.9 or osg-2.9.10 I get messages like: libiris.so: undefined reference to `non-virtual thunk to osgViewer::Viewer::setSceneData(osg::Node*)' I'm using CentOS and gcc 4.1.2. I googled a bit and found this problem mentioned when using one optimization level for a building a library and a different optimization level when compiling programs that link with the library. The executable, and the programs comprising libiris.so, are compiled with whatever's the default optimization. I built osg-2.9.9 and osg-2.9.10 just before building libiris.so, so I'm using the same compiler, system libraries and so forth. I don't get this error on a freshly rebuilt osg-2.8.3. I also didn't specify any optimization level when building OSG. osgviewer builds and runs. Any ideas about how to start tracking this problem down? More gory details on request. Many thanks, John ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] OSG problem with multiple cards
On Mon, Dec 13, 2010 at 9:51 PM, Steve Satterfield st...@nist.gov wrote: Hi, I would like to update the discussion we started back in October regarding an apparent problem scaling OSG to multiple windows on multiple graphics cards. For full details on the previous discussion search the email archive for problem scaling to multiple cards. Summary of the problem: We have a multi-threaded OSG application using version 2.8.3. (We also ran the same tests using version 2.9.9 and got the same results.) We have a system with four Nvidia FX5800 cards (an immersive cave like config) and 8 cores with 32 GB memory. Are you using Linux? Since the application is parallel drawing to independent cards using different cores, we expect the frame rate to be independent of the number of cards in use. However, frame rate is actually X/N where N is the number of cards being used. For example if the frame rate is 100 using one card, the frame rate drops to 50 for 2 cards and 25 for 4 cards in use. If the application worked properly, the FPS would be 100 in all cases. We have tried a number of things to isolate the problem: ... * We have created a pure OpenGL threaded application which draws to 1, 2, 3, or 4 cards. There is no OSG involved. This application runs properly, no degradation in FPS for multiple cards. Could you share the source of this program? * When we set OSG_SERIALIZE_DRAW_DISPATCH to OFF (default is ON) the total FPS actually drops. Watching the graphical statistics, the DRAW is clearly running in parallel, but is actually a bit slower than when the DRAW is serialized. While this behavior is consistent with the messages posted by Robert in August 2007 (search for OSG_SERIALIZE_DRAW_DISPATCH), its not what one would think should happen. Specifically, it seems counter-intuitive that serialized DRAW is faster than parallel DRAW. It is paradoxical. That it works at all is do to the fact that, with vsync enabled, all GPU activity is buffered up until the after the next SwapBuffers call. ... OSG is a critical component to our immersive virtual reality environment. Our scientific visualization applications are continuing to demand more and more performance. We need multi-threading to work properly. What experiences are others with multiple cards having regarding multi-threading? If anyone is interested, we can send our test program. We would very much appreciate any help or suggestions on solving this problem anyone can offer. I put together a multicard system specifically to look at these issues, and I too am very interested in getting it to work. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error Compiling OSG GL3 on Win7/VS 2008
On 12/13/2010 3:12 PM, Torben Dannhauer wrote: #ifdef NOMINMAX #define NOMINMAX I assume you mean #ifndef above? -- -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] Error Compiling OSG GL3 on Win7/VS 2008
Hi Torben, Perhaps moving this to the CMake files would make sense? I just checked the root CMakeLists.txt, and it has a section: IF (WIN32) ... # Both Cygwin and Msys need -DNOMINMAX ??? IF(UNIX) ADD_DEFINITIONS(-DNOMINMAX) ENDIF() ... ENDIF() Removing the IF(UNIX) from the above would also define NOMINMAX for MSVC (i.e. it would be defined for all Windows compilers, including Cygwin and MinGW which fall under the IF(UNIX) test and MSVC which falls under the IF(MSVC) test just above those lines). Can you try this? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Render on two screens with an angle
I want to build an app which should have one camera (or two identical, meaning that they are at the same position, facing the same direction, if that is more convenient) and multiple screens. The screens will be aligned in a 90 degree angle towards each other. So they are perpendicular: top view: Code: | - 1 | 2 | | | v | O Where O is the eye or camera. It's like looking at a box with holes in all sides and you want to see the inside. And the screens on which I want to project are the sides of the box. It's a bit like the PcubeE, but then with only two screens: http://hct.ece.ubc.ca/research/pcubee/ and http://www.youtube.com/watch?v=2iV0Icy41JM I've been messing with ViewMatrix, ViewProjectionMatrix, frustums etc. but I cannot get the result I want. I've looked at dozens of examples (like 3rdperson, windows, sidebyside, compositeviewer, etc.) but I do not really get the idea how to set this up, quite lost in all the possibilities at the moment. In the PcubeE paper (http://hct.ece.ubc.ca/publications/pdf/stavness-lam-fels-CHI2010.pdf) they say: To generate perspective-corrected images on each screen of pCubee, we use a standard off-axis projection scheme as described by Deering [9]. This is done in OSG by creating three View objects that correspond to the three visible screens on pCubee. The camera for each View is located at the user’s eye-position (which I will set manually at like right in the middle of the two screens, so at 45 degrees), oriented perpendicular to its corresponding virtual screen, and given a view frustum that passes through the corners of its virtual screen. Setting the near-clip plane coincident with the screen plane prevents rendering of virtual objects in front of the screens, which would cause occlusion issues at the screen edges. Synchronization between screens is handled within OSG: the separate Views are contained within a single CompositeViewer object and the camera parameters in each View are updated before a single call is made to CompositeViewer to update all the Views simultaneously. Well my question is: how do you do that in code. I'm sorry, I just started programming for OSG so I'm a noob :(. [/i] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34800#34800 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
Hi Delport,
I have created a new class inherating the osg::Drawable::UpdateCallback. The
class structure is as follows:
*'
class BlurCallback : public osg::Drawable::UpdateCallback
{
public:
BlurCallback(BlurPass *bp)
:_bp(bp),
_blurImage(false)
{
}
virtual void update(osg::NodeVisitor *nv, osg::Drawable *drawable)
{
osg::Geometry *geo = dynamic_castosg::Geometry*(drawable);
osg::StateSet *state = geo-getOrCreateStateSet();
state-setTextureAttributeAndModes(0,
_bp-getOutputTexture().get(),osg::StateAttribute::ON);
}
BlurPass *_bp;
mutable bool _blurImage;
};
**'
.
...
polyGeom-setUpdateCallback(bpCallback);
The program crashes when it reaches the viewer.run(); If the comment the above
code
the application runs. I think i need to implement some kind of callbacks
implement what you have suggested in the last post. Isnt it?
Regards
Sajjadul
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34801#34801
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render on two screens with an angle
On 14/12/10 10:23 , Bart Jan Schuit wrote: I want to build an app which should have one camera (or two identical, meaning that they are at the same position, facing the same direction, if that is more convenient) and multiple screens. The screens will be aligned in a 90 degree angle towards each other. So they are perpendicular top view: | - 1 | 2 | | | v | O In the PcubeE paper (http://hct.ece.ubc.ca/publications/pdf/stavness-lam-fels-CHI2010.pdf) they say: To generate perspective-corrected images on each screen of pCubee, we use a standard off-axis projection scheme as described by Deering [9]. This is done in OSG by creating three View objects that correspond to the three visible screens on pCubee. The camera for each View is located at the user’s eye-position (which I will set manually at like right in the middle of the two screens, so at 45 degrees), oriented perpendicular to its corresponding virtual screen, and given a view frustum that passes through the corners of its virtual screen. ... As I understand it, they're setting up two cameras, located in the eye point '0'. Camera 1 is projecting onto the vertical screen, and camera two is projecting onto the horizontal screen (as per your drawing). Camera 1 would look due right (down the X axis in your drawing), and camera 2 would look up/north (down the Y axis in your drawing). The frustum for camera 1 would then be *sheared* (not rotated) in the positive Y direction to coincide with the bounds or the projection rectangle. (This is one of those cases where a drawing says more than 1000 words, but I suck at drawing, as I've just rediscovered.) Hope this still makes some sense, Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG problem with multiple cards
Hi Steve, sorry, I might have asked this the previous time as well... Have you checked the thread affinity of the different threads? Are they not bound to a single CPU? AFAIR the osgviewer used to set its affinity and all subsequent threads inherited it. jp On 13/12/10 22:51, Steve Satterfield wrote: Hi, I would like to update the discussion we started back in October regarding an apparent problem scaling OSG to multiple windows on multiple graphics cards. For full details on the previous discussion search the email archive for problem scaling to multiple cards. Summary of the problem: We have a multi-threaded OSG application using version 2.8.3. (We also ran the same tests using version 2.9.9 and got the same results.) We have a system with four Nvidia FX5800 cards (an immersive cave like config) and 8 cores with 32 GB memory. Since the application is parallel drawing to independent cards using different cores, we expect the frame rate to be independent of the number of cards in use. However, frame rate is actually X/N where N is the number of cards being used. For example if the frame rate is 100 using one card, the frame rate drops to 50 for 2 cards and 25 for 4 cards in use. If the application worked properly, the FPS would be 100 in all cases. We have tried a number of things to isolate the problem: * We can run four copies of the test program each drawing to a different card, using a different core, and get the expected FPS. In this case, 4 copies run the same speed as 4, 3 or 1 copies. * We have created a pure OpenGL threaded application which draws to 1, 2, 3, or 4 cards. There is no OSG involved. This application runs properly, no degradation in FPS for multiple cards. * When we set OSG_SERIALIZE_DRAW_DISPATCH to OFF (default is ON) the total FPS actually drops. Watching the graphical statistics, the DRAW is clearly running in parallel, but is actually a bit slower than when the DRAW is serialized. While this behavior is consistent with the messages posted by Robert in August 2007 (search for OSG_SERIALIZE_DRAW_DISPATCH), its not what one would think should happen. Specifically, it seems counter-intuitive that serialized DRAW is faster than parallel DRAW. * We have created a separate system using two Nvidia FX4600 cards and experienced the same mis-behavior. * We have tried numerous Nvidia drivers, from the most recent to older drivers with the same mis-behavior. * We have configured a system using two ATI Radeon HD 3450 cards and get the same mis-behavior. This test eliminates the Nvidia driver and OpenGL libraries as a source of the problem. * We tried a version of the test program that uses separate copies of the scenegraph for each camera, to eliminate contention on the data in the scenegraph, but got the same results. Looking at the results of our tests, its seems to indicate there is some OSG problem preventing multi-threaded applications from running properly on systems with multiple graphics cards (and multiple cores). OSG is a critical component to our immersive virtual reality environment. Our scientific visualization applications are continuing to demand more and more performance. We need multi-threading to work properly. What experiences are others with multiple cards having regarding multi-threading? If anyone is interested, we can send our test program. We would very much appreciate any help or suggestions on solving this problem anyone can offer. Thanks, Steve Satterfield, st...@nist.gov John Kelso, ke...@nist.gov ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
Hi,
On 14/12/10 02:46, Sajjadul Islam wrote:
Hi Delport,
I have created a new class inherating the osg::Drawable::UpdateCallback. The
class structure is as follows:
*'
class BlurCallback : public osg::Drawable::UpdateCallback
{
public:
BlurCallback(BlurPass *bp)
:_bp(bp),
_blurImage(false)
{
}
virtual void update(osg::NodeVisitor *nv, osg::Drawable *drawable)
{
osg::Geometry *geo = dynamic_castosg::Geometry*(drawable);
osg::StateSet *state = geo-getOrCreateStateSet();
state-setTextureAttributeAndModes(0,
_bp-getOutputTexture().get(),osg::StateAttribute::ON);
}
BlurPass *_bp;
mutable bool _blurImage;
};
**'
.
...
polyGeom-setUpdateCallback(bpCallback);
The program crashes when it reaches the viewer.run(); If the comment the above
code
the application runs. I think i need to implement some kind of callbacks
implement what you have suggested in the last post. Isnt it?
You can for a start just do it when you modify the switch using the
keyboard. The callback will be called every frame, so I don't think that
is what you want.
jp
Regards
Sajjadul
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34801#34801
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
Hi, On 13/12/10 19:25, Sajjadul Islam wrote: Hi Delport, I am sorry that i did not get much from your last reply asking how am i changing the texture when i switch the branches. Do i have to explicitly specify the texture? Even it is i believe that it is done as follows: stateset-setTextureAttributeAndModes(0, bp-getOutputTexture().get(),osg::StateAttribute::ON); bp-getOutputTexture() is retrieving the correct texture based on the value of the _ActiveBranch. With key press event i have a function that flips the switch node that turns one switch's input to other switch's output. yes, but does the keypress cause bp-getOutputTexture() to be called again? If i have to call this function again where should the call go into? It seems that the state is dynamic and do i have to implement a state change callback ? Just call it on the keypress. jp Thank you! Regards Sajjadul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34786#34786 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error Compiling OSG GL3 on Win7/VS 2008
Hi Paul, Hi J-S yes you are right, I meant #ifndef, sorry for the typo :) Yes I'll move it to the cmake file as it does not touch the cource files, but I have no clue about bugs my changes could introduce on other build systems the MSVC, so I decided to ask :) Todayevening I'll move it to the cmakelists.txt and then try to solve the issues with tesselator and unit. So far, Thank you! :) Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34807#34807 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
