Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Hi Eric, some info in this recent thread too. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/68096/ jp On 26/05/11 18:14, Eric Sokolowsky wrote: Robert Osfield wrote: Hi Eric, On Thu, May 26, 2011 at 4:21 PM, Eric Sokolowsky esok@gmail.com wrote: Yes, this is what I mean. X11 itself crashes and restarts. One of the weird issues is that this happens only for OSG trunk, not for OSG 2.8 svn, on the same machine. Perhaps there is some OpenGL3+ weirdness going on here. I doubt it has anything to do with GL3 as the svn/trunk doesn't do anything special for GL3 unless you compile the OSG specifically for the GL3 subset. Ok, thanks for the info. There have been a few changes to GraphisWindowX11.cpp since 2.8.x so you revert these to see if one of the changesets is the culprit. It could be just a co-incidence though, sometimes threading problems can appear and disappear just with slight changes in timing. I'm afraid I'll have to leave it to you to try out different versions of GraphicsWindowX11.cpp as I can't reproduce the problem at my end so have no way of know which changes might be introducing problems. Well I'm making some progress. After updating my nvidia driver X11 no longer crashes, but osgviewer still does. I'm going to try this on another mac machine also running Fedora 14. Anyone else using Fedora 14 out there? I'll try messing with GraphicsWindowX11.cpp next. Eric ___ 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO incosistencies between 2.8 and 2.912
Excellent news I will the svn right away. On a side note, what is the best way in your opinion to update changing vbo geometry say for a morpher. In my code I do a array swap, but is there a faster way? Thank you for spending time hunting down this bug Dimi - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thu, May 26, 2011 6:50:51 PM Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 Hi Dimi, I have tracked down the problem to the GLBufferObject::compileBuffer() which was not downloading all the BufferData entries when it resized the gl buffer obejct. I also fixed the BufferObject so that when new a BufferData enty is added to it automatically dirties the GLBufferObjects assigned to it. With these change one doesn't dirty of the array when you swap the vertex array, one simple calls setVertexArray() and the OSG does the rest for you. These fixes are now checked into svn/trunk. 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
Re: [osg-users] VBO incosistencies between 2.8 and 2.912
HI Dimi, On Fri, May 27, 2011 at 8:21 AM, dimi christop dimi_chris...@yahoo.com wrote: Excellent news I will the svn right away. On a side note, what is the best way in your opinion to update changing vbo geometry say for a morpher. In my code I do a array swap, but is there a faster way? It all depends upon how you are modifying the geometry data. The most efficient way is to not modify the vertex data at all and do all the computation on the GPU. Downloading two static vertex arrays (use a vertex attrib array) and then morphing between on the GPU is an pretty effective scheme. Swapping arrays like you did is pretty efficient as well, but only call dirty on the data if you have actually modified it though, as the OSG will be able to just do a pointer swap if you just assign a new array, and OpenGL will just happily use the different pointers without any performance cost. Copying the data will have if you are dynamically updating the data on the CPU and can't offload this to the GPU. If you are copying data every frame then using VBO's won't be as valuable, you'll need to performance test using staight vertex arrays vs VBOs. Thank you for spending time hunting down this bug I have to put my hands up and admit that the regression was done to me, It's good nail regressions so I'm glad that you were able to reproduce the problem. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
Hi,
what is the usage of the script? I guess it is not run from Blender,
because of the commented out line importing the osggui module.
I have tried to do the same as the 2.4x exporter from the command line,
${blender_exec} -b ${model} -P ${path_to_osgexport.py} --osg=filename=name.osg
but it seems the script gets its arguments duplicated, and later I get
some errors that could be related to this issue.
Thanks,
--
Alberto
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vrml plugin for 2.9.14
Hi Keith,
Could you please post the changes you've made as a full modified file
to osg-submissions.
Thanks,
Robert.
On Tue, May 17, 2011 at 8:17 PM, Keith Parkins
kpark...@cs.rochester.edu wrote:
Hi all,
I was playing around with the dev release 2.9.14 on Windows (not the
latest svn) and had to play around with some build files to get it to
compile. I'm no guru on cmake by any stretch, but to compile the plugin I
had to edit one of the cmake files. First though, I downloaded openvrml
0.17.12 and used my existing boost build (1.44.0 the plugin readme says
to use an older version of boost, but I think this version works too). I
noticed that cmake wanted to find openvrml _antlr and _regex libraries,
but both are no longer used in openvrml. I commented out the following
lines in src/osgPlugins/vrml/CMakeLists.txt:
# FIND_LIBRARY(OPENVRML_ANTLR_LIBRARY
# NAMES antlr.lib
# PATHS $ENV{OPENVRML_DIR}/lib)
# FIND_LIBRARY(OPENVRML_ANTLR_LIBRARY_DEBUG
# NAMES antlrd.lib
# PATHS $ENV{OPENVRML_DIR}/lib)
# FIND_LIBRARY(OPENVRML_REGEX_LIBRARY
# NAMES regex.lib
# PATHS $ENV{OPENVRML_DIR}/lib)
# FIND_LIBRARY(OPENVRML_REGEX_LIBRARY_DEBUG
# NAMES regexd.lib
# PATHS $ENV{OPENVRML_DIR}/lib)
and
SET(TARGET_LIBRARIES_VARS
# OPENVRML_ANTLR_LIBRARY
# OPENVRML_REGEX_LIBRARY
OPENVRML_LIBRARY
JPEG_LIBRARY
PNG_LIBRARY
ZLIB_LIBRARY)
Then I was able to run cmake without a problem.
The last thing I had to do was to set one of the use/build macros
defined in the openvrml library file openvrml-config.h. You need
to choose either OPENVRML_USE_DLL or OPENVRML_USE_LIB depending on
whether you are linking to dynamic or static libs. In VisualStudio, you
just open up the properties window, find the Preprocessor menu under
Configuration Properties-C/C++. Then click Preprocessor Definitions
and add eitherOPENVRML_USE_DLL or OPENVRML_USE_LIB.
I didn't notice any mention of this in the osg-users list, so I thought
I'd send this out in case anyone else had this problem. If there is a
cleaner solution that I missed, please do correct me.
Thanks,
-K
Keith Parkins U of R Center for Visual Science
___
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] A small spelling problem in the cmake scripts
Hi Robert, As OSG is on its way to the 3.0 release, I'd like to report a very small bug... in fact it's a spelling bug, I think: In Find3rdPartyDependencies.cmake, there is a ACTUAL_3DPARTY_DIR option for Windows users to specify the root directory of third party libraries. But I think it should be ACTUAL_3RDPARTY_DIR (3rd, not 3d), isn't it? If so, to repair this we may have to face some other compatibility problems (especially to Windows users who already set up this option). So what do you think of the solution? Or we could just leave it alone? Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A small spelling problem in the cmake scripts
Hi Rui, I haven't looked at the problem .cmake file yet I would suggest retaining the old ACTUAL_3DPARTY_DIR one for backwards compatibility and just add the correctly spelled one and make sure the docs just refer the to correctly spelled one. Robert. On Fri, May 27, 2011 at 11:21 AM, Wang Rui wangra...@gmail.com wrote: Hi Robert, As OSG is on its way to the 3.0 release, I'd like to report a very small bug... in fact it's a spelling bug, I think: In Find3rdPartyDependencies.cmake, there is a ACTUAL_3DPARTY_DIR option for Windows users to specify the root directory of third party libraries. But I think it should be ACTUAL_3RDPARTY_DIR (3rd, not 3d), isn't it? If so, to repair this we may have to face some other compatibility problems (especially to Windows users who already set up this option). So what do you think of the solution? Or we could just leave it alone? Cheers, Wang Rui ___ 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] Trackball manipulator start position
Hi, I'm trying to modify simple application osgViewer. I want to set the initial position of the camera (trackball manipulator). How? I try to set it with setByMatrix, setByInverseMatrix but nothing. can you explain me? thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39836#39836 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trackball manipulator start position
Hi Daniele, Try setHomePosition(..). Robert. On Fri, May 27, 2011 at 11:56 AM, daniele argiolas arj...@gmail.com wrote: Hi, I'm trying to modify simple application osgViewer. I want to set the initial position of the camera (trackball manipulator). How? I try to set it with setByMatrix, setByInverseMatrix but nothing. can you explain me? thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39836#39836 ___ 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] Trackball manipulator start position
ok!!! thank you very much! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39841#39841 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi, Will this issue likely be addressed in the near future? I guess only somebody relatively experienced with the OSG code base can dig into this. I can test the code quite extensively as I have routines that process a lot of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there is no minor leak with that release either. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39844#39844 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Fred, On Fri, May 27, 2011 at 1:12 PM, Fred Smith osgfo...@tevs.eu wrote: Will this issue likely be addressed in the near future? I guess only somebody relatively experienced with the OSG code base can dig into this. I can test the code quite extensively as I have routines that process a lot of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there is no minor leak with that release either. I really don't know what is amiss and your modified version osggeometry.cpp I find just plain confusing. I can't start testing something that I don't under is supposed to do in the first and why. What you've provide as a test case just doens't make sense to me, I can't work why you'd do what you are trying to do in this way. I can't dive in on topic that I have no grasp of. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
J.P. Delport wrote: Hi Eric, some info in this recent thread too. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/68096/ jp Thanks for the pointer. I must have skipped over that thread. The problem described there looks like what is happening to me (I'm glad I'm not the only one!) Following Robert's suggestion to look into changes made to GraphicsWindowX11.cpp, I reverted back to r12292 and everything seems to work reliably, and now I'm working forward. There were a pretty major couple of changes r12293 and r12294 and that's what I suspect caused the problem. The only other change to this file after then was r12339. I saw the discussion of making the viewer single-threaded, which of course is not a long-term solution. Did anyone find anything in their digging? Eric On 26/05/11 18:14, Eric Sokolowsky wrote: Robert Osfield wrote: Hi Eric, On Thu, May 26, 2011 at 4:21 PM, Eric Sokolowsky esok@gmail.com wrote: Yes, this is what I mean. X11 itself crashes and restarts. One of the weird issues is that this happens only for OSG trunk, not for OSG 2.8 svn, on the same machine. Perhaps there is some OpenGL3+ weirdness going on here. I doubt it has anything to do with GL3 as the svn/trunk doesn't do anything special for GL3 unless you compile the OSG specifically for the GL3 subset. Ok, thanks for the info. There have been a few changes to GraphisWindowX11.cpp since 2.8.x so you revert these to see if one of the changesets is the culprit. It could be just a co-incidence though, sometimes threading problems can appear and disappear just with slight changes in timing. I'm afraid I'll have to leave it to you to try out different versions of GraphicsWindowX11.cpp as I can't reproduce the problem at my end so have no way of know which changes might be introducing problems. Well I'm making some progress. After updating my nvidia driver X11 no longer crashes, but osgviewer still does. I'm going to try this on another mac machine also running Fedora 14. Anyone else using Fedora 14 out there? I'll try messing with GraphicsWindowX11.cpp next. Eric ___ 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] FrameBufferObject problems on OSG 2.9.11
robertosfield wrote: Hi Fred, Please try the latest updates to svn/trunk, it may or may not address the issues you have seen. If it doesn't please put together a small example that reproduces the problem. Robert. robertosfield wrote: Hi Fred, On Fri, May 27, 2011 at 1:12 PM, Fred Smith wrote: Will this issue likely be addressed in the near future? I guess only somebody relatively experienced with the OSG code base can dig into this. I can test the code quite extensively as I have routines that process a lot of data. Right now I'm stuck with release 2.9.10. Not absolutely sure there is no minor leak with that release either. I really don't know what is amiss and your modified version osggeometry.cpp I find just plain confusing. I can't start testing something that I don't under is supposed to do in the first and why. What you've provide as a test case just doens't make sense to me, I can't work why you'd do what you are trying to do in this way. I can't dive in on topic that I have no grasp of. Run the modified osggeometry.cpp sample and look at the memory usage. There is, apparently, a big memory leak. Increase the number of times testRTTCamera() is called and you should see the leak even better. As to why I'm doing what I'm doing, this is to do RTT. I need to do offscreen rendering at some point in my application, and for this purpose I'm adding a slave camera to my existing viewer, then do my RTT rendering, then dispose of the aforementionned camera. It's either that, or I use a separate viewer and do the RTT rendering from there. In both cases I have a memory leak. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39848#39848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Fred, On Fri, May 27, 2011 at 2:22 PM, Fred Smith osgfo...@tevs.eu wrote: Run the modified osggeometry.cpp sample and look at the memory usage. There is, apparently, a big memory leak. Increase the number of times testRTTCamera() is called and you should see the leak even better. The modified example is *mess*. I wouldn't know if it was a memory leak due to the messy code or an actual bug in the OSG. As to why I'm doing what I'm doing, this is to do RTT. I need to do offscreen rendering at some point in my application, and for this purpose I'm adding a slave camera to my existing viewer, then do my RTT rendering, then dispose of the aforementionned camera. It's either that, or I use a separate viewer and do the RTT rendering from there. In both cases I have a memory leak. Off screen rendering is nothing unusual, but convoluteed means of doing it aren't. Please think about isolating one problem at a time and providing a clean code example, telling me just to run an example that I have already reviewed and decided it's too convulteed to know what going is of no help to me. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Here's some more information about the problem. I have narrowed it down to the patch r12294. Before this change I cannot get osgviewer to fail, but after this patch it is very easy to get osgviewer to fail. Something there caused the timing instability we are seeing. I'm going to investigate further but if there are others who want to look at it too you are welcome. Eric J.P. Delport wrote: Hi Eric, some info in this recent thread too. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/68096/ jp On 26/05/11 18:14, Eric Sokolowsky wrote: Robert Osfield wrote: Hi Eric, On Thu, May 26, 2011 at 4:21 PM, Eric Sokolowsky esok@gmail.com wrote: Yes, this is what I mean. X11 itself crashes and restarts. One of the weird issues is that this happens only for OSG trunk, not for OSG 2.8 svn, on the same machine. Perhaps there is some OpenGL3+ weirdness going on here. I doubt it has anything to do with GL3 as the svn/trunk doesn't do anything special for GL3 unless you compile the OSG specifically for the GL3 subset. Ok, thanks for the info. There have been a few changes to GraphisWindowX11.cpp since 2.8.x so you revert these to see if one of the changesets is the culprit. It could be just a co-incidence though, sometimes threading problems can appear and disappear just with slight changes in timing. I'm afraid I'll have to leave it to you to try out different versions of GraphicsWindowX11.cpp as I can't reproduce the problem at my end so have no way of know which changes might be introducing problems. Well I'm making some progress. After updating my nvidia driver X11 no longer crashes, but osgviewer still does. I'm going to try this on another mac machine also running Fedora 14. Anyone else using Fedora 14 out there? I'll try messing with GraphicsWindowX11.cpp next. Eric ___ 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] OSG trunk crashing, perhaps an nvidia driver problem?
Hi Eric, On Fri, May 27, 2011 at 2:29 PM, Eric Sokolowsky esok@gmail.com wrote: Here's some more information about the problem. I have narrowed it down to the patch r12294. Before this change I cannot get osgviewer to fail, but after this patch it is very easy to get osgviewer to fail. Something there caused the timing instability we are seeing. I'm going to investigate further but if there are others who want to look at it too you are welcome. Thanks to narrowing it down. For those interested in look up the changeset that looks to introduced the problems you can see it up on the openscenegraph.org: http://www.openscenegraph.org/projects/osg/changeset/12294/OpenSceneGraph/trunk/src/osgViewer/GraphicsWindowX11.cpp A quick review of the code doesn't raise any obvious causes. I suspect the problems you are seeing are the same as those discusssed on the thread [build] 2.9.14 and trunk problems on lubuntu 11.04+lxde+nvidia. I will run the tests suggest by J.P in this thread to see if I can reliably reproduce the problem and then see about backing out to before r12294 and if this fixes things then I'll revert r12294. I would like to tag a 2.9.15 dev release today so would like to things working for it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Hi On 27/05/11 15:07, Eric Sokolowsky wrote: J.P. Delport wrote: Hi Eric, some info in this recent thread too. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/68096/ jp Thanks for the pointer. I must have skipped over that thread. The problem described there looks like what is happening to me (I'm glad I'm not the only one!) Following Robert's suggestion to look into changes made to GraphicsWindowX11.cpp, I reverted back to r12292 and everything seems to work reliably, and now I'm working forward. There were a pretty major couple of changes r12293 and r12294 and that's what I suspect caused the problem. The only other change to this file after then was r12339. I saw the discussion of making the viewer single-threaded, which of course is not a long-term solution. Did anyone find anything in their digging? sorry, I've not had any chance to look at it again. I think you've come closest to getting to the actual commits that causes this. jp -- 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. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Hi All, I'm just doing a code review from before and after the r12294 rev and it looks like the move of the code from a method being called in the graphics thread GraphicsWindowX11::swapBufferImplentation() to on being called from the main thread GraphcisWindowX11::checkEvents() without the display being changed from the one used for the graphics thread to the one used for events. If I am correct then it should be a simple fix of just replacing the _display variable usage to the local display variable. I will test in the svn/trunk configuration and then with my suggested change. Will update you all soon on how I get on. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
Hi Alberto, The script is for using within blender. Copy the files from the blenderExporter directory to your blender scripts folder. I'm on linux so my folder is at: ~/.blender/2.57/scripts/addons/ Then when you open blender you will need to enable the script. * Open the User Preferences window (Ctrl + Alt + U) * Click on the Addons tab * Type osg in the search box * Check the checkbox next to the Import-Export: Export OSG format (.osg) entry to enable the plugin. * Click Save as default to save the changes permanently. Now the File - Export menu will have an additional entry - OSG Model (.osg) which will run the script. Hope this helps - Damyon -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39854#39854 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSGExp and Max 2012
Hi all,
I just installed Max 2012 (and the SDK) 64-bit, and am trying to compile
OSGExp, but when it tries to link OSGHelper I'm getting this linker error:
1OSGHelper.cpp.obj : error LNK2001: unresolved external symbol public:
virtual void __cdecl ReferenceMaker::SetReference(int,class
ReferenceTarget *)
(?SetReference@ReferenceMaker@@UEAAXHPEAVReferenceTarget@@@Z)
It's linking to:
${MAXSDK_LIB_DIR}/bmm.lib
${MAXSDK_LIB_DIR}/core.lib
${MAXSDK_LIB_DIR}/geom.lib
${MAXSDK_LIB_DIR}/gfx.lib
${MAXSDK_LIB_DIR}/mesh.lib
${MAXSDK_LIB_DIR}/maxutil.lib
${MAXSDK_LIB_DIR}/maxscrpt.lib
${MAXSDK_LIB_DIR}/manipsys.lib
${MAXSDK_LIB_DIR}/paramblk2.lib
and I had Max 2011 before and it was working fine, so I'm not sure where
this problem comes from. Has anything changed recently that could affect
this?
Thanks in advance,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Attached is a cleaned up, less messy version of the repro.
testRTTCamera() shows off the leak with offscreen rendering using a slave camera
testLeak() shows off the GraphicsContext leak.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39855#39855
/* OpenSceneGraph example, osggeometry.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osg/Math
#include iostream
// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent. This demo uses the OpenGL red book diagram of different
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives. The OpenSceneGraph
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls. Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!
// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene. osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen.
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().
struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};
// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;
osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
std::coutstd::endl;
}
osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();
// following are separate blocks for creating POINTS, LINES, LINE_STRIP, LINE_LOOP, POLYGON, QUADS,
// QUAD_STRIP, TRIANGLES, TRIANGLE_STRIP and TRIANGLE_FAN primitives. An image of these primitives
// is provided in the distribution: OpenSceneGraph-Data/Images/primitives.gif.
// create POINTS
{
// create Geometry object to store all the vertices and points primitive.
osg::Geometry* pointsGeom = new osg::Geometry();
// create a Vec3Array and add to it all my coordinates.
// Like all the *Array variants (see include/osg/Array) , Vec3Array is derived from both osg::Array
// and std::vector. osg::Array's are reference counted and hence sharable,
// which std::vector provides all the convenience, flexibility and robustness
// of the most popular of all STL containers.
osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(-1.02168, -2.15188e-09, 0.885735));
vertices-push_back(osg::Vec3(-0.976368, -2.15188e-09, 0.832179));
vertices-push_back(osg::Vec3(-0.873376, 9.18133e-09, 0.832179));
vertices-push_back(osg::Vec3(-0.836299, -2.15188e-09, 0.885735));
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
this FBO issue will influence on QuadBuffer rendering?I got some quad buffer problem... ... Thank you! Cheers, Nan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39857#39857 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.5 wrappers and osgconv
Thanks! This is in r12464 on the 2.8 branch. -Paul On 5/26/2011 4:41 PM, Ryan Pavlik wrote: On Wed, May 25, 2011 at 6:15 PM, Ryan Pavlik rpav...@iastate.edu mailto:rpav...@iastate.edu wrote: On Tue, May 24, 2011 at 1:46 PM, Paul Martz pma...@skew-matrix.com mailto:pma...@skew-matrix.com wrote: Hi Ryan -- I just wanted to alert you that the 2.8 branch now contains some changes that will likely break the wrappers: Texture2DMultisample support (you'll probably need to add support for this new StateAttribute) and some changes to osgText. If you could provide updated wrappers, that would be great. Thanks! Also, you mentioned some additional changes to osgconv. I'm still waiting on those. The only other work to be done is the 3ds backport, and I understand that's in progress, so hopefully done soon. We're vary close to a release candidate. I've updated the wrappers, and am running a test build overnight. Will get those to you soon. Ryan OK, I've attached the updated wrappers for the 2.8 branch. I've test built these on Linux 64-bit, and they do all successfully load at runtime. Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu mailto:rpav...@iastate.edu http://academic.cleardefinition.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Robert Osfield wrote: Hi All, I'm just doing a code review from before and after the r12294 rev and it looks like the move of the code from a method being called in the graphics thread GraphicsWindowX11::swapBufferImplentation() to on being called from the main thread GraphcisWindowX11::checkEvents() without the display being changed from the one used for the graphics thread to the one used for events. If I am correct then it should be a simple fix of just replacing the _display variable usage to the local display variable. I will test in the svn/trunk configuration and then with my suggested change. Will update you all soon on how I get on. I think this is getting close to the problem. I have further narrowed the problem to the last section of differences in GraphicsWindowX11.cpp between r12293 and r12294 (I applied all the other parts of the difference and there is no problem). If I comment out the second while( XPending(_display) ) loop (see around line 1467) there is no crash. Is the _display variable changed in the first loop? I also tried putting a sleep(1) call just above line 1467 the first time the function is run and now I can not get it to crash, further suggesting a race condition that the loop is triggering. Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 2.8.5 Call for testing
Hi all -- I've just tagged 2.8.5 RC1 and would like to request your help in testing. You can check out the release candidate from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5-rc1 All features are in place at this time, with the one exception of the 3DS plugin backport. Assuming that work is complete soon, and there is sufficient testing, we should be able to release in the very near future. Features in 2.8.5: * Uniform performance enhancement. r11952, Michael Plating's performance enhancement for large numbers of uniforms, which effectively eliminates the std::mapstd::string lookup. r11998, Wojciech Lewandowski's backwards compatibility fix for 11952. r12074, Chris Hanson's backwards compatibility fix for 11952. * Support for Texture2DMultisample r11218, changes to Extensions. r11229, fix warnings. r11365, 2D multisample support. * Added new OutputRelativeTextures dot OSG plugin export option (not on trunk). * Enhancements for OcclusionQueryNode. r11760 (plus r11472 for OQN.cpp only). Support for RTT Camera (not on trunk). * osgconv --use-world-frame option. * NOTIFY_WARN (and friends) macros to ease backporting. OSG_NOTIFY_DISABLED CMake variable. * FLT plugin update. A complete backport of the trunk FLT plugin (as if May 4 2010) to the 2.8 branch. Includes export fixes for multitexture. Includes osgSim MultiSwitch changes in r11971. * PNM plugin enhancements: r12220, adds support for reading and writing images using streams. Bug fixes for reading 8-bit and 16-bit images, including loading the images upside-down. * Fix issue with linking apps to libdl on Linux systems. * osgText fix (r11768) to improve text appearance. * Updated osgWrappers for all API changes. * Bump version# 2.8.5, SO# 74. Thanks for your help! -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
On Fri, 2011-05-27 at 10:41 -0400, Eric Sokolowsky wrote: Robert Osfield wrote: Hi All, I'm just doing a code review from before and after the r12294 rev and it looks like the move of the code from a method being called in the graphics thread GraphicsWindowX11::swapBufferImplentation() to on being called from the main thread GraphcisWindowX11::checkEvents() without the display being changed from the one used for the graphics thread to the one used for events. If I am correct then it should be a simple fix of just replacing the _display variable usage to the local display variable. I will test in the svn/trunk configuration and then with my suggested change. Will update you all soon on how I get on. Just to chime in, I'm also experiencing this problem. Fedora 14-64, NVidia 270 driver. I think this is getting close to the problem. I have further narrowed the problem to the last section of differences in GraphicsWindowX11.cpp between r12293 and r12294 (I applied all the other parts of the difference and there is no problem). If I comment out the second while( XPending(_display) ) loop (see around line 1467) there is no crash. Is the _display variable changed in the first loop? I also tried putting a sleep(1) call just above line 1467 the first time the function is run and now I can not get it to crash, further suggesting a race condition that the loop is triggering. Eric ___ 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] osgexport for blender?
Damyon,
Damyon Wiese writes:
Hi Alberto,
The script is for using within blender. Copy the files from the
blenderExporter directory to your blender scripts folder. I'm on linux so my
folder is at:
~/.blender/2.57/scripts/addons/
Then when you open blender you will need to enable the script.
* Open the User Preferences window (Ctrl + Alt + U)
* Click on the Addons tab
* Type osg in the search box
* Check the checkbox next to the Import-Export: Export OSG format (.osg)
entry to enable the plugin.
* Click Save as default to save the changes permanently.
Now the File - Export menu will have an additional entry - OSG Model
(.osg) which will run the script.
Hope this helps - Damyon
Indeed it does, thank you very much. I'm such a newbie when dealing with
these new 2.5x series. I could export some meshes at will. I had only
problems when exporting a MakeHuman skeleton. I attach the log in case
you are interested:
BlenderExporter directory blenderExporter
read blend: /tmp/5-abril/mr.blend
OpenScenGraph Option [ AUTHOR ] =
OpenScenGraph Option [ LOG ] = True True
OpenScenGraph Option [ SELECTED ] = ALL ALL
OpenScenGraph Option [ INDENT ] = 3 3
OpenScenGraph Option [ FLOATPRE ] = 4 4
OpenScenGraph Option [ ANIMFPS ] = 25 25.0
OpenScenGraph Option [ FILENAME ] = /tmp/5-abril/mr3.osg /tmp/5-abril/mr3.osg
{'INDENT': 3, 'LOG': True, 'AUTHOR': '', 'SELECTED': 'ALL', 'ANIMFPS': 25.0,
'FLOATPRE': 4, 'FILENAME': '/tmp/5-abril/mr3.osg'}
FILENAME:'mr3'
mr3
osg: processing Armature Armature
Traceback (most recent call last):
File /tmp/blenderSVN/build/bin/2.57/scripts/addons/osgExport.py, line 151,
in execute
OpenSceneGraphExport(config)
File /tmp/blenderSVN/build/bin/2.57/scripts/addons/osgExport.py, line 55,
in OpenSceneGraphExport
export.process()
File /tmp/osgexport/blenderExporter/osg/osgdata.py, line 444, in process
self.exportItemAndChildren(obj)
File /tmp/osgexport/blenderExporter/osg/osgdata.py, line 246, in
exportItemAndChildren
item = self.exportChildrenRecursively(obj, None, None)
File /tmp/osgexport/blenderExporter/osg/osgdata.py, line 288, in
exportChildrenRecursively
item = self.createSkeletonAndAnimations(obj)
File /tmp/osgexport/blenderExporter/osg/osgdata.py, line 406, in
createSkeletonAndAnimations
for nla_track in obj.animation_data.nla_tracks:
AttributeError: 'NoneType' object has no attribute 'nla_tracks'
location:unknown location:-1
location:unknown location:-1
Regards,
--
Alberto
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Nan, On Fri, May 27, 2011 at 3:09 PM, Nan WANG nan.c...@gmail.com wrote: this FBO issue will influence on QuadBuffer rendering?I got some quad buffer problem... QuadBuffer stereo is totally unrelated to FBO's. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Hi Eric, On Fri, May 27, 2011 at 4:22 PM, Eric Sokolowsky esok@gmail.com wrote: Changing _display to display fixes the crashing problem for me. Here is an updated GraphicsWindow.cpp with the fix, which you may have already applied. Good to hear that this fixed the problem - it illustrates it was a multi-threaded X11 usage issue. Having reviewed the wider code the actual check for the window close is already done further up in checkEvents so the second bit of code shouldn't have any effect. Removing the check for close from the swapBuffers doesn't seem safe either so I think the whole submission is suspect, not just the usage of the _display rather display variable. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp and Max 2012
Hi Jean-Sébastien, On Fri, May 27, 2011 at 6:56 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: and I had Max 2011 before and it was working fine, so I'm not sure where this problem comes from. Has anything changed recently that could affect this? It compiles fine for me, but I just noticed the following in the Max 2012 SDK release notes: There are some incorrect usages of the reference system that can allow plug-ins to cause instabilities in 3ds Max, and eventually leading to unexpected behavior or crashes. One such case is when plug-ins call ReferenceMaker::SetReference()http://download.autodesk.com/global/docs/3dsmaxsdk2012/en_us/cpp_ref/class_reference_maker.html#ac11372157c1539fe4beb9160e106d739 directly on other plug-ins. Doing so only partially updates the reference graph which results in system instability when the reference links are deleted. The visibilityReferenceMaker::SetReference()http://download.autodesk.com/global/docs/3dsmaxsdk2012/en_us/cpp_ref/class_reference_maker.html#ac11372157c1539fe4beb9160e106d739 has been changed from public to protected in the class ReferenceMakerhttp://download.autodesk.com/global/docs/3dsmaxsdk2012/en_us/cpp_ref/class_reference_maker.html and all of its sub-classes, to prevent plug-ins from accidentally calling this method. Plug-ins that have been calling ReferenceMaker::SetReference()http://download.autodesk.com/global/docs/3dsmaxsdk2012/en_us/cpp_ref/class_reference_maker.html#ac11372157c1539fe4beb9160e106d739 on objects of types other than themselves or their parent class, will have to change their code to call ReferenceMaker::ReplaceReference()http://download.autodesk.com/global/docs/3dsmaxsdk2012/en_us/cpp_ref/class_reference_maker.html#aa14a0521d1381a989ecd80f385bd instead. I don't understand why it compiles fine for me though. I am using a developer preview version of Max 2012. Maybe this change only appeared in the final release version, but then what was the point of the developer preview! I'll try to download the latest version and see if I can replicate this issue. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
Hi Alberto, Here is an updated script that should fix this crash. Cheers, Damyon -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39870#39870 osgexport-no-mercurial-20100527_r6.tar.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Pyramid Does not appear
hi i did write the code of Basic Geometry tutorial on OSG tutorials page and when i run it the pyramid does not appear in the osg window any help in that :) cheers, Omar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp and Max 2012
Also, as a quick fix, can you try declaring the SetReference method of OSGHelper in a protected namespace? On Fri, May 27, 2011 at 6:56 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: and I had Max 2011 before and it was working fine, so I'm not sure where this problem comes from. Has anything changed recently that could affect this? Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Hi Eric et. al, I have now reverted the problematic part the r12294 that original moved the check for close events from the swapBuffersImplementation to checkEvents, this caused problems because the check was being done on the _display member variable that is X11 Display connection setup for access from the graphics thread only. Could you please do an svn update and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] 2.9.14 and trunk problems on lubuntu 11.04+lxde+nvidia
Hi All, On Thu, May 26, 2011 at 2:31 PM, J.P. Delport jpdelp...@csir.co.za wrote: ulimit -c unlimited for ((i=0; i100; i++)) do osgviewer --window 0 100 800 600 cow.osg osgviewer --window 500 0 800 600 cow.osg sleep 0.5; killall osgviewer; done As discussed in the OSG trunk crashing, perhaps an nvidia driver problem? thread, I've reverted the change that caused the X11 threading issues. Before reverting these changes I was reliably getting errors when running the above script, but now I'm getting a clean run of 100 sets of two windows appearing and disappearing without any errors. Yay for a neat little unit test ;-) Could you all do an svn update and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.5 Call for testing
Excellent work, will get banging on it. -- mew On Fri, May 27, 2011 at 8:47 AM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- I've just tagged 2.8.5 RC1 and would like to request your help in testing. You can check out the release candidate from here: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.5-rc1 All features are in place at this time, with the one exception of the 3DS plugin backport. Assuming that work is complete soon, and there is sufficient testing, we should be able to release in the very near future. Features in 2.8.5: * Uniform performance enhancement. r11952, Michael Plating's performance enhancement for large numbers of uniforms, which effectively eliminates the std::mapstd::string lookup. r11998, Wojciech Lewandowski's backwards compatibility fix for 11952. r12074, Chris Hanson's backwards compatibility fix for 11952. * Support for Texture2DMultisample r11218, changes to Extensions. r11229, fix warnings. r11365, 2D multisample support. * Added new OutputRelativeTextures dot OSG plugin export option (not on trunk). * Enhancements for OcclusionQueryNode. r11760 (plus r11472 for OQN.cpp only). Support for RTT Camera (not on trunk). * osgconv --use-world-frame option. * NOTIFY_WARN (and friends) macros to ease backporting. OSG_NOTIFY_DISABLED CMake variable. * FLT plugin update. A complete backport of the trunk FLT plugin (as if May 4 2010) to the 2.8 branch. Includes export fixes for multitexture. Includes osgSim MultiSwitch changes in r11971. * PNM plugin enhancements: r12220, adds support for reading and writing images using streams. Bug fixes for reading 8-bit and 16-bit images, including loading the images upside-down. * Fix issue with linking apps to libdl on Linux systems. * osgText fix (r11768) to improve text appearance. * Updated osgWrappers for all API changes. * Bump version# 2.8.5, SO# 74. Thanks for your help! -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Black Hawk, Colorado USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG trunk crashing, perhaps an nvidia driver problem?
Robert, I tested your changes and I could not get it to crash, so it looks squashed to me. Thanks! Eric Robert Osfield wrote: Hi Eric et. al, I have now reverted the problematic part the r12294 that original moved the check for close events from the swapBuffersImplementation to checkEvents, this caused problems because the check was being done on the _display member variable that is X11 Display connection setup for access from the graphics thread only. Could you please do an svn update and let me know how you get on. Cheers, 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
Re: [osg-users] OSGExp and Max 2012
Hi Farshid, Also, as a quick fix, can you try declaring the SetReference method of OSGHelper in a protected namespace? Actually, since it's never called by anyone, I just commented it out. It compiles and exports correctly. Just another data point for you, but is that method useful at all? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp and Max 2012
Hi Jean-Sébastien, On Fri, May 27, 2011 at 9:43 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Actually, since it's never called by anyone, I just commented it out. It compiles and exports correctly. Just another data point for you, but is that method useful at all? It might be called internally by Max, since it is overriding the base class method. I'm not 100% sure of this, but it's probably safest to leave it there. Also, what version of Visual Studio are you compiling with? The version of the 2012 SDK I'm using does include the previously mentioned change. So I'm thinking we might have different compilers. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Fred,
On Fri, May 27, 2011 at 2:57 PM, Fred Smith osgfo...@tevs.eu wrote:
Attached is a cleaned up, less messy version of the repro.
testRTTCamera() shows off the leak with offscreen rendering using a slave
camera
testLeak() shows off the GraphicsContext leak.
The test code is still rather a mess, especially the testRTTCamera() -
this *really* isn't how you should do RTT. To test the two code paths
I had to introduce use of osg::ArgumentParser and make it an option to
run either testRTTCamera or testLeak. I renamed the file fbotest and
a CmakeLists.txt both of which are attached,
I run both tests :
fbotest --testRTT
And
fbotest
And both run without problems and without memory growth, there both
seem fine, despite be pretty dire ways to drive the OSG, both seem to
not cause any problems.
I can't really say whether you have ever seen an actual OSG bug, given
the code you have provided I'd suspect that the convolted way of doing
RTT would easily have problems that would lead bugs in your own code.
Feel free to use tools to debug your application.
Robert.
cmake_minimum_required(VERSION 2.6)
PROJECT(fbotest)
FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgViewer)
SET(SOURCES
fbotest.cpp
)
INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})
LINK_DIRECTORIES(${OSG_LIB_DIR})
ADD_EXECUTABLE(fbotest ${SOURCES})
TARGET_LINK_LIBRARIES(fbotest ${OSG_LIBRARY} ${OSGVIEWER_LIBRARY}
${OPENTHREADS_LIBRARY})
/* OpenSceneGraph example, osggeometry.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osg/Geode
#include osg/Geometry
#include osg/GraphicsContext
#include osg/Material
#include osg/Vec3
#include osg/MatrixTransform
#include osg/Texture2D
#include osg/PolygonStipple
#include osg/TriangleFunctor
#include osg/io_utils
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgGA/TrackballManipulator
#include osgViewer/Viewer
#include osg/Math
#include iostream
// This demo illustrates how to create the various different types of geometry that
// the osg::Geometry class can represent. This demo uses the OpenGL red book diagram of different
// OpenGL Primitives as a template for all the equivalent OpenSceneGraph Primitives. The OpenSceneGraph
// wraps OpenGL very thinly and therefore uses all the same enum and naming conventions. The coordinate data is also
// wrapped around OpenGL's vertex arrays and draw arrays/elements calls. Familiarity with
// OpenGL will help you understand the osg::Geometry class which encapsulate all this, or if you
// havn't learned OpenGL yet, learning osg::Geometry will help you understand how OpenGL
// works!
// The osg::Geometry class is a subclass of osg::Drawable base class, so is an object that provides
// a draw method for drawing objects in the scene. osg::Geometry contains all the vertex, normal
// color and texture coordinate arrays required to specify the coordinates of your objects, and the
// primitives join these coordinates together as the points, lines or surfaces that you will see
// rendered on your screen.
//
// This demo is split into two functions, the createScene() function which creates the scene graph
// with the various primitives in it, and the main() which sets up a basic viewer window and
// adds to the it the scene generated by createScene().
struct NormalPrint
{
void operator() (const osg::Vec3 v1,const osg::Vec3 v2,const osg::Vec3 v3, bool) const
{
osg::Vec3 normal = (v2-v1)^(v3-v2);
normal.normalize();
std::cout \t(v1) (v2) (v3) ) normal (normal)std::endl;
}
};
// decompose Drawable primitives into triangles, print out these triangles and computed normals.
void printTriangles(const std::string name, osg::Drawable drawable)
{
std::coutnamestd::endl;
osg::TriangleFunctorNormalPrint tf;
drawable.accept(tf);
std::coutstd::endl;
}
osg::Node* createScene()
{
// create the Geode (Geometry Node) to contain all our osg::Geometry objects.
osg::Geode* geode = new osg::Geode();
// following are separate blocks for
Re: [osg-users] OSGExp and Max 2012
Hi Farshid, It might be called internally by Max, since it is overriding the base class method. I'm not 100% sure of this, but it's probably safest to leave it there. Seems to me that if it's not in the libs, then it can't be called by Max... Unless there's a bug in the libs I'm using (perhaps solved by a service pack?) Also, what version of Visual Studio are you compiling with? The version of the 2012 SDK I'm using does include the previously mentioned change. So I'm thinking we might have different compilers. I'm compiling on VC9 x64 for Max 2012 x64 running on Windows 7 x64. :-) So, what do you suggest? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp and Max 2012
Hi Jean-Sébastien, I'm compiling on VC9 x64 for Max 2012 x64 running on Windows 7 x64. :-) That's also my setup. Strange. So, what do you suggest? Can you post the contents of the buildnumber.h max header file? Also, try building using the solution files in the VisualStudio folder. Maybe there is some project setting that CMake isn't setting properly. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp and Max 2012
Hi Farshid,
Can you post the contents of the buildnumber.h max header file?
/* This file is automatically generated by the DailyBuild script. */
/* VERSION_STRING is the build's posting, ie. MXXX, Daily, Midday. */
/* VERSION_INT is the last successful major (MXXX) with the letter
prefix (M) dropped. */
#if defined(GAME_FREE_VER)
#define VERSION_STRING C000
#define VERSION_INT 0
#elif defined(GAME_VER)
#define VERSION_STRING G000
#define VERSION_INT 0
#elif defined(WEBVERSION)
#define VERSION_STRING M000
#define VERSION_INT 0
#elif defined (DESIGN_VER)
#define VERSION_STRING B000
#define VERSION_INT 0
#else // MAX
#define VERSION_STRING Rampage with PDBs MAX_R121_64_RL 02-22-2011
21:37 143392
#define VERSION_INT 121
#endif
Also,
try building using the solution files in the VisualStudio folder.
Maybe there is some project setting that CMake isn't setting properly.
Yes, that helped find out what was amiss. The CMake build setup was
missing a define _USRDLL. With this defined (and the SetReference()
method uncommented) it builds and runs fine.
The modified file is attached. I added the define before adding the src
subdirectory, instead of inside each project individually, so it will
get added to all projects. That is also the case in the projects under
the VisualStudio folder (I checked), so I assume this is OK.
Perhaps you could add a comment as to why this is required (other than
to fix the linker error I don't know).
Thanks,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
cmake_minimum_required(VERSION 2.6)
set( ProjectName OSGExp )
project( ${ProjectName} )
set (CMAKE_BUILD_TYPE Release)
list( APPEND CMAKE_MODULE_PATH ${OSGExp_SOURCE_DIR}/CMakeModules )
# Platform specific definitions
IF(WIN32)
IF(MSVC)
# To enable /MP, parralel build on MSVC
OPTION(WIN32_USE_MP Set to OFF to diable /MP. ON)
MARK_AS_ADVANCED(WIN32_USE_MP)
IF(WIN32_USE_MP)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /MP)
ENDIF(WIN32_USE_MP)
# Other MSVC compilation flags
ADD_DEFINITIONS(-D_SCL_SECURE_NO_WARNINGS)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
ENDIF(MSVC)
ENDIF (WIN32)
SET(CMAKE_DEBUG_POSTFIX d CACHE STRING add a postfix, usually d)
SET(CMAKE_RELEASE_POSTFIX CACHE STRING add a postfix, usually empty)
SET(CMAKE_RELWITHDEBINFO_POSTFIX rd CACHE STRING add a postfix, usually rd)
SET(CMAKE_MINSIZEREL_POSTFIX s CACHE STRING add a postfix, usually s)
#
# Find Max SDK headers and libraries
#
find_path(MAXSDK_INCLUDE_DIR max.h
HINTS
$ENV{MAXSDK}
PATH_SUFFIXES include
)
# If compiling for 64 bit, look for the 64 bit libraries
# In the default Max 2011 SDK install, the 32 bit libraries are
# in ${MAXSDK}/lib, and 64 bit ones are in ${MAXSDK}/x64/lib
SET(MAXSDK_LIB_PATH_SUFFIX lib)
IF(CMAKE_SIZEOF_VOID_P MATCHES 8)
SET(MAXSDK_LIB_PATH_SUFFIX x64/lib)
MARK_AS_ADVANCED(LIB_POSTFIX)
ENDIF()
find_path(MAXSDK_LIB_DIR maxutil.lib
HINTS
$ENV{MAXSDK}
PATH_SUFFIXES ${MAXSDK_LIB_PATH_SUFFIX}
)
SET(MAXSDK_LIBRARIES
${MAXSDK_LIB_DIR}/bmm.lib
${MAXSDK_LIB_DIR}/core.lib
${MAXSDK_LIB_DIR}/geom.lib
${MAXSDK_LIB_DIR}/gfx.lib
${MAXSDK_LIB_DIR}/mesh.lib
${MAXSDK_LIB_DIR}/maxutil.lib
${MAXSDK_LIB_DIR}/maxscrpt.lib
${MAXSDK_LIB_DIR}/manipsys.lib
${MAXSDK_LIB_DIR}/paramblk2.lib
)
find_path(MAX_DIR 3dsmax.exe
# No hints...
)
add_definitions(-D_USRDLL)
add_subdirectory(src)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp and Max 2012
Hi Jean-Sébastien, Yes, that helped find out what was amiss. The CMake build setup was missing a define _USRDLL. With this defined (and the SetReference() method uncommented) it builds and runs fine. The modified file is attached. I added the define before adding the src subdirectory, instead of inside each project individually, so it will get added to all projects. That is also the case in the projects under the VisualStudio folder (I checked), so I assume this is OK. Thanks, I just committed it. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pyramid Does not appear
On 5/27/2011 10:02 AM, Omar Khaled Aly wrote: hi i did write the code of Basic Geometry tutorial on OSG tutorials page and when i run it the pyramid does not appear in the osg window any help in that :) I recall some sort of primitiveset error in that last time I saw it. I don't have the time to spend reviewing it again right now. Have you turned up logging, and do you see any GL errors or OSG errors? cheers, Omar -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPango] Alpha when rendering letters
Hi, I use osgPango to render text ( latest version from svn ). from what I got from code, first glyphs are rendered to layers, then default shader puts everything into frontbuffer ( default is frag1 shader - which I use ). However - due to use of alpha in shader the text looks somewhat not very crisp ( some parts of letters appear as if they have some alpha ( I render above alpha texture but with osgPango node with blend option switched off - but still shader takes it into account) from shader generator baseFragmentHeader(unsigned int num) there is a statement return vec4(c.rgb * t.a, t.a); so - naturally alpha is present in output pixel. Replacing the string to return vec4(c.rgb, t.a); does not change much. but return vec4(c.rgb , 1.0 ); renders everything outside letters with black ( so instead of text - filled rectangles ). now, maybe I miss something simple but how to filter alpha so that I have less fuzzy letters and also do not produce non needed artifacts. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPango] Alpha when rendering letters
Can you send me an example showing this? I can probably fix the problem right up when I see the code. However, unless you've got some FFP blending setup elsewhere in your scene, I'm having a hard time imagining what could be wrong... On Fri, 2011-05-27 at 23:46 +0400, Sergey Kurdakov wrote: Hi, I use osgPango to render text ( latest version from svn ). from what I got from code, first glyphs are rendered to layers, then default shader puts everything into frontbuffer ( default is frag1 shader - which I use ). However - due to use of alpha in shader the text looks somewhat not very crisp ( some parts of letters appear as if they have some alpha ( I render above alpha texture but with osgPango node with blend option switched off - but still shader takes it into account) from shader generator baseFragmentHeader(unsigned int num) there is a statement return vec4(c.rgb * t.a, t.a); so - naturally alpha is present in output pixel. Replacing the string to return vec4(c.rgb, t.a); does not change much. but return vec4(c.rgb , 1.0 ); renders everything outside letters with black ( so instead of text - filled rectangles ). now, maybe I miss something simple but how to filter alpha so that I have less fuzzy letters and also do not produce non needed artifacts. Regards Sergey ___ 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] Too long to generate the DEM with osgdem
Dear all, I am newer for using OSG. I compile gdal and VPB and rightly get all the files with VS2005. When I use osgdem to generate DEM, I find it generates .IVE and a folder of XXX-_root_L0_X0_Y0 . The problem is: It takes too long to generate the DEM. I check the time of file genration time and find the intervals between first several file is very short for level 0, level 1 and level 2. Coming to level 3 and after, the intervals are long, in my case 2 minutes or 3 minutes. So, after one and a half days, the DEM is only generated half. The input files are : Texture is: texture.tilf 70m 4019*4284 ; DEM is: height.tif 47m 4019*4284. The comand line to generate DEM is : osgdem -t texture.tif -d height.tif -l 8 -a mydem.osga Anybady can help me? Thanks a lot. 2011-05-28 ijustfu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
