[osg-users] OSG2.4 and 2.5.5 Windows static build problems
Hi, I have searched the archive but cant find any mention of the problem, though I think can remember reading about a solution some time ago on the list. I have just tried to build the static version of OSG v2.4 and v2.5.5 using ViualStudio .Net 2003. When I do this build I get 5000+ warnings about dulpicate definitions when linking (LNK 4006). I then cannot link my aplication against the resulting .libs. Has anyone else encountered this problem and have a fix / workaround? The same versions worked fine on my CentOS5 machine. Cheers, Brad DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PrecipitationEffect not updating - problem solved
HI Murray, On Mon, Jul 21, 2008 at 3:40 AM, Murray Curtis [EMAIL PROTECTED] wrote: Found it. I had failed to add my view to the composite viewer so even though an update callback reported valid framestamps from the visitor, the precipitation node was not being updated (or updated incorrectly). Good to hear you've sorted out the problem. I have several of osgViewer::View each with differing viewports all sharing a common osg::GraphicsContext. Only one of the views needs to be added to my osgViewer::CompositeViewer to make all of them visible. Thats what caught me out. Is that expected behaviour? The rendering itself is done via the GraphicsContext, and when you assign the GraphicContext to the Camera's the GraphicsContext will keep a pointer to the Camera and use this when rendering a frame to the call the Camera's Renderer on each new frame. This facilities means you can add HUD's etc (the StatsHandler is done this way), but it does mean that such Camera's will just be rendered, updating is the responsibility of the viewer/app. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Avoiding the intersection visitor
Hi,
I want to save some CPU-cycles by ignoring collision-detection on some of my
scene nodes.
Is the following code the best way to do it?
void MyGroup::traverse( osg::NodeVisitor nv)
{
switch( nv.getVisitorType() )
{
case osg::NodeVisitor::NODE_VISITOR:
if( dynamic_castosgUtil::IntersectionVisitor*(nv) )
{
return; // Prohibit visitor from visiting my children
}
... other traverse code ...
}
osg::Group::traverse( nv );
}
The class MyGroup (public of osg::Group) is the parent of all nodes that I do
not want intersection visitors to see.
Viggo
_
Hold kontakten med Windows Live Messenger.
http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Avoiding the intersection visitor
Hi, On Monday 21 July 2008 10:37, Viggo Løvli wrote: I want to save some CPU-cycles by ignoring collision-detection on some of my scene nodes. Is the following code the best way to do it? I use node masks to classify which modes are visible to intersection and which not. GReetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Avoiding the intersection visitor
Hi Mathias, Thanx, your way is much better. :-) Cheers, Viggo From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Date: Mon, 21 Jul 2008 10:43:24 +0200 Subject: Re: [osg-users] Avoiding the intersection visitor Hi, On Monday 21 July 2008 10:37, Viggo Løvli wrote: I want to save some CPU-cycles by ignoring collision-detection on some of my scene nodes. Is the following code the best way to do it? I use node masks to classify which modes are visible to intersection and which not. GReetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Hold kontakten med Windows Live Messenger. http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG2.4 and 2.5.5 Windows static build problems
Christiansen, Brad schrieb: Hi, I have searched the archive but cant find any mention of the problem, though I think can remember reading about a solution some time ago on the list. I have just tried to build the static version of OSG v2.4 and v2.5.5 using ViualStudio .Net 2003. When I do this build I get 5000+ warnings about dulpicate definitions when linking (LNK 4006). I then cannot link my aplication against the resulting .libs. Has anyone else encountered this problem and have a fix / workaround? Are these link-errors related to OpenThreads? A quick and dirty fiy would be: change CMakeLists for all osg-libs/src from IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) to IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ADD_DEFINITIONS(-DOT_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) The underlying problem is: The setting, that you compiled OpenThreads statically is not carried out to a public header or something. If another lib includes a header-file of OpenThreads the compiler thinks, that OpenThreads is linked for dynamic-usage (because OT_LIBARY_STATIC is not defined so the EXPORT-definition for OpenThreads is not setup correctly), so you'll get multiple defined symbols, when you try to link your app with static OpenThreads and static osg, because osg includes OpenThreads-symbols for dynamic-linking. IMHO the definition of OT_LIBARY_STATIC should be carried out to OpenThreads/Config. The same should be done for OSG_LIBRARY_STATIC. On Linux there's no such problem, because you don't have to declare different exports for static versus dynamic linking. I am no expert in CMake, so perhaps somebody may jump in here? cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
I used this code... const int TEX_WIDTH = 512; const int TEX_HEIGHT = 512; osg::ref_ptrosg::Texture2D texture (new osg::Texture2D()); texture-setTextureSize (TEX_WIDTH, TEX_HEIGHT); osg::Image* image = new osg::Image; image-allocateImage(TEX_WIDTH, TEX_HEIGHT, 1, GL_RGBA, GL_UNSIGNED_BYTE); texture-setImage(0, image); osg::ref_ptrosg::Image zim = texture-getImage(); unsigned char* imptr = zim-data(); With OSG 1.0 and was able to readback the image via the pointer imptr. The same code fails with OSG 2.0 and 2.4 I have also used an openGL read with osg 1.0, this also fails with osg 2. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 16 July 2008 14:48 To: OpenSceneGraph Users Subject: Re: [osg-users] Render to Texture *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I'm not sure what is going on but I switched to dumping a png file and still see the banding (see attached)... Are you sure the PNG plugin can handle dumping an RGBA GL_FLOAT image? All I did was add a osgDB::writeImageFile(*_image, somefilename.png) at the end of the GL_FLOAT/RGBA if statement in MyCameraPostDrawCallback::operator() in the osgprerender.cpp example and then ran this example using --image cow.osg. Paul P. - Original Message From: J.P. Delport [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 15, 2008 8:11:14 AM Subject: Re: [osg-users] Render to Texture Hi, make sure the image writer can handle your image format. Bands usually mean an alignment error in the data the writer expects. E.g. expects binary input data to be RGB, but the data is RGBA. .jpg does not support alpha I think. Try .png jp [EMAIL PROTECTED] wrote: I'm attempting to render to a texture and then dump the rendered texture to a file (every frame), but I'm having trouble. I've attempted to use the osgprerender example (using the --image option), and replaced the MyCameraPostDrawCallback::operator() to have a osgDB::writeImageFile(*_image, fileName); where fileName is a .tif file (or .jpg file). When I look at the .tif file using the Linux display program, I get some funny banded image. What am I doing wrong? Is there a more efficient way to get access to the rendered image? Must I allocate an image array to the texture to access the image? Paul P. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] material attributes of an object
Hi i´ve got a problem concerning the material attributes of an illuminated object i want some of them to reflect only the ambient light, but not diffuse i guess i can do it by setting the object diffuse color to zero but i don´t know how to specify the material attributes of an object any ideas??? _ Hazte tu propia televisión a la carta. Música, noticias, estrenos, cine, humor y viajes en MSN Vídeo http://video.msn.com/?mkt=es-es___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgLua
Hello,
I've a problem with osgLua.
Is it always maintained ?
For the moment, I just want to test the osgLua examples :
osg::Group* group = new osg::Group;
osg::Group* root = new osg::Group;
try {
group-addChild(root);
osg::ref_ptrosgLua::Script script = new osgLua::Script();
script-enable(osg);
script-set(root, root);
script-loadFile(/home/julien/workspace/TestLua/src/test.lua);
} catch (osgLua::Exception e) {
std::cout e.what() std::endl;
}
and the test.lua provided with osgLua :
local root2 = osg.Group()
local geode = osg.Geode()
local shape = osg.ShapeDrawable()
shape:setShape( osg.Sphere(osg.Vec3(0,0,0),15) )
geode:addDrawable(shape)
root:addChild(geode)
-- we will now load osgText from the script
osgLua.loadWrapper(osgText)
text = osgText.Text()
text:setCharacterSize(4)
text:setPosition(osg.Vec3(0,0,18))
text:setAxisAlignment(osgText.Text.AxisAlignment.SCREEN)
text:setAlignment(osgText.Text.AlignmentType.CENTER_BASE_LINE)
text:setText(Hi all from osgLua!)
text:setColor(osg.Vec4(0.9,0.8,0.2,1.0))
geode:addDrawable(text)
The result :
/TestLua/src/test.lua:9: [/home/julien/OSG/osgLua/src/osgLua/Value.cpp:260]
ype `PN3osg5GroupE' is declared but not defined
I have liked all the osg and osgLua libraries, I don't understand...
Someone has an idea ? Thank you
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
Hi Gareth, There isn't anyway that we can say exactly what is up give the code extract you have given - its the rest of the setup code and usage code in your app that would tell us this. Render To Texture support in OSG 2.x is far more mature and flexible than that on the OSG 1.x series, and copy to image still works, as does adding your own OpenGL code. My guess is that your code is probably relying upon undocumented behaviour of the OSG 1.x when running single threaded, single context - the behaviour being that the main frame loop has the graphics context current so you can do OpenGL calls directly in it. With OSG 2.x the osgViewer::Viewer is more multi-threaded than the osgProducer::Viewer, even when running single with a context it'll be multi-threaded on multi-core machines, with the graphics being done in its own dedicated thread. This is where you may well be coming unstuck, you reliance on the main loop having the graphics context current just doesn't work, and you most likely are just lucky it's not crashing. Solutions would be, to run the viewer single threaded, or just fix your code so that the OpenGL ops are do in a camera post draw callback. Robert. On Mon, Jul 21, 2008 at 10:41 AM, Roberts, Gareth [EMAIL PROTECTED] wrote: I used this code... const int TEX_WIDTH = 512; const int TEX_HEIGHT = 512; osg::ref_ptrosg::Texture2D texture (new osg::Texture2D()); texture-setTextureSize (TEX_WIDTH, TEX_HEIGHT); osg::Image* image = new osg::Image; image-allocateImage(TEX_WIDTH, TEX_HEIGHT, 1, GL_RGBA, GL_UNSIGNED_BYTE); texture-setImage(0, image); osg::ref_ptrosg::Image zim = texture-getImage(); unsigned char* imptr = zim-data(); With OSG 1.0 and was able to readback the image via the pointer imptr. The same code fails with OSG 2.0 and 2.4 I have also used an openGL read with osg 1.0, this also fails with osg 2. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 16 July 2008 14:48 To: OpenSceneGraph Users Subject: Re: [osg-users] Render to Texture *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I'm not sure what is going on but I switched to dumping a png file and still see the banding (see attached)... Are you sure the PNG plugin can handle dumping an RGBA GL_FLOAT image? All I did was add a osgDB::writeImageFile(*_image, somefilename.png) at the end of the GL_FLOAT/RGBA if statement in MyCameraPostDrawCallback::operator() in the osgprerender.cpp example and then ran this example using --image cow.osg. Paul P. - Original Message From: J.P. Delport [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 15, 2008 8:11:14 AM Subject: Re: [osg-users] Render to Texture Hi, make sure the image writer can handle your image format. Bands usually mean an alignment error in the data the writer expects. E.g. expects binary input data to be RGB, but the data is RGBA. .jpg does not support alpha I think. Try .png jp [EMAIL PROTECTED] wrote: I'm attempting to render to a texture and then dump the rendered texture to a file (every frame), but I'm having trouble. I've attempted to use the osgprerender example (using the --image option), and replaced the MyCameraPostDrawCallback::operator() to have a osgDB::writeImageFile(*_image, fileName); where fileName is a .tif file (or .jpg file). When I look at the .tif file using the Linux display program, I get some funny banded image. What am I doing wrong? Is there a more efficient way to get access to the rendered image? Must I allocate an image array to the texture to access the image? Paul P. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK
Re: [osg-users] Render to Texture
HI WRT your OGL read, I suspect you are doing this in a process with NO OGL context, OSG 2.x is multi-threaded by default unlike 1.x, so you can only do OGL calls in the Draw process with say a draw callback ( see examples and mailing list archive on the subject) Also See the examples in 2.4/5 for render to textures -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roberts, Gareth Sent: Monday, July 21, 2008 5:42 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Render to Texture I used this code... const int TEX_WIDTH = 512; const int TEX_HEIGHT = 512; osg::ref_ptrosg::Texture2D texture (new osg::Texture2D()); texture-setTextureSize (TEX_WIDTH, TEX_HEIGHT); osg::Image* image = new osg::Image; image-allocateImage(TEX_WIDTH, TEX_HEIGHT, 1, GL_RGBA, GL_UNSIGNED_BYTE); texture-setImage(0, image); osg::ref_ptrosg::Image zim = texture-getImage(); unsigned char* imptr = zim-data(); With OSG 1.0 and was able to readback the image via the pointer imptr. The same code fails with OSG 2.0 and 2.4 I have also used an openGL read with osg 1.0, this also fails with osg 2. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 16 July 2008 14:48 To: OpenSceneGraph Users Subject: Re: [osg-users] Render to Texture *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I'm not sure what is going on but I switched to dumping a png file and still see the banding (see attached)... Are you sure the PNG plugin can handle dumping an RGBA GL_FLOAT image? All I did was add a osgDB::writeImageFile(*_image, somefilename.png) at the end of the GL_FLOAT/RGBA if statement in MyCameraPostDrawCallback::operator() in the osgprerender.cpp example and then ran this example using --image cow.osg. Paul P. - Original Message From: J.P. Delport [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 15, 2008 8:11:14 AM Subject: Re: [osg-users] Render to Texture Hi, make sure the image writer can handle your image format. Bands usually mean an alignment error in the data the writer expects. E.g. expects binary input data to be RGB, but the data is RGBA. .jpg does not support alpha I think. Try .png jp [EMAIL PROTECTED] wrote: I'm attempting to render to a texture and then dump the rendered texture to a file (every frame), but I'm having trouble. I've attempted to use the osgprerender example (using the --image option), and replaced the MyCameraPostDrawCallback::operator() to have a osgDB::writeImageFile(*_image, fileName); where fileName is a .tif file (or .jpg file). When I look at the .tif file using the Linux display program, I get some funny banded image. What am I doing wrong? Is there a more efficient way to get access to the rendered image? Must I allocate an image array to the texture to access the image? Paul P. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list
Re: [osg-users] material attributes of an object
Look around and in the examples for osg::Material and osg::StateSets ( The OSG uses Materials just the same as OGL, ) You could apply a material state to a root node of your object Have a root round the Examples and a search of the mail-list archives, there have been some recent discussion on using material _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David _ Sent: Monday, July 21, 2008 6:59 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] material attributes of an object Hi i´ve got a problem concerning the material attributes of an illuminated object i want some of them to reflect only the ambient light, but not diffuse i guess i can do it by setting the object diffuse color to zero but i don´t know how to specify the material attributes of an object any ideas??? _ ¡Atrévete con Abecedario, el juego del momento! Invita a tus contactos de Messenger y demuéstrales lo que sabes demuéstrales lo que http://www.vivelive.com/abecedario sabes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MSVC9 CMake bug in src/CMakeLists.txt ?
I was looking for something else and came across this in src/CMakeLists.txt and it looked a little odd. I thought I would ask the question if this was meant to apply to VS9 as well? If so, MSVC_VERSION should probably be used here. IF(MSVC80) OPTION(OSG_MSVC_GENERATE_PLUGINS_AND_WRAPPERS_MANIFESTS Generate or not manifests files under VS8 for dynamically loaded dlls ON) ENDIF(MSVC80) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC9 CMake bug in src/CMakeLists.txt ?
Hi Philip, I added this option some time ago, and VS9 wasn't still available. So feel free to update it and add VS9. As a side note, is it possible to make a condition like all VS versions superiors to 8 ? On Mon, Jul 21, 2008 at 1:31 PM, Philip Lowman [EMAIL PROTECTED] wrote: I was looking for something else and came across this in src/CMakeLists.txt and it looked a little odd. I thought I would ask the question if this was meant to apply to VS9 as well? If so, MSVC_VERSION should probably be used here. IF(MSVC80) OPTION(OSG_MSVC_GENERATE_PLUGINS_AND_WRAPPERS_MANIFESTS Generate or not manifests files under VS8 for dynamically loaded dlls ON) ENDIF(MSVC80) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC9 CMake bug in src/CMakeLists.txt ?
Erf I did not read your mail carefully, using MSVC_VERSION seems to be the right thing to do yes. On Mon, Jul 21, 2008 at 1:45 PM, Serge Lages [EMAIL PROTECTED] wrote: Hi Philip, I added this option some time ago, and VS9 wasn't still available. So feel free to update it and add VS9. As a side note, is it possible to make a condition like all VS versions superiors to 8 ? On Mon, Jul 21, 2008 at 1:31 PM, Philip Lowman [EMAIL PROTECTED] wrote: I was looking for something else and came across this in src/CMakeLists.txt and it looked a little odd. I thought I would ask the question if this was meant to apply to VS9 as well? If so, MSVC_VERSION should probably be used here. IF(MSVC80) OPTION(OSG_MSVC_GENERATE_PLUGINS_AND_WRAPPERS_MANIFESTS Generate or not manifests files under VS8 for dynamically loaded dlls ON) ENDIF(MSVC80) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG2.4 and 2.5.5 Windows static build problems
On Mon, Jul 21, 2008 at 5:21 AM, Stephan Maximilian Huber [EMAIL PROTECTED] wrote: Christiansen, Brad schrieb: Hi, I have searched the archive but cant find any mention of the problem, though I think can remember reading about a solution some time ago on the list. I have just tried to build the static version of OSG v2.4 and v2.5.5 using ViualStudio .Net 2003. When I do this build I get 5000+ warnings about dulpicate definitions when linking (LNK 4006). I then cannot link my aplication against the resulting .libs. Has anyone else encountered this problem and have a fix / workaround? Are these link-errors related to OpenThreads? A quick and dirty fiy would be: change CMakeLists for all osg-libs/src from IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) to IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ADD_DEFINITIONS(-DOT_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) The underlying problem is: The setting, that you compiled OpenThreads statically is not carried out to a public header or something. If another lib includes a header-file of OpenThreads the compiler thinks, that OpenThreads is linked for dynamic-usage (because OT_LIBARY_STATIC is not defined so the EXPORT-definition for OpenThreads is not setup correctly), so you'll get multiple defined symbols, when you try to link your app with static OpenThreads and static osg, because osg includes OpenThreads-symbols for dynamic-linking. IMHO the definition of OT_LIBARY_STATIC should be carried out to OpenThreads/Config. The same should be done for OSG_LIBRARY_STATIC. On Linux there's no such problem, because you don't have to declare different exports for static versus dynamic linking. I am no expert in CMake, so perhaps somebody may jump in here? You can add OT_LIBRARY_STATIC to OpenThreads/Config but it does rule out the ability to #include the same set of headers and alternate between a static and a shared library version of OpenThreads on MSVC. It's not uncommon to ship a foo.lib and a foo_static.lib or foo_a.lib with a particular library so the user can choose between either. It would be relatively easy to add this to OpenThreads one day if it was desired (also generation of libOpenThreads.a) but it would be impossible to arbitrate between the two on MSVC (without using separate install prefixes) if the selection was done in the OpenThreads/Config header file. I'd say the right thing to do in this case is to push this issue to the user actually linking against the code, in other words the OSG, with the initial fix you suggested. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC9 CMake bug in src/CMakeLists.txt ?
On Mon, Jul 21, 2008 at 7:45 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi Philip, I added this option some time ago, and VS9 wasn't still available. So feel free to update it and add VS9. As a side note, is it possible to make a condition like all VS versions superiors to 8 ? On Mon, Jul 21, 2008 at 1:31 PM, Philip Lowman [EMAIL PROTECTED] wrote: I was looking for something else and came across this in src/CMakeLists.txt and it looked a little odd. I thought I would ask the question if this was meant to apply to VS9 as well? If so, MSVC_VERSION should probably be used here. IF(MSVC80) OPTION(OSG_MSVC_GENERATE_PLUGINS_AND_WRAPPERS_MANIFESTS Generate or not manifests files under VS8 for dynamically loaded dlls ON) ENDIF(MSVC80) I think this might work although I can't test (either if this conditional will work or if manifest generation on MSVC9 will work properly) IF(MSVC_VERSION EQUAL 1400 OR MSVC_VERSION GREATER 1400) # do stuff http://predef.sourceforge.net/precomp.html#sec32 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture
On a similar subject, I'm looking at osgprerendering --image cow.osg example in OSG 2.5.3. My application only requires capturing the rendered (1st pass) (texture/image) and using it on the CPU rather than rendering it again. Therefore, I'm attempting to modify the osgprerender example to not do the second pass rendering, however, when I delete the polyGeom-setVertexArray reference and/or the polyGeom-addPrimitiveSet() calls, my cow becomes black in the image/texture but the rest of the texture has color. Any idea what is going on? Is there a better way to capture the texture/image without the need to render it? Paul P. - Original Message From: Gordon Tomlinson [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, July 21, 2008 7:13:58 AM Subject: Re: [osg-users] Render to Texture HI WRT your OGL read, I suspect you are doing this in a process with NO OGL context, OSG 2.x is multi-threaded by default unlike 1.x, so you can only do OGL calls in the Draw process with say a draw callback ( see examples and mailing list archive on the subject) Also See the examples in 2.4/5 for render to textures -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roberts, Gareth Sent: Monday, July 21, 2008 5:42 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Render to Texture I used this code... const int TEX_WIDTH = 512; const int TEX_HEIGHT = 512; osg::ref_ptrosg::Texture2D texture (new osg::Texture2D()); texture-setTextureSize (TEX_WIDTH, TEX_HEIGHT); osg::Image* image = new osg::Image; image-allocateImage(TEX_WIDTH, TEX_HEIGHT, 1, GL_RGBA, GL_UNSIGNED_BYTE); texture-setImage(0, image); osg::ref_ptrosg::Image zim = texture-getImage(); unsigned char* imptr = zim-data(); With OSG 1.0 and was able to readback the image via the pointer imptr. The same code fails with OSG 2.0 and 2.4 I have also used an openGL read with osg 1.0, this also fails with osg 2. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 16 July 2008 14:48 To: OpenSceneGraph Users Subject: Re: [osg-users] Render to Texture *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I'm not sure what is going on but I switched to dumping a png file and still see the banding (see attached)... Are you sure the PNG plugin can handle dumping an RGBA GL_FLOAT image? All I did was add a osgDB::writeImageFile(*_image, somefilename.png) at the end of the GL_FLOAT/RGBA if statement in MyCameraPostDrawCallback::operator() in the osgprerender.cpp example and then ran this example using --image cow.osg. Paul P. - Original Message From: J.P. Delport [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 15, 2008 8:11:14 AM Subject: Re: [osg-users] Render to Texture Hi, make sure the image writer can handle your image format. Bands usually mean an alignment error in the data the writer expects. E.g. expects binary input data to be RGB, but the data is RGBA. .jpg does not support alpha I think. Try .png jp [EMAIL PROTECTED] wrote: I'm attempting to render to a texture and then dump the rendered texture to a file (every frame), but I'm having trouble. I've attempted to use the osgprerender example (using the --image option), and replaced the MyCameraPostDrawCallback::operator() to have a osgDB::writeImageFile(*_image, fileName); where fileName is a .tif file (or .jpg file). When I look at the .tif file using the Linux display program, I get some funny banded image. What am I doing wrong? Is there a more efficient way to get access to the rendered image? Must I allocate an image array to the texture to access the image? Paul P. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose
Re: [osg-users] osgviewerQT, qt4.4.0 and .osg file
Hi Robert, It works ! For reading and writing .osg. I've done a full osg checkout (version 2.5.5), then I've compiled and tested osg with a modified version of osgviewerQT (only to write .osg file). All works. To be absolutely sure, I've re-compiled and re-executed my osgviewerQT version with osg2.5.0 and once again I have the truncation problem (for reading and writing .osg) Thanks a lot. Johan. Robert Osfield a écrit : Hi Johan, On Fri, Jul 18, 2008 at 12:07 PM, Robert Osfield [EMAIL PROTECTED] wrote: I have now written an osg_atof function and placed this in src/osgDB/Field.cpp, this is now used in the Field::getFloat methods that the .osg plugins uses. This new function always assumes that a '.' is a decimal place. Could you do an svn update and let me know if it works fine. Could you also check the writing to a .osg file as well as loading existing .osg files. The .osg plugin already has code to set the local to classic of the std::stream's used, so in theory it should work OK, but I'd like confirmation before I tick this problem off as being solved. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Johan Nouvel, RD Project Manager http://www.archivideo.com tel : +33 (0)2 99 86 30 20 ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Combining Textures
Hi, I am trying to combine two or more Textures. I read an OSG File in. After that I try to add a new Texture Attribute to my StateSet. E.g. the first Texture is a RGB Texture in the second one has some Alpha values. As result I want to see only the first texture at the texel where texture two the alpha value is set to transparent. Are there any Examples or can someone help me out? Cheers Ming __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Combing Texture
One Additional Information the only thing I see is that texture one is half transparent, but cannot see anything from texture two!! Why!! __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo quad buffering
Gerwin, The setting was not enabled on my graphics card, so that was the problem. Thanks for your help. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerwin de Haan Sent: Friday, July 18, 2008 3:10 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Stereo quad buffering OSG tries to construct an OpenGL context with stereo properties, but cannot find any type of context that has this type of stereo available. This indicates your Quadbuf stereo is not (correctly) enabled in the NVidia driver. Did you enable the quadbuf in the Nvidia control panel, and do other apps run stereo correctly? On Fri, Jul 18, 2008 at 1:20 AM, Hart, Derek [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Hi all, I'm trying to run the osgviewer in a QUAD_BUFFERed stereo mode, but I'm running into problems. As a note, all the other stereo modes work just fine. The following is the output that I'm getting running from the osgShell shortcut: C:\Program Files\OpenSceneGraph\binosgviewer --stereo QUAD_BUFFER cow.osg Error: [Screen #0] GraphicsWindowWin32::setPixelFormat() - No matching pixel for mat found based on traits specified GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows Error: [Screen #0] GraphicsWindowWin32::setPixelFormat() - No matching pixel for mat found based on traits specified GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows This machine has a Quadro FX 4500. I'm running OSG 2.4 from the Windows installers distributed on the OSG website, and I'm running XP. Any hints as to what my problem might be? Thanks, Derek ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Combining Textures
Hi Ming, I wrote something about multitexturing here: http://osghelp.com/articles.php?cat_id=3rowstart=15 good luck, Peter http://osghelp.com On Mon, Jul 21, 2008 at 3:04 PM, ka Ming [EMAIL PROTECTED] wrote: Hi, I am trying to combine two or more Textures. I read an OSG File in. After that I try to add a new Texture Attribute to my StateSet. E.g. the first Texture is a RGB Texture in the second one has some Alpha values. As result I want to see only the first texture at the texel where texture two the alpha value is set to transparent. Are there any Examples or can someone help me out? Cheers Ming -- Gesendet von Yahoo! Mailhttp://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52427/*http://de.overview.mail.yahoo.com. Dem pfiffigeren Posteingang. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sun, moon, clouds. Any recommendations?
Hi all, I've gotta add the sun, moon and some 3D clouds to our simulation. Any recommendations on osg-friendly examples to follow? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiler discomfort on IRIX at OpenFlight plugin
Hi Robert,
Robert Osfield wrote:
[...], my best guess is that you changed:
virtual ~Record() {}
To:
virtual ~Record();
Yes, this is the change I made in 'src/osgPlugins/OpenFlight/Record.h'
at line 64 to make the MIPSPro compiler happy, thus reverting that tiny
part of changeset 7756.
Yet I had to realize that, after finally getting proper binaries, I was
unable to load an OpenFlight sample database that loaded nicely on a
Linux machine where I didn't apply that change - but that's a different
issue.
I'm currently rebuilding this morning's SVN to see if this issue is
still valid. Such a build takes several hours on my Octane (I had the
hope to get my hands onto a dual R14k CPU board right in time, but that
didn't work out), so I'll report when it's done,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sun, moon, clouds. Any recommendations?
Hi Chris , You can have a look at osg Ephemeris for sun , moon and stars at http://www.andesengineering.com/ cheers RJ Dorosky, Christopher G wrote: Hi all, I've gotta add the sun, moon and some 3D clouds to our simulation. Any recommendations on osg-friendly examples to follow? Thanks, Chris ___ 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] Frame delay when using setViewMatrix()
Hi,
I'm writing an OSG application which uses the Viewer class to setup/display
the SceneGraph. I'm manually updating the camera location each frame using
the setViewMatrix() function on my camera, and this seems to be introducing
a 1 frame delay into the loop (which is bad for my application). The first
time I call frame() on camera, the old camera pose is used; the second time
I call frame, it is correct again. I tried calling frame() twice in each
frame, and this solves the problem, but drawing the entire scene twice is
hardly an efficient solution. I have two osg::Image instances attached to
the camera (one reading color and the other reading the depth buffer, which
I need for my application).
I'm using OSG 2.4.0 and Visual C++ Express.
I've been searching online for this problem, but I can't find anything that
looks similar. Here is an example of the problem:
// setup viewer
viewer = new osgViewer::Viewer;
viewer-setUpViewInWindow(100,100,width,height);
viewer-setSceneData(osgModel);
viewer-getCamera()-setClearColor(osg::Vec4(1, 1, 1, 1));
viewer-getCamera()-setRenderOrder(osg::CameraNode::POST_RENDER);
viewer-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
// attach an image to the camera to be rendered each frame
osg::Image osg_image = new osg::Image;
osg_image-allocateImage(width, height, 1, GL_RGBA, GL_UNSIGNED_BYTE);
viewer-getCamera()-attach(osg::Camera::COLOR_BUFFER, osg_image);
// attach a depth image to the camera to be rendered each frame
osg::Image osg_depth = new osg::Image;
osg_depth-allocateImage(width, height, 1, GL_DEPTH_COMPONENT, GL_FLOAT);
viewer-getCamera()-attach(osg::Camera::DEPTH_BUFFER, osg_depth);
Main Loop
{
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-frame();
// here the images are rendered using the old camera pose
viewer-frame();
// here they are correct
}
I've done some research into what the frame() function actually does, and I
divided it into separate functions and found out that renderingTraversals()
is the function that needs to be called twice. For example, this code works
as well:
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-advance();
viewer-eventTraversal();
viewer-updateTraversal();
viewer-renderingTraversals();
// here the images are rendered using the old camera pose
viewer-renderingTraversals();
// here they are correct
}
Thanks in advance!
- David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiler discomfort on IRIX at OpenFlight plugin
Martin Spott wrote:
Robert Osfield wrote:
[...], my best guess is that you changed:
virtual ~Record() {}
To:
virtual ~Record();
Yes, this is the change I made in 'src/osgPlugins/OpenFlight/Record.h'
at line 64 to make the MIPSPro compiler happy, thus reverting that tiny
part of changeset 7756.
Yet I had to realize that, after finally getting proper binaries, I was
unable to load an OpenFlight sample database that loaded nicely on a
Linux machine where I didn't apply that change - but that's a different
issue.
The primary complaint is still valid and the mentioned change is still
required to make MIPSpro happy.
Unfortunately I'm unable to tell why 'osgviewer' now dumps a core when
loading the Peaceful Valley OpenFlight sample set from
'http://3dnature.com/scenesample.html'. Looking at GDB, it seems to me
that the last action is to load 'libosgSim' - I'll see if I get
anywhere further,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Frame delay when using setViewMatrix()
Hi David,
I can't guess what is up with your setup, but if you do things
correctly the viewer-getCamera()-setViewMatrix() will apply to the
next renderingTraversal(). Is there a chance that you have a camera
manipulator attached to your viewer?
Could it be that OpenGL double buffering is confusing you?
Robert.
On Mon, Jul 21, 2008 at 6:34 PM, David Rubel [EMAIL PROTECTED] wrote:
Hi,
I'm writing an OSG application which uses the Viewer class to setup/display
the SceneGraph. I'm manually updating the camera location each frame using
the setViewMatrix() function on my camera, and this seems to be introducing
a 1 frame delay into the loop (which is bad for my application). The first
time I call frame() on camera, the old camera pose is used; the second time
I call frame, it is correct again. I tried calling frame() twice in each
frame, and this solves the problem, but drawing the entire scene twice is
hardly an efficient solution. I have two osg::Image instances attached to
the camera (one reading color and the other reading the depth buffer, which
I need for my application).
I'm using OSG 2.4.0 and Visual C++ Express.
I've been searching online for this problem, but I can't find anything that
looks similar. Here is an example of the problem:
// setup viewer
viewer = new osgViewer::Viewer;
viewer-setUpViewInWindow(100,100,width,height);
viewer-setSceneData(osgModel);
viewer-getCamera()-setClearColor(osg::Vec4(1, 1, 1, 1));
viewer-getCamera()-setRenderOrder(osg::CameraNode::POST_RENDER);
viewer-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
// attach an image to the camera to be rendered each frame
osg::Image osg_image = new osg::Image;
osg_image-allocateImage(width, height, 1, GL_RGBA, GL_UNSIGNED_BYTE);
viewer-getCamera()-attach(osg::Camera::COLOR_BUFFER, osg_image);
// attach a depth image to the camera to be rendered each frame
osg::Image osg_depth = new osg::Image;
osg_depth-allocateImage(width, height, 1, GL_DEPTH_COMPONENT, GL_FLOAT);
viewer-getCamera()-attach(osg::Camera::DEPTH_BUFFER, osg_depth);
Main Loop
{
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-frame();
// here the images are rendered using the old camera pose
viewer-frame();
// here they are correct
}
I've done some research into what the frame() function actually does, and I
divided it into separate functions and found out that renderingTraversals()
is the function that needs to be called twice. For example, this code works
as well:
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-advance();
viewer-eventTraversal();
viewer-updateTraversal();
viewer-renderingTraversals();
// here the images are rendered using the old camera pose
viewer-renderingTraversals();
// here they are correct
}
Thanks in advance!
- David
___
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] Compiler discomfort on IRIX at OpenFlight plugin
HI Martin,
Could you send me the changes you've made to get things to compile,
I'll get these merged with SVN.
I'm downloading the peaceful valley data right now and will test to
see if things run correctly.
BTW, do other datasets work fine?
Robert.
On Mon, Jul 21, 2008 at 6:45 PM, Martin Spott [EMAIL PROTECTED] wrote:
Martin Spott wrote:
Robert Osfield wrote:
[...], my best guess is that you changed:
virtual ~Record() {}
To:
virtual ~Record();
Yes, this is the change I made in 'src/osgPlugins/OpenFlight/Record.h'
at line 64 to make the MIPSPro compiler happy, thus reverting that tiny
part of changeset 7756.
Yet I had to realize that, after finally getting proper binaries, I was
unable to load an OpenFlight sample database that loaded nicely on a
Linux machine where I didn't apply that change - but that's a different
issue.
The primary complaint is still valid and the mentioned change is still
required to make MIPSpro happy.
Unfortunately I'm unable to tell why 'osgviewer' now dumps a core when
loading the Peaceful Valley OpenFlight sample set from
'http://3dnature.com/scenesample.html'. Looking at GDB, it seems to me
that the last action is to load 'libosgSim' - I'll see if I get
anywhere further,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
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] Compiler discomfort on IRIX at OpenFlight plugin
Hi Martin, On Mon, Jul 21, 2008 at 7:33 PM, Robert Osfield [EMAIL PROTECTED] wrote: I'm downloading the peaceful valley data right now and will test to see if things run correctly. I've now tested the PeacefulValley.flt model and it works fine on my 64bit Linux Quad core/Nvidia 7800GT box. I'd suspect the problem you've seen is a build issue. Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Frame delay when using setViewMatrix()
Robert,
Thanks for the quick response. I'm definitely not attaching any
manipulators to the viewer, so I don't think that's the problem; just to be
sure, I set the manipulator to NULL, and it's still rendering one frame
behind.
How would double buffering work with an attached osg::Image? Do I need to
attach two images to separate buffers? Right now I have one set to the
depth buffer and one to the color buffer, and I expect that after calling
renderingTraversal() the rendered scene is available in the image. Is there
something wrong with that logic?
Thanks again,
- David
On Mon, Jul 21, 2008 at 2:30 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi David,
I can't guess what is up with your setup, but if you do things
correctly the viewer-getCamera()-setViewMatrix() will apply to the
next renderingTraversal(). Is there a chance that you have a camera
manipulator attached to your viewer?
Could it be that OpenGL double buffering is confusing you?
Robert.
On Mon, Jul 21, 2008 at 6:34 PM, David Rubel [EMAIL PROTECTED] wrote:
Hi,
I'm writing an OSG application which uses the Viewer class to
setup/display
the SceneGraph. I'm manually updating the camera location each frame
using
the setViewMatrix() function on my camera, and this seems to be
introducing
a 1 frame delay into the loop (which is bad for my application). The
first
time I call frame() on camera, the old camera pose is used; the second
time
I call frame, it is correct again. I tried calling frame() twice in each
frame, and this solves the problem, but drawing the entire scene twice is
hardly an efficient solution. I have two osg::Image instances attached
to
the camera (one reading color and the other reading the depth buffer,
which
I need for my application).
I'm using OSG 2.4.0 and Visual C++ Express.
I've been searching online for this problem, but I can't find anything
that
looks similar. Here is an example of the problem:
// setup viewer
viewer = new osgViewer::Viewer;
viewer-setUpViewInWindow(100,100,width,height);
viewer-setSceneData(osgModel);
viewer-getCamera()-setClearColor(osg::Vec4(1, 1, 1, 1));
viewer-getCamera()-setRenderOrder(osg::CameraNode::POST_RENDER);
viewer-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
// attach an image to the camera to be rendered each frame
osg::Image osg_image = new osg::Image;
osg_image-allocateImage(width, height, 1, GL_RGBA, GL_UNSIGNED_BYTE);
viewer-getCamera()-attach(osg::Camera::COLOR_BUFFER, osg_image);
// attach a depth image to the camera to be rendered each frame
osg::Image osg_depth = new osg::Image;
osg_depth-allocateImage(width, height, 1, GL_DEPTH_COMPONENT, GL_FLOAT);
viewer-getCamera()-attach(osg::Camera::DEPTH_BUFFER, osg_depth);
Main Loop
{
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-frame();
// here the images are rendered using the old camera pose
viewer-frame();
// here they are correct
}
I've done some research into what the frame() function actually does, and
I
divided it into separate functions and found out that
renderingTraversals()
is the function that needs to be called twice. For example, this code
works
as well:
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-advance();
viewer-eventTraversal();
viewer-updateTraversal();
viewer-renderingTraversals();
// here the images are rendered using the old camera pose
viewer-renderingTraversals();
// here they are correct
}
Thanks in advance!
- David
___
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
--
David Rubel
6th Year BS/MS Computer Science Student
Rochester Institute of Technology
[EMAIL PROTECTED]
703.409.3464
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Frame delay when using setViewMatrix()
Hi David,
What makes you say that you've got some kind of view matrix update problem?
What are the images for? You didn't say what they were for or how you
used them, you just jammed the code in their, which given the context
you gave suggested this was just a distraction.
Having to double guess you logic, and what missing code you haven't
told us about, could it be that you are calling renderinTraversals()
and then immediatlely trying to read the Images attached to the
Cameras?
If so... then perhaps you have a threading synchronization issue...
if the osgViewer::Viewer is running with DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then renderingTraversals()
will return before all rendering is complete.
If this is the issue, then you are best to stick to SingleThreaded or
CullDrawThreadPerContext as these threading models don't return before
all rendering is complete.
Robert.
On Mon, Jul 21, 2008 at 7:52 PM, David Rubel [EMAIL PROTECTED] wrote:
Robert,
Thanks for the quick response. I'm definitely not attaching any
manipulators to the viewer, so I don't think that's the problem; just to be
sure, I set the manipulator to NULL, and it's still rendering one frame
behind.
How would double buffering work with an attached osg::Image? Do I need to
attach two images to separate buffers? Right now I have one set to the
depth buffer and one to the color buffer, and I expect that after calling
renderingTraversal() the rendered scene is available in the image. Is there
something wrong with that logic?
Thanks again,
- David
On Mon, Jul 21, 2008 at 2:30 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi David,
I can't guess what is up with your setup, but if you do things
correctly the viewer-getCamera()-setViewMatrix() will apply to the
next renderingTraversal(). Is there a chance that you have a camera
manipulator attached to your viewer?
Could it be that OpenGL double buffering is confusing you?
Robert.
On Mon, Jul 21, 2008 at 6:34 PM, David Rubel [EMAIL PROTECTED] wrote:
Hi,
I'm writing an OSG application which uses the Viewer class to
setup/display
the SceneGraph. I'm manually updating the camera location each frame
using
the setViewMatrix() function on my camera, and this seems to be
introducing
a 1 frame delay into the loop (which is bad for my application). The
first
time I call frame() on camera, the old camera pose is used; the second
time
I call frame, it is correct again. I tried calling frame() twice in
each
frame, and this solves the problem, but drawing the entire scene twice
is
hardly an efficient solution. I have two osg::Image instances attached
to
the camera (one reading color and the other reading the depth buffer,
which
I need for my application).
I'm using OSG 2.4.0 and Visual C++ Express.
I've been searching online for this problem, but I can't find anything
that
looks similar. Here is an example of the problem:
// setup viewer
viewer = new osgViewer::Viewer;
viewer-setUpViewInWindow(100,100,width,height);
viewer-setSceneData(osgModel);
viewer-getCamera()-setClearColor(osg::Vec4(1, 1, 1, 1));
viewer-getCamera()-setRenderOrder(osg::CameraNode::POST_RENDER);
viewer-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
// attach an image to the camera to be rendered each frame
osg::Image osg_image = new osg::Image;
osg_image-allocateImage(width, height, 1, GL_RGBA, GL_UNSIGNED_BYTE);
viewer-getCamera()-attach(osg::Camera::COLOR_BUFFER, osg_image);
// attach a depth image to the camera to be rendered each frame
osg::Image osg_depth = new osg::Image;
osg_depth-allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
GL_FLOAT);
viewer-getCamera()-attach(osg::Camera::DEPTH_BUFFER, osg_depth);
Main Loop
{
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-frame();
// here the images are rendered using the old camera pose
viewer-frame();
// here they are correct
}
I've done some research into what the frame() function actually does,
and I
divided it into separate functions and found out that
renderingTraversals()
is the function that needs to be called twice. For example, this code
works
as well:
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
viewer-getCamera()-setViewMatrix(mat);
// render the scene
viewer-advance();
viewer-eventTraversal();
viewer-updateTraversal();
viewer-renderingTraversals();
// here the images are rendered using the old camera pose
viewer-renderingTraversals();
// here they are correct
}
Thanks in advance!
- David
___
Re: [osg-users] Compiler discomfort on IRIX at OpenFlight plugin
Robert Osfield wrote:
I've pre-empted you sending the files, and had a guess at what you
might have changed - I moved the Record {} body from Record.h into the
Record.cpp. This, what should be a superfluous change, is now checked
in to SVN.
Fine, thanks, I'm now creating a debug-build - I guess it will bb
finished at least when I wake up tomorrow :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Frame delay when using setViewMatrix()
Robert,
I'm trying to access the images immediately after calling
renderingTraversals(), so it looks like threading was my issue. I changed
the threading mode to CullDrawThreadPerContext, and everything works great
(although it's a bit slower).
As for my application, I'm building a model-based tracker for an augmented
reality system. I'm rendering a 3D model of a real world object and
comparing with live camera input, which allows me to estimate the pose of
the camera in real time. I was wrapping the image data from the osg::Images
in IplImages and using OpenCV to do some image processing. While testing, I
removed all of the OpenCV code and was just checking the central pixel
color, to ensure that OpenCV wasn't causing the problem.
Thanks for the help!
- David
On Mon, Jul 21, 2008 at 3:07 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi David,
What makes you say that you've got some kind of view matrix update problem?
What are the images for? You didn't say what they were for or how you
used them, you just jammed the code in their, which given the context
you gave suggested this was just a distraction.
Having to double guess you logic, and what missing code you haven't
told us about, could it be that you are calling renderinTraversals()
and then immediatlely trying to read the Images attached to the
Cameras?
If so... then perhaps you have a threading synchronization issue...
if the osgViewer::Viewer is running with DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then renderingTraversals()
will return before all rendering is complete.
If this is the issue, then you are best to stick to SingleThreaded or
CullDrawThreadPerContext as these threading models don't return before
all rendering is complete.
Robert.
On Mon, Jul 21, 2008 at 7:52 PM, David Rubel [EMAIL PROTECTED] wrote:
Robert,
Thanks for the quick response. I'm definitely not attaching any
manipulators to the viewer, so I don't think that's the problem; just to
be
sure, I set the manipulator to NULL, and it's still rendering one frame
behind.
How would double buffering work with an attached osg::Image? Do I need
to
attach two images to separate buffers? Right now I have one set to the
depth buffer and one to the color buffer, and I expect that after calling
renderingTraversal() the rendered scene is available in the image. Is
there
something wrong with that logic?
Thanks again,
- David
On Mon, Jul 21, 2008 at 2:30 PM, Robert Osfield
[EMAIL PROTECTED]
wrote:
Hi David,
I can't guess what is up with your setup, but if you do things
correctly the viewer-getCamera()-setViewMatrix() will apply to the
next renderingTraversal(). Is there a chance that you have a camera
manipulator attached to your viewer?
Could it be that OpenGL double buffering is confusing you?
Robert.
On Mon, Jul 21, 2008 at 6:34 PM, David Rubel [EMAIL PROTECTED] wrote:
Hi,
I'm writing an OSG application which uses the Viewer class to
setup/display
the SceneGraph. I'm manually updating the camera location each frame
using
the setViewMatrix() function on my camera, and this seems to be
introducing
a 1 frame delay into the loop (which is bad for my application). The
first
time I call frame() on camera, the old camera pose is used; the second
time
I call frame, it is correct again. I tried calling frame() twice in
each
frame, and this solves the problem, but drawing the entire scene twice
is
hardly an efficient solution. I have two osg::Image instances
attached
to
the camera (one reading color and the other reading the depth buffer,
which
I need for my application).
I'm using OSG 2.4.0 and Visual C++ Express.
I've been searching online for this problem, but I can't find anything
that
looks similar. Here is an example of the problem:
// setup viewer
viewer = new osgViewer::Viewer;
viewer-setUpViewInWindow(100,100,width,height);
viewer-setSceneData(osgModel);
viewer-getCamera()-setClearColor(osg::Vec4(1, 1, 1, 1));
viewer-getCamera()-setRenderOrder(osg::CameraNode::POST_RENDER);
viewer-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
// attach an image to the camera to be rendered each frame
osg::Image osg_image = new osg::Image;
osg_image-allocateImage(width, height, 1, GL_RGBA, GL_UNSIGNED_BYTE);
viewer-getCamera()-attach(osg::Camera::COLOR_BUFFER, osg_image);
// attach a depth image to the camera to be rendered each frame
osg::Image osg_depth = new osg::Image;
osg_depth-allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
GL_FLOAT);
viewer-getCamera()-attach(osg::Camera::DEPTH_BUFFER, osg_depth);
Main Loop
{
...
// update camera pose
osg::Matrixd mat = viewer-getCamera()-getViewMatrix();
mat.set(newMatrix.getArray());
Re: [osg-users] Frame delay when using setViewMatrix()
Hi David, For best performance see if you can do all the image process down on the GPU this way there won't be any need for readback. Robert. On Mon, Jul 21, 2008 at 8:50 PM, David Rubel [EMAIL PROTECTED] wrote: Robert, I'm trying to access the images immediately after calling renderingTraversals(), so it looks like threading was my issue. I changed the threading mode to CullDrawThreadPerContext, and everything works great (although it's a bit slower). As for my application, I'm building a model-based tracker for an augmented reality system. I'm rendering a 3D model of a real world object and comparing with live camera input, which allows me to estimate the pose of the camera in real time. I was wrapping the image data from the osg::Images in IplImages and using OpenCV to do some image processing. While testing, I removed all of the OpenCV code and was just checking the central pixel color, to ensure that OpenCV wasn't causing the problem. Thanks for the help! - David On Mon, Jul 21, 2008 at 3:07 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi David, What makes you say that you've got some kind of view matrix update problem? What are the images for? You didn't say what they were for or how you used them, you just jammed the code in their, which given the context you gave suggested this was just a distraction. Having to double guess you logic, and what missing code you haven't told us about, could it be that you are calling renderinTraversals() and then immediatlely trying to read the Images attached to the Cameras? If so... then perhaps you have a threading synchronization issue... if the osgViewer::Viewer is running with DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext then renderingTraversals() will return before all rendering is complete. If this is the issue, then you are best to stick to SingleThreaded or CullDrawThreadPerContext as these threading models don't return before all rendering is complete. Robert. On Mon, Jul 21, 2008 at 7:52 PM, David Rubel [EMAIL PROTECTED] wrote: Robert, Thanks for the quick response. I'm definitely not attaching any manipulators to the viewer, so I don't think that's the problem; just to be sure, I set the manipulator to NULL, and it's still rendering one frame behind. How would double buffering work with an attached osg::Image? Do I need to attach two images to separate buffers? Right now I have one set to the depth buffer and one to the color buffer, and I expect that after calling renderingTraversal() the rendered scene is available in the image. Is there something wrong with that logic? Thanks again, - David On Mon, Jul 21, 2008 at 2:30 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi David, I can't guess what is up with your setup, but if you do things correctly the viewer-getCamera()-setViewMatrix() will apply to the next renderingTraversal(). Is there a chance that you have a camera manipulator attached to your viewer? Could it be that OpenGL double buffering is confusing you? Robert. On Mon, Jul 21, 2008 at 6:34 PM, David Rubel [EMAIL PROTECTED] wrote: Hi, I'm writing an OSG application which uses the Viewer class to setup/display the SceneGraph. I'm manually updating the camera location each frame using the setViewMatrix() function on my camera, and this seems to be introducing a 1 frame delay into the loop (which is bad for my application). The first time I call frame() on camera, the old camera pose is used; the second time I call frame, it is correct again. I tried calling frame() twice in each frame, and this solves the problem, but drawing the entire scene twice is hardly an efficient solution. I have two osg::Image instances attached to the camera (one reading color and the other reading the depth buffer, which I need for my application). I'm using OSG 2.4.0 and Visual C++ Express. I've been searching online for this problem, but I can't find anything that looks similar. Here is an example of the problem: // setup viewer viewer = new osgViewer::Viewer; viewer-setUpViewInWindow(100,100,width,height); viewer-setSceneData(osgModel); viewer-getCamera()-setClearColor(osg::Vec4(1, 1, 1, 1)); viewer-getCamera()-setRenderOrder(osg::CameraNode::POST_RENDER); viewer-getCamera()-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); // attach an image to the camera to be rendered each frame osg::Image osg_image = new osg::Image; osg_image-allocateImage(width, height, 1, GL_RGBA, GL_UNSIGNED_BYTE); viewer-getCamera()-attach(osg::Camera::COLOR_BUFFER, osg_image); // attach a depth image to the camera to be rendered each frame osg::Image osg_depth = new osg::Image; osg_depth-allocateImage(width, height, 1, GL_DEPTH_COMPONENT, GL_FLOAT);
Re: [osg-users] Sun, moon, clouds. Any recommendations?
Hi Chris We used the osgEphemeris project that Don Burns did along with some of our stuff on top There were issues that had to be dealt with but it worked ok ... Certainly better than working from Scratch... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Monday, July 21, 2008 11:06 AM To: OpenSceneGraph Users Subject: [osg-users] Sun, moon, clouds. Any recommendations? Hi all, I've gotta add the sun, moon and some 3D clouds to our simulation. Any recommendations on osg-friendly examples to follow? Thanks, Chris ___ 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] Sun, moon, clouds. Any recommendations?
Hi Chris, You could try SilverLinning: http://www.sundog-soft.com/ Mention of OSG integration too: http://www.sundog-soft.com/docs/html/usage.html Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Help with osgdem
I don't find anything named osgdem* in the current source code, and the make instructions on the page seem to be pertinent to builds prior to the cmake build structure. Is osgdem still available, and if so, is it done as a separate project from OpenSceneGraph? Thanks, Lenny ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help with osgdem
Hi Lenny, osgdem is now part of VirtualPlanetBuilder. http://www.openscenegraph.org/projects/VirtualPlanetBuilder Robert. On Mon, Jul 21, 2008 at 9:35 PM, Smith, Leonard C [EMAIL PROTECTED] wrote: I don't find anything named osgdem* in the current source code, and the make instructions on the page seem to be pertinent to builds prior to the cmake build structure. Is osgdem still available, and if so, is it done as a separate project from OpenSceneGraph? Thanks, Lenny ___ 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] Please test SVN of OpenSceneGraph in prep for 2.5.6 dev release
Hi All, There have been a number of fixes, and new additions to SVN since 2.5.5 so we'll need to get this thoroughly tested out across platforms. The main new addition is an osg::ImageSequence class, and associated osgDB::ImagePager and osgimagestream example. This late work is not yet complete, alas, but API wise is mostly there and close to its final form for 2.6. I should wrap the implementation side up tomorrow morning. FYI, I've pushed the ImageSequence work ahead of 2.6 as hopefully code that'll be using it can get integrated with osgExp, without getting this in now osgExp would have to target a non stable release to be able to integrate the improvements. The osgExp changes aren't mine though, so please don't ask questions and expect answers.. I'll have to defer to those developing the changes to pass them on in time. This extra code does push potential for build breakage, the best we can do is be test on as many plarforms as possible and be quick to fix anything that is amiss. So please, pretty please could you do an svn update on your machines and let me know how you get on. Many thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin problems with Visual Studio 2008
I just recently encountered this same problem. Here's my situation: i had both vs2005 and vs2008 installed and had no problems as Paul mentions. Then I removed vs2005 and after that the osgdb_png plugin could not be loaded. I traced it all the way down to DynamicLibrary.cpp at line 96: #if defined(WIN32) !defined(__CYGWIN__) handle = LoadLibrary( libraryName.c_str() ); It was failing to load it due to compiler incompatibilities. osgdb_png was linking against a libpng and zlib that were built with vs2005. After much effort I recompiled zlib and libpng with vs2008 and replaced the libraries and then rebuilt osgdb_png. Now everything is back to normal. A couple of very strange things I noticed: a) Everything worked before removing vs2005 b) The latest version of libpng seems to be 1.2.29 while the name of the 3rd party dependency is libpng13. The version I compiled came out as libpng12. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Help with HUD.
Hi all, I tried to display two special HUD objects in the OSG HUD example and got stuck. 1. one HUD object follows the rotation of the Viewer's trackball , but not the zooming and panning. 2. the other HUD object follows the panning and rotation of the Viewer's trackball, but not the zooming. Can someone please give me some clues? Thanks. Li _ Keep your kids safer online with Windows Live Family Safety. http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sun, moon, clouds. Any recommendations?
Thanks for the replies. I am investigating both. Has anyone run into osgephemeris drawing 2 moons? The sun and the moon look so similiar, I can't tell, but for either today's date, or one month ago, it renders the sun nicely, with a brightness glow, but I get twin moons, separated by 15 degrees or so. Odd. There were also fixes to bring it up to date with osg 2.4. VS_2005 Should I submit those changes to this forum or somewhere else? Thanks, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dorosky, Christopher G Sent: Monday, July 21, 2008 10:06 AM To: OpenSceneGraph Users Subject: [osg-users] Sun, moon, clouds. Any recommendations? Hi all, I've gotta add the sun, moon and some 3D clouds to our simulation. Any recommendations on osg-friendly examples to follow? Thanks, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiler discomfort on IRIX at OpenFlight plugin
Hi Robert,
Robert Osfield wrote:
I've pre-empted you sending the files, and had a guess at what you
might have changed - I moved the Record {} body from Record.h into the
Record.cpp. This, what should be a superfluous change, is now checked
in to SVN.
Ok, the main difference between my workaround and your fix is, as it
seems, that your fix is technically correct :-)
Tad, I didn't catch your 'ImageSequence' stuff, but the previous
state in SVN compiles properly _and_ I'm now able to load the PV-demo
scenery. Thanks for taking care of this !
I have a little side note concerning CMake's habits on IRIX. Apparently
N32 is the default output format on IRIX for OSG - compiler calls often
look like this one:
/usr/bin/CC -DEFAULT:abi=n32:isa=mips4:proc=r10k [...] -n32
This appears to be pre-defined somewhere in the CMake defaults at
least I guess so - CMake version 2.4-patch 6 working here.
So, I have a $LD_LIBRARYN32_PATH which includes, among other
directories, '/usr/freeware/lib32'. I also have a $LD_LIBRARY64_PATH
which includes '/usr/freeware/lib64' That's entirely fine.
Yet, after running 'cmake' with not a single LD_LIBRARY_PATH-related
option, I always find references to '/usr/freeware/lib64' in the two
'src/osgPlugins/gif/CMakeFiles/osgdb_gif.dir/*link.txt' files, even
though N32 is the default.
This doesn't trouble me, I'm used to run a simple script to fix these
before calling 'make', it would just be nice to have if this would
get handled properly by 'cmake'.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compiler discomfort on IRIX at OpenFlight plugin
Hi Martin, On Tue, Jul 22, 2008 at 12:02 AM, Martin Spott [EMAIL PROTECTED] wrote: Ok, the main difference between my workaround and your fix is, as it seems, that your fix is technically correct :-) Tad, I didn't catch your 'ImageSequence' stuff, but the previous state in SVN compiles properly _and_ I'm now able to load the PV-demo scenery. Thanks for taking care of this ! Thanks for the testing and feedback. Now if you could just test the build of ImageSequence stuff :-) I have a little side note concerning CMake's habits on IRIX. Apparently N32 is the default output format on IRIX for OSG - compiler calls often look like this one: /usr/bin/CC -DEFAULT:abi=n32:isa=mips4:proc=r10k [...] -n32 This appears to be pre-defined somewhere in the CMake defaults at least I guess so - CMake version 2.4-patch 6 working here. So, I have a $LD_LIBRARYN32_PATH which includes, among other directories, '/usr/freeware/lib32'. I also have a $LD_LIBRARY64_PATH which includes '/usr/freeware/lib64' That's entirely fine. Yet, after running 'cmake' with not a single LD_LIBRARY_PATH-related option, I always find references to '/usr/freeware/lib64' in the two 'src/osgPlugins/gif/CMakeFiles/osgdb_gif.dir/*link.txt' files, even though N32 is the default. This doesn't trouble me, I'm used to run a simple script to fix these before calling 'make', it would just be nice to have if this would get handled properly by 'cmake'. Alas I'm no CMake expert, perhaps others on the list can spot an easy way to get things compiling smoothly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] crash in frame(); in the multithreading
Based on your opinion that the crash is *a straight iterator invalidation issue due to your add/removing stuff from the scene graph.* , can you give me some suggestions on fix the bug? the codes was so huge that i can't paste it in mail. Thanks a lot. Xiaodong. On Fri, Jul 18, 2008 at 6:13 PM, Robert Osfield [EMAIL PROTECTED] wrote: 2008/7/18 Wu Xiaodong [EMAIL PROTECTED]: In my case, I added some new child-node to a group-node, then it crashed some times; Could the bug be fixed if i call osg::Group::setDataVariance ( )? Setting DataVariance on the Group will have no effect, it only is critical for StateSet and Drawable. It could be that your crash has nothing to do with threading though, and is a straight iterator invalidation issue due to your add/removing stuff from the scene graph. Since I don't have your code in front of me I can but guess at what the cause might be. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Xiaodong Wu 吴晓东 'Xiao' means the time and the view when the sun rises and 'dong' means the east in Chinese ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] crash in frame(); in the multithreading
I debug my code once more. Your judgment was right. In the single thread, it crashed also. Thanks. Xiaodong 2008/7/22 Wu Xiaodong [EMAIL PROTECTED]: Based on your opinion that the crash is *a straight iterator invalidation issue due to your add/removing stuff from the scene graph.* , can you give me some suggestions on fix the bug? the codes was so huge that i can't paste it in mail. Thanks a lot. Xiaodong. On Fri, Jul 18, 2008 at 6:13 PM, Robert Osfield [EMAIL PROTECTED] wrote: 2008/7/18 Wu Xiaodong [EMAIL PROTECTED]: In my case, I added some new child-node to a group-node, then it crashed some times; Could the bug be fixed if i call osg::Group::setDataVariance ( )? Setting DataVariance on the Group will have no effect, it only is critical for StateSet and Drawable. It could be that your crash has nothing to do with threading though, and is a straight iterator invalidation issue due to your add/removing stuff from the scene graph. Since I don't have your code in front of me I can but guess at what the cause might be. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Xiaodong Wu 吴晓东 'Xiao' means the time and the view when the sun rises and 'dong' means the east in Chinese -- Xiaodong Wu 吴晓东 'Xiao' means the time and the view when the sun rises and 'dong' means the east in Chinese ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG2.4 and 2.5.5 Windows static build problems
Hi, Thanks for the suggestions. I made the changes you recomened but it seems to have had no effect on my problems. When I tried rebuilding after the change I got the following results: OpenThreads, Builds fine. osg, Builds fine. osgUtil: 60 warnings about duplicate symbols from OpenThreads osgText (which built osgDB first): 2126 warnings about duplicate symbols from both OpenThreads and osg. Some examples: osg35-osg.lib(VertexProgram.obj) : warning LNK4006: public: static void __cdecl osg::VertexProgram::discardDeletedVertexProgramObjects(unsigned int) ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]) already defined in osg35-osgDB.lib(VertexProgram.obj); second definition ignored osg35-osg.lib(WIN32Condition.obj) : warning LNK4006: public: virtual int __thiscall OpenThreads::Condition::wait(class OpenThreads::Mutex *,unsigned long) ([EMAIL PROTECTED]@OpenThreads@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) already defined in osg35-osgDB.lib(WIN32Condition.obj); second definition ignored The drails of what I did are: I modified the files as suggested (in 16 files, I am not building any plugins / applications or the wrappers). I reconfigured the static project using cmake. I checked the preprocessor definintions in Visual Studios. Osg, osgUtil, osgDB and osgText all had OSG_LIBRARY_STATIC OT_LIBRARY_STATIC defined. Any further suggestions would be very welcome. Cheers, Brad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephan Maximilian Huber Sent: Monday, 21 July 2008 5:21 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG2.4 and 2.5.5 Windows static build problems Christiansen, Brad schrieb: Hi, I have searched the archive but cant find any mention of the problem, though I think can remember reading about a solution some time ago on the list. I have just tried to build the static version of OSG v2.4 and v2.5.5 using ViualStudio .Net 2003. When I do this build I get 5000+ warnings about dulpicate definitions when linking (LNK 4006). I then cannot link my aplication against the resulting .libs. Has anyone else encountered this problem and have a fix / workaround? Are these link-errors related to OpenThreads? A quick and dirty fiy would be: change CMakeLists for all osg-libs/src from IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) to IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ADD_DEFINITIONS(-DOT_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) The underlying problem is: The setting, that you compiled OpenThreads statically is not carried out to a public header or something. If another lib includes a header-file of OpenThreads the compiler thinks, that OpenThreads is linked for dynamic-usage (because OT_LIBARY_STATIC is not defined so the EXPORT-definition for OpenThreads is not setup correctly), so you'll get multiple defined symbols, when you try to link your app with static OpenThreads and static osg, because osg includes OpenThreads-symbols for dynamic-linking. IMHO the definition of OT_LIBARY_STATIC should be carried out to OpenThreads/Config. The same should be done for OSG_LIBRARY_STATIC. On Linux there's no such problem, because you don't have to declare different exports for static versus dynamic linking. I am no expert in CMake, so perhaps somebody may jump in here? cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users
