Re: [osg-users] thousands spheres renedering with OSG
Hi Robert, thanks for the explanation. I always confuse culling (not visible because it is out of the view frustum?) with occluding (not visible due to object being in front of it?). Best regards, Himar. 2009/7/2 Robert Osfield robert.osfi...@gmail.com Hi Himar, On Thu, Jul 2, 2009 at 6:08 PM, Himar Carmonahimarcarm...@gmail.com wrote: Disabling culling may help? If your bottleneck is culling, perhaps the GPU would eat them all without problems. Of course you will render a lot of geometry you will not see, but you will avoid a lot of CPU computation. Fast and dirty test. If you are not happy, then you can take the other approachs. Disabling culling will do nothing as the OSG already only does cull tests when subgraphs are partially culled - if the subgraph is entirely within the view frustum the view frustum test if switched off. The majority of the cull traversal time in Mikhail's case will simple by traversing a big scene graph and they creating a big rendering graph to rendering it. 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] Read number of Pixels an object takes up
Hi guys, On 3/7/09 12:48 AM, Jeremy Warren wrote: -- From: Robert Osfield robert.osfi...@gmail.com Sent: Wednesday, July 01, 2009 3:18 AM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Read number of Pixels an object takes up Hi Jeremy, The OSG now has support of OpenGL occlusion query that can provide the number of pixels covered when rendering. See osgocclusionquery example. Robert. On Wed, Jul 1, 2009 at 12:35 AM, Jeremy Warrenjw...@hotmail.com wrote: I have a simple scene. Colored background and an object, say a box. I want to figure out how many pixels the box is taking up in the scene. It seems like a simple request, but haven't come up with any solution. Any takers? While we're on the subject: for simple objects, say a sphere or an AABB, shouldn't it be possible to do this calculation quicker on the CPU without going to the GPU? Isn't something like this done for small feature culling? I'm thinking of projecting the object's dimensions (radius or width/height) into pixel space and working from there. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Forum total crash :(
Hi folks, I am unhappy to say, but our server had today at night a total crash. None of our virtual machines is accessable from the outside and hence forum do also not work. I appologize for such circumstances and hope, yes I really hope, that the web-data doesn't get lost ;( I installed automatic backup routines, however they had backed up the data on the second hard drive on the root server as also on other virtual machines. Please, cross your fingers, that nothing happened to the hard drives on the root server, because I has no local copy of the data :( As soon as forum is again online, I will let you know. Cheers and hope the best, Art ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rendering many instances of big Geometries
Hi all, There was a thread recently about rendering many instances of spheres (I didn't want to hijack the thread so I created a new one). Many methods were proposed among which there were opengl pseudo instancing and the draw_instanced extension. First I would like to know the main differences between these two (both in the principle and in terms of efficiency). just for the record, I've read the Nvidia paper given by Christian, http://download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf and it seems that the pseudo instancing methods will be worth only when each instance contains few vertices (less than 50). This constraint won't cause any trouble for a sphere, I guess. Is it the same with the draw_instanced extension? And then what would be the best approach to render many instances of a big geometry (eg thousands of vertices per instance)? Last, are those instancing methods worth even if the geometry is static, or is it more efficient to use DisplayList or VBO? I know there must not be general answers depending on many aspects (as the Graphics card, the driver, etc.) but I am looking forward to get a bit of your expertise in that matter. Thanks in advance. Loïc PS: I'm not very skilled in openGL so don't hesitate to explain things that seems very basic about all those concepts ( like instancing, VBO, displayList). Hopefully this will be also useful for other osg newbies like me. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] rendering many instances of big Geometries
Hi Loic, Optimizing drawing lots of large geometries depends upon lots of factors, both hardware and software. It really is a very open ended topic, so could you qualify what you mean by lots and large a bit more carefully, and also are the geometries all the same, same geometry/different state, different geometries/same state, different geometries and different state. I tend to see lots of nodes/geometries as being in the order of magnitude of 10,000+, and large geometries as being 100,000+ vertices. Modern graphics cards can comfortably do 1,000,000 vertices per frame at 60Hz, but only if you drive it efficiently - so using VBO's and batching the geometries efficiently (avoiding too small geometries). Culling, state sorting and lazy state updating are all crucial factors in getting good performance. With such an open ended topic I can't really add much more, you'll need to explain much more specifically about the type of problem you are trying to solve and the amount of state, nodes and geometry that you are dealing with. Robert. On Fri, Jul 3, 2009 at 11:07 AM, Simon Loicsimon1l...@gmail.com wrote: Hi all, There was a thread recently about rendering many instances of spheres (I didn't want to hijack the thread so I created a new one). Many methods were proposed among which there were opengl pseudo instancing and the draw_instanced extension. First I would like to know the main differences between these two (both in the principle and in terms of efficiency). just for the record, I've read the Nvidia paper given by Christian, http://download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf and it seems that the pseudo instancing methods will be worth only when each instance contains few vertices (less than 50). This constraint won't cause any trouble for a sphere, I guess. Is it the same with the draw_instanced extension? And then what would be the best approach to render many instances of a big geometry (eg thousands of vertices per instance)? Last, are those instancing methods worth even if the geometry is static, or is it more efficient to use DisplayList or VBO? I know there must not be general answers depending on many aspects (as the Graphics card, the driver, etc.) but I am looking forward to get a bit of your expertise in that matter. Thanks in advance. Loïc PS: I'm not very skilled in openGL so don't hesitate to explain things that seems very basic about all those concepts ( like instancing, VBO, displayList). Hopefully this will be also useful for other osg newbies like me. ___ 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] rendering many instances of big Geometries
Thanks Robert for trying to get into the problem. I wanted to let it opened in order to get as many opinion/possible oprimizations as possible. To be truly honest I have a real problem with specific conditions. Many instances refers to hundreds of them. Large geometries are about 10 000 to 100 000 vertices. All the instances have the same geometry (which is static), and the same stateset. cheers, Loïc On Fri, Jul 3, 2009 at 10:19 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Loic, Optimizing drawing lots of large geometries depends upon lots of factors, both hardware and software. It really is a very open ended topic, so could you qualify what you mean by lots and large a bit more carefully, and also are the geometries all the same, same geometry/different state, different geometries/same state, different geometries and different state. I tend to see lots of nodes/geometries as being in the order of magnitude of 10,000+, and large geometries as being 100,000+ vertices. Modern graphics cards can comfortably do 1,000,000 vertices per frame at 60Hz, but only if you drive it efficiently - so using VBO's and batching the geometries efficiently (avoiding too small geometries). Culling, state sorting and lazy state updating are all crucial factors in getting good performance. With such an open ended topic I can't really add much more, you'll need to explain much more specifically about the type of problem you are trying to solve and the amount of state, nodes and geometry that you are dealing with. Robert. On Fri, Jul 3, 2009 at 11:07 AM, Simon Loicsimon1l...@gmail.com wrote: Hi all, There was a thread recently about rendering many instances of spheres (I didn't want to hijack the thread so I created a new one). Many methods were proposed among which there were opengl pseudo instancing and the draw_instanced extension. First I would like to know the main differences between these two (both in the principle and in terms of efficiency). just for the record, I've read the Nvidia paper given by Christian, http://download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf and it seems that the pseudo instancing methods will be worth only when each instance contains few vertices (less than 50). This constraint won't cause any trouble for a sphere, I guess. Is it the same with the draw_instanced extension? And then what would be the best approach to render many instances of a big geometry (eg thousands of vertices per instance)? Last, are those instancing methods worth even if the geometry is static, or is it more efficient to use DisplayList or VBO? I know there must not be general answers depending on many aspects (as the Graphics card, the driver, etc.) but I am looking forward to get a bit of your expertise in that matter. Thanks in advance. Loïc PS: I'm not very skilled in openGL so don't hesitate to explain things that seems very basic about all those concepts ( like instancing, VBO, displayList). Hopefully this will be also useful for other osg newbies like me. ___ 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] rendering many instances of big Geometries
Hi Simon, On Fri, Jul 3, 2009 at 11:35 AM, Simon Loicsimon1l...@gmail.com wrote: Thanks Robert for trying to get into the problem. I wanted to let it opened in order to get as many opinion/possible oprimizations as possible. I'm afraid we don't all have to time to write treaties on the topics of performance optimization - it's a huge topic. To be truly honest I have a real problem with specific conditions. Many instances refers to hundreds of them. OK, so traversals shouldn't be too slow then, so you shouldn't need to batch more coasely. It might be that you might want to divide your scene graph up more for better culling performance, and a existing modest number of scene graph nodes will give you scope to do this. Large geometries are about 10 000 to 100 000 vertices. All the instances have the same geometry (which is static), and the same stateset. The data being shared and static makes things pretty easy. 100,000 vertices will comfortable sit on the graphics card, and VBO's would be able to handle it. The modest number of instances of this geometry would mean that the cost overhead of traversal and dispatch to OpenGL will be low so there is no need to resort to instances, it simply won't be required. The only thing you might want to look at is breaking up your geometries spatially to keep the vertex count a bit more modest and the geometry chunks smaller to aid view frustum culling. If you expect to see a big percentage of your geometries on screen at one time and this breaks frame then you should consider using LOD's to manage scene complexity. The other thing to look at is make your geometry efficient by using DrawElementsUShort/DrawElementUInt where possible, remove duplicate vertices's, tri-strip the geometry etc. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] thousands spheres renedering with OSG
First of all I'd like to thanks all implied persons for the great support. As Robert said : Disabling culling will do nothing as the OSG already only does cull tests when subgraphs are partially culled - if the subgraph is entirely within the view frustum the view frustum test if switched off. The majority of the cull traversal time in Mikhail's case will simple by traversing a big scene graph and they creating a big rendering graph to rendering it. This is exactly the case. The majority of times my whole pile is entirely situated inside of frustum. I've tested with the culling disabled for all geodes and their parents PATs. There is no performance gain at all. Right now I'm looking at geometry instancing with vertex shader in osgforest demo, but don't know yet how I could synchronize the positions and rotations of my rigid bodies and geometries. Beside of that, my boss is not very keen to idea of vertex shader instancing for the reason of hardware limitations we should impose to our customers. Thanks again for your great support. MZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgEarth seed google maps particular location help
Ryan, Cannot help you on this one. Please read the following: http://maps.google.com/help/terms_maps.html http://wush.net/trac/osgearth/wiki/TileSourcePluginGoogle (Data Usage) Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Thu, Jul 2, 2009 at 3:38 PM, Ryan Back back...@wright.edu wrote: Hello all, I am trying to use osgearthseed to create a disk cache from google earth of a specific area according to latitude and longitude boundaries. I need help if anyone knows how. Basically, I want to use osgEarthseed to grab a fully detailed cache of a big square of land from google earth if at all possible. It also needs to have height information and be totally accessible and viewable by osgviewer with no internet connection. Is this possible and if so will you please help me out thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14826#14826 ___ 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] thousands spheres renedering with OSG
Beside of that, my boss is not very keen to idea of vertex shader instancing for the reason of hardware limitations we should impose to our customers. To convince your boss: Vertex shaders even run even on Intel accelerated graphics (GMA 950) which is more than 3 years old since first introduced. Intel has a SSE2 accelerated software path in the driver to make up for the lack of hardware vertex shaders. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Read number of Pixels an object takes up
Hi -- The client that funded the occlusion query work in OSG did not need to know the exact number of pixels, they just needed to know "visible or not visible". As a result, the current implementation hides the exact number of pixels. In retrospect, I probably should have implemented this so that the number of pixels was exposed to host code. However, this is complicated for multidisplay scenarios where the geometry being queried spans multiple windows or contexts. You are welcome to modify the existing implementation or come up with an alternate implementation that exposes the exact number of pixels. Jeremy Warren wrote: Robert-- Thanks for the direction. I looked through osgocclusionquery and also the API, however I have been unable to come up with a pixel specific information pertaining to the node. --Jeremy -- From: "Robert Osfield" robert.osfi...@gmail.com Sent: Wednesday, July 01, 2009 3:18 AM To: "OpenSceneGraph Users" osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Read number of Pixels an object takes up Hi Jeremy, The OSG now has support of OpenGL occlusion query that can provide the number of pixels covered when rendering. See osgocclusionquery example. Robert. On Wed, Jul 1, 2009 at 12:35 AM, Jeremy Warrenjw...@hotmail.com wrote: I have a simple scene. Colored background and an object, say a box. I want to figure out how many pixels the box is taking up in the scene. It seems like a simple request, but haven't come up with any solution. Any takers? Thanks in advance --Jeremy Windows Live™: Keep your life in sync. Check it out. ___ 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 -- Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Read number of Pixels an object takes up
Ulrich Hertlein wrote: While we're on the subject: for simple objects, say a sphere or an AABB, shouldn't it be possible to do this calculation quicker on the CPU without going to the GPU? Isn't something like this done for small feature culling? Host computation has (by definition) no access to the depth buffer. -- Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Background image
Hi ! I m trying to put an image in background behind my 3D scene . the problem is that the 2d image is in middle of 3D scene . any sugestion to resolve this ? thks :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Read number of Pixels an object takes up
Hi Paul, On 3/7/09 5:57 PM, Paul Martz wrote: Ulrich Hertlein wrote: While we're on the subject: for simple objects, say a sphere or an AABB, shouldn't it be possible to do this calculation quicker on the CPU without going to the GPU? Isn't something like this done for small feature culling? Host computation has (by definition) no access to the depth buffer. Certainly not. Sorry, I should've been clearer. What I'm basically after is how big (in pixels) is this box/sphere in screen space without taking occlusion, clipping, or such into account. Given projection and modelview matrix that should be doable, right? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Background image
no, I m using hud but my 3d objects are behind the hud. I want my 3d objets in front of hud . ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Background image
Hi Carlos, you need to put the HUD in a render bin that is drawn before everything else. Setting the render bin to 0 or 1 should work (because I think other geometry would default to bin 2) The HUD also needs to be configured to not write to the z buffer. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Background image
turn off depth testing something like this: camera_-setViewport( 0, 0, image_-s(), image_-t() ); camera_-setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); // *** this is also pretty key ** camera_-setRenderOrder( osg::Camera::PRE_RENDER, 1 ); camera_-attach( osg::Camera::COLOR_BUFFER, texture_.get() ); camera_-setClearMask( GL_COLOR_BUFFER_BIT ); // do not want to clear bg image camera_-setReferenceFrame( osg::Transform::ABSOLUTE_RF ); camera_-setViewMatrix( osg::Matrix::identity() ); // *** make sure depth is off *** camera_-getOrCreateStateSet()-setMode( GL_DEPTH_TEST, osg::StateAttribute::OFF ); From: Carlos Sanches ces...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, July 3, 2009 2:22:27 PM Subject: Re: [osg-users] Background image no, I m using hud but my 3d objects are behind the hud. I want my 3d objets in front of hud . ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgManipulator refactored
Hi Guys,
I've just checked in the addition of the following methods to Dragger
that enable one to control when the draggers can be activated by
clicking on them :
void setActivationModKeyMask(unsigned int mask) {
_activationModKeyMask = mask; }
unsigned int getActivationModKeyMask() const { return
_activationModKeyMask; }
void setActivationKeyEvent(int key) { _activationKeyEvent = key; }
int getActivationKeyEvent() const { return _activationKeyEvent; }
Usage looks like (from the new rev of the osgmanipulator example):
// if we don't set an activation key or mod mask then any mouse click on
// the dragger will activate it, however if do define either of
ActivationModKeyMask or
// and ActivationKeyEvent then you'll have to press either than
mod key or the specified key to
// be able to activate the dragger when you mouse click on it.
Please note the follow allows
// activation if either the ctrl key or the 'a' key is pressed and
held down.
dragger-setActivationModKeyMask(osgGA::GUIEventAdapter::MODKEY_CTRL);
dragger-setActivationKeyEvent('a');
I've added these extra controls so that we can have manipulators on
screen at the same time as being able to have the standard camera
manipulators active (i.e. the camera trackball). Previously the
example had an event handle change modes via presses to the tab key,
but this was rather awkward to use. One can still implement this
approach if you wish just by toggling the
Dragger::setHandleEvents(bool) for you own event handler.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgVolume now supports use of osgManipulator draggers
Hi All, I have just checked in an option -m to osgvolume that attaches a dragger to the volume tile, this allows you to change the portion of the volume that it renders, enabling you to interactively cull away parts you aren't interested in. For now I've enabled the TabBoxDragger, but the technique works just fine with all the draggers - even the TrackballDragger which means it's possible to rotate the volume tile as well as resize. As part of this work I've refactored the ray tracing GLSL shaders and C++ code to enable the VolumeTile Locator to be decoupled from the ImageLayer Locator, as well as have the inernal TexGen and Transform nodes automatically track changes to the Locator values. This means you can change the values in yourself without the need to rebuilding the VolumeTile's internal scene graph that it uses to do the rendering of the volume. This means the cost of changing the dimensions of the volume which your rendering is now very lightweight and can happily be done at a solid 60Hz (if you card is able to hit that when doing volume rendering ;-). The changes are now checked into OpenSceneGraph svn/trunk and OpenSceneGraph-Data svn/trunk (as the in source and in example data shaders have been updated.) Currently there is a custom DraggerCallback defined in the osgvolume example (called DraggerVolumeTileCallback), but it's my plan to move this directly into osgVolume NodeKit once this dragger functionality has been tested more and it's design settled down. On my plan of action is to try out having multiple draggers attached to single volume tile, and allow the user to interactively switch between then, this may well require some further mods to osgManipulator library. When this functionality is all ready to go I'll roll it into Present3D to allow you to interactively adjust volume rendering live in your 3D stereo presentations ;-) Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Off on a weeks holiday!
Hi All, I'm just heading offline to complete my packing for a week family holiday on the beautiful Isle of Skye (part of the west coast of Scoltand.) I hope you all have fun in my absence ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Off on a weeks holiday!
Robert Osfield robert.osfi...@gmail.com (03/07/2009): I'm just heading offline to complete my packing for a week family holiday on the beautiful Isle of Skye (part of the west coast of Scoltand.) Talisker's home! Enjoy. :) Cheers, -- Cyril Brulebois signature.asc Description: Digital signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Off on a weeks holiday!
Enjoy. ) 2009/7/4 Cyril Brulebois cyril.bruleb...@kerlabs.com: Robert Osfield robert.osfi...@gmail.com (03/07/2009): I'm just heading offline to complete my packing for a week family holiday on the beautiful Isle of Skye (part of the west coast of Scoltand.) Talisker's home! Enjoy. :) Cheers, -- Cyril Brulebois -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpOYb8ACgkQ0bIwSk8kpU6rrgCdFZf99EjpY/DYGQTIf4+VUfgT y98AniHAJiwF5h/l5J7Q57vLpSUir51N =hq0M -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Maxim Gammer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Off on a weeks holiday!
Enjoy:) 在2009-07-04，Robert Osfield robert.osfi...@gmail.com 写道： Hi All, I'm just heading offline to complete my packing for a week family holiday on the beautiful Isle of Skye (part of the west coast of Scoltand.) I hope you all have fun in my absence ;-) 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
