[osg-users] Slave cameras and frame buffer objects
Hi,
I have a slave camera attached to my viewer. It is set to PRE_RENDER and has a
RenderBuffer attached to a BufferObject attached to the depth buffer of the
the camera. The main scene camera is disabled (nodeMask = 0). If I run a frame
through the viewer I see the slave camera's rendering flash up in the corner of
the main view. Anyone no how to get rid of this. I have tried attaching a
RenderBuffer the slave camera's color buffer but I still get a flash. I have
attached a code snippet below.
Thank you!
Cheers,
Roger
Code:
osgViewer::Viewer::Cameras ActiveCameras;
std::dequeosg::Node::NodeMask NodeMasks;
pViewer-getCameras(ActiveCameras, true);
osg::ref_ptrosg::Camera pCamera = new osg::Camera;
if (!pCamera.valid() || !m_pFinalImage.valid())
{
VTLOG(CVisualImpactCalculatorOSG::Implementation - Cannot
create camera node or image\n);
return -1.0f;
}
pCamera-setName(Visual impact calculator camera);
pCamera-setClearColor(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f));
pCamera-setViewport(0, 0, DEFAULT_VISUAL_IMPACT_RESOLUTION,
DEFAULT_VISUAL_IMPACT_RESOLUTION);
pCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT,
osg::Camera::FRAME_BUFFER);
pCamera-setRenderOrder(osg::Camera::PRE_RENDER);
pCamera-attach(osg::Camera::DEPTH_BUFFER, GL_FLOAT); // Force a
renderBuffer
pCamera-setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR);
pCamera-setReferenceFrame(osg::Camera::ABSOLUTE_RF);
pCamera-setProjectionMatrix(m_ProjectionMatrix);
pCamera-setViewMatrix(m_ViewMatrix);
pCamera-setGraphicsContext(pViewer-getCamera()-getGraphicsContext());
if (!m_pIntermediateImage.valid())
{
VTLOG(CVisualImpactCalculatorOSG::Implementation - Cannot
create intermediate image\n);
return -1.0f;
}
// Stop any other cameras rendering the scene
for (osgViewer::Viewer::Cameras::iterator itr = ActiveCameras.begin(); itr
!= ActiveCameras.end(); ++itr)
{
NodeMasks.push_back((*itr)-getNodeMask());
(*itr)-setNodeMask(0);
}
// Set up the render bins
for (VisualImpactContributors::iterator itr =
m_VisualImpactContributors.begin(); itr != m_VisualImpactContributors.end();
itr++)
(*itr)-getOrCreateStateSet()-setRenderBinDetails(VISUAL_IMPACT_BIN_NUMBER,
VISUAL_IMPACT_BIN_NAME);
pViewer-addSlave(pCamera.get());
osgViewer::Viewer::ThreadingModel ThreadingModel =
pViewer-getThreadingModel();
if (ThreadingModel osgViewer::Viewer::CullDrawThreadPerContext)
{
pViewer-stopThreading();
pViewer-setThreadingModel(osgViewer::Viewer::CullDrawThreadPerContext);
pViewer-startThreading();
}
if (bOneOffMode)
{
pViewer-frame();
pViewer-removeSlave(pViewer-findSlaveIndexForCamera(pCamera.get()));
if (ThreadingModel != pViewer-getThreadingModel())
{
pViewer-stopThreading();
pViewer-setThreadingModel(ThreadingModel);
pViewer-startThreading();
}
for(osgViewer::Viewer::Cameras::iterator itr = ActiveCameras.begin();
itr != ActiveCameras.end(); ++itr)
{
(*itr)-setNodeMask(NodeMasks[0]);
NodeMasks.pop_front();
}
for (VisualImpactContributors::iterator itr =
m_VisualImpactContributors.begin(); itr != m_VisualImpactContributors.end();
itr++)
{
osg::StateSet *pStateSet = (*itr)-getOrCreateStateSet();
pStateSet-setRenderBinMode(osg::StateSet::INHERIT_RENDERBIN_DETAILS);
pStateSet-setRenderingHint(osg::StateSet::DEFAULT_BIN);
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46286#46286
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is there a reason a why different scene statistics are collected in Renderer::cull and Renderer::cull_draw paths
robertosfield wrote: I fixed the bug by consolodating the collection of the SceneView related stats into a single function and have the cull() and cull_draw() methods call this. I have checked this fix into svn/trunk and the OSG-3.0 branch. Could you please test it out? Thanks, Robert. Robert Thanks for the quick response. I will test the trunk build overnight tonight. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41628#41628 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Is there a reason a why different scene statistics are collected in Renderer::cull and Renderer::cull_draw paths
Hi, I have noticed that different scene statistics are collected in threading models where Renderer::cull_draw is called rather than Renderer::cull. In particular the number of fast drawables and none of the primitive set statistics are collected in cull_draw mode. Is there any reason for this. I just spent a while wondering where all my fast path drawables had disappeared to! Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41611#41611 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.0 and osgShadow texture unit problems
Hi,
I had some shadow code that was working well on 2.8.5 but will not work on
3.0.0. I verified that the same problem occurs with the OSG shadow example
source. My test machine GPU (Nvidia) reports 16 texture units available. If I
set the shadow texture unit number to anything higher than 7 then my OpenGL
trace reports errors as soon as this texture unit is accessed (for texgens from
the positionalStateContainer). This can be verified by adding the following
patch to osgshadow.cpp.
Code:
else /* if (arguments.read(--sm)) */
{
osg::ref_ptrosgShadow::ShadowMap sm = new osgShadow::ShadowMap;
sm-setTextureUnit(8);
shadowedScene-setShadowTechnique(sm.get());
int mapres = 1024;
while (arguments.read(--mapres, mapres))
sm-setTextureSize(osg::Vec2s(mapres,mapres));
}
Here is a snippet of the OpenGL trace.
Code:
glGetString(GL_VERSION)=2.1.2
glGetString(GL_RENDERER)=GeForce Go 7600/PCI/SSE2/...
glGetString(GL_VERSION)=2.1.2
...
glActiveTexture(GL_TEXTURE8)
glLoadMatrixd([1.00,0.00,0.00,0.00,0.00,1.00,0.00,0.00,0.00,0.00,1.00,0.00,0.00,0.00,0.00,1.00])
glTexGendv(GL_S,GL_EYE_PLANE,0x2715740) glGetError() =GL_INVALID_OPERATION
glTexGendv(GL_T,GL_EYE_PLANE,0x2715768) glGetError() =GL_INVALID_OPERATION
glTexGendv(GL_R,GL_EYE_PLANE,0x2715790) glGetError() =GL_INVALID_OPERATION
glTexGendv(GL_Q,GL_EYE_PLANE,0x27157b8) glGetError() =GL_INVALID_OPERATION
glTexGeni(GL_S,GL_TEXTURE_GEN_MODE,9216) glGetError() =GL_INVALID_OPERATION
glTexGeni(GL_T,GL_TEXTURE_GEN_MODE,9216) glGetError() =GL_INVALID_OPERATION
glTexGeni(GL_R,GL_TEXTURE_GEN_MODE,9216) glGetError() =GL_INVALID_OPERATION
glTexGeni(GL_Q,GL_TEXTURE_GEN_MODE,9216) glGetError() =GL_INVALID_OPERATION
Has anyone got any idea what is going on here. Has 3.0 reserved some resources
that have in some way reduced the number of available texture units?
I am at a loss! Obviously I don't see any shadows!
Roger
Cheers,
Roger[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41202#41202
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.0 and osgShadow texture unit problems
Wojciech Lewandowski wrote: Hi, Roger, You might have 16 texture units but only 8 texture coords. And fixed pipeline texgens of course can be set up to 7th stage. Cheers, Wojciech I must admit I had not thought of that. But it was working on 2.8.5 on the same Opengl driver and hardware. I quess I will have to revert to a 2.8.5 build and rerun the trace to see what is different. I wonder if the getmaxtextureunit (or whatever it is) OSG call is reporting something different on 2.8.5. I use the high unit number to keep the shadow out of the way of some other stuff. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41213#41213 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.0 and osgShadow texture unit problems
Wojciech, You were right I was using osg::Texture::Extensions::getNumTextureUnits which on 2.8.5 returns GL_MAX_TEXTURE_UNITS and on 3.0.0 returns GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS I have reverted to a simple glGetIntegerv(GL_MAX_TEXTURE_UNITS) Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41216#41216 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Forcing buffer objects to recompile
Hi, I am trying to use buffer objects in my application. So I call setUseVertexBufferObjects on the relevant geometry. However for other reasons I cannot set up the tex coords and texture image until a few more frames have elapsed. This means that I have somehow got to force the buffers to recompile on that object. I have copied the code from setUseVertexBuffersObjects into a function in my app and modified it to set the buffers dirty instead of allocating them, and then I set the compileOnNextDraw flag in the renderer. But this does not appear to work. What is the correct way to go about this? Thank you! Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41172#41172 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forcing buffer objects to recompile
Paul Martz wrote:
On 7/5/2011 2:42 PM, Roger James wrote:
Hi,
I am trying to use buffer objects in my application. So I call
setUseVertexBufferObjects on the relevant geometry. However for other
reasons I cannot set up the tex coords and texture image until a few more
frames have elapsed. This means that I have somehow got to force the
buffers to recompile on that object. I have copied the code from
setUseVertexBuffersObjects into a function in my app and modified it to set
the buffers dirty instead of allocating them, and then I set the
compileOnNextDraw flag in the renderer. But this does not appear to work.
What is the correct way to go about this?
I searched for the word 'dirty' in the osg/Array header and found this:
/** Dirty the primitive, which increments the modified count, to force
buffer objects to update. */
inline void dirty() { ++_modifiedCount; if (_vbo.valid()) _vbo-dirty(); }
-Paul
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum
Thanks Paul
I started looking at the code from the bottom up. Looks like I missed upping
the modified count. I'll try that tomorrow.
Roger
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41178#41178
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
My final words on this. The frame buffer corruption is caused by the following. osg::View::addSlave causes a default osgViewer::Renderer object to be attached to the slave camera. This Renderer object has _compileOnNextDraw set to true. This causes the next draw on the new camera to compile all the display lists etc. This is done before the view matrix, projection matrix and any frame buffer objects have been set up in OpenGL. The result is a corrupt rendering of the main scene in the real frame buffer. You can stop this being displayed by setting the slave camera to PRE_RENDER. Or you can stop it being rendered by setting compileOnNextDraw to false on the slave camera immediately after addSlave has been called. I do not know whether this can be called a bug, or just the way things are. It may be reasonable for addSlave to assume that when useMastersSceneData is true that CompileOnNextDraw should be set false. I will leave that to Robert. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36806#36806 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
Ok, I think I understand a little bit more about what is happening, but not why. I turned on OpenGL tracing (using glIntercept) and got some very interesting results. I forced the viewer into single thread mode and set the main camera pointing in a direction where basically nothing should be rendered, i.e. pointing away from the geometry. I then logged the frame before I added the slave camera (frame 1), the frame with the slave camera (frame 2), and the next two frames after the slave camera had been removed. These last two frames were trigged by extra calls to Viewer::frame in my routine so they occur after the camera is removed but before it is deleted by it's ref_ptr going out of scope. Frame 1 - shows a whole load of global state being set up as expected but nothing being rendered. This is what I would expect. Frame 2 - shows the same global state being set up, this includes the correct modelview and projection matrices. Then things start to go peculiar. The projection and modelview matrices are set to identity. Then all the scene geometry is redrawn into the real frame buffer. It looks this is done to regenerate all the display lists and vertex arrays etc. This is where the frame buffer corruption is coming from! Only after this has been done is the new camera's renderbuffer and framebuffer bound. The the expected draw (of nothing) is then done to the new frame buffer object. I can now see how the real back buffer is being corrupted. But I still have no idea why. Looking at frames 3 and 4 don't give me any clues but show another strange effect. Remember that the slave camera has been removed from the viewer at this point. Frame 3 - Shows the same global state set and null rendering as frame 1 but then goes on to show the frame buffer object being being rebound, the global state re-established, nothing rendered, and the frame buffer object unbound. I assume this is something to do with lazy deletion of frame buffer objects. Frame 4 - Shows the same as frame 3. Maybe the redundant setting of the fbo will stop when the camera is deleted. I am beginning to think that all this re-affirms Robert's assertion that adding cameras to a scene in live rendering is not a good idea. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36767#36767 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
Continuing my interior monologue on this. I remembered that right at the start I had done a test with the viewer forced into single threading mode and still seen the corruption. So all the threading related tests were irrelevant! More interestingly I have just repeated that test with the camera's node mask set to zero. The scene is not rendered to the frame buffer object, but the corruption still flashes up on screen for a second (probably a persistence of vision thing as the frame rate is in the hundreds). Answers on a post card to. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36678#36678 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
J.P. Delport wrote: Hi, are you using the fbo output texture in the main scene? Hi J.P. The answer is no. It is a screen capture. I just write it away to a file. As I mentioned before I can fix this be setting the fbo camera to PRE_RENDER. However, too many years working on this sort of stuff has taught me that things you cannot explain have a tendency to come back and bite you later :) Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36702#36702 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
Hi Robert, Thanks for your reply. Yes, odd things are certainly happening. From what I am observing it would be more sensible to create the camera at start time. However I am still confused by why this corruption occurs. The osgViewer::Viewer is running in CullDrawThreadPerContext mode. The main thread of my application is calling osgViewer::frame using an frame on idle strategy in wxWindows. I do not use osgViewer::run. The screen capture is called from UI code in this thread. I was assuming, that because of the End Rendering Dispatch Barrier that when osgViewer:frame returns all rendering activity should have finished. Is this correct? I assume from your comments that nodemask is honoured on cameras added by addSlave as well as those added as nodes in the graph. That is useful to know. I have made some notes on concurrency in the various threading models. I would be grateful if you could comment on them and correct me where necessary. I will then put them in the wiki. I apologise in advance if they are utter nonsense, but this stuff is a bit difficult to follow from the code! It took me a while to work out that in standard OSG code the queue of operations in the GraphicsContext is actually always empty and it is the call to the renderer object in the runOperations code that does all the work! SingleThreaded The thread that calls osgViewer::Frame does everything sequentially. CullDrawThreadPerContext An additional thread is created for each GraphicsContext held by the viewer. These additional threads run in parallel but are synchronised to start a cull and draw sequence when the thread that calls osgViewer::frame enters the “Start Rendering” barrier. The thread that calls osgViewer::frame is prevented from returning from that function until all of the additional threads have entered the “End Rendering Dispatch barrier”. (The dynamic draw block is also used, but is it superfluous in this case?) DrawThreadPerContext An additional thread is created for each GraphicsContext held by the viewer. These threads run freely performing the draw operations, they are not synchronised by any barriers. Culling is performed by the main thread during the call to osgViewer:frame. OsgViewer::frame will not return until all dynamic object rendering is complete. CullThreadPerContextDrawThreadPerCamera An additional thread is created for each GraphicsContext held by the viewer. These threads run freely performing the draw operations, they are not synchronised by any barriers. An additional thread is created for the master camera and each slave camera. These camera threads run in parallel but are synchronised to start a draw sequence when the thread that calls osgViewer::Frame enters the “Start Rendering” barrier. OsgViewer::frame will not return until all dynamic object rendering is complete. (Does this mean that non dynamic drawing might not be complete?) Cheers, Roger[/b] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36637#36637 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
After more checking I can see that my finding that test number 4. was not producing the corruption is false. This is due to the fact that the debugger was stopping all threads. If I put breakpoints on two consecutive (nearly) instructions, then the corruption appears again. I now assume that the corruption apppears for one frame in all cases when the rendering order is set to POST_RENDER. Any explanations are welcome, but are of academic interest only :-) Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36664#36664 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
Hi, I am seeing a a strange corruption of the main frame buffer when I use a slave camera to render to a frame buffer object and set the camera render order to POST_RENDER. The camera is set up like this. Code: pCamera-setClearColor(pViewer-getCamera()-getClearColor()); pCamera-setViewport(0, 0, Width, Height); pCamera-setRenderOrder(osg::Camera::POST_RENDER); pCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::FRAME_BUFFER); pCamera-setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR); pCamera-attach(osg::Camera::COLOR_BUFFER, pImage.get()); pCamera-setGraphicsContext(pViewer-getCamera()-getGraphicsContext()); // pViewer-stopThreading(); It seems to work without this, but Robert says it is needed, maybe it is not always needed for simple setups pViewer-addSlave(pCamera.get()); pViewer-frame(); pViewer-removeSlave(pViewer-findSlaveIndexForCamera(pCamera.get())); // pViewer-startThreading(); Immediately aftere this code has executed and before the next frame the the main frame buffer scene has had a white half circle painted over it in approximately the top third of the viewport. If I don't remove the slave camera and allow it to render in following frames the white half circle still dissappears on the following frames. I can fix this by setting the slave camera to PRE_RENDER in this case. But I am really puzzled by this behaviour. Does anyone have any idea on what is happening here? Why should a camera that has been set to render to a FBO be causing things to be drawn in the real frame buffer? Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36577#36577 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
Hi Wojtek, I tried all three variants. 1. Stop threading, add camera, frame, remove camera, start threading. 2. Stop threading, add camera, start threading, frame, stop threading, remove camera, start threading. 3. Leave threading running. All had the same result when the rendering order was POST_RENDER. For information I do not use the update traversal for anything in this application. It would be useful to know when stop and start threading is needed in this kind of scenario. It might save me some bug fixing in the future. I still have no clue where this weird artefact is coming from. I tried not setting any scene data on the slave camera (addSlave(camera, false)) and the artefact disappears, so it seems to be something to do with the slaves traversal of the graph after the main camera was wriiten to the main frame buffer, but how does the corruption end up in the main frame buffer when the slave should not be touching it! Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36580#36580 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camera to POST_RENDER to a FBO
I just tried variant 4. 4. Stop threading, add camera, start threading, frame, remove camera. No artefact! Now I am totally confused. I think I will leave the code like that and set the render order to PRE_RENDER just for good luck! This has got to be some weird thread concurrency thing. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36581#36581 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help with screen capture
Hi, I got my new code working by adding Code: pCamera-setGraphicsContext(pViewer-getCamera()-getGraphicsContext()); For info it also seems to work without the calls to stop and start threading. The only strange thing is a white half circle that flashes up on the screen for one frame when the capture is done. I suspect I am not doing something before I call viewer-frame that I am doing in my main loop. Maybe something to do with the far plane on the main camera. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36567#36567 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Help with screen capture
Hi,
I used to have a screen capture function that worked worked well
with our single threaded rendering loop based on osgUtil::SceneView.
It looked like this.
bool CSaveImageOSG::SaveImage(const char *pFilePath)
{
osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(0, true);
//if (!(fbo_ext fbo_ext-isSupported()) !osg::isGLExtensionSupported(0, "ARB_render_texture"))
if (!(fbo_ext fbo_ext-isSupported()))
return false;
GLint MaxRenderBufferSize;
glGetIntegerv(MAX_RENDERBUFFER_SIZE_EXT, MaxRenderBufferSize);
// For the time being clamp to 3000
if (MaxRenderBufferSize 3000)
MaxRenderBufferSize = 3000;
osgUtil::SceneView SceneView = *vtGetScene()-getSceneView();
osg::ref_ptrosg::Camera pCameraNode = new osg::Camera;
if (!pCameraNode.valid())
return false;
osg::ref_ptrosg::Image pImage = new osg::Image;
if (!pImage.valid())
{
pCameraNode = NULL;
return false;
}
const osg::Viewport Viewport = *SceneView.getViewport();
int Width;
int Height;
if (Viewport.aspectRatio() 1.0)
{
Width = MaxRenderBufferSize;
Height = MaxRenderBufferSize / Viewport.aspectRatio();
}
else
{
Width = MaxRenderBufferSize * Viewport.aspectRatio();
Height = MaxRenderBufferSize;
}
VTLOG("CSaveImageOSG::SaveImage - Width %d Height %d Total %d\n", Width, Height, Width* Height);
pImage-allocateImage(Width, Height, 1, GL_RGB, GL_UNSIGNED_BYTE);
pCameraNode-setClearColor(SceneView.getClearColor());
pCameraNode-setViewport(0, 0, Width, Height);
pCameraNode-setRenderOrder(osg::Camera::POST_RENDER);
pCameraNode-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::FRAME_BUFFER);
pCameraNode-setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR);
pCameraNode-attach(osg::Camera::COLOR_BUFFER, pImage.get());
pCameraNode-setReferenceFrame(osg::Camera::ABSOLUTE_RF);
pCameraNode-setProjectionMatrix(SceneView.getProjectionMatrix());
pCameraNode-setViewMatrix(SceneView.getViewMatrix());
pCameraNode-addChild(SceneView.getSceneData());
SceneView.setSceneData(pCameraNode.get());
SceneView.cull();
SceneView.draw();
SceneView.setSceneData(pCameraNode-getChild(0));
pCameraNode-removeChild(0, 1);
osgDB::writeImageFile(*pImage, pFilePath);
return true;
}
We have now changed to using osgViewer::Viewer in multi-threading
mode for rendering, and I need to update the function to work with
that. My function now is as shown below, and does not work, just
recording a blank image. I am obviously doing something
fundamentally wrong. I have never used slave cameras before and find
the subject somewhat confusing. The screen capture example does
something far too complex for my needs. I just want to capture a
single frame of the current view and then go back to normal
rendering. Any help/pointers will be gratefully received.
Roger
bool CSaveImageOSG::SaveImage(const char *pFilePath)
{
osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(0, true);
if (!(fbo_ext fbo_ext-isSupported()))
return false;
GLint MaxRenderBufferSize = 3000;
glGetIntegerv(MAX_RENDERBUFFER_SIZE_EXT, MaxRenderBufferSize);
// For the time being clamp to 3000
if (MaxRenderBufferSize 3000)
MaxRenderBufferSize = 3000;
osgViewer::Viewer *pViewer = vtGetScene()-getViewer();
osg::ref_ptrosg::Camera pCamera = new osg::Camera;
if (!pCamera.valid())
return false;
osg::ref_ptrosg::Image pImage = new osg::Image;
if (!pImage.valid())
{
pCamera = NULL;
return false;
}
const osg::Viewport* pViewport = pViewer-getCamera()-getViewport();
int Width;
int Height;
if (pViewport-aspectRatio() 1.0)
{
Width = MaxRenderBufferSize;
Height = MaxRenderBufferSize / pViewport-aspectRatio();
}
else
{
Width = MaxRenderBufferSize * pViewport-aspectRatio();
Height = MaxRenderBufferSize;
}
VTLOG("CSaveImageOSG::SaveImage - Width %d Height %d Total %d\n", Width, Height, Width* Height);
pImage-allocateImage(Width, Height, 1, GL_RGB, GL_UNSIGNED_BYTE);
pCamera-setClearColor(pViewer-getCamera()-getClearColor());
pCamera-setViewport(0, 0, Width, Height);
pCamera-setRenderOrder(osg::Camera::POST_RENDER);
pCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::FRAME_BUFFER);
pCamera-setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR);
pCamera-attach(osg::Camera::COLOR_BUFFER, pImage.get());
pViewer-stopThreading();
pViewer-addSlave(pCamera.get());
pViewer-frame();
pViewer-removeSlave(pViewer-findSlaveIndexForCamera(pCamera.get()));
pViewer-startThreading();
osgDB::writeImageFile(*pImage, pFilePath);
return true;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help with screen capture
Hi J P, Thank you for the quick reply. I will probably try that for the save image method. I will admit I was being a little cheeky in posting the question. As I hoped the answer would help me learn more about osgViewer, slave cameras and threading etc, as I probably do need to use a similar technique to the one I proposed in a couple of other areas where I use the frame buffer contents to do some real world, visual impact (solid angle) and sunlight occlusion calculations. Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36491#36491 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help with screen capture
Hi, I just remebered that one of the reasons for the original method was that I wanted to cpature the highest resolution I could get out of the frame buffer, without resorting to tiling. Thank you! Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36492#36492 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Why is my database so big?
Hi Robert, Happy New Year. I soon realized that using ive and dds was a mistake. Also that VPB was trying to generate too many levels (15 I think) not 8 as I first thought. Playing about and just generating the database tree for one level one subtile lead me to the conclusion that the optimum number of levels was in fact 12. Generating that database with jpeg and osg options led to a final overall size of 30Gbytes (1239048 files!). When I get some time I will compress that into zip archive and see if that is any nearer to my original estimate! If it is small enough I will put it up online somewhere for people to play with. It renders quite nicely, I have just been whizzing up and down the M6, a bit easier virtually than it has been getting over Shap in reality in the last few weeks. Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35360#35360 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [vpb] Why is my database so big?
Hi, I am trying to build a VPB database of the United Kingdom using the freely available Ordnance Survey OpenData. This gives me as input an elevation dataset which is approximately 630 Mbytes of ArcGIS ASCII grids with a 50 metre posting, and a collection of TIFF map image overlays which total 4.5gb and have a 2.5 metre resolution. I have 168 GBytes of free space available for the output database. By default VPB appears to split each level into 4 sub-tiles at the next level. In an ideal world this would appear to give the geometric progression T = a + a/4 + a/16 + a/64.etc. which converges on T = 4a/3 (thank you Archimedes) where a is the size of the input datasets and T is the total size of the generated database. I know this is a gross simplification but at least it should provide some guidance on how much disk space will be needed (i.e 7.2 Gbytes) Using VPB 0.9.10 I run out of disk space some time before the run has finished. I set up the run to use DDS compression on the imagery and .ive output (the default). VPB calculates that the optimum number of levels is 8 and that the final level should have 64 subtiles on the X axis and 128 on the Y. OK, I know I have made a stupid mistake in my assumptions. But I find I hard to believe I am so far out. Help! Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35175#35175 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I get the most accurate heightfield reading out of an OsgTerrain paged database
Thanks for the info David. Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34578#34578 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I get the most accurate heightfield reading out of an OsgTerrain paged database
For information this is what I decided on eventually. It seems to work.
Code:
bool vtExternalHeightField3d::FindAltitudeAtPoint(const FPoint3 p3, float
fAltitude, bool bTrue, int iCultureFlags, FPoint3 *vNormal) const
{
if (NULL != vNormal)
return false; // Cannot do normals at the moment
// Transform to OSG Model and then to OSG Local
osg::Vec3d Model = osg::Vec3d(p3.x, p3.y, p3.z) *
m_TransformVTPWorld2OSGModel;
osg::Vec3d Local;
m_pLayer-getLocator()-convertModelToLocal(Model, Local);
// Check if over heightfield
if (Local.x() 0.0 || Local.x() 1.0 || Local.y() 0.0 || Local.y() 1.0)
return false;
// Use HAT
Model.z() = m_fMaxHeight + 1;
if (m_pHat-getNumPoints() == 0)
m_pHat-addPoint(Model);
else
m_pHat-setPoint(0, Model);
if (bTrue)
m_pHat-computeIntersections(m_pLOD);
else
{
// Kill database reading
osg::ref_ptrosgSim::DatabaseCacheReadCallback pCallback =
m_pHat-getDatabaseCacheReadCallback();
m_pHat-setDatabaseCacheReadCallback(NULL);
m_pHat-computeIntersections(m_pLOD);
m_pHat-setDatabaseCacheReadCallback(pCallback.get());
}
fAltitude = (float)(Model.z() - m_pHat-getHeightAboveTerrain(0));
return true;
// Just use the top level
// return m_pLayer-getInterpolatedValue(Local.x(), Local.y(), fAltitude);
}
Cheers,
Roger
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34581#34581
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How do I get the most accurate heightfield reading out of an OsgTerrain paged database
Hi, I need to get the best heightfield reading I can out of an osgTerrain database at runtime. At the moment I am doing something like this: Code: osg::Node *pNode = osgDB::readNodeFile((const char *)fname_local); // Top level node should be a coordinate system node osg::CoordinateSystemNode *pCoordSystem = dynamic_castosg::CoordinateSystemNode*(pNode); // next node down should be a PageLOD osg::PagedLOD *pLod = dynamic_castosg::PagedLOD*(pCoordSystem-getChild(0)); osgTerrain::TerrainTile *pTopTile = dynamic_castosgTerrain::TerrainTile*(pLod-getChild(0)); m_pLayer = pTopTile-getElevationLayer(); ... Then m_pLayer-getLocator()-convertModelToLocal(Model, Local); // Get the Altitude m_pLayer-getInterpolatedValue(Local.x(), Local.y(), fAltitude); What I would really like to do is to drill down to the best LOD, ensure that that heightfield tile is loaded and query it directly Has anyone got any tips or example code on how to do this. Thank you! Cheers, Roger[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34503#34503 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I get the most accurate heightfield reading out of an OsgTerrain paged database
Hi Robert, Chris, David Thanks for the quick reply. I have been playing with putting osgTerrain support into VTP. Ben has probably written me off as a heretic! I just wanted to get my placement of procedurally generated buildings a bit more accurate. So performance at that point is not too much of a problem. I will look into osgSim. Cheers, Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34513#34513 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Texture Problem with osg Collada Plugin
On 02/03/2010 09:56, heishuijing_2000 wrote: Hi Roland, Thank you for your reply,I have look into code in osg SVN.I found there is no update with the collada plugin writer. Anyone can help me with this ploblem? Without knowing what it is you are trying to export it is difficult to offer any help. I suggest that you make a simple geometry (a simple triangle or quad) that illustrates your problem, then post the resulting .osg and .dae files to the list. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada Plugin problem with SketchUpexported models...
On 25/02/2010 16:31, Michael Platings wrote: I had a quick look at your submission, it looks like you have had a good go at fixing the (my :-) ) transparency mess! So I won't submit any fixes. Any chance you can give me a heads up on your thinking behind "getTransparencyCounts", I am puzzled by it! Certainly - some filesuse a transparency value of 1 to mean completely opaque (the spec says this is correct) while other files use a transparency value of 1 to mean completely transparent. It's hard to be completely certainof whichmeaning is used, so instead I added a heuristic to make a best guess: If there are more transparency values of 0 than 1 then 0 is interpreted to mean opaque, otherwise 1 is interpreted to mean opaque. Ah, I thought that was what you were doing. I was just unsure I had missed something in the spec. My original code used to check the authoring tool value and invert transparency if it was Sketchup. However, Google have now fixed their code. Your code provides a more generalised solution. Can I suggest that you make it conditional on the absence of the "StrictTransparency" option, so it can be turned off if necessary. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada Plugin problem with SketchUp exported models...
On 25/02/2010 09:42, Michael Platings wrote: Hi Alessandro, please see my email to osg-submissions on 11th Feb, "[osg-submissions] DAE Animation". This contains many fixes and improvements to the DAE plugin, including handling transparency correctly. Michael, I had a quick look at your submission, it looks like you have had a good go at fixing the (my :-) ) transparency mess! So I won't submit any fixes. Any chance you can give me a heads up on your thinking behind "getTransparencyCounts", I am puzzled by it! Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada Plugin problem with SketchUp exported models...
On 24/02/2010 18:24, alessandro terenzi wrote: So far I used the collada plugin successfully to read models exported from SketchUp but today I installed the latest SketchUp version (7.1.6860) and I noticed that transparent (or not totally opaque) objects now become totally opaque. Searching for some info I found a discussion where SketchUp developers state that they actually changed something but, on the other hand, they say that they still adhere to DOM 1.4.1. Did anyone experience my same problem? I can provide exported DAE models (working and not working variants) if anyone would like to check what changed... BTW, I'm using OSG 2.9.6 (61). Kind regards. Alessandro I made some changes a while back to remove the special case code we had in the the DAE plugin for handling Googles incorrect handling of transparency (no matter what they say, they used to get it back to front!). I thought I had submitted them, but it looks like either I did not or they got lost in the major re-factoring of the plugin. I just checked trunk and they are definitely not in there. I will try and do a trunk build over the next few days so I can resubmit them. I you want to do it yourself just search the dae plugin for m_AuthoringTool and m_GoogleMode and hack them out. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trouble porting to vs2008, heap corruption
Jean-Sbastien Guay wrote: Hi Chris, Usually the linker will yell and scream at you if you try to do this, so it usually doesn't happen accidentally and without the programmer knowing. I'm curious when you've seen the linker scream about mixing debug and release DLLs... I've seen plenty of users do it by mistake and the linker never said a thing, except when mixing the dynamic and static C runtimes. When mixing debug and release (both using the dynamic runtime, for example) the linker says nothing. That's why it's so easy to do, but nevertheless it will lead to bad behavior, crashes, etc. It is usually more of muted cough than a scream, and is often a warning referring to conflicting default libraries. If the least significant bits of the address of the corruption remain the same then you can track it down it down with a data breakpoint. Because of heap randomisation you need to work out what the base address of the heap is for each run and recalculate the address of the breakpoint each time. If you use an absolute address "0xabcd etc" and make sure it is one of the first four breakpoints then a hardware breakpoint register will be used and the program will run at a reasonable speed. You may get a few false positives if the breakpoint is enabled too soon but you should be able to sort that out :-) Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question on status of dae (collada) plugin
Frederic Marmond wrote: Hello world, I'm trying to load some collada files from osg, using osgviewer, recent trunk version on msvc8. I tried on those found on the collada-dom package (collada-dom/dom/test/1.4/data/*.dae ), but only one (cube.dae) is really loading. Some crash (segfault), some display an empty scene, and others don't find any scene at all. Aren't those data files considered as reference ones ? I also tried on some kml files (the google's format based on collada one), without success (even if I rename the .kml in .dae, of course): Warning: The DOM was unable to create an element named kml at line 15. Probably a schema violation. = is the dae plugin supposed to be usable, or is it in early development state (or am I badly using it) ? thanks for any information/confirmation ! Fred Fred, The dae reader should be stable, it has not had any changes made to it since the osg 2.8.2 release which is working for me. All the new development work on it is being being done in a separate repository. It certainly should not crash. The data files in the Collada respository should mostly work although I have not checked them recently, and strangely some of them were in the past not fully compliant Collada and might still be! Google KML files are not Collada .dae files and will not work! However Google KMZ archive files usually do contain Collada .dae files. The .kmz files are really .zip archives and if you rename the .kmz extension to .zip you can then run a standard zip archive tool to extract the .dae file from them. I suspect that your build of the OSG Collada plugin has a problem. One thing you should check is that you have linked against the dom libraries that implement the 1.4 version of the Collada specification not the 1.5 version. I link against libcollada14dom22 (that is Collada specification version 1.4 dom library version 2.2). Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question on status of dae (collada) plugin
Jan Ciger wrote: Roger James ro...@beardandsandals.co.uk wrote: Frederic Marmond wrote: Hello world, I'm trying to load some collada files from osg, using osgviewer, recent trunk version on msvc8. I tried on those found on the collada-dom package (collada-dom/dom/test/1.4/data/*.dae ), but only one (cube.dae) is really loading. Some crash (segfault), some display an empty scene, and others don't find any scene at all. Aren't those data files considered as reference ones ? The plugin works ok for me, but make sure that the transparency in your files is correct. It is likely that it was exported wrong (reversed) and the scene is actually displayed, but all transparent. E.g. the default Blender plugin and Google Sketchup export it incorrectly reversed. An easy way to check for this is to use osgconv and convert the dae file into an osg file - if the data are there but you cannot see them, it is the transparency problem. Regards, Jan Jan, The latest version of Sketchup now gets it the right way round. However that now breaks a fix that I put in some time ago. This fix checks for the string "Google Sketchup" in the authoring_tool field at the start of the dae document. So you can defeat it by changing that to something else. I was going to back out this fix in the trunk once the major changes regarding animation etc. have been integrated. Do you know if the Blender export is still broken. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLIntercept and OSG 2.8.2
Hi Paul, I found my rendering problem and have posted another message requesting help with that (dirtying color arrays when vbo are used). I also tracked down the problem in GLIntercept. I have hacked up a fix for that but a proper one will require a far more comprehensive look at the architecture of GLIntercept. The problem stems from the fact that the underlying driver is making calls back into OpenGL on another thread when some OpenGL functions are called. and that GLIntercept intercepts calls to glGetError and returns a cached error value in some circumstances. This leads to the following. 1. Main thread calls SwapBuffers (windows GDI function) which eventually calls wglSwapBuffers which is intercepted by GLIntercept. 2. GLIntercept end up calling the real glGetError to check the result of the wglSwapBuffers. 3. The nvidia drivers implementation of glGetError for some reason tells (or maybe creates) another thread to do some work and waits for it to complete. 4. The other thread calls wglGetPixelFormat which is intercepted by GLIntercept, which again calls the real glGetError, luckily this does not seem to bother with another OpenGL call, however the cached error code is now messed up. 5. The worker thread releases the main thread which returns 6. The main thread calls glGetError (I have the OSG check every frame option set) and gets a bad cached value from GLIntercept. My fix is very hacky and just stops GLintercept calling glGetError if it is already in the process of doing so. This gets rid of most of the spurious errors. I dont plan to go much further. GLIntercept also crashes on program exit it the runtime heap checks. But the logs seem OK. Let moe know if you want the modified code. Roger Paul Martz wrote: Hi Roger, thanks for the update, sounds like good progress. Roger James wrote: 1. Thread safety in GLIntercept (non-existent). Try forcing osgViewer into SingleThreaded mode. You can do this with the OSG_THREADING env var, or you can call Viewer::setThreadingModel. 2. When and how does the GL error code get cleared. Is GLIntercept or the lack of it affecting this. A single call to glGetError clears returns the first error generated since the last call to glGetError, then clears the OpenGL error code. I haven't looked at GLIntercept but if I'm not mistaken it calls glGetError after every OpenGL call, so the presence of GLIntercept will certainly affect the clearing. The OpenGL error is always queried and therefore cleared. You say this is happening after wglGetPixelFormat... Do you mean ChoosePixelFormat? You might want to step through the GraphicsWindowWin32.cpp context creation code (in osgViewer) in the debugger and see if anything looks suspicious. ChoosePixelFormat is an extension function. Step through the function call in the debugger and make sure you go into the right GLIntercept function. See line 1506 in GraphicsWindowWin32.cpp (OSG v2.8.2). -Paul ___ 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] Help needed with cleaning colour arrays when VBOs in use.
Hi,
I have a little problem with dirtying and cleaning colour arrays when
VBOs are in use.
I found that I needed to dirty a color array to get the colour data in
the associated vertex buffer object updated. I currently do this by
calling osg::Vec4Array::dirty on the colour array. This appears to work
as the application now showed the updated colours. However the
performance took a hit.
The dirty function in osg::Array is implemented like this
/** Dirty the primitive, which increments the modified count,
to force buffer objects to update. */
inline void dirty() { ++_modifiedCount; if (_vbo.valid())
_vbo-dirty(); }
So I put a data breakpoint on _modifiedCount and found that whilst
_modifiedCount was been imcremented by my calls to dirty it was never
being decremented. A quick search through the osg code did not find
anywhere where the value appeared to be decremented. So it seems my
data is being sent to the GPU every frame. Can anyone help me on how I
should implement this to avoid this happening.
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help needed with cleaning colour arrays when VBOs in use.
Hi Robert,
Thanks for the quick response. I had a look at SVN trunk and I see that
the dirty() function on arrays on longer exists. Any chance of a quick
heads up on what I should set to say that an individual colour array's
data on a geometry has changed as should be re-loaded into its VBO.
Roger
Robert Osfield wrote:
Hi Roger,
Looking at the quoted code my guess is that you aren't used svn/trunk,
in which case... I would recommend trying out svn/trunk as the VBO
support is close to total rewrite and should be now both more
flexible, scalable and robust.
Let me know how you get on.
Cheers,
Robert.
On Fri, Nov 13, 2009 at 1:55 PM, Roger James
ro...@beardandsandals.co.uk wrote:
Hi,
I have a little problem with dirtying and cleaning colour arrays when VBOs
are in use.
I found that I needed to dirty a color array to get the colour data in the
associated vertex buffer object updated. I currently do this by calling
osg::Vec4Array::dirty on the colour array. This appears to work as the
application now showed the updated colours. However the performance took a
hit.
The dirty function in osg::Array is implemented like this
/** Dirty the primitive, which increments the modified count, to
force buffer objects to update. */
inline void dirty() { ++_modifiedCount; if (_vbo.valid())
_vbo-dirty(); }
So I put a data breakpoint on _modifiedCount and found that whilst
_modifiedCount was been imcremented by my calls to dirty it was never being
decremented. A quick search through the osg code did not find anywhere where
the value appeared to be decremented. So it seems my data is being sent to
the GPU every frame. Can anyone help me on how I should implement this to
avoid this happening.
Roger
___
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] Help needed with cleaning colour arrays when VBOs in use.
Thanks Robert, I had missed that. I was looking at dirtyColorPointer on the State object and wondering how on earth that would work!. Roger Robert Osfield wrote: Hi Roger, On Fri, Nov 13, 2009 at 5:46 PM, Roger James ro...@beardandsandals.co.uk wrote: Thanks for the quick response. I had a look at SVN trunk and I see that the dirty() function on arrays on longer exists. Any chance of a quick heads up on what I should set to say that an individual colour array's data on a geometry has changed as should be re-loaded into its VBO. osg::Array is now subclassed from osg::BufferData, so Array now gets it's dirty() from BufferData. Just calling dirty() on the colour array should get it to update. 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] GLIntercept and OSG 2.8.2
I have been trying to use GLIntercept (version 0.5) to track down a rendering problem. I have used this tool successfully many times in the past. However I have now moved to a Visual Studio Express 2008 (VC9.1) build environment and I am encountering some problems. I rebuilt GLIntercept for the VC9.1 environment, and updated my installation as I have done a number of times in the past (copy the latest DLL into the directory my app loads from). However when I run my app which is built using OSG 2.8.2, the OSG runtime reports "Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,)" on every frame, this does not occur when the normal OpenGL library is used. Has any else observed this behaviour? GLIntercept also logs a number of "GLI | GL ERROR - Function wglGetPixelFormat generated error 0x0502" which seem to be as a result of a wglGetPixelFormat call from within the nVidia opengl driver interface layer. These may be something to do with my rendering problem. However it is difficult to decide what to track down due to the fact the GLIntercept itself seems to be introducing errors. Any ideas? Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLIntercept and OSG 2.8.2
Hi Paul, Current status is. 1. Recompiled the dependant "corona" library so it would link. 2. Recompiled the GLIntercept library. 3. Found and temporarily fixed a bug in void InterceptLog::GetErrorStringValue. The value of glGetErrorFuncData become invalid if the FunctionTable (std::vector) grows past its reallocation point. 4. Added a bunch of new function defs to the GLIntercept data files (file attached). 5. Still scratching head on why wgkGetPixelFormat returns and error that gets picked up in the OSG diagnostic (Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,)) when the GLIntercept shim is in place, but does not when driving OpenGL direct. Current thoughts are: 1. Thread safety in GLIntercept (non-existent). 2. When and how does the GL error code get cleared. Is GLIntercept or the lack of it affecting this. Roger Recompiled Paul Martz wrote: Are you seeing these same problems just with simple test cases like "osgviewer cow.osg"? That would eliminate your own program as the source of the problem. I am interested in bringing GLIntercept up to date so that it supports current OpenGL features. I'd be interested in knowing what you had to do to get things to compile for VS9. Are you using the dependencies (image support and some other stuff, if I remember correctly)? I have downloaded the source for GLIntercept, but currently this work is on hold, so I've made no progress beyond that. Any info you can share about getting it built would be appreciated. -Paul Roger James wrote: I have been trying to use GLIntercept (version 0.5) to track down a rendering problem. I have used this tool successfully many times in the past. However I have now moved to a Visual Studio Express 2008 (VC9.1) build environment and I am encountering some problems. I rebuilt GLIntercept for the VC9.1 environment, and updated my installation as I have done a number of times in the past (copy the latest DLL into the directory my app loads from). However when I run my app which is built using OSG 2.8.2, the OSG runtime reports "Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,)" on every frame, this does not occur when the normal OpenGL library is used. Has any else observed this behaviour? GLIntercept also logs a number of "GLI | GL ERROR - Function wglGetPixelFormat generated error 0x0502" which seem to be as a result of a wglGetPixelFormat call from within the nVidia opengl driver interface layer. These may be something to do with my rendering problem. However it is difficult to decide what to track down due to the fact the GLIntercept itself seems to be introducing errors. Any ideas? Roger ___ 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 #define GLI_INCLUDE_RFJ void glBlitFramebufferEXT(GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1, GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1, GLbitfield mask, GLenum filter); void glRenderbufferStorageMultisampleEXT( GLenum target, GLsizei samples, GLenum internalformat, GLsizei width, GLsizei height ); void glRenderbufferStorageMultisampleCoverageNV( GLenum target, GLsizei coverageSamples, GLsizei colorSamples, GLenum internalformat, GLsizei width, GLsizei height ); void glUniformMatrix2x3fv( GLint location, GLsizei count, GLboolean transpose, const GLfloat *value ); void glUniformMatrix3x2fv( GLint location, GLsizei count, GLboolean transpose, const GLfloat *value ); void glUniformMatrix2x4fv( GLint location, GLsizei count, GLboolean transpose, const GLfloat *value ); void glUniformMatrix4x2fv( GLint location, GLsizei count, GLboolean transpose, const GLfloat *value ); void glUniformMatrix3x4fv( GLint location, GLsizei count, GLboolean transpose, const GLfloat *value ); void glUniformMatrix4x3fv( GLint location, GLsizei count, GLboolean transpose, const GLfloat *value ); void glGetQueryObjectui64vEXT( GLuint id, GLenum pname, GLvoid *params ); //void glGetQueryObjectui64vEXT( GLuint id, GLenum pname, GLuint64EXT *params ); ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] export DAE file, how to change names?
lucas Grijander wrote:
Hi
all!
I am using the collada plugin to export my geometries in .dae
format. I would like to know if there is an option of specifying the
name of Ids, such as shapes, primitives, materials, etc... It's
important to better differenciate in another application I have between
different objects.
thanks!
Jaime.
Hi Lucas/Jaime,
The DAE exporter gets most of its names from the names of nodes in the
OSG scene graph hierarchy you are exporting.
However, you can change anything in the DAE export by the following
procedure:-
Get hold of the DAE exporter
osg::ref_ptrosgDB::ReaderWriter
pReaderWriter =
osgDB::Registry::instance()-getReaderWriterForExtension("dae");
if (!pReaderWriter.valid())
throw _("Unable to load dae writer plugin");
wxString FileName = FileDialog.GetPath();
Set up the file name in URI format - this is very important.
FileName.Prepend(wxT("file:///"));
Set up some objects to receive information about the DOM objects created
pDae = new DAE; // Use a new object here because
VC8.1 debugger barfs if it tries to show an on stack one in the autos
or watch window !!
if (NULL == pDae)
throw _("Failed to allocate DAE object");
osg::ref_ptrosgDB::ReaderWriter::Options
pOptions = new osgDB::ReaderWriter::Options;
std::string DocURI;
pOptions-setPluginData("DAE", (void*)pDae);
pOptions-setPluginData("DAE-DocumentURI",
(void*)DocURI);
Write the model to a file. This causes the DOM to be built. (On of
these data I might get round to putting a option in the exporter to
just create the DOM and not write the file.)
if (pReaderWriter-writeNode(*pGroup, (const
char *)FileName.mb_str(wxConvUTF8), pOptions.get()).status() !=
osgDB::ReaderWriter::WriteResult::FILE_SAVED)
throw _("Failed to save model");
Retrieve the DOM
domCOLLADA *pDomCollada =
pDae-getDom(DocURI.c_str());
if (NULL == pDomCollada)
throw _("Cannot get DomCollada");
You can now play around with any of the elements in the DAE hierarchy.
For exmaple:-
domAssetRef pAsset = pDomCollada-getAsset();
if (NULL == (domAsset*)pAsset)
throw _("Cannot get domAsset");
domAsset::domUp_axisRef pAxis =
pAsset-getUp_axis();
if (NULL == (domAsset::domUp_axis*)pAxis)
{
// Create a new up axis element
pAxis =
(domAsset::domUp_axis*)pAsset-createAndPlace(COLLADA_ELEMENT_UP_AXIS);
if (NULL == (domAsset::domUp_axis*)pAxis)
throw _("Cannot create up_axis element");
}
pAxis-setValue(UPAXISTYPE_Y_UP);
Write the file out again to save any changes you have just made.
if (DAE_OK != pDae-save((daeUInt)0))
throw _("Failed to save modified dae file");
If you want to ask questions about the DOM DAE API then you need to
post them on the Collada forums https://collada.org/public_forum/
Cheers,
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Using Collada (osgdb_dae) Writer with Google Earth
Reed,
I did something like this using a NodeVisitor. It was only a partial
solution.
osg::PrimitiveSet
CKmlComplianceVisitor::ProcessTriangleStrip(osg::PrimitiveSet
PrimitiveSet)
{
// Convert PrimitiveSet into a DrawElementsUInt
osg::DrawElementsUInt *pNewPrimitiveSet = new
osg::DrawElementsUInt(osg::PrimitiveSet::TRIANGLES);
switch(PrimitiveSet.getType())
{
case osg::PrimitiveSet::DrawArraysPrimitiveType:
{
osg::DrawArrays DrawArrays =
static_castosg::DrawArrays(PrimitiveSet);
// Convert the whole vertex array and corresponding
arrays into triangles
GLint Last = DrawArrays.getFirst() +
DrawArrays.getCount() - 2;
for (GLint i = DrawArrays.getFirst(); i Last; i++)
{
if ((i % 2) == 0)
{
pNewPrimitiveSet-push_back(i);
pNewPrimitiveSet-push_back(i + 1);
pNewPrimitiveSet-push_back(i + 2);
}
else
{
pNewPrimitiveSet-push_back(i + 1);
pNewPrimitiveSet-push_back(i);
pNewPrimitiveSet-push_back(i + 2);
}
}
}
break;
case osg::PrimitiveSet::DrawArrayLengthsPrimitiveType:
{
osg::DrawArrayLengths DrawArrayLengths =
static_castosg::DrawArrayLengths(PrimitiveSet);
// Convert each chunk of the vertex arrays and
corresponding arrays into triangles
// and concatenate them into one array
GLint Index = DrawArrayLengths.getFirst();
for( osg::DrawArrayLengths::iterator primItr =
DrawArrayLengths.begin();
primItr != DrawArrayLengths.end();
++primItr)
{
GLsizei Last = *primItr - 2;
for (GLint i = 0; i Last; i++)
{
if ((i % 2) == 0)
{
pNewPrimitiveSet-push_back(Index);
pNewPrimitiveSet-push_back(Index + 1);
pNewPrimitiveSet-push_back(Index + 2);
}
else
{
pNewPrimitiveSet-push_back(Index + 1);
pNewPrimitiveSet-push_back(Index);
pNewPrimitiveSet-push_back(Index + 2);
}
Index++;
}
Index += 2;
}
}
break;
case osg::PrimitiveSet::DrawElementsUBytePrimitiveType:
break;
case osg::PrimitiveSet::DrawElementsUShortPrimitiveType:
break;
case osg::PrimitiveSet::DrawElementsUIntPrimitiveType:
break;
}
return *pNewPrimitiveSet;
}
Roger
Reed Whittington wrote:
Hi Gordon,
Good to hear from you. Thanks for chiming in.
Yea it is a de-optimization or de-normalization. I dont really care how it is categorized.
Does it makes sense to have a visitor that decomposes the osg PrimitiveSets into triangles (GL_TRIANGLES)?
Im really just trying to see if there is an osg visitor class that that already does this or see who has had experience with loading osg created dae files into GE. The "GoogleMode" switch on the dae writer leads me to believe that the dae writer was designed with the GE use case in mind. So perhaps there is already an existing "path to success" in taking optimized osg content into GE via osg dae. I can't imagine I am the first to try this. Anyway, your insight is very much appreciated.
If I don't find an existing code path by Monday or Tuesday then I will probably code up my own osg visitor. Any suggestions to point me in the right direction great and might get you free beer on your next visit to Texas.
Have a good day.
Cheers,
-Reed
http://www.linkedin.com/in/reedwhit
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17515#17515
___
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] [osgPlugins] COLLADA Blender reading problem
Marco Cosentino wrote:
Marco Cosentino wrote:
Quote: � Select � � Expand �
Quote: � Select � � Expand �
Hi,
I have a problem (maybe a bug?) in loading a .dae file made with Blender collada exporter.
I'm writing a robot simulation software that uses collada to load both 3d and physics.
The error I get is an exception :
"Unhandled exception at 0x0049fb10 (msvcr80d.dll) in RobotSimulator.exe: 0xC005: Access violation reading location 0x."
This occours when I try to load the collada file. Here is the code I wrote:
Code:
bool VisualModel::CreateFromColladaFileAndFillDAE(std::string filename,DAE *dae)
{
osg::ref_ptrosgDB::ReaderWriter::Options rwoptions(new osgDB::ReaderWriter::Options());
rwoptions-setPluginData("DAE",dae);
modelnode = osgDB::readNodeFile(filename,rwoptions);
if(!modelnode) return false;
return true;
}
Here is the stack trace:
Code:
Quote: � Select �
msvcr80d.dll!strlen(unsigned char * buf=0x0012e760) Line 81 Asm
msvcp80d.dll!std::char_traitschar::length(const char * _First=0x) Line 559 + 0x9 bytes C++
msvcp80d.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar ::assign(const char * _Ptr=0x) Line 1042 + 0x9 bytes C++
msvcp80d.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar ::operator=(const char * _Ptr=0x) Line 893 C++
osg55-osgd.dll!osg::Object::setName(const char * name=0x) Line 102 + 0x21 bytes C++
osgdb_daed.dll!osgdae::daeReader::processSinglePPrimitivedomTriangles(osg::Geode * geode=0x05c08620, domTriangles * group=0x05c1cbe8, std::mapdaeElement *,osgdae::domSourceReader,std::lessdaeElement *,std::allocatorstd::pairdaeElement * const,osgdae::domSourceReadersources=[2](...,...), unsigned int mode=4) Line 243 + 0x14 bytes C++
osgdb_daed.dll!osgdae::daeReader::processGeometry(domGeometry * geo=0x05c1a3e8) Line 219 C++
osgdb_daed.dll!osgdae::daeReader::processInstanceGeometry(domInstance_geometry * ig=0x05c1ee98) Line 47 + 0xc bytes C++
osgdb_daed.dll!osgdae::daeReader::processNode(domNode * node=0x05c1e310) Line 366 + 0x22 bytes C++
osgdb_daed.dll!osgdae::daeReader::processVisualScene(domVisual_scene * scene=0x05c1dd58) Line 156 + 0x23 bytes C++
osgdb_daed.dll!osgdae::daeReader::convert(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileURI="./simpleworld.dae") Line 123 + 0xc bytes C++
osgdb_daed.dll!ReaderWriterDAE::readNode(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fname=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 65 + 0x12 bytes C++
osg55-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter rw={...}) Line 1399 + 0x40 bytes C++
osg55-osgDBd.dll!osgDB::Registry::read(const osgDB::Registry::ReadFunctor readFunctor={...}) Line 1537 + 0x22 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readImplementation(const osgDB::Registry::ReadFunctor readFunctor={...}, bool useObjectCache=false) Line 1645 + 0x13 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readNodeImplementation(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileName=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 1850 + 0x57 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readNode(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileName=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100, bool buildKdTreeIfRequired=true) Line 237 + 0x98 bytes C++
osg55-osgDBd.dll!osgDB::readNodeFile(const std::basic_stringchar,std::char_traitschar,std::allocatorchar filename=".simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 69 + 0x1f bytes C++
RobotSimulator.exe!RobotSimulator::VisualModel::CreateFromColladaFileAndFillDAE(std::basic_stringchar,std::char_traitschar,std::allocatorchar filename=".simpleworld.dae", DAE * dae=0x0012f958) Line 10 + 0x15 bytes C++
RobotSimulator.exe!RobotSimulator::Simulable::LoadModel(RobotSimulator::Model model={...}) Line 21 + 0x16 bytes C++
RobotSimulator.exe!RobotSimulator::Simulator::LoadSimulation(const char * pfilename=0x05b4d9c1) Line 93 + 0x28 bytes C++
RobotSimulator.exe!main(int argc=2, char * * argv=0x05b4d968) Line 54 + 0x20 bytes C++
RobotSimulator.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
RobotSimulator.exe!mainCRTStartup() Line 403 C
kernel32.dll!7c817077()
The collada model is made by Blender 2.48a using the default startup scene with the cube with assigned a green material and esported with Triangles option and DisablePhisics option (for testing). You can find it in attachments.
Note that with collada-dom viewer the model is loaded adn displayed correctly and with osgviewer the model is loaded witout exceptions but nothing is displayed into the scene.
I think the problem is related to the call (you can see in the stack trace)
osg55-osgd.dll!osg::Object::setName(const char * name=0x)� Line 102 + 0x21 bytes
Can you tell me why this appens and how to
Re: [osg-users] COLLADA Blender reading problem
Marco Cosentino wrote:
Hi,
I have a problem (maybe a bug?) in loading a .dae file made with Blender collada exporter.
I'm writing a robot simulation software that uses collada to load both 3d and physics.
The error I get is an exception :
"Unhandled exception at 0x0049fb10 (msvcr80d.dll) in RobotSimulator.exe: 0xC005: Access violation reading location 0x."
This occours when I try to load the collada file. Here is the code I wrote:
Code:
bool VisualModel::CreateFromColladaFileAndFillDAE(std::string filename,DAE *dae)
{
osg::ref_ptrosgDB::ReaderWriter::Options rwoptions(new osgDB::ReaderWriter::Options());
rwoptions-setPluginData("DAE",dae);
modelnode = osgDB::readNodeFile(filename,rwoptions);
if(!modelnode) return false;
return true;
}
Here is the stack trace:
Code:
msvcr80d.dll!strlen(unsigned char * buf=0x0012e760) Line 81 Asm
msvcp80d.dll!std::char_traitschar::length(const char * _First=0x) Line 559 + 0x9 bytes C++
msvcp80d.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar ::assign(const char * _Ptr=0x) Line 1042 + 0x9 bytes C++
msvcp80d.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar ::operator=(const char * _Ptr=0x) Line 893 C++
osg55-osgd.dll!osg::Object::setName(const char * name=0x) Line 102 + 0x21 bytes C++
osgdb_daed.dll!osgdae::daeReader::processSinglePPrimitivedomTriangles(osg::Geode * geode=0x05c08620, domTriangles * group=0x05c1cbe8, std::mapdaeElement *,osgdae::domSourceReader,std::lessdaeElement *,std::allocatorstd::pairdaeElement * const,osgdae::domSourceReadersources=[2](...,...), unsigned int mode=4) Line 243 + 0x14 bytes C++
osgdb_daed.dll!osgdae::daeReader::processGeometry(domGeometry * geo=0x05c1a3e8) Line 219 C++
osgdb_daed.dll!osgdae::daeReader::processInstanceGeometry(domInstance_geometry * ig=0x05c1ee98) Line 47 + 0xc bytes C++
osgdb_daed.dll!osgdae::daeReader::processNode(domNode * node=0x05c1e310) Line 366 + 0x22 bytes C++
osgdb_daed.dll!osgdae::daeReader::processVisualScene(domVisual_scene * scene=0x05c1dd58) Line 156 + 0x23 bytes C++
osgdb_daed.dll!osgdae::daeReader::convert(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileURI="./simpleworld.dae") Line 123 + 0xc bytes C++
osgdb_daed.dll!ReaderWriterDAE::readNode(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fname=".\simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 65 + 0x12 bytes C++
osg55-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter rw={...}) Line 1399 + 0x40 bytes C++
osg55-osgDBd.dll!osgDB::Registry::read(const osgDB::Registry::ReadFunctor readFunctor={...}) Line 1537 + 0x22 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readImplementation(const osgDB::Registry::ReadFunctor readFunctor={...}, bool useObjectCache=false) Line 1645 + 0x13 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readNodeImplementation(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileName=".\simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 1850 + 0x57 bytes C++
osg55-osgDBd.dll!osgDB::Registry::readNode(const std::basic_stringchar,std::char_traitschar,std::allocatorchar fileName=".\simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100, bool buildKdTreeIfRequired=true) Line 237 + 0x98 bytes C++
osg55-osgDBd.dll!osgDB::readNodeFile(const std::basic_stringchar,std::char_traitschar,std::allocatorchar filename=".\simpleworld.dae", const osgDB::ReaderWriter::Options * options=0x05c07100) Line 69 + 0x1f bytes C++
RobotSimulator.exe!RobotSimulator::VisualModel::CreateFromColladaFileAndFillDAE(std::basic_stringchar,std::char_traitschar,std::allocatorchar filename=".\simpleworld.dae", DAE * dae=0x0012f958) Line 10 + 0x15 bytes C++
RobotSimulator.exe!RobotSimulator::Simulable::LoadModel(RobotSimulator::Model model={...}) Line 21 + 0x16 bytes C++
RobotSimulator.exe!RobotSimulator::Simulator::LoadSimulation(const char * pfilename=0x05b4d9c1) Line 93 + 0x28 bytes C++
RobotSimulator.exe!main(int argc=2, char * * argv=0x05b4d968) Line 54 + 0x20 bytes C++
RobotSimulator.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
RobotSimulator.exe!mainCRTStartup() Line 403 C
kernel32.dll!7c817077()
The collada model is made by Blender 2.48a using the default startup scene with the cube with assigned a green material and esported with Triangles option and DisablePhisics option (for testing). You can find it in attachments.
Note that with collada-dom viewer the model is loaded adn displayed correctly and with osgviewer the model is loaded witout exceptions but nothing is displayed into the scene.
I think the problem is related to the call (you can see in the stack trace)
osg55-osgd.dll!osg::Object::setName(const char * name=0x)� Line 102 + 0x21 bytes
Can you tell me why this appens and
Re: [osg-users] [osgPlugins] Collada plugin texture problem
daniele argiolas wrote:
Hi,
in attachment the model.
Thank you!
daniele
Daniele,
I have mailed the modified file directly to you to avoid cluttering up
the list. The changes are at the end of the file. I have changed all
instances of
bind semantic="UVSET0" target="#cageShape-lib-map1"/
to
bind_vertex_input semantic="#cageShape-lib-map1"
input_semantic="UVSET0" input_set="0"/
The bind element is not allowed in the Collada COMMON profile from
verison 1.4.1 of the specification onwards. However if a
bind_vertex_input is not found our loader will just issue the warning
and then go on to use the first TEXCOORD found if any. This will not
work in all cases but does work on your file.
if (k == bvia.getCount())
{
osg::notify( osg::WARN ) "Failed to find matching
bind_vertex_input for " MainTextureTexcoordName
std::endl;
// This may be a departure from the spec. For the time being I am
only going to do this
// for the MAIN_TEXTURE_UNIT.
// Not found so just use the first TEXCOORD we have if any.
if (cachedGeometry-_TexcoordSetMap.size() 0)
clonedGeometry-setTexCoordData(MAIN_TEXTURE_UNIT,
cachedGeometry-getTexCoordData(cachedGeometry-_TexcoordSetMap.begin()-second));
}
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modified dae file
Daniele Argiolas wrote: Hi, thank you. All model that I've found from Collada Test Model Bank, Google Warehouse or that I generate with ColladaMaya or ColladaMax don't work in OSG. Who has decided Collada COMMON profile and who uses it? If all models are in this way, not precise, it's very restrictive that OSG can accept only a limited number of files. I see that all checks are in daeRMaterial.cpp, correct? I think that I'll try to modify this to make loader more versatile. Daniele Daniele, The Collada COMMON profile is part of the Collada spec and is under the control of the Collada Working Group which is a part of the Khronos Group (www.khronos.org); it is not something that is decided by OSG. The common profile is supposed to be the baseline which is supported by all implementations of the Collada spec. The file you supplied me with does work unmodified with with the current OSG 2.8.1 build, the bind_vertex_input message is just informative in that case. The code I put in to use the first TEXCOORD array if a specific named one cannot be found was an attempt to overcome problems with incorrect interpretations of the spec. However the use of bind_vertex_input is required to make other files work! I am afraid the Collada standard and various implementations are riddled with these problems, due to the lack of clarity in the specification, which the authors seem unwilling to address. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Collada plugin texture problem
daniele argiolas wrote: Hi, I've a Nvidia Geforce 7900GS. If I use an OSG version from 2.8 to 2.9 when I open a Collada file with texture (taken from collada-dom sample) texture are not loaded. Then I've tried with version 2.6 of OSG and texture works fine. What can I do? Someone have resolved it? I must use version 2.9 of OSG. Output of 2.9.4 has a difference, write: "Failed to find matching bind_vertex_group for UVSET0" Thanks, daniele Danielle, The collada plugin is now much stricter its interpretation of the Collada spec. This message means that the file you are using does not conform to the collada schema. There are some samples on the Colllada website that are not conformant.. If you can send me the file you are using, I can probably show you how to hand edit it. This usually found in files generated by an old version of a popular 3d editor, I cannot remember which one, but the top of the Collada file should tell you. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] A quick clean up of the Collada plugin build system
I have spent a little time looking at the Collada plugin build system and have done a small amount of cleaning up. In the rest of this message I use the term "Collada DOM library" to refer to the open source Collada parser and writer library, and "plugin" to refer to the OSG dae plugin that uses this library. Before I get onto that, here is a little review of the current state of the build system for the Collada DOM library that the plugin depends on. I will put this information into the wiki once you guys have had a chance to review it. It is a work in progress and you can skip to the bottom if you are just interested in trying out the new CMake files! == The Collada plugin depends on a version of the Collada DOM library that supports version 1.4 of the Collada schema. The current packaged version of the Collada DOM library is version 2.2 which supports both versions 1.4 and 1.5 of the schema but not simultaneously. However this version incorrectly names its output libraries which can lead to problems. The best version to use is version 2.2.1 which is only available as a source checkout from the Collada DOM subversion repository at https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.2.1 . The version of the schema supported is selected by choosing the relevant DAE include directory both at the time the library is being built and when anything that uses the library is being built. The resulting libraries are differentiated by a naming convention, libcolladaXXdomYY where XX is the schema version and YY is DOM library version. So anything that uses the library as well as using the correct DAE include directory has to link to the correct library name as well. Static versions have the suffix -s added to the name, debug versions have the suffix -d, a version which is both static debug has the suffix -sd. The Collada DOM library has a number of external dependencies. If you build with the default configuration (highly recommended) these are boost(filesystem), libxml2, minizip, pcre, and zlib. To avoid potential problems it is best to ensure that the Collada DOM library build system points to versions of these libraries that are the same ones used by OSG or your application using OSG, especially if you are using dynamic versions of these libraries. For windows the Collada DOM library build system provides various Visual C++ project files. The location of dependant library include files and library files can be edited through Visual C++ property pages in the normal way. Out of the box the situation looks like this. On windows by default all the dependencies are satisfied from the DOMs own extenal lib sources and binaries in the external-libs directory of the dom source tree. Static Build Include Paths "..\..\external-libs\libxml2\include";"..\..\external-libs\tinyxml";"..\..\external-libs\pcre";"..\..\external-libs\minizip\include";"..\..\external-libs\boost" Dynamic Build Include Paths "..\..\external-libs\libxml2\include";"..\..\external-libs\tinyxml";"..\..\external-libs\pcre";"..\..\external-libs\minizip\include";"..\..\external-libs\boost" Dynamic Build Library Paths "..\..\external-libs\libxml2\win32\lib";"..\..\external-libs\tinyxml\lib\vc8";"..\..\external-libs\pcre\lib\vc8";"..\..\external-libs\minizip\win32\lib";"..\..\external-libs\boost\lib\vc8" Dynamic Build Library Names (I copied these from the debug build properties) libxml2_a.lib zlib.lib pcre-d.lib pcrecpp-d.lib minizip.lib libboost_filesystem-d.lib libboost_system-d.lib TODO - work out what really needs zlib. At a guess I think both the precompiled minizip and precompiled libxml2 use it. On Linux the values are hardcoded into dom/make/dom.mk Include Paths -I/usr/include/libxml2 -Iexternal-libs/boost -Iexternal-libs/minizip/include Library Names -lxml2 -lpcre -lpcrecpp external-libs/boost/lib/$(buildID)/libboost_system.a external-libs/boost/lib/$(buildID)/libboost_filesystem.a -Lbuild/$(buildID)-$(colladaVersion)$(debugSuffix)/ -lminizip$(debugSuffix) So the linux build will default to the internal versions of boost and minizip. = The changes I made to the plugin build system relate to the fact the main Collada Dom library include file dae.h by default includes boost/filesystem/convenience.hpp. Unfortunately although this include file is a primary part of the external published interface of the Collada DOM library it has code in it which makes calls on the boost library. This forces a reference to the boost libraries by any code that includes this file, even though the calling code may make no use of the boost libraries itself. This is especially irksome if a dynamic version of the Collada DOM library is being used. Fortunately the include statement is wrapped in a conditional compile (NO_BOOST). My tests so far indicate that defining this for our plugin has no ill effects and means that
Re: [osg-users] A quick clean up of the Collada plugin build system
Roger James wrote: The changes I made to the plugin build system relate to the fact the main Collada Dom library include file dae.h by default includes boost/filesystem/convenience.hpp. Unfortunately although this include file is a primary part of the external published interface of the Collada DOM library it has code in it which makes calls on the boost library. This forces a reference to the boost libraries by any code that includes this file, even though the calling code may make no use of the boost libraries itself. As per usual I noticed that did not make much sense after I posted. This is my second attempt. I am not sure if it is much clearer! One thing for sure is that putting convenience.hpp in dae.h is a bad idea as far as I am concerned and I will raise a feature request on the Collada DOM to try and get it moved into the internal .cpp files that actually need it. "The changes I made to the plugin build system relate to the fact the main Collada Dom library include file dae.h by default includes boost/filesystem/convenience.hpp. dae.h is a primary part of the externallypublished interface to the Collada DOM library. Unfortunately convenience.hpp contains executable code which makes calls on the boost libraries. This forces a reference to the boost libraries by any code that includes dae.h, even though the calling code may make no use of the boost libraries itself." Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
People, We seem to have jumped straight into a technical discussion on how this could be done with very little discussion on whether it should be done. I think we need to take a step back here. At the moment I am tending toward the view that we should spend effort on improving the current build system and documentation for the plugin. I have yet to see a good argument why we should do otherwise. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Hi Robert, Comments in line. Roger Robert Osfield wrote: Hi Roger, On Thu, May 7, 2009 at 9:26 AM, Roger James ro...@beardandsandals.co.uk wrote: We seem to have jumped straight into a technical discussion on how this could be done with very little discussion on whether it should be done. I think we need to take a step back here. At the moment I am tending toward the view that we should spend effort on improving the current build system and documentation for the plugin. I have yet to see a good argument why we should do otherwise. As a first step improving the current build system and docs is the right thing to do. It's far less work and will provide much more immediate results. Agreed. I should have some time to look at this in about two weeks time. One thing I was thinking about was trying to force a static link of the DOM to try and alleviate some of the dll/so problems. Unfortunately I do not have a Linux build environment at the moment. However, we can't magically turn the Collada DOM into something it's not, it's not a lightweight easy to use dependency, it's a beast to download, and slippery fish to compile. Our own build tweaks won't ever solve this issue. I know that well! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada plugin not found.... but it is!
lucas Grijander wrote: I download collada dom 2.1, compile and installed it... then I recompiled osg 2.8.0... the dll are there but... still same error! any clue? thanks Jaime. Date: Tue, 5 May 2009 20:49:31 +0100 From: ro...@beardandsandals.co.uk To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Collada plugin not found but it is! lucas Grijander wrote: you mean I should use 2.1 version of collada DOM instead of 2.2? J. Date: Tue, 5 May 2009 17:54:05 +0100 From: ro...@beardandsandals.co.uk To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Collada plugin not found but it is! lucas Grijander wrote: Dear all, I installed the last version of OSG (2.8.0) and the 2.2 version of the collada-dom. I compiled and installed everything (debug and release). Now, when I execute my application and I try to "writeNodeFile" in dae format I get the well-known warning: "plugin not found". I got this information too: trying c:\osgdb_daed.dll USING c:...\osgdb_daed.dll DynamicLibrary::failed loading "osgPlugins-2.8.0\osgdb_daed.dll". any idea of what's the problem? many thanks! Jaime. From memory osg_daed.dll normally links against version 2.1 of the Collada DOM i.e. libcollada14dom21-d.dll Roger Yes Roger Jaime I suggest you use this excellent utility http://www.dependencywalker.com/ on the dae plugin dll and see what other dlls it is trying to load implicitly. Then make sure that these dlls are on the windows dll search path. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thoughts on a non Collada DOM based Collada plugin
Robert Osfield wrote: Hi All, To me it's looks like we are consistently getting a lot more support queries about the Collada plugin than any other our plugins. Build problems are rampant, and alas there isn't that much we can do about it directly. The Collada DOM does cause lots of problems for us, and they are problems that hasn't got fixed as time has moved on, at best one problem has been solved only to replaced by others. Collada DOM has always been troublesome, and it looks like it always will be. Robert, The problems with the collada plugin seem to me to fall into two broad categories. 1. Problems with the plugins (and other implementations) interpretation of the Collada specification. 2. Problems with the Collada DOM's build and deployment system and its interaction with the OSG build and deployment system. Problems in area 1 will still be there if we move to an in house parser. So we can probably ignore them for this discussion. However, here is my two pennies worth on them! (Flame On) Most of these problems stem from various different interpretations of the Collada Common Profile. This profile is said to be a profile for the exchange of digital assets between content authoring tools where the effects and techniques used are limited to those that can be eventually rendered on some abstract but so far undocumented fixed functionality rendering pipeline. The specification does not specifically cover the case where the asset exchange is between a content authoring system and a rendering system (such as OSG), although that is increasingly where Collada is being used. So to implement the OSG Collada plugin we have to define a mapping between an undocumented abstract model of a fixed function pipeline, and what ever OpenGL rendering pipeline model we choose to support. After many months of patient trying I have given up trying to get answers from the Collada people about issues that this raises as we seem to be talking different languages! http://collada.org/public_forum/viewtopic.php?f=12t=1210(Flame off!) Problems in area 2 seem to revolve around two main issues. Firstly that the OSG Collada plugin only supports version 2.1 of the Collada DOM object model and needs to be specifically linked against a build of the Collada DOM that is made for that version and if dynamic linking is used it needs to be able to find the correct DOM library at runtime. Secondly, the out of the box Collada DOM build systems links against versions of standard libraries such as boost that are contained and built in its own source tree. In the case of boost it does this even if the library is never used (due to inline code in include files); again this leads to problems finding the correct dynamic libraries at runtime. Most of the problems in area 2 can be solved by better documentation and improvements to the CMake build for the plugin. However this still leaves us as a hostage to future changes in the Collada DOM build system. I suspect that in the short term that improving the build system and documentation is a better option. However rolling our own parser might prove to be a better long term investment provided that the incorporation of future changes to the Collada schema are not too costly to implement. The effort involved in implementing a parser should not be underestimated. The Collada DOM's XML schema is extensive and complex. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada plugin not found.... but it is!
lucas Grijander wrote: Dear all, I installed the last version of OSG (2.8.0) and the 2.2 version of the collada-dom. I compiled and installed everything (debug and release). Now, when I execute my application and I try to "writeNodeFile" in dae format I get the well-known warning: "plugin not found". I got this information too: trying c:\osgdb_daed.dll USING c:...\osgdb_daed.dll DynamicLibrary::failed loading "osgPlugins-2.8.0\osgdb_daed.dll". any idea of what's the problem? many thanks! Jaime. >From memory osg_daed.dll normally links against version 2.1 of the Collada DOM i.e. libcollada14dom21-d.dll Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada plugin not found.... but it is!
lucas Grijander wrote: you mean I should use 2.1 version of collada DOM instead of 2.2? J. Date: Tue, 5 May 2009 17:54:05 +0100 From: ro...@beardandsandals.co.uk To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Collada plugin not found but it is! lucas Grijander wrote: Dear all, I installed the last version of OSG (2.8.0) and the 2.2 version of the collada-dom. I compiled and installed everything (debug and release). Now, when I execute my application and I try to "writeNodeFile" in dae format I get the well-known warning: "plugin not found". I got this information too: trying c:\osgdb_daed.dll USING c:...\osgdb_daed.dll DynamicLibrary::failed loading "osgPlugins-2.8.0\osgdb_daed.dll". any idea of what's the problem? many thanks! Jaime. From memory osg_daed.dll normally links against version 2.1 of the Collada DOM i.e. libcollada14dom21-d.dll Roger Yes Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input
Martin Scheffler wrote: Hi, I export from Max using the feeling exporter 3.05b (c gives the same results). I have a diffuse map and an ambient map in my model. When importing the collada file into osg, the maps are not shown. It seems that I have to modify [code]instance_material symbol="r8.3.007_1" target="#r8.3.007-material"/[/code] to [code] instance_material symbol="r8.3.007_1" target="#r8.3.007-material" bind_vertex_input semantic="CHANNEL2" input_semantic="TEXCOORD" input_set="2"/ bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/ /instance_material [/code] Then everything works as expected. Is this faulty behavior of the exporter? The collada 1.4 spec says: [quote] The bind_vertex_input element binds geometry vertex streams (identified as input elements within geometry elements) to material effect vertex stream semantics. Although applications commonly perform automatic binding of vertex streams with identical semantic identifiers, there are frequently mismatches in a semantic identifier’s meaning. Use bind_vertex_input to remove these ambiguities [/quote] So maybe the exporter could detect texture coordinate sets automatically? Thanks, Martin[/quote] Martin, When I added the support for bind_vertex_input I am afraid I was quite strict in requiring it to be present. I admit if there if there was only one vertex stream with a CHANNEL1 or a CHANNEL2 semantic available then probably the binding should be automatic. However, in this case it looks like the exporter is still at fault as the the streams appear to have been given a TEXCOORD semantic, and because there are two of them then a bind_vertex_input is definitely needed to differentiate between the input sets. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada and ambient occlusion maps - only with diffuse texture?
Martin Scheffler wrote: Hi, I use 3ds Max render-to-texture to generate ambient occlusion maps. I then export the model to collada (with the nextgen plugin) and try to load them into osg. For some meshes I get this message: "Ambient occlusion map only supported when diffuse texture also specified", and the occlusion map is not loaded. Is that a collada thing or a shortcoming of the osg collada importer? Can I circumvent it by adding small one-color textures to the no-texture materials? Or is there a better way? Thank you. - Martin, It is the way the Collada importer is written. I admit that I thought I had good reason for making it work that way when I wrote that bit, however, now, I cannot remember what that reason was! It was something to do with mapping the Collada Common profile, which is supposed to represent a fixed a function pipeline, on to the OpenGL fixed function pipeline. This is what the code does when both the diffuse and ambient texture maps are present. // Set the ambient and diffuse colour white so that the incoming fragment colour ends up as a // lit white colour. I modulate both textures onto this to approximate the lighting equation. // Using a zero diffuse and then an ADD of the diffuse texture seems overlit to me. mat-setAmbient( osg::Material::FRONT_AND_BACK, osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f ) ); mat-setDiffuse( osg::Material::FRONT_AND_BACK, osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f ) ); // Use the ambient texture map as an occlusion map. ss-setTextureMode( AMBIENT_OCCLUSION_UNIT, GL_TEXTURE_2D, GL_TRUE ); ss-setTextureAttribute(AMBIENT_OCCLUSION_UNIT, new osg::TexEnv(osg::TexEnv::MODULATE) ); ss-setTextureAttribute( AMBIENT_OCCLUSION_UNIT, AmbientStateAttribute ); // Modulate in the diffuse texture ss-setTextureMode( MAIN_TEXTURE_UNIT, GL_TEXTURE_2D, GL_TRUE ); ss-setTextureAttribute(MAIN_TEXTURE_UNIT, new osg::TexEnv(osg::TexEnv::MODULATE) ); ss-setTextureAttribute( MAIN_TEXTURE_UNIT, DiffuseStateAttribute ); So setting up a texture for your diffuse colour should probably work. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows users - VS2008 comments
sherman wilcox wrote: Slightly off-topic for this mailing list but here goes. For the Windows users out there, those of you that are using or know of developers using VS2008 - any comments? Problems, benefits, pros/cons? My project is using VS2005 and has been for a while now but I'm considering switching to VS2008. In my case there's only one reason - the /MP benefit. /MP enables parallel compilation. For multiprocessor or multicore systems it's a real performance increase. I'm not talking about parallel builds of multiple projects but compiling multiple modules in the same project(s) in parallel. On VS2005 /MP is undocumented but works, mostly. It's a tremendous performance boost. However, I've ran into a PDB corruption issue here as of late. Error C2471. Not sure why it's suddenly happening as I've been using /MP for a long while now. I believe Gordon warned me this could happen and it has. I phoned Microsoft about this and they said that /MP is unsupported on VS2005 and I have no recourse but to either not use that feature (no way - too fast) or upgrade to VS2008. So, I may be upgrading. However, there are numerous developers on my project and I want to have a clear understanding of any potential issues before moving forward. I'll be purchasing a copy to test but I'd like to hear from the list. This reply is probably not very helpful, but I would check if you can actually install VC2008 Sp1. I have been trying for two days but I cannot get past the .NET 3.5 SP1 install that is a prerequisite. It fails with an access denied error that I cannot track down. This is only a fairly vanilla Vista installation. Best of luck. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Collada Commands
Adam Wise wrote: rogerjames99 wrote: Adam Wise wrote: I set osg_notify_level to debug, and I recieved this when I ran osgconv. I honestly have no idea what this means, but at least it finds something. GraphicsContext::setWindowingSystemInterface() 03571930 003D9198 Also, the collada plugin was built as far as I can tell. I attached the release log. Everything was located in:C:OpenSceneGraph-2.8.0buildsrcosgPluginsdaeosgdb_dae.dirRelease. Does that mean I made a mistake in setting things up? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9154#9154 (http://forum.openscenegraph.org/viewtopic.php?p=9154#9154) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) Did you remember to run the INSTALL target as I mentioned in my last message. "Remember OSG cannot find plugins from the bin (build) directory, you need to run the INSTALL target (in both Release and Debug mode) as admiminstrator if you are on Vista. This will probably copy them into the right place under "/Program Files/OpenSceneGraph"." Another point..If OSG cannot find ANY of the plugins then try setting the environment variable OSG_LIBRARY_PATH to C:Program FilesOpenSceneGraphlib or wherever the INSTALL target is putting the main osg libraries Roger -- Post generated by Mail2Forum Ok. just to make sure, the INSTALL target is in the solution explorer (that's in Visual studio) of the OpenSceneGraph.sln? Yes Also, to install both debug and release you simply go into properties (of the install target) and change the configuration to debug/release? No, I think that just changes the particular set of build properties you are looking at. You normally select the solution configuration to build by using the "solution configuration" drop down list in the standard toolbar. I'm trying to make sure that the osg library path is found by using sysedit. I normally use the Environment Variable editor on (My) Computer...Properties..Advanced. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Collada Commands
Adam Wise wrote: A unique little issue comes up when I build with release, visual studio C++ prompts me for an executable for debug session. What should I select? I am guessing here, but I suspect that are pressing the icon that looks like the play symbol on a cd player to the left of the "solution configuration" drop down. That in fact is the "execute program in debug mode" button, not the build button. I would suggest that you left click on the INSTALL project in the solution explorer and select build from the pop up menu. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Collada Commands
Adam Wise wrote: I set osg_notify_level to debug, and I recieved this when I ran osgconv. I honestly have no idea what this means, but at least it finds something. GraphicsContext::setWindowingSystemInterface() 03571930 003D9198 Also, the collada plugin was built as far as I can tell. I attached the release log. Everything was located in:C:\OpenSceneGraph-2.8.0\build\src\osgPlugins\dae\osgdb_dae.dir\Release. Does that mean I made a mistake in setting things up? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9154#9154 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Did you remember to run the INSTALL target as I mentioned in my last message. "Remember OSG cannot find plugins from the bin (build) directory, you need to run the INSTALL target (in both Release and Debug mode) as admiminstrator if you are on Vista. This will probably copy them into the right place under "/Program Files/OpenSceneGraph"." Another point..If OSG cannot find ANY of the plugins then try setting the environment variable OSG_LIBRARY_PATH to C:\Program Files\OpenSceneGraph\lib or wherever the INSTALL target is putting the main osg libraries Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Big performance hit when using shadows
Hi, I have been doing some tests using the minimal draw bounds LISPSM implementation. I find that when the shadow node is inserted in the graph my frame rates go from 60 fps (vsync) down to less then 10 fps. I have verfified this on a number of different machine configurations with varying levels of graphic card capability. The original scene graph uses fixed pipeline functionality only, so the the introduction of the shadow node is turning on programmable functionality and some extra traverses of parts of the scene graph. Is anyone else experiencing these levels of performance hit. I am wondering if there is some kind of fundamental bottleneck in the way my graph is constructed that is really being exacerbated when the programmable pipeline is active. Is this a possibility? What sort of things should I be looking for? Any help or comments gratefully received! My apologies for the vagueness of the question, but I do not know where to start. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big performance hit when using shadows
Thanks Wojciech and Robert, You have given me some things to think about. I used the DB variant because my dynamic terrain geometry (Virtual Terrain Project) is almost always far bigger than the area in which I am interested in drawing good (building) shadows resulting in blocky shadows in most of the other methods. I will check whether the way we set up attributes in the graph could be affecting this. Though I don't rememeber using protected atrributes anywhere. I must admit that I have been puzzled in the past when I have added things that use shaders into our scenes about how much the frame rate slows. I did some experiments recently trying to ensure that fast paths and VBOs were used throughout but they did not seem to improve things. Maybe there is a clue for me somewhere in that, and the shadow stuff is really just highlighting an already existing performance bottleneck in our scenes. Roger Wojciech Lewandowski wrote: Hi Guys, I usually gethalf of theinitial framerate with LISPSM DB shadows.DB variant does one extra pass (beyond shadow map pass) to prerenderthe scene and compute minimal shadow bounds.This may be the culprit in your case. Result of this phase,the image with depths recorded at some smallerresultion, is scanned (CPU unfortuanately) and polytope around shadow receiving scenecomputed. Obvious performance penaltycaused hereis related to reading prerendered image to main memory and computing bounding box around points associated with every depth rendered. This is a step I would like to see computed on GPU butIwas not sure howcould I implement this withoutnumber of extra passes. I made an attempt to override most of the StateAttributes with minimal setof simple attributes to avoid unnecessary statechangesthis depth prernder phase and shadow map rendering phase. But I could imagine that if someone somehow(PROTECTED attributes?)managed to avoidthis override on some of their states it may cause longer than normal rendering. You may try LISPSM_CB and see if this causes the same loss of framerate. CB flavour computes shadwed scene by scanning renderbin and computesbounding boxes around render leaves selected for draw phase. This method should provide similar precision as DB if your drawables are fairly small. But if some of the drawables extend far beyond visible scene, computed shadowed voulem will be much larger than DB result. And this could eventually greatly degrade shadow generation precision. Cheers, Wojetek Lewandowski - Original Message - From: Robert Osfield To: OpenSceneGraph Users Sent: Wednesday, March 25, 2009 1:47 PM Subject: Re: [osg-users] Big performance hit when using shadows Hi Roger, I haven't seen such great performance hits in my own testing, but I haven't pushed things too hard on the shadows front so perhaps I just haven't tested hard enough :-) At your end you need to look into what the performance bottleneck is, bring up the on screen stats and the look at the sizes of the update, cull, draw and GPU draw costs, comparing between the scene with shadows and the one without. Also try the standard osgshadow example: osgshadow -4 --lispsm For this scene I get a solid 60Hz, update and cull and GPU draw are all pretty low, but curiously the draw dispatch is locked out at 16ms which suggests that the draw is blocking on the OpenGL FIFO. Robert. 2009/3/25 Roger James ro...@beardandsandals.co.uk Hi, I have been doing some tests using the minimal draw bounds LISPSM implementation. I find that when the shadow node is inserted in the graph my frame rates go from 60 fps (vsync) down to less then 10 fps. I have verfified this on a number of different machine configurations with varying levels of graphic card capability. The original scene graph uses fixed pipeline functionality only, so the the introduction of the shadow node is turning on programmable functionality and some extra traverses of parts of the scene graph. Is anyone else experiencing these levels of performance hit. I am wondering if there is some kind of fundamental bottleneck in the way my graph is constructed that is really being exacerbated when the programmable pipeline is active. Is this a possibility? What sort of things should I be looking for? Any help or comments gratefully received! My apologies for the vagueness of the question, but I do not know where to start. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Collada Commands
Adam Wise wrote: rogerjames99 wrote: Adam Wise wrote: Robert Osfield wrote: On Tue, Mar 17, 2009 at 4:35 PM, Adam Wise wrote: Question: exactly what does this mean? Warning: Could not find plugin to write nodes to file "new.dae" What is means is that it's warning your that it couldn't find the plugin to write the nodes to the file "new.dae". But then... that's exactly what it says. I don't know what more to add. Perhaps you should try asking a different questions... such as WHY it's not able to find a plugin to write the nodes to the file "new.dae" If you are asking this question then ask the question have you compiled and installed the dae plugin? Robert. -- Post generated by Mail2Forum That's what I meant...why is it not able to find the plugin? As far as I know, I BUILT the collada package, and viewer in windows. I followed the instructions in the read me. As far as installing it, there were no explicit instructions as to how to do that. Should I create a path to something? A fairly fundamental check is to see if you have a file osgdb_dae.[dll|so] in the directory where all your other OSG plugins are located. On a recent windows install this will probably be "c:Program FilesOpenSceneGraphbinosgPlugins-2.8.0. If you have not, then you have not built the OSG Collada plugin. The OSG Collada plugin is built as part of the OSG build, it is not part of the Collada DOM library build. Roger -- Post generated by Mail2Forum DynamicLibrary::failed loading "osgPlugins-2.8.0/osgdb_daed.dll" Warning: Could not find plugin to write nodes to file "new.dae". So it's likely that I didn't build the OSG collada plugin. The closest thing I could find to that plugin was osgdb_daed.dll.embed.manifest. Which was located in C:\OpenSceneGraph-2.8.0\build\src\osgPlugins\dae\osgdb_dae.dir\Debug. It was well hidden for the most part. So, just to clarify, using visual studio 2008, how would I build the collada dom library? You should find a file called BuildLog.htm in that directory. That will tell you where and whether an output file has been built. If you used default settings the file should under the root of your OSG tree (c:\OpenSceneGrpah-2.8.0|) at bin/osgPlugins-2.8.0/osgdb_daed.dll. You can check up on whether you have a built a Release version by looking in the Release directory in osgdb_dae.dir (if it exists). Remember OSG cannot find plugins from the bin directory, you need to run the INSTALL target (in both Release and Debug mode) as admiminstrator if you are on Vista. This will probably copy them into the right place under "/Program Files/OpenSceneGraph". The Collada plugin will be only be added to the build if CMake finds the collada dom library files you can check this by running CMake and looking for the COLLADA_* values (you may need to select "show advanced values"). Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Plugin Collada
Patrick Roiss wrote: Hi, i have a problem. I would like to see files written in Collada (DAE). I build and compile the plugin (collada-dom) and osg with no errors. now if i try to open a collada-test file (collada-logo) i get an exception. what have i done wrong :-)? I know my information is to low, so what else do you know? i use windows XP and Visual Studio 2008 Express Patrick, A common problem is using a collada dom compiled against the Release C runtime with and OSG compiled against a Debug C runtime and vice versa. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Collada Commands
Adam Wise wrote: Robert Osfield wrote: On Tue, Mar 17, 2009 at 4:35 PM, Adam Wise wrote: Question: exactly what does this mean? Warning: Could not find plugin to write nodes to file "new.dae" What is means is that it's warning your that it couldn't find the plugin to write the nodes to the file "new.dae". But then... that's exactly what it says. I don't know what more to add. Perhaps you should try asking a different questions... such as WHY it's not able to find a plugin to write the nodes to the file "new.dae" If you are asking this question then ask the question have you compiled and installed the dae plugin? Robert. -- Post generated by Mail2Forum That's what I meant...why is it not able to find the plugin? As far as I know, I BUILT the collada package, and viewer in windows. I followed the instructions in the read me. As far as installing it, there were no explicit instructions as to how to do that. Should I create a path to something? A fairly fundamental check is to see if you have a file osgdb_dae.[dll|so] in the directory where all your other OSG plugins are located. On a recent windows install this will probably be "c:\Program Files\OpenSceneGraph\bin\osgPlugins-2.8.0. If you have not, then you have not built the OSG Collada plugin. The OSG Collada plugin is built as part of the OSG build, it is not part of the Collada DOM library build. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Duplicate dylib warnings on 2.8 OSX build
Roger James wrote: Stephan Maximilian Huber wrote: Hi Robert, Roger James schrieb: I just kicked off a build of 2.8 on OSX using the CMake generated Xcode projects. Along with a few warnings about deprecated functions in the carbon stuff I get a lot of warnings about duplicate dylibs whenever an osg dylib is referenced from another osg dylib during the build. It is a long time since I last built on OSX and it not an environment I am very familiar with. I don't remember seeing these warnings last time round, but I might have missed them. Does anyone know what these warnings mean, and can they be safely ignored. I can't see any warnings (beside the deprecated warnings in osgViewer+quicktime) when building current trunk with cmake (2.6.2) / XCode (3.1.2) using the 10.5 sdk What version of cmake, XCode and what sdk are you using? Can you paste some warnings into a mail and send to the list? cheers, Stephan ___ Hi Stephan, Here is a sample of the warnings I am seeing Ld /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release/osgarchive normal i386 mkdir /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release cd /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8 /Developer/usr/bin/g++-4.0 -o /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release/osgarchive -L/Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release -F/Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release -filelist /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/OpenSceneGraph.build/Release/osgarchive.build/Objects-normal/i386/osgarchive.LinkFileList -arch i386 -Wl,-search_paths_first -headerpad_max_install_names /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libOpenThreads.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosg.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgDB.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgUtil.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgGA.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgViewer.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgText.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgGA.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgUtil.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgDB.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosg.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libOpenThreads.dylib -lpthread /usr/lib/libm.dylib -framework Carbon -framework AGL -framework OpenGL ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgGA.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgUtil.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgDB.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosg.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libOpenThreads.dylib CMake version is 2.6.2 XCode is 3.0 SDK is "Current MAC OS" which is version 9.6 (I have forgotten how to find the current SDK version) I just did a software update and left everything at default. By the way and somewhat unrelated I had to change the Xcode settings to get the gdal plugin to compile. CMake had picked up the gdal include path but had not put into the additional include paths setting in the project. Roger Looking more closely at the duplicate dylib warnings it appears that they are caused by the relevant libraries appearing more than once in the link line. This would suggest that the warnings are innocuous but the problem does lie somewhere in the CMake configuration. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Duplicate dylib warnings on 2.8 OSX build
I just kicked off a build of 2.8 on OSX using the CMake generated Xcode projects. Along with a few warnings about deprecated functions in the carbon stuff I get a lot of warnings about duplicate dylibs whenever an osg dylib is referenced from another osg dylib during the build. It is a long time since I last built on OSX and it not an environment I am very familiar with. I don't remember seeing these warnings last time round, but I might have missed them. Does anyone know what these warnings mean, and can they be safely ignored. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Duplicate dylib warnings on 2.8 OSX build
Stephan Maximilian Huber wrote: Hi Robert, Roger James schrieb: I just kicked off a build of 2.8 on OSX using the CMake generated Xcode projects. Along with a few warnings about deprecated functions in the carbon stuff I get a lot of warnings about duplicate dylibs whenever an osg dylib is referenced from another osg dylib during the build. It is a long time since I last built on OSX and it not an environment I am very familiar with. I don't remember seeing these warnings last time round, but I might have missed them. Does anyone know what these warnings mean, and can they be safely ignored. I can't see any warnings (beside the deprecated warnings in osgViewer+quicktime) when building current trunk with cmake (2.6.2) / XCode (3.1.2) using the 10.5 sdk What version of cmake, XCode and what sdk are you using? Can you paste some warnings into a mail and send to the list? cheers, Stephan ___ Hi Stephan, Here is a sample of the warnings I am seeing Ld /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release/osgarchive normal i386 mkdir /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release cd /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8 /Developer/usr/bin/g++-4.0 -o /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release/osgarchive -L/Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release -F/Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/Release -filelist /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/bin/OpenSceneGraph.build/Release/osgarchive.build/Objects-normal/i386/osgarchive.LinkFileList -arch i386 -Wl,-search_paths_first -headerpad_max_install_names /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libOpenThreads.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosg.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgDB.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgUtil.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgGA.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgViewer.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgText.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgGA.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgUtil.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgDB.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosg.dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libOpenThreads.dylib -lpthread /usr/lib/libm.dylib -framework Carbon -framework AGL -framework OpenGL ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgGA.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgUtil.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosgDB.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libosg.dylib ld: warning, duplicate dylib /Users/rogerjames/EnvironProject/APIs/OpenSceneGraph-2.8/lib/Release/libOpenThreads.dylib CMake version is 2.6.2 XCode is 3.0 SDK is "Current MAC OS" which is version 9.6 (I have forgotten how to find the current SDK version) I just did a software update and left everything at default. By the way and somewhat unrelated I had to change the Xcode settings to get the gdal plugin to compile. CMake had picked up the gdal include path but had not put into the additional include paths setting in the project. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can't compile Collada 1.5 with RC5
Martin Scheffler wrote: Using Visual Studio 2008. OSG 2.8 RC 5 Collada Dom 1.5 Crosspost from here: https://sourceforge.net/forum/message.php?msg_id=6398399 Compiling Collada 1.5 dom worked without a problem for both static and dynamic. Now when I build OpenSceneGraph 2.8 RC5 in VS 2008 I get these error messages: 1libcollada15dom21-sd.lib( daeIOPluginCommon.obj) : error LNK2019: Verweis auf nicht aufgelstes externes Symbol ""public: virtual __thiscall daeZAEUncompressHandler::~daeZAEUncompressHandler(void)" (??1daeZAEUncompressHandler@@u...@xz)" in Funktion ""public: virtual int __thiscall daeIOPluginCommon::read(class daeURI const ,char const *)" (?r...@daeioplugincommon@@UAEHABVdaeURI@@p...@z)". 1libcollada15dom21-sd.lib(daeIOPluginCommon.obj) : error LNK2019: Verweis auf nicht aufgelstes externes Symbol ""public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const __thiscall daeZAEUncompressHandler::obtainRootFilePath(void)" (?obtainrootfilep...@daezaeuncompresshandler@@qaeabv?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@XZ)" in Funktion ""public: virtual int __thiscall daeIOPluginCommon::read(class daeURI const ,char const *)" (?r...@daeioplugincommon@@UAEHABVdaeURI@@p...@z)". 1libcollada15dom21-sd.lib(daeIOPluginCommon.obj) : error LNK2019: Verweis auf nicht aufgelstes externes Symbol ""public: __thiscall daeZAEUncompressHandler::daeZAEUncompressHandler(class daeURI const )" (??0daeZAEUncompressHandler@@q...@abvdaeuri@@@Z)" in Funktion ""public: virtual int __thiscall daeIOPluginCommon::read(class daeURI const ,char const *)" (?r...@daeioplugincommon@@UAEHABVdaeURI@@p...@z)". Sorry about the german, the compiler is complaining about unresolved symbols. When I configure OSG to use the dynamic collada libs I get the following unresolved symbols: 3daeReader.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_TYPE_INSTANCE_RIGID_BODY" (?COLLADA_TYPE_INSTANCE_RIGID_BODY@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_GEOMETRY" (?COLLADA_ELEMENT_GEOMETRY@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_LIBRARY_GEOMETRIES" (?COLLADA_ELEMENT_LIBRARY_GEOMETRIES@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_TRIFANS" (?COLLADA_ELEMENT_TRIFANS@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_TRISTRIPS" (?COLLADA_ELEMENT_TRISTRIPS@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_LINESTRIPS" (?COLLADA_ELEMENT_LINESTRIPS@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_VCOUNT" (?COLLADA_ELEMENT_VCOUNT@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_POLYLIST" (?COLLADA_ELEMENT_POLYLIST@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_POLYGONS" (?COLLADA_ELEMENT_POLYGONS@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_TRIANGLES" (?COLLADA_ELEMENT_TRIANGLES@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_P" (?COLLADA_ELEMENT_P@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_LINES" (?COLLADA_ELEMENT_LINES@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_VERTICES" (?COLLADA_ELEMENT_VERTICES@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_MESH" (?COLLADA_ELEMENT_MESH@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_PARAM" (?COLLADA_ELEMENT_PARAM@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_ACCESSOR" (?COLLADA_ELEMENT_ACCESSOR@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_FLOAT_ARRAY" (?COLLADA_ELEMENT_FLOAT_ARRAY@@3PBDB)". 3daeWGeometry.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_SOURCE" (?COLLADA_ELEMENT_SOURCE@@3PBDB)". 3daeWMaterials.obj : error LNK2001: Nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_TECHNIQUE" (?COLLADA_ELEMENT_TECHNIQUE@@3PBDB)". 3daeWSceneObjects.obj : error LNK2019: Verweis auf nicht aufgelstes externes Symbol ""char const * const COLLADA_ELEMENT_TECHNIQUE" (?COLLADA_ELEMENT_TECHNIQUE@@3PBDB)" in Funktion ""public: virtual void __thiscall osgdae::daeWriter::apply(class
Re: [osg-users] collada
Roland Smeenk wrote:
Well, there's FCollada that is more or less abandoned when Feeling Software pulled it's hands off it. This used to be the preferred alternative, but I believe the DOM is becoming a better option since it is still in development and follows the latest updates when a new version of Collada is released.
--
Roland
Guys,
Firstly I think we are too close to 2.8 to put any changes in to the
CMake system. I propose that we sort this out on trunk first. As a
short term we maybe put the CMake hacking details onto the wiki and put
a link in the release notes to them.
Robert hit the nail on the head when he said the real problem was the
Collada build system. But I agree with Roland that Collada is a
valuable plugin to have. We could probably limit the number of
dependencies if we insisted on linking against a dynamic build of the
Collada DOM. However because of the inclusion of inline functions in
the boost headers the still leaves a dependency on boost. I dont know
if there anything in the Collada DOM build we can do to remove this. As
soon as we pull in one of the Collada dependencies we have a problem
because Collada always links against its own internal versions of the
libraries which may not match other already installed versions. With
boost on windows this is compounded by the fact that is has different
versions for VC8 and VC9. I also have a (ugly) hacked version of the
CMakelists.txt for building on my system.
So to summarise I suggest.
1. Put the hand editing instructions on how to build on the wiki.
2. Put a link to these in the release note.
3. Decide on whether to link only to the dynamic dom.
4. See if we can remove the inline dependencies in boost.
5. Make the CMakelists.txt changes on trunk.
6. Merge them inot 2.8.1 (whenever).
OK. So firstly is what I have said accurate? The can we have some help
on the CMake changes.. I have attached my hacked windows file for
information.
Roger
INCLUDE_DIRECTORIES( ${COLLADA_INCLUDE_DIR} ${COLLADA_INCLUDE_DIR}/1.4
${COLLADA_INCLUDE_DIR}/../external-libs/boost)
SET(TARGET_SRC
daeReader.cpp
daeRGeometry.cpp
daeRMaterials.cpp
daeRSceneObjects.cpp
daeRTransforms.cpp
daeWGeometry.cpp
daeWMaterials.cpp
daeWriter.cpp
daeWSceneObjects.cpp
daeWTransforms.cpp
domSourceReader.cpp
ReaderWriterDAE.cpp
)
SET(TARGET_H
daeReader.h
daeWriter.h
domSourceReader.h
)
IF (COLLADA_STATIC_LIBRARY)
SET(COLLADA_USE_STATIC YES)
ELSE(COLLADA_STATIC_LIBRARY)
SET(COLLADA_USE_STATIC NO)
ENDIF(COLLADA_STATIC_LIBRARY)
IF (COLLADA_DYNAMIC_LIBRARY OR COLLADA_STATIC_LIBRARY)
OPTION(COLLADA_USE_STATIC Set to ON to build OpenSceneGraph with static
Collada support. OFF)
MARK_AS_ADVANCED(COLLADA_USE_STATIC)
ENDIF(COLLADA_DYNAMIC_LIBRARY OR COLLADA_STATIC_LIBRARY)
IF(WIN32)
ADD_DEFINITIONS(-DBOOST_ALL_NO_LIB)
IF (COLLADA_USE_STATIC)
SET(TARGET_EXTERNAL_LIBRARIES libxml2 pcrecpp pcre
${COLLADA_INCLUDE_DIR}/../external-libs/boost/lib/vc8/libboost_system.lib)
ELSE (COLLADA_USE_STATIC)
SET(TARGET_EXTERNAL_LIBRARIES
${COLLADA_INCLUDE_DIR}/../external-libs/boost/lib/vc8/libboost_system.lib)
ADD_DEFINITIONS(-DDOM_DYNAMIC)
ENDIF(COLLADA_USE_STATIC)
ELSE (WIN32)
IF(COLLADA_USE_STATIC)
SET(TARGET_EXTERNAL_LIBRARIES collada14dom xml2 pcrecpp)
ELSE(COLLADA_USE_STATIC)
SET(TARGET_EXTERNAL_LIBRARIES collada14dom xml2)
ENDIF(COLLADA_USE_STATIC)
ENDIF(WIN32)
IF (COLLADA_USE_STATIC)
SET(TARGET_LIBRARIES_VARS COLLADA_STATIC_LIBRARY)
ELSE (COLLADA_USE_STATIC)
SET(TARGET_LIBRARIES_VARS COLLADA_DYNAMIC_LIBRARY)
ENDIF(COLLADA_USE_STATIC)
SET(TARGET_ADDED_LIBRARIES osgSim )
end var setup ###
SETUP_PLUGIN(dae dae)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collada users please test svn/trunk
Robert Osfield wrote: Hi All, I have just merged changes to svn/trunk from Roger James, Roland Smeenk and myself. The primary objective with these changes are fixing the build under Windows with the Collada DOM 2.1 + 2.2 for static and dynamic builds. As the collada build looks to be broken under the OSG-2.8 branch I feel that if the changes made to svn/trunk to improve things for the Collada building then we should merge these changes with svn/trunk. The revisions to svn/trunk of interest are 9841 and 9751. Robert. Robert, Works fine for me with Collada dynamic build in windows. My dae test files work as expected in viewer. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake error on trunk HEAD
I am getting the following error in Cmake after updating to the latest truink (9687). .src/OpenThreads/PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in does not exist. Is this a temporary situation or something not been checked in. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] collada
Matt Fair wrote: I am trying to get collada compiled into OSG and am having some trouble. It looks like collada-dom comes with boost and statically links to it, I have another version of boost on my system also, but how the make files are setup it is using the provided copy. When I compile OSG I get: Matt, To build against 2.2 on Windows I had to mod the CMake generated build files as follows:- 1. Added a path for boost to the additional include directories. 2. Added BOOST_ALL_NO_LIB to the preprocessor defines. 3. Added a path for boost to the linker additional library directories. 4. Added libboost_system-d.lib to the linker additional dependencies. However you can still build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom without making any changes. I suppose these changes should realy go into CMake, but I find CMake somewhat opaque :-) Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Robert Osfield wrote: Hi Roger, This is some experiment VS versioning. The path to the PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in is wrong in the src/OpenThreads/CMakeLists.txt, but the file is there (I just double checked that I check it in.) While I made the changes, unfortuantely I don't a VS box to test them on... Hi Robert, Looks OK now. Just kicked off a build. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] collada
alessandro terenzi wrote: Roger, are there also some changes that we should make to build collada plugin on Mac? I'm experiencing some problem when building collada plugin on Mac OSX (10.5). I'm quite new to Mac's developinng environment (as well as Unix and Linux), so maybe it is my fault and I apologize if I make silly questions, anyway here is what I did: 1) I built Collada DOM 2.2 (resulting in Collada14Dom.dylib) 2) I set OSG's cmake parameters for COLLADA in order to point to the just built Collada14Dom.dylib and to Collada DOM's headers too 3) I tried to build OSGusingXcode project as generated by cmake, but building failed So, I manually added the path to boost headers (that was a problem) andcompiling was successful, but linking failed becuase it looks like that the collada lib is still not found (even though I also added the path toCollada14Dom.dylib). Please can you tell me if there are some steps to follow in order to build dae plugin against DOM 2.2? By the way I'm usingOSG 2.7.9? Thanks. Alessandro On Fri, Feb 6, 2009 at 2:10 PM, Roger James ro...@beardandsandals.co.uk wrote: Matt Fair wrote: I am trying to get collada compiled into OSG and am having some trouble. It looks like collada-dom comes with boost and statically links to it, I have another version of boost on my system also, but how the make files are setup it is using the provided copy. When I compile OSG I get: Matt, To build against 2.2 on Windows I had to mod the CMake generated build files as follows:- 1. Added a path for boost to the additional include directories. 2. Added BOOST_ALL_NO_LIB to the preprocessor defines. 3. Added a path for boost to the linker additional library directories. 4. Added libboost_system-d.lib to the linker additional dependencies. However you can still build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom without making any changes. I suppose these changes should realy go into CMake, but I find CMake somewhat opaque :-) Roger Alessandro, I suspect you will have to make similar changes to the Xcode build files to successfully link against the Collada DOM api version 2.2. However there is really not much to gain from linking against this version rather than the 2.1 version. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Roger James wrote: Robert Osfield wrote: Hi Roger, This is some experiment VS versioning. The path to the PlatformSpecifics/Windows/OpenThreadsVersionInfo.rc.in is wrong in the src/OpenThreads/CMakeLists.txt, but the file is there (I just double checked that I check it in.) While I made the changes, unfortuantely I don't a VS box to test them on... Hi Robert, Looks OK now. Just kicked off a build. Roger Robert, I spoke too soon. The build fails because it cannot find afxres.h. I had quick look at the resource files you were trying to include and looks like you have a load of old MS appstudio stuff in there which I don't think you need. I have attached examples of how we include version resources in our products. We only split out the stuff into environversion.h because that file gets automatically updated with a new build number every time we do a release build. Roger // 108 #define FILE_VERSION1,3,2,108 #define PRODUCT_VERSION 1,3,2,108 #define FILE_VERSION_STR 1, 3, 2, 108\n #define PRODUCT_VERSION_STR 1, 3, 2, 108\n #ifndef _MAC / // // Version // #include environversion.h VS_VERSION_INFO VERSIONINFO FILEVERSION FILE_VERSION PRODUCTVERSION PRODUCT_VERSION FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x1L #else FILEFLAGS 0x0L #endif FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 080904b0 BEGIN VALUE Comments, \0 VALUE CompanyName, Virtual Outlooks Ltd.\0 VALUE FileDescription, Environ Communicator\0 VALUE FileVersion, FILE_VERSION_STR VALUE InternalName, Environ Communicator\0 VALUE LegalCopyright, Copyright © 2003,2004,2005,2006,2007\0 VALUE LegalTrademarks, \0 VALUE OriginalFilename, EnvironCommunicator.exe\0 VALUE PrivateBuild, \0 VALUE ProductName, Virtual Outlooks Ltd. Environ Communicator\0 VALUE ProductVersion, PRODUCT_VERSION_STR VALUE SpecialBuild, \0 END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x809, 1200 END END #endif// !_MAC ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
Robert Osfield wrote:
Hi Roger,
Sorry to hear it's still broke. I'm not the original author of
version additions, just the integrator. Would it be possible for you
to tweak the version support now checked in and get it working.
Cheers,
Robert.
Robert,
Modified template resources attached.
Roger
1 VERSIONINFO
FILEVERSION ${OPENSCENEGRAPH_MAJOR_VERSION}, ${OPENSCENEGRAPH_MINOR_VERSION},
${OPENSCENEGRAPH_PATCH_VERSION}, ${OPENSCENEGRAPH_SOVERSION}
PRODUCTVERSION ${OPENSCENEGRAPH_MAJOR_VERSION},
${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION},
${OPENSCENEGRAPH_SOVERSION}
FILEFLAGSMASK 0x17L
#ifdef _DEBUG
FILEFLAGS 0x1L
#else
FILEFLAGS 0x0L
#endif
FILEOS 0x4L
FILETYPE 0x0L
FILESUBTYPE 0x0L
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904b0
BEGIN
VALUE FileDescription, OpenSceneGraph Binary
VALUE FileVersion, ${OPENSCENEGRAPH_MAJOR_VERSION},
${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION},
${OPENSCENEGRAPH_SOVERSION}
VALUE InternalName, OSG
VALUE LegalCopyright, Copyright (C) 2009
VALUE OriginalFilename,
VALUE ProductName, OpenSceneGraph
VALUE ProductVersion, ${OPENSCENEGRAPH_MAJOR_VERSION},
${OPENSCENEGRAPH_MINOR_VERSION}, ${OPENSCENEGRAPH_PATCH_VERSION},
${OPENSCENEGRAPH_SOVERSION}
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
1 VERSIONINFO
FILEVERSION ${OPENTHREADS_MAJOR_VERSION}, ${OPENTHREADS_MINOR_VERSION},
${OPENTHREADS_PATCH_VERSION}, ${OPENTHREADS_SOVERSION}
PRODUCTVERSION ${OPENTHREADS_MAJOR_VERSION}, ${OPENTHREADS_MINOR_VERSION},
${OPENTHREADS_PATCH_VERSION}, ${OPENTHREADS_SOVERSION}
FILEFLAGSMASK 0x17L
#ifdef _DEBUG
FILEFLAGS 0x1L
#else
FILEFLAGS 0x0L
#endif
FILEOS 0x4L
FILETYPE 0x0L
FILESUBTYPE 0x0L
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904b0
BEGIN
VALUE FileDescription, OPENTHREADS Binary
VALUE FileVersion, ${OPENTHREADS_MAJOR_VERSION},
${OPENTHREADS_MINOR_VERSION}, ${OPENTHREADS_PATCH_VERSION},
${OPENTHREADS_SOVERSION}
VALUE InternalName, OSG
VALUE LegalCopyright, Copyright (C) 2009
VALUE OriginalFilename,
VALUE ProductName, OPENTHREADS
VALUE ProductVersion, ${OPENTHREADS_MAJOR_VERSION},
${OPENTHREADS_MINOR_VERSION}, ${OPENTHREADS_PATCH_VERSION},
${OPENTHREADS_SOVERSION}
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OpenGL materials
Jean-Sbastien Guay wrote: Hi Gordon, (sorry, sent before I had finished typing...) No Lighting = No Material Hi J-S, Here is a probably worthless suggestion written without a proper review of the thread. I you want a material that looks the same as the unlit colour just set the materials emissive colour to the same as the vertex colour and set all the other material colours to black. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in 2.7.9 with collada
Patrice Bouvier wrote: Hi All, I'm working under ubuntu 8.04 Hardy. I've just installed the OSG 2.7.9 version. Unfortunately i've a problem with a collada scene, no textures are loaded. With the 2.6.1 version it was ok. I use the collada dom 2.0 version. Could someone give me a fix for that problem ? Thanks Patrice Without any information a fix will be difficult :-) Can you at least supply a copy of your osg notify log. If your model is a large one it would be good if you could cut it down to a single geometry node which fails to show a texture and post that. Collada files are xml and quite easy to hand edit. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SoftShadowMap jitter texture values
Hi, I am trying to merge the soft shadow functionality (jittering and pixel branching) used in osgShadow::SoftShadowMap into a shadow technnique derived from osgShadow::LightSpacePerspectiveShadowMap. If I derive LightSpacePerspectiveShadowMapDB I cannot get a penumbra, if I derive from LightSpacePerspectiveShadowMapVB I do get a penumbra but it is not jittered. If I modify the shader to report the results of the jittered lookups I can see that in the DB case the 8 initial test samples are all false wherever the fragment is in the shadow and all true in the lit areas. In the VB case in areas that are close to the edge of the shadow 4 unshadowed hits are reported no matter how near to the edge of the shadow the test is. The soft shadow code jitters the coordinates it uses to access the sample map using the following calculation ShadowMapCoord.xy = offset.xy * width * ShadowMapCoord.w + ShadowMapCoord.xy where offset.xy is obtained from the jitter map and is in the range -1 to +1, ShadowMapCoord is from an eye linear texgen, and offset is a parameter currently set to 0.005. Can anyone offer any insight into what is going on, especially on just what the ShadowCoord.w actually represents in this situation. The texgen matrix planes will have been set as follows. _texgen-setPlanesFromMatrix( _camera-getProjectionMatrix() * osg::Matrix::translate(1.0,1.0,1.0) * osg::Matrix::scale(0.5f,0.5f,0.5f) ); I admit that I have never really quite understood the use of w coordinates in projected spaces. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and cow.ive
Alexandre Amalric wrote:
Hi osg-users,
has anyone tried to launch osgShadow example with --lispsm and cow.ive
model, apparently LightSpacePerspectiveShadowMapDB do not handle
multi-textured model.
Is there any specific configuration to make it work ?
I'm using osg svn.
Kind regards,
--
Alexandre AMALRIC Ingnieur RD
Alexandre,
It is not a bug, and you cannot configure round it. The fragment
shaders in osgShadow::StandardShadowMap which are used by all the
lispsm variants do not support multi-texturing or the use of texgens.
The only way round it is to write your own shadow technique which
derives from lispsm and overrides the shaders with ones that do what
you want. Here is a very useful code snippet provided by Wojtek that
shows how it is done.
class CComplexShadowTechnique : public
osgShadow::LightSpacePerspectiveShadowMapVB
{
public:
/** Convenient typedef used in definition of ViewData struct and
methods */
typedef CComplexShadowTechnique ThisClass;
/** Convenient typedef used in definition of ViewData struct and
methods */
typedef osgShadow::LightSpacePerspectiveShadowMapVB BaseClass;
CComplexShadowTechnique()
{
// Override shaders here
}
struct ViewData: public BaseClass::ViewData
{
virtual void init( ThisClass * st, osgUtil::CullVisitor * cv
)
{
BaseClass::ViewData::init( st, cv );
// Add additional uniforms here
}
};
// This macro is required if you override ViewData and
ViewData::init
// It generates virtual stub function in trhe Base class which
// calls associated ViewData::init.
// Probably this was the reason your ViewData::init was not called.
// Its just a case where virtualization does not help because I
actually
// want to virtualize ThisClass subclass and its method.
META_ViewDependentShadowTechniqueData( ThisClass,
ThisClass::ViewData )
};
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and cow.ive
Wojciech Lewandowski wrote:
Guys,
Sorry if I offend anyone but I
thought thisshould be obvious. Looks like only J-Sgot it ;-)So
Inow shouttomake it clear:
If you don't like Vertex
shader I use you can easily turn it off and switch to Fragment shader
only version.You caneasilyadopt approach whereyou have
only one Fragmentshader as olderosgShadow::ShadowMap did. I have
added Vertex Shaderonly for one reason: to make sure ambient color is
not wiped.
But if you want fixed vertex
pipeline - simply call:
lispmObject-setMainVertexShader(
NULL );
lispmObject-setShadowVertexShader(
NULL );
and voila you got rid of
VertexShaders.
Of course you will also have to
substitute Fragment shaderswith yours, becausemy Fragment
shadersexpect that ambient termcolorAmbientEmissivewould be passed
from VertexShaders you turned off.
But further replacing
fragmentShaders with something similar to osgShadow::ShadowMap
shadersis really straight forward. Just set setMainFragmentShader with
your Shader. And call setShadowFragmentShader with NULL argument and
then you will land with configuration similar to osgShadow::ShadowMap.Which meansyou will lose ambient ;-).
Roger, You dont need to override
ViewData if you only want to replace shaders. Simply change the shaders
in yourDerivedShadowMapconstructor.I thought you want to do
something more complicated when youpresented me your class.
Wojtek
PS. Actually there are a ways to
compute ambient component in fragment shader if one is desperate,
butit would require other sacirfices. I wrote a post on this topic few
weeks ago.
-
Original Message -
From:
Roger James
To:
OpenSceneGraph Users
Sent:
Thursday, January 22, 2009 6:27 PM
Subject:
Re: [osg-users] Bug : LightSpacePerspectiveShadowMapDB and cow.ive
Alexandre Amalric wrote:
Hi osg-users,
has anyone tried to launch osgShadow example with --lispsm and cow.ive
model, apparently LightSpacePerspectiveShadowMapDB do not handle
multi-textured model.
Is there any specific configuration to make it work ?
I'm using osg svn.
Kind regards,
--
Alexandre AMALRIC Ingnieur RD
Alexandre,
It is not a bug, and you cannot configure round it. The fragment
shaders in osgShadow::StandardShadowMap which are used by all the
lispsm variants do not support multi-texturing or the use of texgens.
The only way round it is to write your own shadow technique which
derives from lispsm and overrides the shaders with ones that do what
you want. Here is a very useful code snippet provided by Wojtek that
shows how it is done.
class CComplexShadowTechnique : public
osgShadow::LightSpacePerspectiveShadowMapVB
{
public:
/** Convenient typedef used in definition of ViewData struct and
methods */
typedef CComplexShadowTechnique ThisClass;
/** Convenient typedef used in definition of ViewData struct and
methods */
typedef osgShadow::LightSpacePerspectiveShadowMapVB BaseClass;
CComplexShadowTechnique()
{
// Override shaders here
}
struct ViewData: public BaseClass::ViewData
{
virtual void init( ThisClass * st, osgUtil::CullVisitor * cv
)
{
BaseClass::ViewData::init( st, cv );
// Add additional uniforms here
}
};
// This macro is required if you override ViewData and
ViewData::init
// It generates virtual stub function in trhe Base class which
// calls associated ViewData::init.
// Probably this was the reason your ViewData::init was not called.
// Its just a case where virtualization does not help because I
actually
// want to virtualize ThisClass subclass and its method.
META_ViewDependentShadowTechniqueData( ThisClass,
ThisClass::ViewData )
};
Roger
Wojtek,
Mea culpa. I just missed it. I thought you had to override shaders in
the constructor.Thinking back I now remember that I had noticed the
setXXShader methods a while back I guess I had just forgotten them. I
assume that you still have to override the init to set up additonal
uniforms.
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Changing the value of a uniform during at scene graph traversal
I want to change the value of a uniform for the traversal of a subgraph. A the moment I am not sure how to do this. Does anyone have any suggestions on the easiest way to do this? Thanks, Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing the value of a uniform during at scene graph traversal
Robert Osfield wrote: Hi Roger, Do you mean you want a uniform to hold multiple values, one for each subgraph it's associated with? If so this isn't possible, if you want different values then you'll need to use multiple Uniforms, perhaps dynamically deciding which StateSet to use for each subgraph to be able to pass in the uniforms you want. If you just want to update a uniform say in the update traversal then you an just use an update callback on the uniform or the Node/StateSet it's associated with. Robert. On Wed, Jan 21, 2009 at 5:04 PM, Roger James ro...@beardandsandals.co.uk wrote: I want to change the value of a uniform for the traversal of a subgraph. A the moment I am not sure how to do this. Does anyone have any suggestions on the easiest way to do this? Thanks, Roger Thanks for the quick reply Robert. I was hoping that I could change the value the uniform of a whilst a particular geode was rendered and use it to tell a shader to do something different for that geometry. I was wondered if I could do something like attaching a uniform of the same name to the stateset of that node. I must admit I could not think of an easy way of doing it! I am trying to override some of the shader functionality in osgShadow to make it work with geometry that is unlit and uses a texgen for its main texture coords. osgShadow::StandardShadowMap uses a vertex shader which defeats any built in texgen functinality (and also does not work with unlit geometry). Unfortunaterly there does not appear to be a way of finding out if fixed function loightinh is off or a fixed function texgen has been requested when you are in a shader. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing the value of a uniform during at scene graph traversal
Jean-Sbastien Guay wrote: Hi Roger, I was wondered if I could do something like attaching a uniform of the same name to the stateset of that node. I must admit I could not think of an easy way of doing it! Well, you can do that! Different statesets can have uniforms of the same name, same type but different values and the values will be as you expect when it comes time for the shader to render a vertex or fragment of the given object. I (and probably Robert too) thought you wanted to change the value of a Uniform in mid-traversal... I am trying to override some of the shader functionality in osgShadow to make it work with geometry that is unlit and uses a texgen for its main texture coords. osgShadow::StandardShadowMap uses a vertex shader which defeats any built in texgen functinality (and also does not work with unlit geometry). Unfortunaterly there does not appear to be a way of finding out if fixed function loightinh is off or a fixed function texgen has been requested when you are in a shader. You could just write your own shader (you can start by copying the ones in osgShadow's code) which does lighting only when a uniform (say named EnableLighting) is true, and generates texcoords as osgShadow expects, and when it isn't then it wouldn't calculate any lighting and would calculate texcoords differently. You can also have a uniform (say named TexcoordType) which would be an int which would select different types of texcoord generation, and you would set it to be what osgShadow expects in the root node, but then change it to what you want in your own node's stateset. There's lots of possibilities. We do this for texcoord generation, lighting, texturing, fog coordinates and application, shadows, etc. Hope this helps, J-S Thanks J-S, Thats good news. I keep forgetting that cull just puts things into render bins for a later draw stage. I tend to visualise the rendering as occuring in the cull pass which I know is wrong. Sorry. Yes, I am planning to do exactly what you suggest. I have been hacking the code in osgShadow, but for production I want to avoid that! I just need to workj out how to override the ViewData::init code now, I cannot seem to get the method signature right. I have mailed Wojciech asking for help! Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with deletion ofDrawableDrawWithDepthShadowComparisonOffCallback
Philip, I am afraid I have already checked that path! The problem is definitely that execution is going into the compiler generated destructor (actually the 'vector deleting destructor') with the wrong value in the 'this' pointer which is usually passed around in the ecx register in Microsoft c++ calls. Why the vector destructor is called on a scalar delete I am not sure, however this appears to happen quite frequently in other places with no ill efffect. Roger Philip Taylor wrote: Roger, Any chance you are mixing debug and release dlls? This isa typical debug/release memory management problem, whenmemory allocated by one dll (using say debug memory management) is deallocated by another dll (built with releasememory management). The only solution (and it sort of feels right anyhow) is always let the dll that allocatesmemory also be responsible for deallocating the memory. That way, there is never a conflict with memory management - mind you other issues might then arise, so probably best to ensure that dlls (and the .exe) are built to the same debug or release state. PhilT -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org]On Behalf Of Roger James Sent: 19 January 2009 16:03 To: OpenSceneGraph Users Subject: [osg-users] Problem with deletion ofDrawableDrawWithDepthShadowComparisonOffCallback Has anyone else come across this problem. When the debugging features of osgShadow are activated by calling setDebugDraw(true). I get a crash when cleaning up my scene. This crash occurs when the destructor of DrawableDrawWithDepthShadowComparisonOffCallback is called. It appears that the 'this' pointer is off by a few (16) bytes by the time the compiler generated destructor is called. I suspect this is a compiler issue with Microsoft VC8.1. Tracing shows that the this pointer starts off OK and the right things are being done to handle the virtual destructor but when the chain of destructor calls gets thunked across into the osgShadow DLL the wrong offset is applied to get from the base virtual destructor this pointer (~osg::Referenced) to the correct derived class this pointer at this point. So has anyone else come across this, or got any ideas whether it is fixable. This might finally force me to move to VC9, a task I am not looking forward to. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem withdeletion ofDrawableDrawWithDepthShadowComparisonOffCallback
Wojciech, I think you may have pointed me in the right direction. I have just used the handy /d1ReportSingleClassLayoutclassname to dump out what VC8.1 thought was the class layout for DrawableDrawWithDepthShadowComparisonOffCallback inside DebugShadowMap.cpp and it thinks that the virtual function table pointers are 16 bytes apart. However if I break the execution on the exit from the constructor for DrawableDrawWithDepthShadowComparisonOffCallback inside DebugShadowMap.cpp the memory layout looks like this. 0x0A825160 042b64d0 042b64d8 0a81c448 cdcdcdcd 0004 0x0A825174 042b649c cdcdcdcd cdcdcd00 which looks to me like the the virtual function pointers are actually 20 bytes apart suggesting that there are an extra 4 bytes of derived class members. So it looks like something thinks it is allocating the "other" class. I use standard parameters for building OSG. The calls are being thunked across into the osgShadowd.dll. I am going to take a break now. Then I will change the name of the class in ShadowMap and see what happens. Roger Wojciech Lewandowski wrote: Roger, I am following your posts but unfortunately cannot find any strong suggestion to help. But I may offer two blind shots, maybe they bring some relief to your problem. 1:I have found thatwe accidentally created twoindependent classeswith DrawableDrawWithDepthShadowComparisonOffCallback name. One is defined in ShadowMap and second in DebugShadowMap. Maybe linker does something wrong here. Do you use standard linker options for building OSG ? Maybe changing nameof one them brings some new observations ? DrawableDrawWithDepthShadowComparisonOffCallback defined in DebugShadowMapshould be easily replacable by the one defined ShadowMap. There is one extra parameter in ShadowMap version for texture stage but this could be set to zeroand used instead ofDebugShadowMap version. 2: My otherattempt would be prefixingDrawableDrawWithDepthShadowComparisonOffCallback with OSGSHADOWEXPORT macro. Its a long shot but maybe destructor is somehow calledfrom your application executableand not inside osgShadow.dll code. Btw which one of DrawableDrawWithDepthShadowComparisonOffCallback classes is your problem ? One defined in ShadowMap or the one defined in DebugShadowMap ? Cheers, Wojtek - Original Message - From: Roger James To: phili...@ntlworld.com ; OpenSceneGraph Users Sent: Tuesday, January 20, 2009 11:48 AM Subject: Re: [osg-users] Problem withdeletion ofDrawableDrawWithDepthShadowComparisonOffCallback Philip, I am afraid I have already checked that path! The problem is definitely that execution is going into the compiler generated destructor (actually the 'vector deleting destructor') with the wrong value in the 'this' pointer which is usually passed around in the ecx register in Microsoft c++ calls. Why the vector destructor is called on a scalar delete I am not sure, however this appears to happen quite frequently in other places with no ill efffect. Roger Philip Taylor wrote: Roger, Any chance you are mixing debug and release dlls? This isa typical debug/release memory management problem, whenmemory allocated by one dll (using say debug memory management) is deallocated by another dll (built with releasememory management). The only solution (and it sort of feels right anyhow) is always let the dll that allocatesmemory also be responsible for deallocating the memory. That way, there is never a conflict with memory management - mind you other issues might then arise, so probably best to ensure that dlls (and the .exe) are built to the same debug or release state. PhilT -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org]On Behalf Of Roger James Sent: 19 January 2009 16:03 To: OpenSceneGraph Users Subject: [osg-users] Problem with deletion ofDrawableDrawWithDepthShadowComparisonOffCallback Has anyone else come across this problem. When the debugging features of osgShadow are activated by calling setDebugDraw(true). I get a crash when cleaning up my scene. This crash occurs when the destructor of DrawableDrawWithDepthShadowComparisonOffCallback is called. It appears that the 'this' pointer is off by a few (16) bytes by the time the compiler generated destructor is called. I suspect this is a compiler issue with Microsoft VC8.1. Tracing shows that the this pointer starts off OK and the right things are being done to handle the virtual destructor but when the chain of destructor calls gets thunked across into the osgShadow DLL the wrong offset is applied to get from the base virtual destructor this pointer (~osg::Referenced) to the correct derived class this pointer at this point. So
[osg-users] Problem with deletion of DrawableDrawWithDepthShadowComparisonOffCallback
Has anyone else come across this problem. When the debugging features of osgShadow are activated by calling setDebugDraw(true). I get a crash when cleaning up my scene. This crash occurs when the destructor of DrawableDrawWithDepthShadowComparisonOffCallback is called. It appears that the 'this' pointer is off by a few (16) bytes by the time the compiler generated destructor is called. I suspect this is a compiler issue with Microsoft VC8.1. Tracing shows that the this pointer starts off OK and the right things are being done to handle the virtual destructor but when the chain of destructor calls gets thunked across into the osgShadow DLL the wrong offset is applied to get from the base virtual destructor this pointer (~osg::Referenced) to the correct derived class this pointer at this point. So has anyone else come across this, or got any ideas whether it is fixable. This might finally force me to move to VC9, a task I am not looking forward to. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Roland Smeenk wrote: Roger, I compiled the code two days ago, but have not spent a lot of time on it yet. Hopefully I can take a look at it tonight. Roland Roland, I won't submit until I have heard from you. I am just recompiling against head at the moment. There is a small conflict in the DaeReader constructor that I have fixed, it looks like some of the initialisation has been re-ordered. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Roland Smeenk wrote: Roger, I am running osgsidebyside to see if reading and writing of Collada files is still OK and I am running into a few problems. Attached is a screenshot of the before (above) and after (below) of the duck.dae Collada example. Run like this: Code: osgsidebyside -o dummy.dae "collada dir\Public Section\COLLADA 1.4.1 Complex Samples\Dining Room\diningroomc.dae" All colors seem to be very washed out and what is strange is that after writing and reading the file again (right half of the screenshot) the color is even more different. Since you didn't change anything on the writer side I guess the model is now using some state that isn't properly written by the writer. Other models like seymour_plane.dae have the same problem and are rendered better with the HEAD version of the Collada plugin. I like the new support for ambient textures, but they are barely visible due to the washed out colors. Another problem I ran into is that the following line in processTransparencySettings Code: if (strcmp( ctt-getTexture()-getTexture(), diffuseTextureName)) crashes if there exists a texture in the transparent element, but there is no diffuseTexture (NULL). Roland -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4487#4487 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Roland, I will look at this on Tuesday. I must admit I thought strcmp handled NULL pointers, but that was probably wishful thinking. I thought I had tested duck.dae, but it looks like I have broken something late on. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Collada plugin and multi-texturing (a Christmas cracker)
I looking for help and inspiration on this one. Collada experts please note that this email contains some huge simplifications and generalisations. Even within the confines of the common profile material effects in Collada can define the use of more than one texture. Collada geometries can contain a variable number of texture coordinate arrays. Collada materials can contain a number of textures. The way Collada defines materials is that you define them all in a library. The same applies to geometries. In a node in the Collada scene graph you can then bind a geometry to a material. During this binding process you define which texture coordinate arrays in the geometry bind to which textures in the material. The way the Collada plugin works at the moment is that it processes the scene and as it comes across geometry/material bindings it first of all processes the Collada geometry into an osg::Geometry or reuses an osg::Geometry from a cache if it has already processed the Collada geometry. It then uses a similar technique to process the bound Collada material into a osg::StateSet. The problem I have is that it is the material that defines which textures should be used and in which order. But as far as I can see osg efectively "allocates" texture coordinate arrays to texture units in the Geometry object. This leads to a problem when using fixed functionality because even if the plugin "reads" the texture unit from the position of the bound texcoord array in the geometry when creating the material stateset, the implied ordering may be incorrect for this material. Even if it is correct at this time it may be incorrect if the material/stateset is cached and subsequently re-used with a different geometry. Unless I can find a way of delaying the allocation of texture units until the binding process occurs, then I suspect a fairly major rewrite of the plugin is needed. I hope I am wrong on this. So I leave this with you all to ponder over the holiday period. I will go back to trying to make transparency work properly :-) It is still somewhat broken at the moment. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building the Collada plugin
Randolph Fritz wrote: DOM 2.1 isn't even available on sourceforge any more. Basically I think I'm scrod, or some other sort of fish. I'll experiment some more with 2.2, and I suppose I can try the 2.7.8 release, but writing an OSG export script for SketchUp is looking better and better. Randolph Smeenk, R.J.M. (Roland) wrote: Randolph, The Collada plugin has only be used with the Collada DOM 2.1 library. DOM 2.2 was silently released two weeks ago, but I haven't tested it yet. There have been a few changes to the Cmake files since osg 2.6.1 so maybe the older version does not work right out of the box. -- Roland -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of R Fritz Sent: donderdag 18 december 2008 3:14 To: OpenSceneGraph Users Subject: [osg-users] Building the Collada plugin OSG 2.6.1, VS 2008. So far I've downloaded COLLADA_1.4.1_DOM_1.3.0.zip, built it, and got a slew of errors trying to build the plugin. (Collada DOM 2.2, which looks like it might be downward compatible, uses a different library structure, and I've no idea which files are still needed.) Which version of Collada is known to work? Does the plugin work at all with VS 2008? Randolph I build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom, that works fine for me. There is a lot of work by various people going on in the Collada plugin at the moment which is not quite ready for prime time. I will try a build against the latest DOM before I make a submission. I am afraid I have not yet moved to Visual Studio 2008, my production environment is VS2005 and will remain that way for some time. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Yet more fixes for the DAE plugin.
/*
* Copyright 2006 Sony Computer Entertainment Inc.
*
* Licensed under the SCEA Shared Source License, Version 1.0 (the License);
you may not use this
* file except in compliance with the License. You may obtain a copy of the
License at:
* http://research.scea.com/scea_shared_source_license.html
*
* Unless required by applicable law or agreed to in writing, software
distributed under the License
* is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or
* implied. See the License for the specific language governing permissions and
limitations under the
* License.
*/
#ifndef _DAE_CONV_H_
#define _DAE_CONV_H_
#include string
#include dae.h
#include dae/daeURI.h
#include dae/daeElement.h
#include dom/domCommon_color_or_texture_type.h
#include osg/Node
#include osg/Transform
#include osg/Notify
#include osg/PositionAttitudeTransform
#include osgDB/ReaderWriter
#include osgDB/FileNameUtils
#include osgDB/FileUtils
#include osgDB/Registry
#include osg/Material
class domBind_material;
class domCamera;
//class domCommon_color_or_texture_type;
class domCommon_float_or_param_type;
class domGeometry;
class domInstance_controller;
class domInstance_geometry;
class domInstanceWithExtra;
class domLight;
class domLookat;
class domMatrix;
class domNode;
class domP;
class domProfile_COMMON;
class domScale;
class domSkew;
class domTranslate;
class domRotate;
class domVisual_scene;
#include dom/domInputLocalOffset.h
namespace osgdae {
class domSourceReader;
inline daeElement *getElementFromURI( daeURI uri )
{
if ( uri.getState() == daeURI::uri_loaded || uri.getState() ==
daeURI::uri_pending ) {
uri.resolveElement();
}
return uri.getElement();
}
inline daeElement *getElementFromIDRef( daeIDRef idref )
{
if ( idref.getState() == daeIDRef::id_loaded || idref.getState() ==
daeIDRef::id_pending ) {
idref.resolveElement();
}
return idref.getElement();
}
template typename TInputArray, typename TInputType
bool findInputSourceBySemantic( TInputArray inputs, const char* semantic,
daeElement * element,
TInputType ** input = NULL, int unit = 0 )
{
element = NULL;
int count = 0;
for ( size_t i = 0; i inputs.getCount(); i++ ) {
if ( !strcmp(semantic, inputs[i]-getSemantic()) ) {
if ( count == unit )
{
element = getElementFromURI( inputs[i]-getSource() );
*input = (TInputType*)inputs[i];
return true;
}
count++;
}
}
return false;
}
/// Convert string to value using it's stream operator
template typename T
T parseString(const std::string valueAsString) {
std::stringstream str;
str valueAsString;
T result;
str result;
return result;
}
inline osg::Vec3 parseVec3String(const std::string valueAsString)
{
std::stringstream str;
str valueAsString;
osg::Vec3 result;
str result.x() result.y() result.z();
return result;
}
inline osg::Matrix parseMatrixString(const std::string valueAsString)
{
std::stringstream str;
str valueAsString;
osg::Matrix result;
str result(0,0) result(1,0) result(2,0) result(3,0)
result(0,1) result(1,1) result(2,1) result(3,1)
result(0,2) result(1,2) result(2,2) result(3,2)
result(0,3) result(1,3) result(2,3) result(3,3);
return result;
}
/**
@class daeReader
@brief Read a OSG scene from a DAE file
*/
class daeReader {
public:
daeReader(DAE *dae_);
virtual ~daeReader();
bool convert( const std::string fileURI );
osg::Node* getRootNode(){ return rootNode; }
// Additional Information
std::string m_AssetUnitName;
float m_AssetUnitMeter;
domUpAxisType m_AssetUp_axis;
// Texture unit useage
enum
{
MAIN_TEXTURE_UNIT = 0,
AMBIENT_OCCLUSION_UNIT,
TRANSPARENCY_MAP_UNIT
};
protected:
//scene processing
osg::Node*processVisualScene( domVisual_scene *scene );
osg::Node*processNode( domNode *node );
osg::Node*processOsgMatrixTransform( domNode *node );
//osg::Node* processInstance( domInstanceWithExtra *iwe );
// Processing of OSG specific info stored in node extras
osg::Node* processExtras(domNode *node);
void processNodeExtra(osg::Node* osgNode, domNode *node);
domTechnique* getOpenSceneGraphProfile(domExtra* extra);
void processAsset( domAsset *node );
osg::Node* processOsgSwitch(domTechnique* teq);
osg::Node* processOsgMultiSwitch(domTechnique* teq);
osg::Node* processOsgLOD(domTechnique* teq);
osg::Node* processOsgDOFTransform(domTechnique* teq);
osg::Node* processOsgSequence(domTechnique* teq);
//geometry processing
osg::Geode* processInstanceGeometry( domInstance_geometry *ig );
osg::Geode*
[osg-users] Strange error on 2.7.7 VC8.1 INSTALL(Release) target
I just did a build on a clean 2.7.7 source tree using Visual Studio 8.1. When I came to do the Release INSTALL target I got a failure whilst it was copying header files into the "\Program Files\OpensceneGraph\Include" directory. The error message was not very informative, it just said "failed to copy". I looked into the directory and all the files up to the one the failed had a new date stamp. On a whim I reran the INSTALL target and this time it got past the file it had failed on and failed on another header file further on. I reran it a couple more times and it got further each time eventually completing without error. It looks like there may be an error in the Cmake file install scripts when they have to copy a large a number of files. The reason it appeared to get further each time appeared to be because the header files it had already copied now showed as "up to date" rather than "Installing". If anyone else sees this don't worry just rerun the INSTALL. I leave this to anyone who understands CMake to fix! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strange error on 2.7.7 VC8.1 INSTALL(Release) target
Hi Matt, Mattias Helsing wrote: Hi Roger, On 12/19/08, Roger James ro...@beardandsandals.co.uk wrote: I just did a build on a clean 2.7.7 source tree using Visual Studio 8.1. When I came to do the Release INSTALL target I got a failure whilst it was copying header files into the "\Program Files\OpensceneGraph\Include" directory. The error message was not very informative, it just said "failed to copy". I looked into the directory and all the files up to the one the failed had a new date stamp. On a whim I reran the INSTALL target and this time it got past the file it had failed on and failed on another header file further on. I reran it a couple more times and it got further each time eventually completing without error. It looks like there may be an error in the Cmake file install scripts when they have to copy a large a number of files. The reason it appeared to get further each time appeared to be because the header files it had already copied now showed as "up to date" rather than "Installing". If anyone else sees this don't worry just rerun the INSTALL. I leave this to anyone who understands CMake to fix! I'm not sure it needs fixing. I just ran an install of my entire build tree including the reference docs (1 files). I'm on winxp with msvc8 sp1 with osg-2.7.8. No problems reported (except that with an encrypted ntfs drive it takes a bit of time :) What you are seeing could have many causes. Could be that you are installing to a network drive, antivirus software, hard drive failures, ... cheers Mattias Agreed, I am not going to worry about it :-) I have to run in adninistrator mode in Vista to do the INSTALL so who knows what arcane paths are being invoked! Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] An observation on the 2.7.7 dae plugin build
I don't use the osg third party sources, preferring to keep my own copies of dependant libary sources. So I switch on the advanced mode of CMake and fill in my own include and library locations. I filled in (I think they may actually have been filled in automatically, but I am not going back to check) COLLADA_DYNAMIC_LIBRARY, COLLADA_DYNAMIC_LIBRARY_DEBUG, COLLLADA_STATIC_LIBRAY, COLLADA_STATIC_LIBRARY_DEBUG and I set COLLADA_USE_STATIC to OFF. However I still got a static build, which gave me errors as it could not find my libxml2 library (another problem!). The only way I could get a dynamic build was to set the entries for the the static libraries to empty. I find this a bit confusing as the help for COLLADA_USE_STATIC says "Set to ON to build OpenSceneGraph with static Collada support". Enjoy, Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The Collada plugin and transparency
Smeenk, R.J.M. (Roland) wrote:
Hi Roger,
I tested this code with a few
models of the Collada test bank and not all examples work like before.
I did not take a look at the specific code paths that these examples
used.
Maybe it is wise that we set up
a regression data set specifically targeted at transparency.
--
Roland
From:
osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roger
James
Sent: vrijdag 12 december 2008 17:04
To: OpenSceneGraph Users
Subject: Re: [osg-users] The Collada plugin and transparency
Ok,
Here is where I am at the moment with the handling of transparency etc.
Being a developer I have pasted in the actual code. I must admit the
handling of the FX_OPAQUE_RGB_XXX stuff does not make much sense to me,
but then I have never seen it used. Comments welcome.
void daeReader::processTransparencySettings( domCommon_transparent_type
*ctt, domCommon_float_or_param_type *pTransparency, osg::StateSet *ss,
osg::Material *material )
{
if (NULL == ctt NULL == pTransparency)
return;
if (ctt ctt-getTexture() != NULL)
{
osg::notify( osg::WARN ) "Currently no support for
texture in transparent channel." std::endl;
return;
}
// Fix up defaults acoording to 1.4.1 release notes
domFloat4 f4;
domFx_opaque_enum Opaque = FX_OPAQUE_ENUM_A_ONE;
if (NULL == ctt)
{
f4.append(0.0f);
f4.append(0.0f);
f4.append(0.0f);
f4.append(1.0f);
}
else
{
Opaque = ctt-getOpaque();
if (NULL != ctt-getColor())
{
f4 = ctt-getColor()-getValue();
}
else if ((NULL == ctt-getParam()) ||
!GetFloat4Param(ctt-getParam()-getRef(), f4))
{
f4.append(0.0f);
f4.append(0.0f);
f4.append(0.0f);
f4.append(1.0f);
}
}
domFloat Transparency;
if (NULL == pTransparency)
Transparency = 1.0f;
else
{
if (NULL != pTransparency-getFloat())
{
Transparency = pTransparency-getFloat()-getValue();
if (m_AuthoringTool == GOOGLE_SKETCHUP) // Google back to
front support
Transparency = 1.0f - Transparency;
}
else if (NULL != pTransparency-getParam())
{
if
(GetFloatParam(pTransparency-getParam()-getRef(), Transparency))
{
if (m_AuthoringTool == GOOGLE_SKETCHUP) // Google back
to front support
Transparency = 1.0f - Transparency;
}
else
Transparency = 1.0f;
}
}
if (NULL != ctt || NULL != pTransparency)
{
// I assume that the presence of either a tansparent or
a transparency element
// means that the user may want some kind of alpha blending
int SourceBlendFactor;
int DestBlendFactor;
bool HaveTranslucentDiffuseTexture = false;
bool SwitchOnTheBlender = false;
if ((NULL != ctt)
(GL_TRUE == ss-getTextureMode(0, GL_TEXTURE_2D))
(NULL !=
dynamic_castosg::Texture2D*(ss-getTextureAttribute(0,
osg::StateAttribute::TEXTURE)))
(NULL !=
dynamic_castosg::Texture2D*(ss-getTextureAttribute(0,
osg::StateAttribute::TEXTURE))-getImage())
(dynamic_castosg::Texture2D*(ss-getTextureAttribute(0,
osg::StateAttribute::TEXTURE))-getImage()-isImageTranslucent()))
HaveTranslucentDiffuseTexture = true;
osg::Vec4 Diffuse;
if (material)
Diffuse =
material-getDiffuse(osg::Material::FRONT_AND_BACK);
// Determine whether or not to switch on the blender and which
blending factors to use.
// I switch the blender on if the supplied (or default)
transparent and transparency elements work out as non
opaque,
// or if they work out opaque and I have a translucent diffuse
texture or a non opaque value in the diffuse colour
switch(Opaque)
{
/*
case FX_OPAQUE_ENUM_RGB_ONE:
if ((Transparency * f4[0] 0.99f)
(Transparency * f4[1] 0.99f)
(Transparency * f4[2] 0.99f)
(Transparency * f4[3] 0.99f))
{
SourceBlendFactor = GL_SRC_COLOR;
DestBlendFactor = GL_ONE_MINUS_SRC_COLOR;
if (HaveTranslucentDiffuseTexture || ((Diffuse.r()
0.99f) (Diffuse.g() 0.99f) (Diffuse.b()
0.99f) (Diffuse.a() 0.99f)))
SwitchOnTheBlender = true;
}
else
{
SourceBlendFactor = GL_CONSTANT_COLOR;
DestBlendFactor = GL_ONE_MINUS_CONSTANT_COLOR;
SwitchOnTheBlender = true;
}
break;
case FX_OPAQUE_ALPHA_ZERO:
if (Transparency * f4[3] 0.01f)
{
SourceBlendFactor = GL_ONE_MINUS_SRC_ALPHA;
DestBlendFactor = GL_SRC_ALPHA;
if (HaveTranslucentDiffuseTexture || (Diffuse.a()
0.01f))
SwitchOnTheBlender = true;
}
else
{
SourceBlendFactor = GL_ONE_MINUS_CONSTANT_ALPHA;
DestBlendFactor = GL_CONSTANT_ALPHA;
SwitchOnTheBlender = true;
}
break;
*/
case FX_OPAQUE_ENUM_RGB_ZERO:
if ((Transparency * f4[0] 0.01f)
(Transparency * f4[1] 0.01f)
(Transparency * f4[2] 0.01f)
(Transparency * f4[3] 0.01f))
{
SourceBlendFactor = GL_ONE_MINUS_SRC_COLOR;
DestBlendFactor = GL_SRC_COLOR;
if (HaveTranslucentDiffuseTexture || ((Diffuse.r()
0.01f) (Diffuse.g() 0.01f) (Diffuse.b()
0.01f)
Re: [osg-users] The Collada plugin and transparency
Jason Daly wrote: Smeenk, R.J.M. (Roland) wrote: Hello Roger, I did not make a study of the Collada transparency intricacies like you did. The assumption I made was that a texture for diffuse specifies the diffuse components to use in the texture. The fact that texture coincidently was packed with an alpha channel (which of course happens a lot) should not influence that. When you consider the chain texturesamplersurfaceimagethe responsibilities are clearly dividided. It could be possible that somebody decides to pack an ambient occlusion or specular value in the alpha channel of an image. The semantics of the data sourceshould bespecified by the texture elements in ambient, diffuse, specular, etc. That's why I added code to only enable blending if a texture was specified in the transparant element. What you say makes sense, but I've never seen it done this way in any of the files I've used or created via COLLADA plugins. I think we need to support the "RGBA texture in diffuse channel only" model, just because so many files and tools work that way. This isn't ideal, but it's probably necessary. I've been very suprised to see suggested everywhere that the common profile maps to the fixed function pipeline, but this easily falls short if you need to support both blinn and phong. Well OpenGL FFP does not even support phong shading. Gouraud is the closest we get with per vertex lighting. It clearly doesn't map to FFP, but it's as close as COLLADA comes. The biggest problem with handling profile_COMMON with shaders is that it makes it hard for an OSG developer to use his/her own shaders higher up in the scene graph. I think this is what drives the desire to handle profile_COMMON with FFP. I don't know how to map textures specified for both ambient, diffuse, specular etc. to the Ogl FFP. Texture combiners might bring us a little closer, but I hardly consider this the FFP. Well, I believe ARB_texture_env_combine was made a core feature in OpenGL 1.3, so many would consider it FFP. But I digress... Besides what happens if the surface contains a channels specification other that rgb or rgba? It gets even worse if it is allowed to compose3 channel input for a diffuse texture combining components of three different source images. I am not sure if this is allowed in the profile_COMMON. Though very flexible,who is going to support this? I don't think that is allowed (the schema says only one color or texture per channel). That would get out of hand quickly. I don't think anyone here expects that to work anyway. We're just talking about a single RGBA texture in the diffuse channel. Roland, As Jason says, attempting to map the Collada FX common profile to OpenGL fixed functionality is a design goal rather than an absolute. I apologise that I have used the term "fixed functionality" loosely to refer to both the OpenGL FFP and the abstract fixed functionality referred to in the Collada spec. "The profile_COMMON elements encapsulate all the values and declarations for a platform-independent fixed-function shader. All platforms are required to support profile_COMMON. profile_COMMON effects are designed to be used as the reliable fallback when no other profile is recognized by the current effects runtime." If you also take into account Mark Barnes statement in his book.. "profile_COMMON (is) for basic interchange between digital content creation (DCC) tools" then you can see that Collada's abstract understanding of fixed functionality could be quite different from OpenGL's concrete implementation. For example the "fixed functionality" of a DCC might in fact be a ray tracer implemented in software, in fact it could even be implementeed entirely in programmable OpenGL shaders! The problems we have been wrestling with stem from the lack of a clear definition of what Collada's abstract "fixed functionality" model is. Your intrepretation of the spec clearly highlights this, and it is very close to the intrepretation I have been trying to map into a concrete OpenGL implementation (and trying to obey our design goals whilst doing this). Correct me if I am wrong but I believe your interpretation is that the diffuse, ambient etc. terms of a particular technique define the source of a colour term (either a texture map or a fixed value) that is used as input to the lighting equation of that technique. The result of this equation is the colour of the material (it is probably easier to think of this as a fragment colour in OpenGL terms). Collada defines colour as a RGBA value. So this intrepration would seem to imply that the alpha component of, for example, the diffuse element should be passed through the lighting equation and contribute to the alpha component of the result, and I think this is the only point where we differ. The main problem this model gives us is that when we try and map this interpretation to OpenGL,
Re: [osg-users] The Collada plugin and transparency
Jason Daly wrote:
Roger James wrote:
I was assuming that because the lighting equation (blinn) has already
been applied in the pipeline before textures are applied, that if we
wanted to use a texture map to supply the ambient terms to that
equation, then the lighting equation would have to be somehow
re-implemented in a fragment shader. I did not think the the fixed
functionality could be configured to handle it, especially the
contributions from light sources. I am happy to be wrong in this.
Well, thinking about it more, in order to get it mathematically
correct, you're probably right. However, fixed-function multitexturing
can give a reasonable facsimile (especially with an ambient occlusion
map in the ambient channel).
The "right" way to implement all of this is probably to write a COLLADA
Blinn shader (as well as one for Phong, one for Lambert, etc.) and
avoid fixed function altogether. Unfortunately, this leads to problems
if users want to make use of their own shaders.
I think I will just assume that if a translucent texture is present in
the ambient channel that it contains an ambient map and blend it in as
texture unit 1 (0 is used for diffuse). According to both the spec and
Mark's book the common profile of Collada FX is supposed to represent
an abstraction for a "platform independent fixed-function shader".
However in the abscence of any significant definition of what this
abstract shader/pipeline actually is, the specification appears to
suggest that texture values are used as input to the lighting process
(blinn, lambert,etc.). Obviously this is not the way OpenGL works. I am
not sure that this is what was intended :-). It is the source of much
of the confusion (well mine at least!).
The
transparency bit is the bit that needs fixing. We are just not
handling transparent textures at the moment. I would really appreciate
your input in this area, as I feel that I am just wandering about in
the wilderness on it at the moment.
I don't really remember enough about how this works. I know there are
issues and subtle differences regarding A_ONE and RGB_ZERO modes, and
I thought I even heard the spec for this changed between 1.4 and 1.5 (I
wrote my code for 1.4). I'll tell you what I did in my code, but I
don't have time to research this further right now.
Yes, some more opaque values have been added. There is a misprint in
the spec on all of them that suggests that the default value has
changed. I have been told that this is not the case, and the schema
document should be taken as authorative on this.
In my
code, (which is probably technically wrong, but seems to work
most of the time) I check the opaque setting on the transparent color.
If it's A_ONE, I use the transparency value as the alpha on the
material (the OpenGL material, that is). If it's RGB_ZERO, and
transparency is specified as a color, I average the transparency
color's RGB values and set the material's alpha to 1 minus the average
(this is probably a best-effort kind of hack). If transparency is a
texture (an alpha map), I ignore it, since it's not possible to support
in fixed-function (at least I don't think it is).
Of course, none of this has anything to do with whether or not the
diffuse texture has alpha. If the diffuse texture has an alpha
channel, this needs to be honored as well. I check for this with a
call to osg::Image::isImageTranslucent() on the image from the texture
in question.
That sounds like a reasonable approach. However, I have thought some
more about the approach I was suggesting and have modified it slightly.
I think I will try that and if it gives too many problems fall back to
your approach. I will attempt to pseudo code my latest thinking:
if (transparent or transparency element present in the technique)
{
// Turn on the OpenGL blender
Calculate a blending factor using transparent and transparency
according to the "opaque" mode in force.
// Decide whether to use GL_SRC_XXX or GL_CONSTANT _XXX in the
OpenGL blender
if (the calculated factor would mean opacity when applied)
Use the relevant blend factor from the incoming lit and textured
fragment
else
Use the previously calculated blending factor as a constant
blend factor
}
I would appreciate any comments you have, time permitting of course.
For anyone else reading this. Just a reminder that we are talking about
transparent and transparency within the confines of the common profile
which does not allow multiple techniques in an effect. I suspect that
in profiles that do allow multiple techniques there are many more
issues, the decalling of materials and textures being just one I can
think of.
Roger
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
