Re: [osg-users] [vpb] Specifying a patch level lower than the maximum terrain level
Hi, Luc Claustres wrote: Hi, I've tested the patching capabilities of VPB and it seems to work almost good. However I have a question related to min/max level specification. I have generated a world at 500m resolution, specifying a max level of 16 (option : -l 16). Then I patched a country at resolution 15m specifying different levels : - without the -levels option, the 15m data always appear on top of the 450m data - with the -levels 10 16 option, the 15m data appear on top of the 450m data only starting from a given range (level 10) - with the -levels 6 10 option, the 15m data always appear on top of the 450m data except on the border of the patch where the 450m data seem to be used The following image summarizes this : [Image: http://claustres.lautre.net/upload/bug-niveau-3.png ] I wonder if the last thing is a bug or a normal behaviour ? Indeed, I expected that the 15m data will appear at a given range (level 6) then disappear (level 10) to let the 450m be there again. But maybe it is impossible to specify a end level lower than the maximum resolution of the terrain. Sorry, I cannot help with your question, but could you post the command lines you used to patch. I'm also interested in experimenting with it. I will add the procedure here, or you can if you want: http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/UsageExamples thanks jp Thank you! Cheers, Luc -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17383#17383 ___ 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] [build] OSX 10.6.1 Snow Leopard woes
E. Wing schrieb: I am not currently on the OSG track so I'm afraid I can't be much help at the moment. But be aware that in Snow Leopard, the default architecture is 64-bit (assuming you are on a 64-bit machine which almost all Intel Macs are now). All the Carbon stuff in osgViewerCarbon will likely not compile in 64-bit. I thought there was at least a preliminary Cocoa based viewer now, but I haven't been following. It seems like the Cocoa one needs to be made the default for just this problem that people are going to encounter over and over again. The cocoa backend is part of osg 2.9.x (Also, if my ImageIO plugin has not been integrated yet, now is the time do so so as the Quicktime plugin is also not going to work in 64-bit.) Also the imageio-plugin. Second, I don't know if the Xcode project is maintained anymore. It's maintained for 2.9.x but not tested with Snow leopard. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSX 10.6.1 Snow Leopard woes
hi, stefan nortd schrieb: Hi, I just updated to osx 10.6.1 snow leopard and ran into a couple of problems. (1) My old osg binaries (osg 2.8.2 compiled for the 10.5 sdk) work but I get a ton of warning (I also needed to update to xcode 3.2). They are all of the different visibility type. (2) Osg does not want to compile on osx 10.6. I tried both Xcode and Makefiles. And for each I tried the 10.5 and 10.6 sdk which does not seem to change the nature of the compilation error. The attached screenshots are the errors I get with xcode. The following code snippet is the errors I get with the Makefiles. It gets 25% into the build and fails with the osgViewer. Make sure you are compiling for 32bit only. The carbon backend in 2.8.x is not 64bit compatible. With snow-leopard the standard compiler is gcc 4.2x, try switching back to 4.0 if 32bit only doesn't help. Try the current svn-version of osg, it supports 64bit and has a better integrated cocoa-backend. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Give a specific color/material to a portion of a shape/geometry
Hi, I have try to find a specific solution to my problem but I really don't how to do it. I have an osg shape (I suppose that it could work on a 3d model from a 3D file). I would like to give a specific color to a portion of a shape (along an axis) using a begin distance and stop distance vectors describing the interval to render the geometry. I have looked at the osgClip example but when the geometry is FILL (and not LINE) the rendering is ugly. May be a specific state to activate ? Any idea ? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17407#17407 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSX 10.6.1 Snow Leopard woes
Hi Eric, Thanks for the hints. I was able to build osg for the most part now (i386, 10.5 sdk). I did not figure out why the int32_t typedef was missing though. I simple changed it in line 70 of the Atomic header file to singed long int. This did the trick for building osg with xcode. Code: #elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC) # volatile int32_t _value; volatile signed long int _value; The osgdb_qt quicktime plugin still does not build. I get two identical errors in the ReaderWriterQT.cpp. Code: /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgPlugins/quicktime/ReaderWriterQT.cpp:121:0 /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgPlugins/quicktime/ReaderWriterQT.cpp:121: error: extra qualification 'ReaderWriterQT::' on member 'ReaderWriterQT' Best, stefan PS: I am not sure what is up with the int32_t but I even get the same problem with the 2.9.5 dev release (i386, sdk 10.5, cocoa, imageio) stefan hechenberger http://linear.nortd.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17409#17409 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems port OSG 1.0 - 2.8.2; Can't embed viewer in external app
Hi Natasha,
I'm not familiar with GTK so can't help with this directly. As a general
comment I'd suggest doing the port in parts. So move the loading and
rendering across to an osgViewer::Viewer based app using osgViewer's native
windowing support, this will allow you to get something up on the screen and
a bit of exposure with the basics of the viewer. Then once you are happy
port across the using GTK by either using the window inhertiance or
subclassing from GraphicsWindow to provide a GraphicsWindowGTK. Window
inheritance is the route most similar to Producer's means of adapting to
other windowing toolkits.
Robert.
On Tue, Sep 15, 2009 at 6:19 PM, Natasha Westland westl...@ll.mit.eduwrote:
The osgviewerGTK example does work but that embeds the viewer in its own
application. I have tried modifying the OSGGTKDrawingArea class so that it
would work given my scenario but to no avail (for example, I can't just open
a gtk dialog when instantiating an OSGGTKDrawingArea object. I tried
modifying the appropriate methods so instead of creating a new window, it
embeds itself using the code in my below example but I get the same
behavior). The viewer is created, embedded in the GTK application and then
is never seen again.
The reason for the upgrade from OSG 1.0 to 2.8.2 was due to the upgrade of
our OS (from FC 5 to CentOS). The underlying libraries were newer and
mandated the upgrade. Thanks for the response.
Natasha
jp wrote:
Hi,
does the osgviewerGTK example work?
jp
Natasha Westland wrote:
Hello, I am having difficulties upgrading from OSG 1.0 to 2.8.2 (on
CentOS) and was hoping to tap into this wealth of knowledge after failing
miserably poking around the source code and attempting to retrofit the
example applications into my own. Using OSG 1.0, I have an application
which used an osgProducer to embed a viewer in another (GTK+ based)
application. Using the below approach, I am able to successfully render
images in the external application. In my attempt to port to OSG 2.8.2, I
am able to embed the viewer in the external application but I can't seem to
render any images. (I've tried simply changing the background color and
that doesn't work either.) Based on observations in the debugger, it
appears that my viewer may not be integrated properly with the gtk redrawing
thread of the external application due to the fact that the visible (black)
view is overdrawn by the external application at random times, and it is
never seen again. Any pointers would be greatly appreciated. Thanks!
Natasha westl...@ll.mit.edu _ Initialization of osgProducer viewer
using OSG 1.0: _osgProducer::Viewer viewer (BuildConfig());
viewer.setUpViewer (osgProducer::Viewer::SKY_LIGHT_SOURCE |
osgProducer::Viewer::HEAD_LIGHT_SOURCE |
osgProducer::Viewer::STATE_MANIPULATOR |
osgProducer::Viewer::STATS_MANIPULATOR |
osgProducer::Viewer::VIEWER_MANIPULATOR ); gtk_init (argc, argv);
// set the xid of the GtkSocket and connect the GtkPlug guint32 xid
= wGtkPlug;// gtksocket of external application GtkWidget *plug =
gtk_plug_new(xid); gtk_signal_connect(GTK_OBJECT(plug),
destroy-event, GTK_SIGNAL_FUNC(destroy_event), viewer); // set the
viewer to display in the plug
viewer.getCamera(0)-getRenderSurface()-setWindow(gtk_plug_get_id(GTK_PLUG(plug)));
// create a new thread to handle GTK events
pthread_create(gtk_thread, NULL, gtk_thread_loop, NULL);// create the
windows and run the threads.viewer.realize();while( !viewer.done()
) {viewer.sync();viewer.update(); // fire off
the cull and draw traversals of the scene. viewer.frame();
usleep(50); }Producer::CameraConfig*BuildConfig(void) {
Producer::RenderSurface *rs1 = new Producer::RenderSurface;
rs1-setScreenNum(0);rs1-setWindowName(external-app);
rs1-setWindowRectangle (0,0,640,480);Producer::Camera *camera1 =
new Producer::Camera;camera1-setRenderSurface(rs1);
camera1-setOffset( 0.0, 0.0 );rs1-setInputRectangle
(Producer::RenderSurface::InputRectangle(0.0,1.0,0.0,1.0));
Producer::InputArea *ia = new Producer::InputArea;
ia-addRenderSurface(rs1);Producer::CameraConfig *cfg = new
Producer::CameraConfig;cfg-addCamera(Camera 1,camera1);
cfg-setInputArea(ia);return cfg;} void
*gtk_thread_loop(void *arg) { gtk_main(); return NULL; }
_ Rendering the images in OSG 1.0 is implemented as follows (same for
OSG 2.8.2): __loadedModel = osgDB::readNodeFile(sName);if
(!_loadedModel) { viewer.setClearColor( osg::Vec4( 0.9f, 0.9f, 0.9f,
1.0) ); return 1;}viewer.setClearColor( osg::Vec4( 0.701961f,
0.862745f, 0.949020f, 1.0) );// optimize the scene graph, remove
rendundent nodes
Re: [osg-users] LineSegmentIntersector, IntersectionVisitor and children
Hi Julien-Charles, The interesection code only using the node bounding spheres during traversal, it doesn't use them for the final intersection calculation as this is done against the actual primitives of the drawable leaves. I can't say way is wrong with your setup, but it won't be a parental bounding sphere issue. Robert. On Tue, Sep 15, 2009 at 8:24 PM, Julien-Charles Levesque levesque...@gmail.com wrote: Hi, I am using LineSegmentIntersectors with IntersectionVisitor to do some ray casting in my architecture. Everything works fine to select and move objects. However I want to implement a drag-and-drop interaction, where I can move an object onto another and have something different happen. I want to obtain this object using the ray casting as well, so I cast a ray and check to get the first object in Intersections that is not my current object (which I saved in a member variable at the beginning of my drag-and-drop). It all works fine until I start interacting with parent/child objects. I have a sphere and a cube, the sphere is the parent of the cube. When I drag-and-drop my cube over black space, the IntersectionVisitor returns me the sphere (the parent) as the second object intersected even though there is nothing behind the cube at the place I dropped it. Now I believe this has something to do with the parent's bounding sphere including it's children and thus being counted as an intersection, but I'm not sure how I can deal with this kind of stuff. Then again, I could be mistaken. I tried reading about bounding spheres in the reference guide and did not see much, neither could I get much information (or enough information ;) about IntersectionVisitors.. any help would be strongly appreciated ! Thanks in advance ! Sincerely, Julien-Charles -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17395#17395 ___ 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] Huge triangle mesh / Geometry Clipmap
Hi David, I used to work in the oil-gas sector so I'm rather familiar with needs for visualizing large seismic horizon meshes, albeit a bit rusty - it was last century that I did the work :-) VPB and osgEarth aren't likely to be too helpful for you as they really aren't geared up for the quite specific type of needs you have. What route you take depends upon some of the constraints that you might be able to put upon the geometry. For instance, is it a regular grid with holes, or does this mesh need to be an irregular triangle mesh? Robert. On Tue, Sep 15, 2009 at 8:40 PM, David Angelo vonengel.gro...@googlemail.com wrote: Hi folks, I am starting to work on a project, where I have to render and manipulate huge triangle meshes (~200 mio. vertices). The meshes are seismic horizons, which are quite similar to ordinary terrain meshes. However, theses meshes can and will have holes. I think both VPN and osgEarth (which are pretty cool and I used them in different contexts) are not suited for this purpose. For the rendering part, my first idea was to use the Geometry Clipmap: http://research.microsoft.com/en-us/um/people/hoppe/geomclipmap.pdf technique by Losasso Hoppe. Has anybody already implemented it (preferably with OSG), or does anybody know if this technique supports meshes with holes? Perhaps an integration of this technique into VPB would also be worth thinking of. What do you think? Cheers, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Give a specific color/material to a portion of a shape/geometry
Hi Miguel, I can't really make out what you exactly want, but at a guess multi-texturing and texgen might well be one route to look into. Have a look at the osgtexture1D example. Robert. On Wed, Sep 16, 2009 at 9:13 AM, Miguel Lokida mlok...@yahoo.fr wrote: Hi, I have try to find a specific solution to my problem but I really don't how to do it. I have an osg shape (I suppose that it could work on a 3d model from a 3D file). I would like to give a specific color to a portion of a shape (along an axis) using a begin distance and stop distance vectors describing the interval to render the geometry. I have looked at the osgClip example but when the geometry is FILL (and not LINE) the rendering is ugly. May be a specific state to activate ? Any idea ? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17407#17407 ___ 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] [osgPPU] Precision in osgPPU
Hi everyone, I would like to use osg PPU to compute very accurate data, about ten number behind the comma, to avoid numerical errors. So I used 32 bits textures for the render to texture : texture2D-setInternalFormat(GL_RGBA32F_ARB); texture2D-setSourceFormat(GL_RGBA); texture2D-setSourceType(GL_FLOAT); texture2D-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setWrap(osg::Texture2D::WRAP_R,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST); texture2D-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::NEAREST); But I noticed, by exemple, when I put the value 0.012024048 in one shader (gl_FragColor = vec(0.012024048, 0.012024048, 0.012024048, 1.0);), the value read in the next shader becomes 0.012023926. I checked the values twice, once with the glsl Devil debugger, once with an UnitOutCapture. Is there a way to have more precision for my data ? Thanks in advance, Josselin. This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with cameras of stereo mode
Hi, At first, sorry if my english is bad. I'm using stereo mode in a project with horizontal split option and I need adjust the cameras of right and left eye. In other words, I need to move left or right eye camera X in vertical and Y in horizontal while the program is running without move the other eye camera and I don't find the code to access to these cameras. Thank you! Cheers, Samuel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17408#17408 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSX 10.6.1 Snow Leopard woes
Hi Stefan, there are still some patches for osg snow-leopard in the submission-queue, try to switch to the gcc 4.0-compiler in the project settings. This should give you the same results as for Leopard. HTH, Stephan stefan nortd schrieb: Hi Eric, Thanks for the hints. I was able to build osg for the most part now (i386, 10.5 sdk). I did not figure out why the int32_t typedef was missing though. I simple changed it in line 70 of the Atomic header file to singed long int. This did the trick for building osg with xcode. Code: #elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC) # volatile int32_t _value; volatile signed long int _value; The osgdb_qt quicktime plugin still does not build. I get two identical errors in the ReaderWriterQT.cpp. Code: /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgPlugins/quicktime/ReaderWriterQT.cpp:121:0 /Users/noema/Downloads/OpenSceneGraph-2.8.2/src/osgPlugins/quicktime/ReaderWriterQT.cpp:121: error: extra qualification 'ReaderWriterQT::' on member 'ReaderWriterQT' Best, stefan PS: I am not sure what is up with the int32_t but I even get the same problem with the 2.9.5 dev release (i386, sdk 10.5, cocoa, imageio) stefan hechenberger http://linear.nortd.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17409#17409 ___ 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] [osgPPU] Precision in osgPPU
Hi, josselin.pe...@lcpc.fr wrote: Hi everyone, I would like to use osg PPU to compute very accurate data, about ten number behind the comma, to avoid numerical errors. I don't think you will reach this with single precision floating point. So I used 32 bits textures for the render to texture : texture2D-setInternalFormat(GL_RGBA32F_ARB); texture2D-setSourceFormat(GL_RGBA); texture2D-setSourceType(GL_FLOAT); texture2D-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setWrap(osg::Texture2D::WRAP_R,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST); texture2D-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::NEAREST); But I noticed, by exemple, when I put the value 0.012024048 in one shader (gl_FragColor = vec(0.012024048, 0.012024048, 0.012024048, 1.0);), the value read in the next shader becomes 0.012023926. I checked the values twice, once with the glsl Devil debugger, once with an UnitOutCapture. What video card do you have? Is there a way to have more precision for my data ? Two options maybe: 1) Double precision float path. You will have to first get hardware that supports it and I think you will probably have to look at CUDA. I'm not sure which cards do this, have a look at the CUDA documentation. Other problem is that I don't know of double precision floating point texture formats that will work easily with OSG. 2) If your data can be split (ito precision) across multiple colour channels you might be able to do some arithmetic in shaders yourself. See also here: http://www.gpgpu.org/wiki/FAQ I don't have much experience with either of 2 options above, so if someone else has some concrete info I would also be interested. rgds jp Thanks in advance, Josselin. This message was sent using IMP, the Internet Messaging Program. ___ 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] [build] OSX 10.6.1 Snow Leopard woes
On 16-09-2009, at 10:15, stefan nortd wrote: Hi Eric, Thanks for the hints. I was able to build osg for the most part now (i386, 10.5 sdk). I did not figure out why the int32_t typedef was missing though. I simple changed it in line 70 of the Atomic header file to singed long int. This did the trick for building osg with xcode. I managed to compile/run most of OSG under OS X 10.6.1 with the 10.6 SDK in 32 bit, using Cocoa and ImageIO plugin. Please be aware of a bug in cmake that does not set the architecture properly if you specify that you only want 32-bit. See http://public.kitware.com/Bug/view.php?id=9466 . Code: #elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC) # volatile int32_t _value; volatile signed long int _value; I also encountered that using gcc 4.2 cmake detected both _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS and _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC and that leads to a logic error in conditional compilation of the current Openthread/Atomic header. Attached file fixes this logic error. Atomic Description: Binary data Cheers, Erik den Dekker___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Give a specific color/material to a portion of a shape/geometry
Here 's what I obtain. But I would like to use FILL despite of LINE for the rest of the shape. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17417#17417 attachment: ScreenShot002.jpgattachment: ScreenShot001.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] Precision in osgPPU
Hi jp, Thanks for your quick answer :) I'm working with a nVidia GeForce 280, so I think it's ok for 32 bits textures and Cuda. Thanks too for your two propositions. I'll tell you if one works... Josselin. This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Far Nodes - geometry as background
OK, I'm trying now using local cameras as proposed by Robert. What I do : I put somewhere in my scene graph a camera, setting it as PRE_RENDER, and setting its setReferenceFrame to RF_RELATIVE. When doing this, I notice the local cam get the main cam matrix, which is a good behavior for me (at beginning I was setting it to RF_ABSOLUTE, and so need to write a cullcallback when I grab the main ca matrix and copy it to my local cam...). What I notice is : I DO NOT need to set the ClearMask on the viewer's master Camera to just clear the depth buffer, maybe because OSG do like this : 1. clear the buffers corresponding to main cam attributes 2. clear the buffers corresponding to local cam attributes 3. render the nodes which are child of my local cam 4. render the other nodes Maybe this behaviour occurs because my local cam is a child on the root to which the main cam is applied, isn't it ? I'm now in front of another problem : the z buffer precision, because, if I understand well, such a scene graph do that my main camera take ALL the scene to computes its near and far planes... - to refresh your mind, the nodes under the local cam are designed to be very far in the scene - Is there any simple way to tell to the main cam to avoid traversing the local cam's children when computing its near/far planes ? I know that the osgdepthpartition is a good point to start, but it's a bit complicated and single threaded designed (don't know where the problems appear with multi threads in this example). thanks Eric -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17421#17421 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPPU] Precision in osgPPU
Hi Josselin, as J.P. already said, I think your problem is that single precision float values are not enough to be precise for the tenth number behind the comma. There is no OpenGL texture format which can support double textures. There exists only 32bit single precision float format. Maybe some of the vendor OpenGL extensions do support such texture, but I think no. CUDA does support native double values, however only if you GPU does also support them, so having CUDAs computing capability of at least 1.3, I think. Currently this works only on G200 GPUs. So, if you wish to work with OpenGL, then think on the way how either to: - overcome your precision problem (i.e. move the comma to the right): very easy to implement, however precision get lost when having large numbers before comma - analyze your algorithm and maybe start to use 32bit integers (very common in µC programming), because they can represent any value between -2^16 to 2^16, so you have at least 9 numbers for your precision): I agree that using integers instead of floats in a GLSL shader is somehow a big misuse and might not work, but why not ;) - or pack your doubles in two floats and think on how to use the packed values in your computations Cheers, art P.S. In a lot of cases researches complain that they have not enough precision. However in most such cases the precision problem can be solved by analyzing and changing the algorithm to use the given hardware setup in more efficient way. josselin wrote: Hi everyone, I would like to use osg PPU to compute very accurate data, about ten number behind the comma, to avoid numerical errors. So I used 32 bits textures for the render to texture : texture2D-setInternalFormat(GL_RGBA32F_ARB); texture2D-setSourceFormat(GL_RGBA); texture2D-setSourceType(GL_FLOAT); texture2D-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setWrap(osg::Texture2D::WRAP_R,osg::Texture2D::CLAMP_TO_BORDER); texture2D-setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST); texture2D-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::NEAREST); But I noticed, by exemple, when I put the value 0.012024048 in one shader (gl_FragColor = vec(0.012024048, 0.012024048, 0.012024048, 1.0);), the value read in the next shader becomes 0.012023926. I checked the values twice, once with the glsl Devil debugger, once with an UnitOutCapture. Is there a way to have more precision for my data ? Thanks in advance, Josselin. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17422#17422 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with cameras of stereo mode
Hi Samuel,
Currently the stereo is implemented by the low level osgUtil::SceneView
class, which has a ComputeStereoMatricesCallback that you can use (from
include/osgUtil/SceneView) :
/** Callback for overidding the default method for compute the
offset projection and view matrices.*/
struct ComputeStereoMatricesCallback : public osg::Referenced
{
virtual osg::Matrixd computeLeftEyeProjection(const
osg::Matrixd projection) const = 0;
virtual osg::Matrixd computeLeftEyeView(const osg::Matrixd
view) const = 0;
virtual osg::Matrixd computeRightEyeProjection(const
osg::Matrixd projection) const = 0;
virtual osg::Matrixd computeRightEyeView(const osg::Matrixd
view) const = 0;
};
void setComputeStereoMatricesCallback(ComputeStereoMatricesCallback*
callback) { _computeStereoMatricesCallback=callback; }
ComputeStereoMatricesCallback* getComputeStereoMatricesCallback() {
return _computeStereoMatricesCallback.get(); }
const ComputeStereoMatricesCallback*
getComputeStereoMatricesCallback() const { return
_computeStereoMatricesCallback.get(); }
You can get access to the SceneView via the osgViewer::Renderer, and the
Render you'll find attached to the viewers main camera.
The other approach is to not use the low stereo support of the OSG, and just
implement the stereo yourself using Viewer slave Camera's, this is how I'd
tackle it these days. The low level SceneView stereo support dates back to
the early days of the OSG, and awaits replacement by provide convenience
functions for setup of stereo using slave Camera's in osgViewer.
Good luck,
Robert.
On Wed, Sep 16, 2009 at 9:13 AM, Samuel Jarque samuel.jar...@gmail.comwrote:
Hi,
At first, sorry if my english is bad.
I'm using stereo mode in a project with horizontal split option and I need
adjust the cameras of right and left eye. In other words, I need to move
left or right eye camera X in vertical and Y in horizontal while the program
is running without move the other eye camera and I don't find the code to
access to these cameras.
Thank you!
Cheers,
Samuel
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17408#17408
___
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] [forum] 600 Forum members (+some statistics)
Hi folks, The next hundred users are now registered on our forum. Here are current and last statistics: June, 2009: 1865 mailing list users. 508 forum users Overlap of 143 Total amount of users: 2230 users September, 2009: 1865 mailing list users, 601 forum users Overlap of 159 users Total amount of users: 2307 users --- Percentage: total amount raised by 3.5% number of ML users grew by 0.0% number of forum users grew by 18.3% --- Have a nice day, forum-team -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17424#17424 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Threading
Hi Jason Robert,
Thanks for the reply. When I set viewer.setDone(true) the osg window(scene)
is closing. I want the OSGWindow should be operational(running) and wants to
work with my rest of the application.
[color=orange]Class1[/color]
{
Class2 scene;
// My applicaion
(c++ stuff)
...
...
scene.display();
(After displaying the the scene wants to continue with my application )
.
.
.
}
[color=orange]Class2[/color] // class for displaying the scene and geometry
{
void disply()
{
// Here i have the code for setting up viewer and displaying geometry
osgViewer viewer;
...
...
After everything finishes wants to display viewer
for ex I have done this
viewer.run();
or
while (!viewer.done())
{
viewer.frame()
}
return 0; // wants to reach this point with osg is running
} // After display wants to go back to parent class(Class1)
}
When i done viewer.frame() or viewer.run() or what ever I am in inside osg main
loop. Hence I am not able to go back and continue with my application. I know
that with viewer.setDone(true) , able to come out of loop but without
osgwindow(scene).
Is there any way to display osg scene and continue with my rest of the
application??
Is it possible for displaying the scene with out going into osg main loop??
Any Idea??
Thank you!
Cheers,
Prasad
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17425#17425
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Give a specific color/material to a portion of a shape/geometry
I try to use a 1DTexture (basing on the example) but when I want to apply it to a osg::cone, I can 't apply it correctly from the top to the basis of the cone (without any repeat or mirror) . I try to use texgen but the map didn't fit on the surface cone and, I don't find any example about it. How can it be done correctly ? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17426#17426 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Give a specific color/material to a portion of a shape/geometry
Hi Miguel, If you want fine control of texture coordinates then you are probably best to create the geometry yourself rather than use the ShapeDrawable as it really isn't resigned for this type of work. See the osggeometry example. Robert. On Wed, Sep 16, 2009 at 2:07 PM, Miguel Lokida mlok...@yahoo.fr wrote: I try to use a 1DTexture (basing on the example) but when I want to apply it to a osg::cone, I can 't apply it correctly from the top to the basis of the cone (without any repeat or mirror) . I try to use texgen but the map didn't fit on the surface cone and, I don't find any example about it. How can it be done correctly ? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17426#17426 ___ 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] [osgPPU] Precision in osgPPU
Art Tevs wrote: - analyze your algorithm and maybe start to use 32bit integers (very common in µC programming), because they can represent any value between -2^16 to 2^16, so you have at least 9 numbers for your precision): I agree that using integers instead of floats in a GLSL shader is somehow a big misuse and might not work, but why not ; The more recent GLSL versions shouldn't have problems with integers. Just use ivec4 instead of vec4. For textures, just use INT_SAMPLER_xD or UNSIGNED_INT_SAMPLER_xD in osg::Unform. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Threading
Prasad Pokala wrote:
Hi Jason Robert,
Thanks for the reply. When I set viewer.setDone(true) the osg window(scene) is closing. I want the OSGWindow should be operational(running) and wants to work with my rest of the application.
[color=orange]Class1[/color]
{
Class2 scene;
// My applicaion
(c++ stuff)
...
...
scene.display();
(After displaying the the scene wants to continue with my application )
.
.
.
}
[color=orange]Class2[/color] // class for displaying the scene and geometry
{
void disply()
{
// Here i have the code for setting up viewer and displaying geometry
osgViewer viewer;
...
...
After everything finishes wants to display viewer
for ex I have done this
viewer.run();
or
while (!viewer.done())
{
viewer.frame()
}
return 0; // wants to reach this point with osg is running
} // After display wants to go back to parent class(Class1)
}
When i done viewer.frame() or viewer.run() or what ever I am in inside osg main
loop. Hence I am not able to go back and continue with my application. I know
that with viewer.setDone(true) , able to come out of loop but without
osgwindow(scene).
Is there any way to display osg scene and continue with my rest of the application??
Is it possible for displaying the scene with out going into osg main loop??
Does your program already have a loop that constantly calls that
disply() method? If so, then all you should need to do is have a single
call to viewer.frame() at the end (there's no need to create another
loop if you're already looping).
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems port OSG 1.0 - 2.8.2; Can't embed viewer in external app
Natasha Westland wrote: The osgviewerGTK example does work but that embeds the viewer in its own application. I have tried modifying the OSGGTKDrawingArea class so that it would work given my scenario but to no avail (for example, I can't just open a gtk dialog when instantiating an OSGGTKDrawingArea object. I tried modifying the appropriate methods so instead of creating a new window, it embeds itself using the code in my below example but I get the same behavior). The viewer is created, embedded in the GTK application and then is never seen again. The reason for the upgrade from OSG 1.0 to 2.8.2 was due to the upgrade of our OS (from FC 5 to CentOS). The underlying libraries were newer and mandated the upgrade. Thanks for the response. Natasha, I read through the code, and I realized that I missed the part about it being two different applications using GtkPlug and GtkSocket. Just curious, have you verified that the plug/socket works with a simple OpenGL application in CentOS 5? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render FBOs with main camera disabled - possible?
Hi JP, thanks, it seems to work. Attached a simple test app modified from osgscreencapture. If with vsync on (60Hz) I render one pbo and then 1 normal, the stats report 120fps, 2 pbo and 1 normal gives 180fps... Excellent, good to know it worked out. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Threading
Hi Jason, I do not have a loop but I will call display() when ever is required. When I wrote only viewer.frame() as soon as it come out of display() the osgwindow(scene) is closing. I want osgwindow(scene) should be running after display() Thank you! Cheers, Prasad -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17434#17434 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Threading
Hi Prasad, I do not have a loop but I will call display() when ever is required. When I wrote only viewer.frame() as soon as it come out of display() the osgwindow(scene) is closing. Well of course if your viewer instance goes out of scope at the end of display(), the viewer will close. You need to keep the viewer in an osg::ref_ptrosgViewer::Viewer in your class. Then YourClass::display() can call viewer-frame() and your app can call YourClass::display() when it needs to. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgCompute] oscOpenCL?
Hi Folks, New to OSG but osgCompute is incredibly exciting to me. I see that there is some CUDA action happening but was hoping to here about in progress or planned support for OpenCL as well. Has anyone started working with OpenCL yet? Cheers, Chip -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17401#17401 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] oscOpenCL?
Chip Collier wrote: Hi Folks, New to OSG but osgCompute is incredibly exciting to me. I see that there is some CUDA action happening but was hoping to here about in progress or planned support for OpenCL as well. Has anyone started working with OpenCL yet? Not yet. Nvidia won't give me the drivers... (and I'm not registering to be a developer again, because they completely ignored me last time). --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Huge triangle mesh / Geometry Clipmap
Hi Robert, hi folks, last century. ;-) Good to have an expert in this area. About VPB and osgEarth. I think so too. Nevertheless, they are both great tools! Thumbs up for the developers. The input data I currently have is a regular grid with holes. At the moment support for irregular meshes is not needed. All mesh manipulationa will be based on the regular grid. Do you have a hint how to efficiently triangulate this regular grid with holes? Since the resulting mesh will be pretty big and may not fit in the texture memory (I also have to share resources with a ravenous volume renderer), my first thought was using a continious LOD (no popping) approach. Does anybody have experience with such an algorithm? This algorithm may also be interesting for VPB. Ah, I almost forgot, the hole algorithm must be an out-of-core solution. So most propably I need to do paging at least between the main memory and the texture memory. Paging between hard disk and main memory may not be needed, since they normally have machines with quite a lot of memory. Thanks in advance for your comments. Cheers, David On Wed, Sep 16, 2009 at 10:27 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi David, I used to work in the oil-gas sector so I'm rather familiar with needs for visualizing large seismic horizon meshes, albeit a bit rusty - it was last century that I did the work :-) VPB and osgEarth aren't likely to be too helpful for you as they really aren't geared up for the quite specific type of needs you have. What route you take depends upon some of the constraints that you might be able to put upon the geometry. For instance, is it a regular grid with holes, or does this mesh need to be an irregular triangle mesh? Robert. On Tue, Sep 15, 2009 at 8:40 PM, David Angelo vonengel.gro...@googlemail.com wrote: Hi folks, I am starting to work on a project, where I have to render and manipulate huge triangle meshes (~200 mio. vertices). The meshes are seismic horizons, which are quite similar to ordinary terrain meshes. However, theses meshes can and will have holes. I think both VPN and osgEarth (which are pretty cool and I used them in different contexts) are not suited for this purpose. For the rendering part, my first idea was to use the Geometry Clipmap: http://research.microsoft.com/en-us/um/people/hoppe/geomclipmap.pdf technique by Losasso Hoppe. Has anybody already implemented it (preferably with OSG), or does anybody know if this technique supports meshes with holes? Perhaps an integration of this technique into VPB would also be worth thinking of. What do you think? Cheers, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Huge triangle mesh / Geometry Clipmap
Have you looked into streaming meshes? I've only looked at them briefly, but they look somewhat related. Brian 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-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: David Angelo vonengel.gro...@googlemail.com Sent by: osg-users-boun...@lists.openscenegraph.org Date: 09/16/2009 03:26PM Subject: Re: [osg-users] Huge triangle mesh / Geometry Clipmap Hi Robert, hi folks, last century. ;-) Good to have an expert in this area. About VPB and osgEarth. I think so too. Nevertheless, they are both great tools! Thumbs up for the developers. The input data I currently have is a regular grid with holes. At the moment support for irregular meshes is not needed. All mesh manipulationa will be based on the regular grid. Do you have a hint how to efficiently triangulate this regular grid with holes? Since the resulting mesh will be pretty big and may not fit in the texture memory (I also have to share resources with a ravenous volume renderer), my first thought was using a continious LOD (no popping) approach. Does anybody have experience with such an algorithm? This algorithm may also be interesting for VPB. Ah, I almost forgot, the hole algorithm must be an out-of-core solution. So most propably I need to do paging at least between the main memory and the texture memory. Paging between hard disk and main memory may not be needed, since they normally have machines with quite a lot of memory. Thanks in advance for your comments. Cheers, David On Wed, Sep 16, 2009 at 10:27 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi David, I used to work in the oil-gas sector so I'm rather familiar with needs for visualizing large seismic horizon meshes, albeit a bit rusty - it was last century that I did the work :-) VPB and osgEarth aren't likely to be too helpful for you as they really aren't geared up for the quite specific type of needs you have. What route you take depends upon some of the constraints that you might be able to put upon the geometry. For instance, is it a regular grid with holes, or does this mesh need to be an irregular triangle mesh? Robert. On Tue, Sep 15, 2009 at 8:40 PM, David Angelo vonengel.gro...@googlemail.com wrote: Hi folks, I am starting to work on a project, where I have to render and manipulate huge triangle meshes (~200 mio. vertices). The meshes are seismic horizons, which are quite similar to ordinary terrain meshes. However, theses meshes can and will have holes. I think both VPN and osgEarth (which are pretty cool and I used them in different contexts) are not suited for this purpose. For the rendering part, my first idea was to use the Geometry Clipmap: http://research.microsoft.com/en-us/um/people/hoppe/geomclipmap.pdf technique by Losasso Hoppe. Has anybody already implemented it (preferably with OSG), or does anybody know if this technique supports meshes with holes? Perhaps an integration of this technique into VPB would also be worth thinking of. What do you think? Cheers, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] Huge triangle mesh / Geometry Clipmap
David Angelo wrote: Since the resulting mesh will be pretty big and may not fit in the texture memory (I also have to share resources with a ravenous volume renderer), my first thought was using a continious LOD (no popping) approach. Does anybody have experience with such an algorithm? This algorithm may also be interesting for VPB. Most CLOD algorithms dislike holes. I know Robert's preference in VPB is to avoid CLOD in favor of discrete LODs (DLOD?). CLODs require dynamic geometries and discrete LODs require only the shoving of big chunks of triangles around. On-GPU CLOD might be a nice approach, but the DLOD approach has served very well with current graphics hardware that might bottleneck on CPU-served CLOD geometry. Whether CLOD or DLOD, You might consider filling the holes in your dataset with interpolated values, then using texturing to knock visible holes into the surface. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Huge triangle mesh / Geometry Clipmap
For the streaming mesh have you had a look at http://www.cs.unc.edu/~isenburg/sd/ It's by the same team that did the famous 'triangle' program - but this is free (MIT licence) Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17440#17440 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
