Re: [osg-users] What's the mpr.dll ?
never heard of it. google sez: mpr.dll is a module containing functions used to handle communication between the Windows operating system and the installed network providers. -- mew On Thu, Apr 17, 2008 at 8:03 PM, [EMAIL PROTECTED] wrote: Hello, I develop a osg application,it runs right on development machine,but change other machine,it can't. I use DEPENDS.Exe to find the file mpr.dll have problem,it show the error: Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module. (Both machine have mpr.dll file,but different file date.) what's the mpr.dll? is there the relationship with the OSG? Thank you. Donlin 飙舞赚QQ秀赢旅行券 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Austin Texas 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] Cyclic graphs?!
Hi Art, A long way back, 7 years ago, perhaps more, when I wrote NodeVisitor I did consider adding detecting of cycles but considered the code too costly to apply on every traverse or accept invocation. Cyclic scene graphs are very much a special case that very few users will ever use so adding a cost for everybody to support such a few just doesn't make sense. The progress of years has not changed this, you are the first person for many years, perhaps even the first to raise this topic on the OSG users list so its most definitely nieche. My recomendation is to either a custom Node that overrides accept() or traverse() to catch cycles, or to use a callback as I suggested. Robert. On Thu, Apr 17, 2008 at 10:09 PM, Art Tevs [EMAIL PROTECTED] wrote: Hi folks, Hmm, yeah it could be. However I haven't thought a lot of thread safety in a cyclic scene graph. Of course, for my purpose, I maybe would be able to redesign the problem and break the cycle in it or more or less leave with it by changing hte ::traverse() methods accordingly. However, I think, that the more elegant solution is to allow cycles and to catch them through the scene graph. I'll try to make some more thoughts about this. I think the idea with a barrier node or something like this would allow the user to be responsible for resolving the cycles. My idea is to put some cycle-detection code into the NodeVisitor and whenever it detects a path with a cycle, it could just add a new node, BarrierNode. The traverse method of the barrier node should forbid traversion of the subgraph per default. In this manner, we break the cycles automagically. Additional feature of it that the user defined nodes, derived from BarrierNode, are able to take care of what to do with the cycle. In this manner we wouldn't break any current functionality of the osg, because cycles are not allowed in any case. And by adding BarrierNodes we just break the cycles and just stop traversion there. Art P.S. Maybe there are some research papers from the beginning of scene graphs where they made already some thoughts on it. I wasn't able to find any ;-( Take a look here: http://www.gamasutra.com/view/feature/2812/dependency_graphs_in_games.php?page=3 --- Robert Osfield [EMAIL PROTECTED] schrieb: Hi Art, I've never tried it myself, but the OSG should be able to support cyclic graphs, just not out of the box. The way I'd do it is have a custom Update/Event/CullCallback that is attached to a node in the cycle, these callbacks count the number of times through in each traversal, once an max number of cycles in reach the traversal is stopped - simply be not calling the traverse method. One of the more tricky parts will be making the callbacks thread safe - much more of an issue of the cull traversal as update and event traversals are strictly single threaded so one can store state local to the callback itself. For a thread safe cull traversal I guess you might be able to use the NodePath that the NodeVisitor accumulates as it traverses as a measure of how many times the cycle has been completed. I'd guess you should be able to write such a callback with just a few lines of code. Perhaps this would be a nice little exercise for the community ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Gesendet von Yahoo! Mail. Der Mailbox mit unbegrenztem Speicher. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] picking osg objects using osgUtil::SceneView (cant find osgUtil::PickVisitor!)
Hi Erland, You could use osgViewer::GraphicsWindowEmbedded to replace SceneView, see the osgviewerGLUT and osgviewerSDL examples. Robert. On Thu, Apr 17, 2008 at 10:13 PM, [EMAIL PROTECTED] wrote: Hei Robert. I would like to do that, but im working in a company and right now im trying to integrating osg in a existing rendring system (which handles events, mfc window, renders 3d terrain++) for rendering simple objects, so i'd rather use SceneView as for now. I think i could be using LineProjector and IntersectVisitor to find intersections..? But havent testet yet. See attachment. Erlend -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 17. april 2008 22:22 To: OpenSceneGraph Users Subject: Re: [osg-users] picking osg objects using osgUtil::SceneView (cant find osgUtil::PickVisitor!) Hi Erland, Would it not be possible just to use osgViewer rather than SceneView. One of the points of osgViewer is that it provides more higher level functionality that users commonly require, and in doing so avoid the pain of end users having to implement themselves, and the pain involved in trying to communicate all the low level details required to teach a 3rd party how to implement something already implemented for them. Robert. On Thu, Apr 17, 2008 at 8:49 PM, [EMAIL PROTECTED] wrote: I want to pick osg objects in the scene when pressing the mouse button on them. I am using sceneView so i guess i cant use the osgViewer::View. computeIntersections and i did not find PickVisitor! Im using osg 2.3.7. So i guess i have to use IntersectVisitor. Is there a utility function for getting a line from camera towards mouse position. Or do i: camera.pos - gluUnproject screen to world erlend ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] When must you use SingleThreaded threading model
Hi Paul, The osgdepthpartion example would be best rewritten as a Viewer with slave Cameras, rather than a CompositeViewer with multiple Views. The reason for this is that depth partition cameras are conceptually work on the same view, and are locked in sync with the view and projection matrix of the master camera. Robert. On Fri, Apr 18, 2008 at 12:28 AM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- Another one of the examples that forces SingleThreaded is osgdepthpartition. I keep intending to rewrite it using CompositeViewer with ordered view processing, but haven't gotten around to it yet. In a nutshell, if any code executed by the cull or draw threads (such as your own callbacks or custom nodes) isn't thread safe, then you must use SingleThreaded. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Thursday, April 17, 2008 11:40 AM To: osg users Subject: [osg-users] When must you use SingleThreaded threading model Hi Robert, I was looking through the examples and noticed that osgphotoalbum, osgdistortion and a few of the other examples are explicitly setting the viewer to SingleThreaded threading model. Is there anything inherit in those examples where you *must* use the SingleThreaded viewer model rather than the others? Just curious as I'm trying to get my head around the new OSG threading models. Thanks, jason ___ 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] picking osg objects using osgUtil::SceneView (cant find osgUtil::PickVisitor!)
Looking at that example I see that swapbuffers has to be called manually in this case, but I fail to find the place in the source where Viewer checks if it is running embedded and therefore doesn't have to call swapbuffers itself. Can you give a hint where this is? Paul Robert Osfield wrote: Hi Erland, You could use osgViewer::GraphicsWindowEmbedded to replace SceneView, see the osgviewerGLUT and osgviewerSDL examples. Robert. On Thu, Apr 17, 2008 at 10:13 PM, [EMAIL PROTECTED] wrote: Hei Robert. I would like to do that, but im working in a company and right now im trying to integrating osg in a existing rendring system (which handles events, mfc window, renders 3d terrain++) for rendering simple objects, so i'd rather use SceneView as for now. I think i could be using LineProjector and IntersectVisitor to find intersections..? But havent testet yet. See attachment. Erlend -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: 17. april 2008 22:22 To: OpenSceneGraph Users Subject: Re: [osg-users] picking osg objects using osgUtil::SceneView (cant find osgUtil::PickVisitor!) Hi Erland, Would it not be possible just to use osgViewer rather than SceneView. One of the points of osgViewer is that it provides more higher level functionality that users commonly require, and in doing so avoid the pain of end users having to implement themselves, and the pain involved in trying to communicate all the low level details required to teach a 3rd party how to implement something already implemented for them. Robert. On Thu, Apr 17, 2008 at 8:49 PM, [EMAIL PROTECTED] wrote: I want to pick osg objects in the scene when pressing the mouse button on them. I am using sceneView so i guess i cant use the osgViewer::View. computeIntersections and i did not find PickVisitor! Im using osg 2.3.7. So i guess i have to use IntersectVisitor. Is there a utility function for getting a line from camera towards mouse position. Or do i: camera.pos - gluUnproject screen to world erlend ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] svn 8134 osgprerender --image
Hi, with the latest SVN and osgprerender --image, I'm getting a lot of: Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) lines written to the screen. Does anyone else see this? Without --image there are no errors. On another machine I have rev 8084 and have recompiled that version and do not see the error then. regards 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to set Fonts file Path?
Hi Donlin, A good way to debug file search paths is to enable verbose debug messages via: set OSG_NOTIFY_LEVEL=DEBUG And then look for the output where it searches for the Font. It could be that the search paths on each machine is different, or that each machine doesn't have the same set of data installed on the same paths. To set paths you can simply do: set OSG_FILE_PATH=. Or programatically: osgDB::setDataFilePath(...); Robert. On Fri, Apr 18, 2008 at 1:51 AM, [EMAIL PROTECTED] wrote: Hello,all, I use setFont(Fonts//ARIAL.TTF) ,it can take affects on development machine,but after change other machine it can't show the right Fonts,why? (The file ARIAL.TTF is on the both machine C:\WINDOWS\Fonts\ARIAL.TTF) I got a little confuse: - setFont(Fonts/ARIAL.TTF); setFont(Fonts//ARIAL.TTF); setFont(Fonts\\ARIAL.TTF); setFont(C:\WINDOWS\Fonts\ARIAL.TTF); setFont(C:\\WINDOWS\\Fonts\\ARIAL.TTF); setFont(C://WINDOWS//Fonts//ARIAL.TTF); -- Which is correct and should be? Thank you. Donlin 飙舞赚QQ秀赢旅行券 ___ 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] picking osg objects using osgUtil::SceneView (cant find osgUtil::PickVisitor!)
Hi Paul, On Fri, Apr 18, 2008 at 10:18 AM, Paul Melis [EMAIL PROTECTED] wrote: Looking at that example I see that swapbuffers has to be called manually in this case, but I fail to find the place in the source where Viewer checks if it is running embedded and therefore doesn't have to call swapbuffers itself. Can you give a hint where this is? osgViewer::Viewer/CompositeViewer don't check to see if the graphics window is an embedded one, they just assume its not, and go ahead and call makeCurrent and swapBuffers on the graphics window. In the case of GraphicsWindowEmbedded these are non ops, since they nothing about the actual graphics context, only the app does they can't do anything but non ops. This does sound like a bit of recipe for disaster... but, as long as the app is running the viewer with single context and single threaded and does the makeCurrent and swapBuffers as required in its own code everything works. GraphicsWindowEmbedded is really just a an adapter that fools osgViewer into behaving more like osgUtil::SceneView, just a far more capable version that supports events, event handlers, camera manipulators, database paging, all with the same API as the fullblown osgViewer base apps. This makes it much simpler to migrate to a full scalable OSG app just a few code changes in the client app. On of the key points about osgViewer is the ability to unify a full range of usage models all within the same set of classes, this makes providing a consistent set of API and functionality across the usage range, and make it easier to move between different usage styles, and for me it makes it easier to maintain, document and support. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
Hi J.P, On Fri, Apr 18, 2008 at 10:53 AM, J.P. Delport [EMAIL PROTECTED] wrote: version 8084 (that works) already has MRT included, that's why I had it on another machine. It seems like it was the moving of the MRT to FBO that might be the problem. Thanks for the clarification, gives us a little more to go on. Another possible clue: osgprerender cow.osg --image --fbo Produces the OpenGL error, while: osgprerender cow.osg --image --window osgprerender cow.osg --image --fb osgprerender cow.osg --image --pbuffer Don't produce and error, so its certainly the FBO code itself that is at fault. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
Hi J.P, Thanks for the heads up, I just tried it on my machine (Kubuntu 7.10, 7800GT) and get the same error. My guess is that the changes to support Multiple Render Targets has broken something in RenderStage w.r.t reading imagery. Arrrgghghg two steps forward, one step back Robert. On Fri, Apr 18, 2008 at 10:20 AM, J.P. Delport [EMAIL PROTECTED] wrote: Hi, with the latest SVN and osgprerender --image, I'm getting a lot of: Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,) lines written to the screen. Does anyone else see this? Without --image there are no errors. On another machine I have rev 8084 and have recompiled that version and do not see the error then. regards 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
Hi Robert, Robert Osfield wrote: Hi J.P, On Fri, Apr 18, 2008 at 10:53 AM, J.P. Delport [EMAIL PROTECTED] wrote: version 8084 (that works) already has MRT included, that's why I had it on another machine. It seems like it was the moving of the MRT to FBO that might be the problem. Thanks for the clarification, gives us a little more to go on. Another possible clue: osgprerender cow.osg --image --fbo Produces the OpenGL error, while: osgprerender cow.osg --image --window osgprerender cow.osg --image --fb osgprerender cow.osg --image --pbuffer Don't produce and error, so its certainly the FBO code itself that is at fault. Yes, I think I know what is wrong. Remember how you modified the enum Camera::BufferComponent so that COLOR_BUFFER and COLOR_BUFFER0 were not the same? When glDrawBuffers was in RenderStage, it knew to only enable MRT when COLOR_BUFFER0 or later was attached. However, the fbo-setAttachment call is the same for COLOR_BUFFER and COLOR_BUFFER0. So now FBO internally incorrectly calls glDrawBuffers when COLOR_BUFFER (vs COLOR_BUFFER0) is attached and this causes the error. I'm not sure how to fix this without changing fbo-setAttachment. Still looking... jp Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
Hi J.P, On Fri, Apr 18, 2008 at 11:20 AM, J.P. Delport [EMAIL PROTECTED] wrote: Yes, I think I know what is wrong. Remember how you modified the enum Camera::BufferComponent so that COLOR_BUFFER and COLOR_BUFFER0 were not the same? When glDrawBuffers was in RenderStage, it knew to only enable MRT when COLOR_BUFFER0 or later was attached. However, the fbo-setAttachment call is the same for COLOR_BUFFER and COLOR_BUFFER0. So now FBO internally incorrectly calls glDrawBuffers when COLOR_BUFFER (vs COLOR_BUFFER0) is attached and this causes the error. Reviewing the code in RenderStage I can see that the use of OpenGL enum GL_COLOR_ATTACHMENT0_EXT for both osg::Camera::COLOR_BUFFER and osg::Camera::COLOR_BUFFERi is the source of the problem i.e. FBO starts assuming its using MRT even when its not actually been requested. Here lies the problem with implicitly turning on/off MRT. I'm not sure how to fix this without changing fbo-setAttachment. Still looking... Change FBO so that it used osg::Camear::BufferComponent rather than GLenum would be one way, as this would allow use to differentiate properly. Changing setAttatchment(GLenum,..) to setAttatchment(osg::Camera::BufferComponent, ..) would however break backwards compatibility. Perhaps we could have both? I'll investigate this avenue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setHeight in DriveManipulator
Hi, how can I set the height in DriveManipulator ? When I use setHeight, it has no effect, specially when I remove the intersectTraversal. When I look in the source code, I can't find how the height effects the calculation. Or do I miss something ? Thanks Dieter Unclassified Mail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] error compiling last svn OSG
Hi i´m compiling against windows with visual studio 2005 sp1 i´ve downloaded the osg windows dependencies from the svn and i´m also using the gdal from the FWTools210 package. Do all the cmake stuff and the i build the solution 62 projects of the solution compile succesfully vs 6 failed projects the main error i´m receiving is this one .\GraphicsWindowWin32.cpp(1844) : error C2065: '_mouseCursor' : undeclared identifier the rest of the errors are supposed to be fixed after this one is ok any ideas thanks PS: the osg distribution is the one from the svn. The last beta 2.3.8 fails the same way. _ MSN Video. 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
Re: [osg-users] svn 8134 osgprerender --image
Hi J.P et. al, On Fri, Apr 18, 2008 at 12:22 PM, Robert Osfield [EMAIL PROTECTED] wrote: Change FBO so that it used osg::Camear::BufferComponent rather than GLenum would be one way, as this would allow use to differentiate properly. Changing setAttatchment(GLenum,..) to setAttatchment(osg::Camera::BufferComponent, ..) would however break backwards compatibility. Perhaps we could have both? I'll investigate this avenue. I have gone with adding a methods: setAttachment(BufferComponent,...) getAttachment(BufferComponent) hasAttachment(BufferComponent) Where BufferComponent is simply typedef osg::Camera::BufferComponent BufferComponent; Internally I've changed FBO so that it now uses BufferComponent in its internal map rather than GLenum, this allow its to differentiate between FBO MRT and FBO non MRT paths, something that can't be done with GLenum alone. I have left the original setAttachment(GLenum) methods in place for backwards compatibility, but... it isn't as robust as using BufferComponent due to the issue of distinguishing between MRT and non MRT paths. Consider these versions deprecated. With these changes the MRT and the non MRT FBO examples work for me. Could users do an svn update and these out the new codes? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error compiling last svn OSG
Hi David, This problem was fixed right after the 2.3.8 dev release, other Windows users have since been compiling fine so I'd recommend you do another svn update, and that doesn't work investigate why your local svn checkout hasn't been updating the include/osgViewer/api/Win32/GraphicsWindowWin32 header. Robert. On Fri, Apr 18, 2008 at 12:54 PM, David _ [EMAIL PROTECTED] wrote: Hi i´m compiling against windows with visual studio 2005 sp1 i´ve downloaded the osg windows dependencies from the svn and i´m also using the gdal from the FWTools210 package. Do all the cmake stuff and the i build the solution 62 projects of the solution compile succesfully vs 6 failed projects the main error i´m receiving is this one .\GraphicsWindowWin32.cpp(1844) : error C2065: '_mouseCursor' : undeclared identifier the rest of the errors are supposed to be fixed after this one is ok any ideas thanks PS: the osg distribution is the one from the svn. The last beta 2.3.8 fails the same way. Todo ruedas: información práctica y todo el glamour del mundo del motor. MSN Estilo y Tendencias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error compiling last svn OSG
i´m doing the checkout from this url http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.8 tell me if that is correct, and if it is not, i´ll investigate on my own why it is not working thanks Date: Fri, 18 Apr 2008 13:35:34 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] error compiling last svn OSG Hi David, This problem was fixed right after the 2.3.8 dev release, other Windows users have since been compiling fine so I'd recommend you do another svn update, and that doesn't work investigate why your local svn checkout hasn't been updating the include/osgViewer/api/Win32/GraphicsWindowWin32 header. Robert. On Fri, Apr 18, 2008 at 12:54 PM, David _ [EMAIL PROTECTED] wrote: Hi i´m compiling against windows with visual studio 2005 sp1 i´ve downloaded the osg windows dependencies from the svn and i´m also using the gdal from the FWTools210 package. Do all the cmake stuff and the i build the solution 62 projects of the solution compile succesfully vs 6 failed projects the main error i´m receiving is this one .\GraphicsWindowWin32.cpp(1844) : error C2065: '_mouseCursor' : undeclared identifier the rest of the errors are supposed to be fixed after this one is ok any ideas thanks PS: the osg distribution is the one from the svn. The last beta 2.3.8 fails the same way. Todo ruedas: información práctica y todo el glamour del mundo del motor. MSN Estilo y Tendencias ___ 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 _ MSN Noticias http://noticias.msn.es/comunidad.aspx___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error compiling last svn OSG
Hi David, i´m doing the checkout from this url http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.8 That refers to the tag directly, so it's identical to the 2.3.8 tarball you had. You won't get any subsequent updates. Check out from http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/ instead. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error compiling last svn OSG
thanks, it´s working now Date: Fri, 18 Apr 2008 08:54:09 -0400 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] error compiling last svn OSG Hi David, i´m doing the checkout from this url http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.8 That refers to the tag directly, so it's identical to the 2.3.8 tarball you had. You won't get any subsequent updates. Check out from http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/ instead. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ MSN Noticias http://noticias.msn.es/comunidad.aspx___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
Hi All, With these changes the MRT and the non MRT FBO examples work for me. Could users do an svn update and these out the new codes? I have just done more testing, and found that while the follow works: osgprerender cow.osg --image --fbo Without the --image it fails - I just get a back window. osgprerender cow.osg --fbo As yet I don't know why, other RTT effect like osgspotlight and osgshadow work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9devrelease
Hi All, Many thanks for the the testing and feedback. Alas I'm afraid I'll now further testing as this morning I've checked in a couple of bug fixes that will need build and runtime testing. I also forgot to mention, the SVN version of the OSG is now under feature freeze, so only bug and build fixes from here on out to 2.4. Could users do an svn update, build and run to see if the SVN version is ready for 2.3.9? Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
The SVN gives this error: [ 1%] Building CXX object src/osg/CMakeFiles/osg.dir/FrameBufferObject.o /home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp: In member function ‘void osg::FrameBufferObject::updateDrawBuffers()’: /home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp:619: error: ‘COLOR_BUFFER15’ is not a member of ‘osg::Camera’ make[2]: *** [src/osg/CMakeFiles/osg.dir/FrameBufferObject.o] Error 1 make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2 make: *** [all] Error 2 El Viernes 18 Abril 2008ES 15:37:42 Robert Osfield escribió: Hi All, I've tracked down the below problem and checked in a bug fix for it. So please svn udpate and test. Robert. On Fri, Apr 18, 2008 at 2:16 PM, Robert Osfield [EMAIL PROTECTED] wrote: I have just done more testing, and found that while the follow works: osgprerender cow.osg --image --fbo Without the --image it fails - I just get a back window. osgprerender cow.osg --fbo As yet I don't know why, other RTT effect like osgspotlight and osgshadow work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn 8134 osgprerender --image
Hi Alberto, Sorry, missed this check in (I was managing multiple patches at once.) The include/osg/Camera updates are now checked in. Robert. On Fri, Apr 18, 2008 at 2:44 PM, Alberto Luaces [EMAIL PROTECTED] wrote: The SVN gives this error: [ 1%] Building CXX object src/osg/CMakeFiles/osg.dir/FrameBufferObject.o /home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp: In member function 'void osg::FrameBufferObject::updateDrawBuffers()': /home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera' make[2]: *** [src/osg/CMakeFiles/osg.dir/FrameBufferObject.o] Error 1 make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2 make: *** [all] Error 2 El Viernes 18 Abril 2008ES 15:37:42 Robert Osfield escribió: Hi All, I've tracked down the below problem and checked in a bug fix for it. So please svn udpate and test. Robert. On Fri, Apr 18, 2008 at 2:16 PM, Robert Osfield [EMAIL PROTECTED] wrote: I have just done more testing, and found that while the follow works: osgprerender cow.osg --image --fbo Without the --image it fails - I just get a back window. osgprerender cow.osg --fbo As yet I don't know why, other RTT effect like osgspotlight and osgshadow work. 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] svn 8134 osgprerender --image
Hi All, I've tracked down the below problem and checked in a bug fix for it. So please svn udpate and test. Robert. On Fri, Apr 18, 2008 at 2:16 PM, Robert Osfield [EMAIL PROTECTED] wrote: I have just done more testing, and found that while the follow works: osgprerender cow.osg --image --fbo Without the --image it fails - I just get a back window. osgprerender cow.osg --fbo As yet I don't know why, other RTT effect like osgspotlight and osgshadow work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry
Hi All, I've a new problem, which is about Geometries. this is simple : I've a node, already with a texture, and I want to put a second texture on it. BUT, the second texture have to be well positioned on the node, without depending on the Geometry's texture coordinates... I've tried osg::TexGen and osg::TextureCubeMap but the second texture is never put correctly on the node... How can I get the texture coordinates ? or how can I put the second texture right on the node ? Thanks. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry
Vincent, I'm not sure what you're trying to do. The second texture will only look right on the geometry if you define the texture coordinates to make it right. Each texture has it's own texture coordinates: osg::Geometry::setTexCoordArray(texture unit, texture coordinate array) The first texture should use texture unit 0 and the second should use texture unit 1. Brian [EMAIL PROTECTED] wrote: - To: osg osg-users@lists.openscenegraph.org From: Vincent Bourdier [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 04/18/2008 10:17AM Subject: [osg-users] Geometry Hi All, I've a new problem, which is about Geometries. this is simple : I've a node, already with a texture, and I want to put a second texture on it. BUT, the second texture have to be well positioned on the node, without depending on the Geometry's texture coordinates... I've tried osg::TexGen and osg::TextureCubeMap but the second texture is never put correctly on the node... How can I get the texture coordinates ? or how can I put the second texture right on the node ? Thanks. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry
Brian, ok so if I understand well, i can set a second array of coordinate of texture. but for that I need the geometry... and i only can get the drawable from a geode... so how can I get the geometry ? thanks for help. Vincent. 2008/4/18, Brian R Hill [EMAIL PROTECTED]: Vincent, I'm not sure what you're trying to do. The second texture will only look right on the geometry if you define the texture coordinates to make it right. Each texture has it's own texture coordinates: osg::Geometry::setTexCoordArray(texture unit, texture coordinate array) The first texture should use texture unit 0 and the second should use texture unit 1. Brian [EMAIL PROTECTED] wrote: - To: osg osg-users@lists.openscenegraph.org From: Vincent Bourdier [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 04/18/2008 10:17AM Subject: [osg-users] Geometry Hi All, I've a new problem, which is about Geometries. this is simple : I've a node, already with a texture, and I want to put a second texture on it. BUT, the second texture have to be well positioned on the node, without depending on the Geometry's texture coordinates... I've tried osg::TexGen and osg::TextureCubeMap but the second texture is never put correctly on the node... How can I get the texture coordinates ? or how can I put the second texture right on the node ? Thanks. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ 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] Geometry
Bonjour Vincent, this is simple : I've a node, already with a texture, and I want to put a second texture on it. BUT, the second texture have to be well positioned on the node, without depending on the Geometry's texture coordinates... Geometry can (and should) have texture coordinates for each texture unit you want to use. In your case you want to use units 0 and 1, so you should have texture coordinates for units 0 and 1. I've tried osg::TexGen and osg::TextureCubeMap but the second texture is never put correctly on the node... Option 1 osg::TexGen generates texture coordinates in a few different modes. It might be what you want, but it might not. See glTexGen (search Google or consult the red book) for a description of the different modes TexGen supports. In your case, if your first texture (unit 0) is applied correctly and you want to generate texture coordinates on unit 1 using a TexGen, you should use: osg::ref_ptrosg::TexGen texgen = new osg::TexGen; texgen-setMode( the mode you want ); geometry-getOrCreateStateSet()-setTextureAttributeAndModes(1, texgen.get(), osg::StateAttribute::ON); The 1 there specifies the texture unit you want the TexGen to affect. Then you would add your texture as you normally do, but to unit 1 as well. osg::ref_ptrosg::Texture2D texture = new osg::Texture2D( osgDB::readImageFile(blah.jpg)); geometry-getOrCreateStateSet()-setTextureAttributeAndModes(1, texture.get(), osg::StateAttribute::ON); Option 2 But as I said, TexGen only generates texture coordinates in a few specific modes. If you want something else, you'll have to make texture coordinates in your modeling program, or programmatically... For example: osg::ref_ptrosg::Vec2Array texcoordsUnit1 = new osg::Vec2Array; // Populate the Vec2Array with texture coordinates, normally as // many Vec2 instances as you have vertices in your geometry. geomtry-setTexCoordArray(1, texcoordsUnit1.get()); Again, assigned to unit 1. Option 3 You could also use the same texture coordinates on unit 1 as on unit 0: geometry-setTexCoordArray(1, geometry-getTexCoordArray(0)); (I think that should work, never tested it, but if it doesn't work you could clone the texcoord array from unit 0 and then assign it to unit 1) So you see, lots of options. It all depends on what you want as your texture coordinates! Hope this helps, and hope it was comprehensible... :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry
Bonjour Vincent, ok so if I understand well, i can set a second array of coordinate of texture. but for that I need the geometry... and i only can get the drawable from a geode... so how can I get the geometry ? Use a NodeVisitor to get to the geode you want (only you can know which one you want, either by name or any other trait, or just find any geode), and then get its drawables and check to see if they're instances of osg::Geometry. Check the examples for uses of NodeVisitor to find a node. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry
Hi Jean-Sébastien, This is a very clear and complete explanation. I'll will try all these to get the best in my case. thanks a lot for these quick answers !! Regards, Vincent. 2008/4/18, Jean-Sébastien Guay [EMAIL PROTECTED]: Bonjour Vincent, ok so if I understand well, i can set a second array of coordinate of texture. but for that I need the geometry... and i only can get the drawable from a geode... so how can I get the geometry ? Use a NodeVisitor to get to the geode you want (only you can know which one you want, either by name or any other trait, or just find any geode), and then get its drawables and check to see if they're instances of osg::Geometry. Check the examples for uses of NodeVisitor to find a node. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry
Vincent,
The geode can have any number of drawables associated with it. You need to
know which one you are interested in.
for (unsigned int ii=0; iigeode-getNumDrawables(); ++ii)
{
osg::Geometry * geom = dynamic_castosg::Geometry
*(geode-getDrawable(ii));
if (geom)
{
// do your stuff here
}
}
Brian
[EMAIL PROTECTED] wrote: -
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
From: Vincent Bourdier [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
Date: 04/18/2008 10:32AM
Subject: Re: [osg-users] Geometry
Brian,
ok so if I understand well, i can set a second array of coordinate of
texture. but for that I need the geometry... and i only can get the
drawable from a geode... so how can I get the geometry ?
thanks for help.
Vincent.
2008/4/18, Brian R Hill [EMAIL PROTECTED] :
Vincent,
I'm not sure what you're trying to do. The second texture will only look
right on the geometry if you define the texture coordinates to make it
right.
Each texture has it's own texture coordinates:
osg::Geometry::setTexCoordArray(texture unit, texture coordinate array)
The first texture should use texture unit 0 and the second should use
texture unit 1.
Brian
- [EMAIL PROTECTED] wrote: -
To: osg osg-users@lists.openscenegraph.org
From: Vincent Bourdier [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
Date: 04/18/2008 10:17AM
Subject: [osg-users] Geometry
Hi All,
I've a new problem, which is about Geometries.
this is simple : I've a node, already with a texture, and I want to put a
second texture on it. BUT, the second texture have to be well positioned on
the node, without depending on the Geometry's texture coordinates...
I've tried osg::TexGen and osg::TextureCubeMap but the second texture is
never put correctly on the node...
How can I get the texture coordinates ? or how can I put the second texture
right on the node ?
Thanks.
Regards,
Vincent.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
___
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
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease
On all three platforms on which I compiled, I got an error: FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera'. I just did svn update in my root directory before compiling. Should I have done something else? andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, April 18, 2008 9:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease Hi All, Many thanks for the the testing and feedback. Alas I'm afraid I'll now further testing as this morning I've checked in a couple of bug fixes that will need build and runtime testing. I also forgot to mention, the SVN version of the OSG is now under feature freeze, so only bug and build fixes from here on out to 2.4. Could users do an svn update, build and run to see if the SVN version is ready for 2.3.9? Thanks in advance, Robert. ___ 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] svn 8134 osgprerender --image
Ok, it builds now, osgprerender --image works if what is intended is to invert the colours of a rectangle inside of the cow texture. I really never tried that example with the --image switch, but I think it's doing its work nicely. El Viernes 18 Abril 2008ES 15:55:54 Robert Osfield escribió: Hi Alberto, Sorry, missed this check in (I was managing multiple patches at once.) The include/osg/Camera updates are now checked in. Robert. On Fri, Apr 18, 2008 at 2:44 PM, Alberto Luaces [EMAIL PROTECTED] wrote: The SVN gives this error: [ 1%] Building CXX object src/osg/CMakeFiles/osg.dir/FrameBufferObject.o /home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp: In member function 'void osg::FrameBufferObject::updateDrawBuffers()': /home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera' make[2]: *** [src/osg/CMakeFiles/osg.dir/FrameBufferObject.o] Error 1 make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2 make: *** [all] Error 2 El Viernes 18 Abril 2008ES 15:37:42 Robert Osfield escribió: Hi All, I've tracked down the below problem and checked in a bug fix for it. So please svn udpate and test. Robert. On Fri, Apr 18, 2008 at 2:16 PM, Robert Osfield [EMAIL PROTECTED] wrote: I have just done more testing, and found that while the follow works: osgprerender cow.osg --image --fbo Without the --image it fails - I just get a back window. osgprerender cow.osg --fbo As yet I don't know why, other RTT effect like osgspotlight and osgshadow work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease
Hi Andy, This error was a missing check-in that has now been checked in. An svn update will fix this. Robert. On Fri, Apr 18, 2008 at 4:07 PM, Andy Skinner [EMAIL PROTECTED] wrote: On all three platforms on which I compiled, I got an error: FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera'. I just did svn update in my root directory before compiling. Should I have done something else? andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, April 18, 2008 9:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease Hi All, Many thanks for the the testing and feedback. Alas I'm afraid I'll now further testing as this morning I've checked in a couple of bug fixes that will need build and runtime testing. I also forgot to mention, the SVN version of the OSG is now under feature freeze, so only bug and build fixes from here on out to 2.4. Could users do an svn update, build and run to see if the SVN version is ready for 2.3.9? Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setHeight in DriveManipulator
You can control this with an environment variable. The following is from the OSG Reference Manual v2.2: 3.2.16 OSG_DRIVE_MANIPULATOR_HEIGHT Specifies the view offset from ground level that the DriveManipulator uses. The value is in world coordinate units. Valid values: Any floating-point number. Default value: 1.5 Hope that helps, -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dieter Pfeffer Sent: Friday, April 18, 2008 5:32 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] setHeight in DriveManipulator Hi, how can I set the height in DriveManipulator ? When I use setHeight, it has no effect, specially when I remove the intersectTraversal. When I look in the source code, I can't find how the height effects the calculation. Or do I miss something ? Thanks Dieter Unclassified Mail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Help]occlusion quey node does not work when theoccluder node is set cullface
OcclusionQueryNode works by performing occlusion tests against the contents of the depth buffer. If your ceiling is being face culled and therefore not writing into the depth buffer, then it shouldn't occlude the furniture, and OcclusionQueryNode should render them. If this isn't happening, something else must be wrong. Can you post a .osg file that reproduces the problem in osgviewer? -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of wangzhuhhjj Sent: Thursday, April 17, 2008 10:09 PM To: osg-users Subject: [osg-users] [Help]occlusion quey node does not work when theoccluder node is set cullface hi,guys I'm using occlusion query node of osg2.3.7 and it's wonderful. But I met a problem that I put the ceiling and floor of a room in root and the furnitures in room in occlusion query node. Then I set ceiling's face osg::CullFace::FRONT and floor as osg::CullFace::BACK, so that when I see from top of the floor, I can see the things in the room because the ceiling is culled, however when I see from in the room, I can also see the ceiling. Then the problem comes, when I use occlusion query node, I found that when I see from top of the room and the ceiling is culled, the furnitures in the room also don't render, I think the problem is that although the ceiling is culled, it can still occlude the furnitures. Because the floor and the ceiling is in the same node (different drawables) and can not placed in different group, so are there any methods to solve this kind of problem ? thanks a lot! shubo ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] When must you use SingleThreaded threading model
Hi J-S -- Perhaps I was being too precise. The question in the subject line is: When must you use SingleThreaded threading model? And the correct answer to that question is any time you must use code that isn't thread safe. :-) Instead, if the question were worded as: How can I avoid having to use SingleThreaded?, then certainly I would have phrased my answer similar to your post below. Thanks for providing that additional information. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Thursday, April 17, 2008 8:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] When must you use SingleThreaded threading model Hi Paul, In a nutshell, if any code executed by the cull or draw threads (such as your own callbacks or custom nodes) isn't thread safe, then you must use SingleThreaded. With all due respect, I would reword that: if any code executed by the cull or draw threads (such as your own callbacks or custom nodes) isn't thread safe, then you must... make it thread safe. Running the viewer/OSG code single threaded is just a workaround, not a solution. With multi-core machines being so widespread these days, I would say that running any moderate-to-large-sized app single threaded just doesn't cut it. And I think the OSG examples should show good practice, and as such whenever possible should show how to make things thread safe (if needed). J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prefor2.3.9devrelease
OK, latest SVN compiled on those same platforms. It is a good bit more work to try it out with our code, and I may wait until 2.3.9 for that. I don't expect a problem once it compiles, but I'll check it before 2.4. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Friday, April 18, 2008 11:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in prefor2.3.9devrelease On all three platforms on which I compiled, I got an error: FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera'. I just did svn update in my root directory before compiling. Should I have done something else? andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, April 18, 2008 9:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease Hi All, Many thanks for the the testing and feedback. Alas I'm afraid I'll now further testing as this morning I've checked in a couple of bug fixes that will need build and runtime testing. I also forgot to mention, the SVN version of the OSG is now under feature freeze, so only bug and build fixes from here on out to 2.4. Could users do an svn update, build and run to see if the SVN version is ready for 2.3.9? Thanks in advance, Robert. ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.3.9 developer release tagged, release candidate for OpenSceneGraph-2.4 stable.
Hi All, Many thanks for the build testing and assistance on getting bugs characterised and fixed. Virtue of these fixes we have stepped closer to OpenSceneGraph-2.4 stable release, and today's 2.3.9 developer release is release candidate for the final 2.4 stable release. Details on OpenSceneGraph-2.3.9 can be found at: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases * OpenSceneGraph-2.3.9, released on 18th April 2008. Now in feature freeze for imminent OpenSceneGraph-2.4 stable release, so only bug and build fixes have been made. OpenSceneGraph-2.3.9 is a release candidate for 2.4. source package : OpenSceneGraph-2.3.9.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.9 OpenSceneGraph Please test thoroughly on as many platforms as you can. If you find a problem please post to the list, and fixes to osg-submissions as whole files. With any fixes please double check that the fix doesn't have any unintended side effects as we are now just days away from 2.4. My plan is to let 2.3.9 be tested, and then based on feedback from this make another candidate release on Monday, then all going well make the release on Tuesday or Wednesday next week. The latest date for 2.4 is next Friday, otherwise we'll loose our window for another couple of weeks. Many thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9 dev release
Hi Daniel, I have made no changes to StateSet, not for a long time, last changes were in a submission back in December. I can only guess that you have mixed OpenGL versions such that the OSX OpenGL headers are setting GLenum to one thing, then another header such as from GLX is setting it to another i.e. something like ones long and ones uint. Robert. On Fri, Apr 18, 2008 at 7:45 PM, Daniel Moos [EMAIL PROTECTED] wrote: Hi Robert, I compiled the newest svn version under mac osx 10.5.2 with the existing xcode project without problems. But if i try to compile our application I get the following new error: Undefined symbols: osg::StateSet::setMode(unsigned int, unsigned int), referenced from: flowmenu::FlowMenu::FlowMenu(osg::ref_ptrflowmenu::FlowMenuViewConfig)in FlowMenu.o ld: symbol(s) not found Anyone have an idea what to do? I found the following link on a apple specific page... http://lists.apple.com/archives/X11-users/2005/Sep/msg00025.html Thanks for your great work. Daniel Moos Am 17.04.2008 um 16:44 schrieb Robert Osfield: Hi All, I'm planning to make a 2.3.9 dev release today. Could SVN users do an svn update and try out compile and build. I have just checked in updates to the Quicktime plugin from Stephan Huber, these will need to be tested by Windows and OSX users that use the Quicktime plugin. Thanks in advance for you efforts, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9 dev release
Hi Robert, Thanks to your answer. You describe the right problem. If i set the following parameter in the xcode project, the application was build successfully. Base SDK Path: $(DEVELOPER_SDK_DIR)/MacOSX10.4u.sdk Thanks, Daniel Moos Am 18.04.2008 um 21:26 schrieb Robert Osfield: Hi Daniel, I have made no changes to StateSet, not for a long time, last changes were in a submission back in December. I can only guess that you have mixed OpenGL versions such that the OSX OpenGL headers are setting GLenum to one thing, then another header such as from GLX is setting it to another i.e. something like ones long and ones uint. Robert. On Fri, Apr 18, 2008 at 7:45 PM, Daniel Moos [EMAIL PROTECTED] wrote: Hi Robert, I compiled the newest svn version under mac osx 10.5.2 with the existing xcode project without problems. But if i try to compile our application I get the following new error: Undefined symbols: osg::StateSet::setMode(unsigned int, unsigned int), referenced from: flowmenu ::FlowMenu::FlowMenu(osg::ref_ptrflowmenu::FlowMenuViewConfig)in FlowMenu.o ld: symbol(s) not found Anyone have an idea what to do? I found the following link on a apple specific page... http://lists.apple.com/archives/X11-users/2005/Sep/msg00025.html Thanks for your great work. Daniel Moos Am 17.04.2008 um 16:44 schrieb Robert Osfield: Hi All, I'm planning to make a 2.3.9 dev release today. Could SVN users do an svn update and try out compile and build. I have just checked in updates to the Quicktime plugin from Stephan Huber, these will need to be tested by Windows and OSX users that use the Quicktime plugin. Thanks in advance for you efforts, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setResizeNonPowerOfTwoHint supresses messages only?
Hi, Mike, Mike Greene wrote: While this did stop the messages from coming to the screen about the texture being resized, it did NOT seem to speed things up. I have two sets of texture sequences - one that is 800 x 600 and one that is 1024 x 512. The latter probably runs 10 times faster, even though there is more pixel information in the file. Does your hardware support the ARB_texture_non_power_of_two extension? If not, the textures will get resized anyway. You can also try using osg::TextureRectangle instead. The only issue here is that you'll have to switch to non-normalized texture coordinates for your geometry. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Some optimization of glActiveTexture
Hi Robert, there is currently some unoptimized code in the osg. If one do specify for example 10 texture attributes for a stateset like this: stateset-setTextureAttribute(i, new osg::Texture2D()); and after some time you remove this attributes, there is still an unneccessary call to glActiveTexture. So the OpenGL calls afterwards are looking like this: glBlah glBlah glActiveTexture(GL_TEXTURE0); glActiveTexture(GL_TEXTURE1); glActiveTexture(GL_TEXTURE2); ... glActiveTexture(GL_TEXTURE9); glBlah glBlah Even if this don't break any functionality it is just an unneeded pipeline state change, which can be removed I think. The problem is maybe in the PositionStateContainer, because this is the only one which do set texture active unit based on some lists. I'll try to track down this and maybe provide some optimization patch later. Or you can just take a look by yourself. Best regards, Art __ Gesendet von Yahoo! Mail. Der Mailbox mit unbegrenztem Speicher. 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
