Hi Robert Thanks for your reply to my question. It led me to the solution of my problem which was on my own light set up. As soon as I removed the following line, my problem went away.
Joan Slottow mSun -> setReferenceFrame( osg::LightSource::ABSOLUTE_RF ); > Message: 8 > Date: Sat, 21 Apr 2007 16:54:32 +0100 > From: "Robert Osfield" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] same light angle on three simultaneous > instances of OpenSceneGraph > To: "osg users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Joan, > > The problem is down to the SceneView's default light position being a > directional light in eye space, and obviously the direction is > different for each of the tiles. > > Try inserting an osg::LightSource in the scene so that all the slaves > are sharing the same lighting set up. You shouldn't need to go any > where need SceneView. See the osglight example. > > Robert. > > On 4/18/07, Joan Slottow <[EMAIL PROTECTED]> wrote: > > My program run on three nodes of a tiled display. I am doing all the > > communication between the nodes and doing the tiling myself. I am also > > following the instructions in the FAQ titled: > > > > > > Q: Can I use OSG within an existing renderer? > > > > In the program running on the center node, the camera is pointed straight > > ahead. I the program running on the left node, the camera is pointed about > > 50 > > degrees left of center, on the right node the camera is pointed about 50 > > degrees right of center. We are running this to 3 projectors that are > > displaying on a large screen that is a portion of a sphere (horizontally its > > less than half the sphere) with overlap being blended by hardware. > > > > There problem is that in each of the displays, the lighting is coming from a > > different direction (because the camera is pointed differently) and this > > results in a disconnect in the lighting when you look at the whole on the > > screen. > > > > I tried setLightingMode(osgUtil::SceneView::SKY_LIGHT), HEADLIGHT, and > > NO_SCENEVIEW_LIGHT in turn on the osgUtil::SceneView but can detect any > > difference so I decided to send the view matrix from the center to the > > sides. > > In the program rinning on the center I did: > > > > osg::Matrixd mTileLightingViewMat = mSceneView -> getViewMatrix( ); > > > > and then I passed that matrix over to the sides: > > > > On the sides I did: > > > > mSceneView ->cull(); > > osgUtil::RenderStage* renderStage = mSceneView -> getRenderStage( ); > > osg::ref_ptr<osg::RefMatrix> mv = > > new osg::RefMatrix( mTileLightingViewMat ); > > renderStage -> getPositionalStateContainer( ) -> reset( ); > > renderStage -> > > addPositionedAttribute( mv.get( ), mSceneView -> getLight( ) ); > > mSceneView ->draw(); > > > > If I do that, I see the sides becoming much darker than the center. > > > > This is explained by the fact that I am calling reset( ). If I print out > > the > > number of matrices on before doing the reset: > > > > std::cerr << "number of light matrices on list before reset " > > << renderStage -> > > getPositionalStateContainer( ) -> _attrList.size( ) > > << std::endl; > > > > I see that there are two where as I only see one being put on in the OSG > > code > > in osgUtill::SceneView.cpp where it says: > > > > case(HEADLIGHT): > > if (_light.valid()) > > renderStage->addPositionedAttribute(NULL,_light.get > > ()); > > else osg::notify(osg::WARN)<<"Warning: no osg::Light attached to > > ogUtil::SceneView to provide head light.*/"<<std::endl; > > break; > > case(SKY_LIGHT): > > if (_light.valid()) > > renderStage->addPositionedAttribute(mv.get(),_light > > .get()); > > else osg::notify(osg::WARN)<<"Warning: no osg::Light attached to > > ogUtil::SceneView to provide sky light.*/"<<std::endl; > > break; > > default: > > break; > > > > > > So to compensate for that I ran the same code on the center as I did on the > > sides all of them were darker than originally but I still say the same > > discontinuities as I did before and it still looked as if the lighting was > > applied at different angles. > > > > What is the solution two the problem of getting all three instances of the > > program to do the lighting as if it were a single view? > > > > Thank You > > > > Joan Slottow > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > > > ------------------------------ > > Message: 9 > Date: Sat, 21 Apr 2007 16:57:30 +0100 > From: "Robert Osfield" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] mouse picking problem > To: "osg users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 4/18/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > I hacked the Quick Start Guide example to draw two large quads instead of > > two cows and you're absolutely right! One of the quad vertices has to be > > inside the polytope in order for picking to work. This seems like a bug in > > the Intersector classes. Either submit a fix, or alert Robert to this when > > he's back from vacation. > > The PolytopeIntersector is only a partial implementation which needs > replacing with a full implementation. An OSG user did extend it to > work better, but didn't submit it an form ready for integration, I was > expecting a later rev of this work, but it hasn't appeared yet. I'll > need to do some searching through the archives to track it down. > > Robert. > > > ------------------------------ > > Message: 10 > Date: Sat, 21 Apr 2007 16:59:21 +0100 > From: "Robert Osfield" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] Quick texture / image question > To: "osg users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Bill and Paul, > > On 4/18/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > Well, you could take a look in the code and see what those functions return, > > and then search for where the return values are actually set. > > > > But if I were to take a guess, I imagine those values are validated only > > when the texture object gets created (on first render pass). > > The width and height are set in the apply if they aren't set > externally (as is done in certain types of usage). > > Note, the osg::Texture* may resize the imagery before passing it to > OpenGL as it'll need to be a power of two on most machines. > > Robert. > > > ------------------------------ > > Message: 11 > Date: Sat, 21 Apr 2007 17:05:53 +0100 > From: "Robert Osfield" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] SPIclops > To: "osg users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Jim, > > In the SVN version of the OSG there is an osgdistortion mode that > computes the distortion correction for a whole dome, a bit overkill > for what you need, but its all native OSG. The osgdistortion example > should give you an idea of how to set up the multiple Render To > Texture Camera's and final distortion correction Camera. > > osgdistortion --dome mymodel.osg > > osgdistortion --faces mymodel.osg > > My plan for osgViewer is to allow the Camera setup and distortion > correction mesh to be set up from configuration file, this will then > make it easy to port to half dome/full dome with just the loading on > the appropriate configuration file, with no need to mess around with > other API's. > > osgviewer -c dome_configuration.osgViewer mymodel.osg > > Robert. > > On 4/19/07, jim_self <[EMAIL PROTECTED]> wrote: > > Hi, > > > > > > can anybody help me getting a copy of the SPIclops API for spherical > > projections? The elumens.com page does apparently not contain any useful > > information on this. Or are there other APIs for spherical projections > > out there? > > > > Thanks and regards, > > Jim Self > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > > > ------------------------------ > > Message: 12 > Date: Sat, 21 Apr 2007 09:11:29 -0700 > From: "Stou Sandalski" <[EMAIL PROTECTED]> > Subject: [osg-users] OpenSceneGraph trac site > To: "osg users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > The current framed layout of the main site takes a lot of screen real > estate even for a simple lookup of an OSG class definition especially > coming from a search engine. So I was wondering if OpenSceneGraph > will be moved to a trac based site like osgProducer? Or if a redesign > is being planned of the main site? > > I only write this now because I just noticed the graphivz and doxygen > plugins for Trac that allow for inlining of graphviz dot files inside > wiki pages... and integration of doxygen documentation inside the Trac > site. The graphiviz plugin would be quite useful for drawing examples > of scene graphs on documentation pages. Whereas the doxygen plugin > would allow for clean navigation of the API reference while still > maintaining navigation elements. I am sure this has already been > discussed but I wanted to check on the status/plans. > > Regards, > > Stou > > > ------------------------------ > > Message: 13 > Date: Sat, 21 Apr 2007 20:32:14 +0400 > From: "Vladimir Shabanov" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] cal3d lod > To: "osg users" <[email protected]>, "Jan Ciger" > <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello Jan! > > I've also developed a library based on LGPL osgCal (actually a nearly > complete rewrite) which works with latest OpenSceneGraph, uses GLSL > shaders for skinning and support normal mapping. Fixed function > implementation is also kept. Library have some optimizations > especially for hi-poly models. OSG picking is also works for HW > models. Library is tested on ATI&nVidia on linux&windows. LOD & .osg > file plugin is not supported. I've also done some small changes in > cal3d Max exporter, to export normal maps, bumps & opacity. > > In the (possibly near) future, I want to release this library as a > major update to LGPL osgCal. > > A week ago I've tried to contact Loïc Dachary (as osgCal project > manager at sourceforge), but received no answer. It seems that now I > should contact Ruben? Am I right? > > > 2007/4/19, Jan Ciger <[EMAIL PROTECTED]>: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Jeremy L. Moles wrote: > > > 2.5) Is my personal adaptation (which I am deriving from osgCal2) which > > > has code cleanup, supports OSG SVN, and will include Vertex Shader > > > animation support. I absolutely cannot suffer software skinning after > > > seeing how much faster it is in a simple shader. :) > > > > > > I haven't actually released mine yet (though obviously the LGPL will > > > require I do so) as it is still in casual development, but it will be > > > available along with all the other OSG stuff I'm working on (osgGTK, > > > osgCairo, osgEgypt, etc.) None of these are really all that impressive > > > at the moment, but hopefully will be soon. :) > > > > Would you mind to contribute your changes to Ruben ASAP, please? It > > would save a lot of duplication of effort - I was also thinking about > > adding hardware skinning there. Not to mention compilation fixes. > > > > Regards, > > > > Jan > > > ------------------------------ > > Message: 14 > Date: Sat, 21 Apr 2007 13:01:19 -0400 (EDT) > From: [EMAIL PROTECTED] > Subject: Re: [osg-users] cal3d lod > To: "osg users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain;charset=iso-8859-1 > > Wow, it seems like there are more people working on this than we had > thought. I'm still new to open source programming; How the heck do we > harness all this beautiful work? > > It seems to make sense, since any simulation/game wants animated > life-forms. Character animation is one place that DirectX has an obvious > advantage to OpenGL. It'd be great to change that. > > > Hello Jan! > > > > I've also developed a library based on LGPL osgCal (actually a nearly > > complete rewrite) which works with latest OpenSceneGraph, uses GLSL > > shaders for skinning and support normal mapping. Fixed function > > implementation is also kept. Library have some optimizations > > especially for hi-poly models. OSG picking is also works for HW > > models. Library is tested on ATI&nVidia on linux&windows. LOD & .osg > > file plugin is not supported. I've also done some small changes in > > cal3d Max exporter, to export normal maps, bumps & opacity. > > > > In the (possibly near) future, I want to release this library as a > > major update to LGPL osgCal. > > > > A week ago I've tried to contact Loïc Dachary (as osgCal project > > manager at sourceforge), but received no answer. It seems that now I > > should contact Ruben? Am I right? > > > > > > 2007/4/19, Jan Ciger <[EMAIL PROTECTED]>: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Jeremy L. Moles wrote: > >> > 2.5) Is my personal adaptation (which I am deriving from osgCal2) > >> which > >> > has code cleanup, supports OSG SVN, and will include Vertex Shader > >> > animation support. I absolutely cannot suffer software skinning after > >> > seeing how much faster it is in a simple shader. :) > >> > > >> > I haven't actually released mine yet (though obviously the LGPL will > >> > require I do so) as it is still in casual development, but it will be > >> > available along with all the other OSG stuff I'm working on (osgGTK, > >> > osgCairo, osgEgypt, etc.) None of these are really all that impressive > >> > at the moment, but hopefully will be soon. :) > >> > >> Would you mind to contribute your changes to Ruben ASAP, please? It > >> would save a lot of duplication of effort - I was also thinking about > >> adding hardware skinning there. Not to mention compilation fixes. > >> > >> Regards, > >> > >> Jan > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > > > > > ------------------------------ > > Message: 15 > Date: Sat, 21 Apr 2007 19:13:27 +0100 > From: "Gordon Tomlinson" <[EMAIL PROTECTED]> > Subject: [osg-users] RE: A bug ? > To: <[email protected]> > Message-ID: > > <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAW1cvqsiaW0GJGr46ewPgUcKAAAAQAAAALH+8Tdst/[EMAIL > PROTECTED]> > > Content-Type: text/plain; charset="us-ascii" > > > See http://www.vis-sim.com/osg/osg_faq_1.htm#f22 > > BTW you sent your question to the wrong list, it should be > [email protected] not submissions > > > __________________________________________________________ > Gordon Tomlinson > > Email : [EMAIL PROTECTED] > Website : www.vis-sim.com www.gordontomlinson.com > > __________________________________________________________ > > "Self defence is not a function of learning tricks > but is a function of how quickly and intensely one > can arouse one's instinct for survival" > -Master Tambo Tetsura > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pietro > Incardona > Sent: 21 April 2007 17:20 > To: [EMAIL PROTECTED] > Subject: [osg-submissions] A bug ? > > I have founded this bug(?) when i have tried to draw only a simple point > into the scene > > i have used the osgpointsprite example procedure to display my point > > The procedure work for n point but for unknow reason don' t work with only > one point n must be a minium of 2 > > i have also tried to change osgpointsprite example I have changed the for > into makeGalaxy cicle to have a 1 cicle 1 vertex created and i have > commented the PointSprite section and Texture so i use standard Point of > size 10.0 > > Now makegalaxy(n) draw correctly n point from 2 to n using make galaxy with > only 1 point don' t draw nothing > > Unfortunately i haven' t finded another way to draw only one point. and i > have no idea to do it. > > #include <osg/PointSprite> > #include <osg/BlendFunc> > #include <osg/StateAttribute> > #include <osg/Point> > #include <osg/Geometry> > #include <osg/Texture2D> > #include <osg/TexEnv> > #include <osgDB/ReadFile> > #include <osgProducer/Viewer> > #include <osg/GLExtensions> > #include <osg/TexEnv> > > osg::Geode *makeGalaxy(unsigned nvertices) { > osg::Geode *geode = new osg::Geode(); > osg::Geometry *galaxy = new osg::Geometry(); > osg::Vec3Array *vertices = new osg::Vec3Array(); > osg::Vec4Array *colors = new osg::Vec4Array(); > osg::Vec4 ini(1,1,0,1); > osg::Vec4 fin(0,0,1,1); > > /** Formula for the two spirals */ > for (unsigned i=0;i<nvertices;i++) // <----- Changed I need 1:1 > > vertex cicle > { > float val = (i*2/(float)nvertices * 2 * 3.14159265359); > float modx1 = rand() / (float)RAND_MAX*2; > float mody1 = rand() / (float)RAND_MAX*2; > float modx2 = rand() / (float)RAND_MAX*2; > float mody2 = rand() / (float)RAND_MAX*2; > float modz1 = ((rand()-RAND_MAX/2) / (float)(RAND_MAX))*3/(val+1); > float modz2 = ((rand()-RAND_MAX/2) / (float)(RAND_MAX))*3/(val+1); > vertices->push_back(osg::Vec3(cos(val)*val+modx1, > sin(val)*val+mody1, modz1)); > // vertices->push_back(osg::Vec3(-cos(val)*val+modx2, > -sin(val)*val+mody2, modz2)); > > colors->push_back(ini+(fin-ini)*(i*2/(float)nvertices)); > // colors->push_back(ini+(fin-ini)*(i*2/(float)nvertices)); > } > galaxy->setVertexArray(vertices); > galaxy->setColorArray(colors); > galaxy->setColorBinding(osg::Geometry::BIND_PER_VERTEX); > galaxy->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POINTS, > 0, nvertices)); > geode->addDrawable(galaxy); > return geode; > } > > osg::StateSet* makeStateSet(float size) > { > osg::StateSet *set = new osg::StateSet(); > > /// Setup cool blending > > <----- Sprite is not requested > /* set->setMode(GL_BLEND, osg::StateAttribute::ON); > osg::BlendFunc *fn = new osg::BlendFunc(); > fn->setFunction(osg::BlendFunc::SRC_ALPHA, osg::BlendFunc::DST_ALPHA); > set->setAttributeAndModes(fn, osg::StateAttribute::ON);*/ > > /// Setup the point sprites > /* osg::PointSprite *sprite = new osg::PointSprite(); > set->setTextureAttributeAndModes(0, sprite, osg::StateAttribute::ON);*/ > > /// Give some size to the points to be able to see the sprite > osg::Point *point = new osg::Point(); > point->setSize(size); > set->setAttribute(point); > > /// Disable depth test to avoid sort problems and Lighting > set->setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF); > set->setMode(GL_LIGHTING, osg::StateAttribute::OFF); > > /// The texture for the sprites > <------ No texture requested > /* osg::Texture2D *tex = new osg::Texture2D(); > tex->setImage(osgDB::readImageFile("Images/particle.rgb")); > set->setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON);*/ > > return set; > } > > int main(int, char *[]) > { > osgProducer::Viewer viewer; > > /// Make the galaxy of points > osg::Node *node = makeGalaxy(1); > > node->setStateSet(makeStateSet(10.0f)); > > viewer.setUpViewer(osgProducer::Viewer::STANDARD_SETTINGS); > viewer.setSceneData(node); > > viewer.realize(); > while (!viewer.done()) > { > viewer.sync(); > viewer.update(); > viewer.frame(); > } > > // wait for all cull and draw threads to complete. > viewer.sync(); > > // run a clean up frame to delete all OpenGL objects. > viewer.cleanup_frame(); > > // wait for all the clean up frame to complete. > viewer.sync(); > > return(0); > } > > _________________________________________________________________ > Windows Live OneCare: tutto per la cura del tuo PC ! Provalo Gratis! > http://onecare.live.com/standard/it-it/default.htm > > _______________________________________________ > osg-submissions mailing list > [EMAIL PROTECTED] > http://openscenegraph.net/mailman/listinfo/osg-submissions > > > > > ------------------------------ > > Message: 16 > Date: Sat, 21 Apr 2007 20:14:30 +0200 > From: Jan Ciger <[EMAIL PROTECTED]> > Subject: Re: [osg-users] cal3d lod > To: osg users <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [EMAIL PROTECTED] wrote: > > Wow, it seems like there are more people working on this than we had > > thought. I'm still new to open source programming; How the heck do we > > harness all this beautiful work? > > > > It seems to make sense, since any simulation/game wants animated > > life-forms. Character animation is one place that DirectX has an obvious > > advantage to OpenGL. It'd be great to change that. > > > > To clarify - DirectX provides only for skinning which is probably 10% of > the whole problem. Properly animating the characters is a quite a bit > more than that. > > A good start to have something more comprehensive available would be to > integrate the work of Vladimir into the upstream osgCal and then replace > the rendering code in ReplicantBody with osgCal. That should give > everybody a reasonable starting point for character animation and it > shouldn't be too hard to do. > > Things that would still remain to be developed/fixed: > > - - proper LOD support in Cal3D > - - exporters > - - support for procedural animation in Cal3D and Replicant. That is > needed for things such as walking, reaching, grasping - canned keyframe > animations are not good enough or you need a specific animation for > every object you want to grasp. That is perhaps possible for somebody > like Ubisoft or EA with their army of designers, animators and motion > capture actors but not people writing simulators. > > Other interesting things to do for which the theories and algorithms are > known: > - - proper skin rendering using bump mapping, sub-surface scattering > model, etc. This is why HalfLife 2 characters looked quite good up close. > > - - rag doll dynamics (needs support in Cal3D - do you see why I have said > that Cal3D may need to be redesidned/replaced?). This also needs support > in the design pipeline to assign masses and collision volumes. > > - - support for forward dynamics (physically *controlled* motion, not only > rag dolls-like tumbling) > > - - support for facial animation (quite a big deal, actually - properly > animating the face can be more complex than the rest of the body) > > - - clothing simulation - unless you want your characters looking like > Superman in a skintight spandex costume you need some simulated > clothing. That is a whole another can of worms computationally. > > - - hair simulation - not everybody is a closely cropped marine. Again, > another big computational problem :( > > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFGKlSGn11XseNj94gRAg9JAKDelKM5aYWnL3yFmi+Rny6CrxRrDwCeKJ8T > M2gbU0lltRxqBykNI6u/gZo= > =tqza > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 17 > Date: Sat, 21 Apr 2007 22:51:55 +0400 > From: "Vladimir Shabanov" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] cal3d lod > To: "Jan Ciger" <[EMAIL PROTECTED]>, "osg users" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 2007/4/21, Jan Ciger <[EMAIL PROTECTED]>: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hello Vladimir, > > > > Vladimir Shabanov wrote: > > > Hello Jan! > > > > > > I've also developed a library based on LGPL osgCal (actually a nearly > > > complete rewrite) which works with latest OpenSceneGraph, uses GLSL > > > shaders for skinning and support normal mapping. Fixed function > > > implementation is also kept. Library have some optimizations > > > especially for hi-poly models. OSG picking is also works for HW > > > models. Library is tested on ATI&nVidia on linux&windows. LOD & .osg > > > file plugin is not supported. I've also done some small changes in > > > cal3d Max exporter, to export normal maps, bumps & opacity. > > > > > > > Excellent - that will probably save a lot of work for many people. > > It is one of purpouses to release it. There are much work done and a > much work to do. People should not reinvent the wheel. > > > > > > In the (possibly near) future, I want to release this library as a > > > major update to LGPL osgCal. > > > > Great! That's a really commendable attitude. > > > > > > > > A week ago I've tried to contact Loïc Dachary (as osgCal project > > > manager at sourceforge), but received no answer. It seems that now I > > > should contact Ruben? Am I right? > > > > Yes, I think so. Loïc maintains the forked (GPL) version of osgCal and > > not the original LGPL one (which is, curiously, named osgCal2). For that > > you need to contact Ruben Lopez who is maintaining it. He > > is also on the osg-users mailing list. > > OK, I've just mailed Ruben. > > > > > Regards, > > > > Jan > > > ------------------------------ > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > > End of osg-users Digest, Vol 31, Issue 31 > ***************************************** _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
