Re: [osg-users] Prepend: OSG file loading...
Hi Adrian, On 8/15/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi Robert, i am also confused where the issue comes from. I don't know, i did a half a hour debug sessions this afternoon, i don't yet get any more information. I propose we will held back this issue in our mind, when ever we have more information may we will be able to fix it. Does this issue exist on any of the OSG examples on your machine? Would it be possible to write a small segment of code that reproduces it? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL 3 announced
Hi Jan, I'm sorry to hear of your bad experience with lock down of phones, but there is more to 3d graphics on embedded and mobile systems than the subset of locked down phones. For the same reason that OpenGL ES has value in the market, a scene graph that supports it would also have value to those who need it. Robert. On 8/15/07, Jan Ciger [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Time is the important thing to consider here. Mobile hardware is getting more and more capable. There is also a movement in mobile hardware that geared towards more open systems. Take a snapshot today and things don't look to positive w.r.t squeezing the OSG into a mobile platform, in 5 years time I would expect things to be very different. I can imagine lots of folks being open to support mobile hardware if they can use similar tools on the desktop as on the mobile device. Robert, you need to consider also the ecosystem, not only the technology. Hopefully the narrow-minded telcos running the cellphone networks will get the idea, but most likely not. The reason why most of this hardware is closed is not so much because of companies like Nokia or Siemens, but because of telcos asking them to make their handsets restricted and unable to run unapproved things under the threat of not selling them with their subscription plans. For example, Symbian (EPOC) used to be quite open system when it was used by Psion handhelds and is being closed down more and more as it moved from PDAs to smart phones. One of the reasons is the fear of uncertified hardware/software damaging their networks. For example, in my home country - Slovakia - it is still *illegal* (there is actually a law on this, even though the telecom is in private hands since a long time) to plug your own phone or modem in the phone outlet. Everybody ignores it, but officially you must petition the telecom and they will send the technician to plug the phone in. Of course, God forbid if the phone/modem/whatever is not one of the officially approved and certified ones - you have to prove it by showing the certificate to the tech, otherwise you will not get it connected. And then they will still botch it (like the DSL line at my girlfriend's place where they installed some part incorrectly causing interference in all phones in the house - but that is another story ...) Then the other thing is pure greed - like 1-2 EUR DRM-ed ringtones (!) so that you cannot share them and avoid paying the inventor of the Crazy Frog or whatever annoyance of the day. Unless this changes, the market for these things will be very limited for 3rd party developers not associated with either the device manufacturers or the telecoms. This afternoon I tried to update to that latest Producer in CVS but couldn't get it compiled. Will have to try another day. I have done it just an hour ago and it worked for me. I didn't run it yet, but it compiled OK. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGw1nTn11XseNj94gRAm18AJ9r50uMwXJKQZIbxwjzzFwqMICEfwCfZDM5 7e7bmo6za4r+l6wRpfq3Y8U= =ztcj -END PGP SIGNATURE- ___ 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] a couple OSG BOF pictures
Hi Mike, On 8/15/07, Mike Weiblen [EMAIL PROTECTED] wrote: here are a few more (blurry) pictures from the OSG BOF last week. http://mew.cx/osg/s2007/ Wow, looks big filled room! I do like the idea of the OSG generated holograms. The 2D pics and displays we labour with won't ever do the hologram justice - will have to see it for real one day :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating unmapped windows?
HI Anye, Not mapping the window till realize is something that is desirable, but its not something that I have set as an immediate goal or tested yet - osgViewer is still in its infancy so its function is not fully fleshed out. Supporting mapping only at realize should be possible give a few tweaks to the implementation. The init() method right now sets this up in preparation for the realize and to check that the requested GraphicsContext::Traits can be fulfilled, but there is no direct requirement to map the window. I'm open to refactoring of GraphicsWindowX11 so that setWindowDecorationImplementation() doesn't require mapping or can be delayed until realize(), we do need to make sure that Carbon and Win32 implementations also fit well with this change. Feel free to hack GraphicsWindowX11 at your end to see if you can get things working as you desire and let me know how you get on. I can then review the required changes and make further changes/recommendations. I can also put this item on my TODO lists, but this list is rather long so I won't get round to it right away. Robert. On 8/15/07, Anye Li [EMAIL PROTECTED] wrote: Hi, Can I create an unmapped GraphicsWindow with an initialized OpenGL context? I really wanted to ask this as how-do-I question, but looking at the latest svn code, I believe this is a feature request. Actually, I can probably already do this by using GLUT (or something else that creates an OpenGL context) with GraphicsWindowEmbedded, but I'd rather not depend on GLUT just for this; I'd rather it be something GraphicsWindows are generally capable of. Most windowing toolkits that I've encountered create unmapped windows and then require you to invoke some kind of show method for it to actually appear on screen. I don't know how things work on other systems, but at least on X11 I'm pretty sure you can set up an OpenGL context on an unmapped window, and do things like set up frame buffer objects before (or without) mapping a window. Perhaps most people do want their windows automatically mapped (and usually I do too), but it doesn't seem like I get a choice: in GraphicsWindowX11, the window gets mapped in setWindowDecorationImplementation(), which gets called during construction; I haven't looked at the other implementations but I would assume similar behaviour. It seems to me the purpose of realizeImplementation() is to map the window; is there any possibility of either not mapping the window during setWindowDecorationImplementation(), or perhaps setWindowDecorationImplementation() not actually taking effect until the window is realized? Thanks, Anye Li ___ 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] Prepend: OSG file loading...
Hi Robert, in fact at the moment i am no longer sure if this exists only in my application or also in the osg example. i will have a look as soon as i got two minutes left. /adegli 2007/8/16, Robert Osfield [EMAIL PROTECTED]: Hi Adrian, On 8/15/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi Robert, i am also confused where the issue comes from. I don't know, i did a half a hour debug sessions this afternoon, i don't yet get any more information. I propose we will held back this issue in our mind, when ever we have more information may we will be able to fix it. Does this issue exist on any of the OSG examples on your machine? Would it be possible to write a small segment of code that reproduces it? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDotNet : Used from C#
The osgIntrospection+osgWrapper and osgDotNet-generator work very well together. (See http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappersGenerator). Thanks to the osg team for such taht interesting release ! After a bunch of tests, the generated Managed C++ DLLs work perfeclty well referenced in a C# solution and porting a native osg program to osgDotNet in C# is quick since names of classes, methods and stay the same through the osgDotNet API. Yet, two problems remain for the programmer that wants to build an interactive application in .NET (C# in my case) : (A) Debugger use. As is, it seems impossible to examine the unmanaged C++ content (native osg) carried by osgDotNet instances, even if the Enable unmanaged code debugging option is set active in the Debug properties of the projects. (B) Update vs Draw. Some fundamental methods of classes (ie Osg.NodeCallback.operator()()) aren't wrapped. Also, some classes interface become very static in osgDotNet compared to native osg because their fundamental members were set public and accessed directly in the native API (limitation of osgIntrospection, as explained among the last points of http://www.openscenegraph.org/projects/osgDotNet/wiki/DifferencesWithNativeAPI ). An example is OsgSim.LightPoint and _on member. Regarding (A)... The Generator builds an osgDotNet solution that only links with the release versions of the native osg libraries (which stays in phase with the fact that using osgDotNet dlls, you have to copy aside your osg.NET dlls - on set in the Windows Path - release versions of the native osg Dlls as explained at http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappers). Question A1 Is that the main explanation of (A), or is there something else ? Question A1bis Can we modify the osgDotNet solution produced by the generator to link with debug version of the native osf librairies to solve the (A) problem ? Regarding (B)... Solving the issue with for example the lightpoint is easy : I only have to make a few accessor add in (native) osgSim as well as in osgWrappers/osgSim and rebuild OpenSceneGraph. In other words a quickly coded litlle patch on the osg native release. Question B1 There, just one question : is it useful to submit to the OSG community those patches as we introduce them or will the release to com (2.2.0) include those or an osgIntrospection improvement that will render this obsolete ? Concerning the more important NodeCallback issue, it may be embarassing : it is a callback method called from the native osg internals that have to impact the overriden method coded in C#. Question B2 Will the mere patching of the osg release (as for the LightPoint) work in that case ? The macros used inside osgWrappers/xxx (osgIntrospection macros) include virtualstate assesment, but will it work on that case where the caller is the osg native core, not a .NET call coming from inside the C# application ? Thanks for comments or answers. -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VirtualPlanetBuilder-0.9.1 tagged
Hi All, I have just cleaned up and tagged VirtualPlanetBuilder-0.9.1, you can grab download it form the project website: http://virtualplanetbuilder.osgforge.org/ No binaries exist as yet so you'll need to build the project yourself, but as it uses the same build system as the OSG this should be straight forward. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting a backgroud image
Thanks Robert. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Tuesday, August 14, 2007 11:08 AM Subject: Re: [osg-users] Setting a backgroud image Hi Guy, On 8/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: About the clear color of ClearNode, I guess the camera node clear color overrides it. A nested ClearNode should be able to set the clear colour for the Camera that contains it. I very rarely used ClearNode these days, and have neved used it with a RTT Camera so perhaps this functionality has dropped between the boards. FYI, ClearNode predates osg::Camera, the later now can take over much of the need to for ClearNode as it allows one to set the clear for the Camera. 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] OpenGL 3 announced
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi Jan, I'm sorry to hear of your bad experience with lock down of phones, but there is more to 3d graphics on embedded and mobile systems than the subset of locked down phones. For the same reason that OpenGL ES has value in the market, a scene graph that supports it would also have value to those who need it. Robert. I certainly wish it would be that way. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxDFan11XseNj94gRAmu4AKDVFwz6uE3uSHyaccJxUWK+tJZrdgCgsmVA Z+JuLpxLjictLjORpcYUhm8= =ds0i -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RTT camera cullmask
Hello, i'm using a osg::Camera with a FBO attached, rendering depth buffer for use as a shadow map. In a special case i just want the camera to render nothing (non of their nodes below) to the texture. At first i tried to set the cull mask of the RTT camera to 0, but that seemed to have the effect that the camera was not traversed and the texture was not updated anymore. So i ended up, setting a NodeMask to the children below the RTT camera to achieve the effect of rendering nothing. Did i misinterpret the meaning of setCullMask? Is there another way of enabling/disabling a RTT camera? Thanks for any help, Michael. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RefCount setSceneData
Hi Michael, On 8/16/07, Michael Ebner [EMAIL PROTECTED] wrote: when setting a root node to an osgViewer with setSceneData, the ref. count of the root node is increased by 2. A explicit call with setSceneData(NULL) is necessary to release the node again, simply setting the ref_ptr of osgViewer to NULL keeps one ref count of the root node. Could someone verfiy that and perhaps fix it? I'm afraid I can't follow where the problem lies. osgViewer::Viewer::setSceneData will use a osgViewer::Scene which will retain a reference to the SceneGraph, and at the same time this scene will be passed on to the Viewer's osg::Camera, so they will take references as well, this is perfectly normal and safe. When a Viewer destructs it should remove scene reference and associated cameras and they will remove their references to the scene as well, so in the end the ref count should return to zero and the scene deleted. Could you provide a code example that reproduces the issue that you perceive. Please specify which version of the OSG you are using. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT camera cullmask
Hi Michael, I'm afraid I can't work out what you mean by do nothing. Setting the NodeMask on Camera will switch it off, it will do nothing. Similar to the cull mask. From your description this works - its does nothing, yet you then say the texture is not updated??!?!? What are you after? You can't do nothing and still have something undefined happen. Could you please explain what bits you want to happen and what you don't. Robert. On 8/16/07, Michael Ebner [EMAIL PROTECTED] wrote: Hello, i'm using a osg::Camera with a FBO attached, rendering depth buffer for use as a shadow map. In a special case i just want the camera to render nothing (non of their nodes below) to the texture. At first i tried to set the cull mask of the RTT camera to 0, but that seemed to have the effect that the camera was not traversed and the texture was not updated anymore. So i ended up, setting a NodeMask to the children below the RTT camera to achieve the effect of rendering nothing. Did i misinterpret the meaning of setCullMask? Is there another way of enabling/disabling a RTT camera? Thanks for any help, Michael. ___ 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] RTT camera cullmask
Hi Robert, Robert Osfield wrote: Well its pretty simple then just switch off the children by setting their NodeMask, [..] that's what i did, thank you. Michael. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why does the osgPlugins directory includethe version?
To Jean-Sebastien, --snip-- The solution is simple, really - users should learn to build the INSTALL target in the Visual Studio project files. To simplify this, the INSTALL target should be the default target in a batch build. But I think we shouldn't put in any workarounds when the true solution is so simple. --snip-- My Cmake knowledge is limited, but I would prefer a Visual Studio solution where the projects actually build to the directory I test/debug my application. Rather than copying files around so you end up having duplicate files and end up testing with an old version. As a Visual Studio programmer I think of the INSTALL target more like a SW deployment step than an actual build stage. No sure if this is a Cmake limitation, but my vote goes for setting up the projects so they build to the /bin directory directly. That way you can make a change to one project, build it and run your testapp. On a separate note. - osgIntrospection is not copied when building INSTALL. - If we have to stick to the INSTALL target, does anyone know if there is a way to setup Cmake to copy the pdb files as well? Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
Hi Joan, The problems you describe look to most likely to be issues with display listing of the geometries. It could be that they are just poorly conditioned datasets - one triangle per geometry is certainly very very badly condidtioned and needs fixing to be able expect any sensible performance level, or it could be that the models are simply to big for the hardware/OGL driver to cope with. There might also be possibility of error in the data such as a primitive index that is invalid. This is also just speculation though... Robert. On 8/16/07, Joan Slottow [EMAIL PROTECTED] wrote: Jan I tested the latest vrml plugin on some larger files, real vrml files rather than the little test files that I sent you before. I tested them with both osgviewer and vrNav2, my own program. First, the problem with osgUtil::SceneView crashing in draw( ) that I had before when I loaded the vrml files with vrNav2 is now gone, so that's good. I notice, from looking at the resultant .osg files, that the vrml translation is introducing a rotation to turn the z of the model up. vrNav2 already does that for all models so I added a test there not to do it for .wrl models it loads. The first few models that I loaded worked fine. Then I ran into a problem. The problem seems to be related to the size or the number of Shapes in the vrml file. Also, it may be some kind of timing problem (in it taking too long to load the model). The problem manifests itself as follows: in osgviewr, the graphics screen comes up as a black screen and then turns into a screen with a blue background and the model appears. With the ones that don't work, the screen remains black and you don't see the model. With vrNav2, vrjuggler is opening for me (using X Windows calls) a black graphics screen of size 640 by 480. With the ones that don't work, I get a black graphics screen that fills the whole screen (not 640 x 480) and no model. When it works, I get my 640 x 480 graphics screen. vrNav2 writes out the model's bounding box dimensions immediately after loading the model and this always happens. Also, if I change the vrNav2 code so that immediately after loading the model it writes out the model in .osg format, the problem is gone and the program work and the problem. But if immediately after loading the model, I just add some sleep, I am back to it not working. If I take a model that doesnt work but which has multiple Shapes, and divide it into .wrl files each with a single shape and load just a single Shape, it always works. I can also take subsets of the Shapes and have it work. Here are 4 models: waves.wrl with 3 Shapes 3406099 bytes isos2_2.wrl with 2 Shapes 883264 bytes sigmoid.wrl with 6 Shapes 326260 bytes vectors.wrl with 8 Shapes 3234335 bytes From them I constructed the following: sigmoid1.wrl the first Shape from sigmoid.wrl, sigmoid2.wrl the second Shape, ... sigmoid6.wrl the sixth Shape, sigmoid1-3.wrl the first three Shapes, sigmoid1-4.wrl the first 4 shapes, sigmoid1-5.wrl the first 5 Shapes. vectors1-4.wrl the first 4 Shapes from vectors.wrl, vectors1-5.wrl and vectors5-8.wrl etc. waves1.wrl the first Shape from waves.wrl, also waves2.wrl, waves3.wrl and waves1-2.wrl. Here are the results: model vrNav osgviewer sigmoid black screenblack screen any of sigmoid1 through sigmoid6works works sigmoid1-3works works sigmoid1-4works black screen sigmoid1-5black screenblack screen isos2_2 works works waves black screenworks waves1black screenworks waves2works works waves3works works waves1-2 black screenblack screen vectors black screenworks vectors1-4works works vectors1-5black screenworks vectors5-8works works Anyway, I am not unhappy with this situation. My goal is to be able to take vrml 2.0 files output by scientific visualization programs and turn them into models that can be loaded. I can easily do this by following this procedure: osconv whatever.wrl whatever.osg edit whatever.osg and remove the matrix transform at the top osconv whatever.osg whatever.ive Then I load the .ive file and that always works. I also tried writing a vrml 2.0 file from VMD a popular program used to visualize chemistry molecules. That program wrote out an absolutely huge file with one Shape per triangle. That file can't be loaded. However, I can write a program to read in the vrml file as output by VMD and convert it to a more
[osg-users] Coordinate systems
What is the easiest way to change the coordinate system of OSG? I read in documentation that there is a way to do it, but it never says how. I need to have the world be XZ on the floor and +Y up. Is it best to attach a transform node below the root, and hang everything off that, or can I configure something? Thanks, Dave ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtualPlanetBuilder-0.9.1 tagged
My plan to work on VirtualPlanentBuilder is that upcoming changes will be done in both core OSG and VPB, with the later relying upon latest OSG in SVN - this means VPB SVN version will require OSG SVN version. The VirtualPlanentBuilder-0.9.1 release should work fine with OSG-2.0 and all the 2.1.x series as well as OSG SVN, so if you don't want to use OSG stable version then you'll need to stick with VirtualPlanentBuilder-0.9.1 release - this is in fact key motivation of for tagging 0.9.1 when I did. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDotNet : Used from C#
Hi Mike
Regarding (A1): you'll need to build the Debug osgDotNet assemblies and use
them with the
Debug OSG DLLs. (...) Unfortunately you can't see the native state when
stepping through
the managed code. Also, debugging across the managed/unmanaged boundary only
works
for 32 bit code, not 64 bit, due to a CLR/Visual Studio limitation.
(A1) That's what I planned to do : link Debug Configuration os osgDotNet.sln
with Debug version of the native osg librairies (and run it aside native osg
Debug dlls) ; link Release Configuration os osgDotNet.sln with Release version
of the native osg librairies (and run it aside native osg Release dlls).
I'm currently working with 32 bit code ; I'll see to what extent I can see
what's going on on the unmanaged side...
(B) Well in fact I tried this afternoon the local OSG copy patching idea, but
it doesn't seem to work. I can't see why... taking the LightPoint issue :
{a} I've added two accessor methods in include/osgSim/LightPoint and
src/osgSim/LightPoint.cpp - that 'updates' native osg dll and library
{b} I've added those through I_Method and I_Method macros in
src/osgWrappers/LightPoint.cpp - that should be taken into account by
Generator when generating again Generator/output/src/osgSim/LightPoint.cpp and
.h
{a} worked perfecly but not {b} : the osgDotNet solution generation still works
but doesn't provide anything new into LightPoint class definition...
For instance I don't understand why.
I totally agree with you the fact that local patches aren't ideal, it can only
be a temporary solution.
I wish I'd have understood the main fundamentals of osgIntrospection and
genwrapper (for in fact source files in osgWrappers aren't supposed to be
editted, gloups !) but just getting in touch with osg it's not the case yet.
Currently there is a rudimentary mechanism in the code generator to add
custom support code to
classes. In the absence of support for operator functions in
osgIntrospection, this could be used
to handle the NodeCallback issue, including virtual calls from C++ to C#.
I don't really understand what you mean by that ; can you tell me a little more
?
Thanks a lot for your answer !
--
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Has anyone tried 64-bit SUSE enterprise
Hello All: I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. I have also tried the latest dev 2.1.5 with the same issues. I am still poking around but do not know if I can resolve this quickly. Take care Garrett ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinate systems
Hi Dave, On 8/16/07, Dave Pugmire [EMAIL PROTECTED] wrote: What is the easiest way to change the coordinate system of OSG? I read in documentation that there is a way to do it, but it never says how. I need to have the world be XZ on the floor and +Y up. Is it best to attach a transform node below the root, and hang everything off that, or can I configure something? The OSG by default loads models with Z up, Y north, X east, and the camera manipulators all default to looking north, Z up, X to the right. If you want to change the coordinate frame than you need to load the models then rotate them by 90 degrees about the X axis, and change the camera manipulator to a different home position by setting the home position on the manipulator. The trackball manipulator doesn't care which way is up save for its default home position, the drive and flight manipulators do though, to get them to understand your new coordinate frame you'll need to tangle with a CoordinteFrameCallback. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Has anyone tried 64-bit SUSE enterprise
Hi Garret, I've used 64 bit Suse for several years without problems with osgText. Recently I've moved to 64bit Kubunto and don't see any problems either. I have had nothing come by that might suggest some latent 64 bit/linux issue. Do you have problems with osgtext running? Which version of freetype do you have? Robert. On 8/16/07, Garrett Potts [EMAIL PROTECTED] wrote: Hello All: I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. I have also tried the latest dev 2.1.5 with the same issues. I am still poking around but do not know if I can resolve this quickly. Take care Garrett ___ 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] Coordinate systems
Hello Dave, I need to have the world be XZ on the floor and +Y up. Is it best to attach a transform node below the root, and hang everything off that, or can I configure something? I've not seen another way of doing it than a transform node, but I haven't looked all that much. Note, your root can be the actual transform node itself... Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ 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] Has anyone tried 64-bit SUSE enterprise
Hello Garret, I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. You might want to try and get a stack trace with gdb. If it turns out that you have vector iterators or OpenThreads in the stack trace, then it's probably a question of calling setText() while another thread is running the draw traversal. To be safe with all threading models that OSG supports, setText on an osgText object must be called in the update traversal. I've run into this lately myself, and the tricky part is that it won't necessarily crash each time you call setText(), it depends on timing issues. Using an update callback fixed it for me. I just have a setText() method in my callback class which saves the new text but does not set it just yet. I then attach an instance of the callback class to the osgText object, and in the callback's operator() method I call setText on the osgText object (gotten from casting the drawable given to operator()). This guarantees that the actual osgText::setText() call will be done in the update traversal, and seems to work great for me on Windows and Linux. If you need a more concrete code example just ask, but it's pretty simple. Then again I may be completely off track here. In any case, getting a stack trace is the first thing to do in order to diagnose the problem correctly. Good luck, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ 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] Has anyone tried 64-bit SUSE enterprise
Hello Robert: You know that version number makes no since. I did a freetype-config --version and that is what was returned. Let me look in the usr lib directory to see if the version is tacked on there. Have to wait for a reboot. Take care Garrett On Aug 16, 2007, at 2:11 PM, Garrett Potts wrote: Hello Robert: Thank you for the fast response. Trying to figure out now how to enable builds of examples on the SUSE. I will try to run the osgtext example to see. I have the font set to so it uses the system font. The version of freetype installed on the enterprise is 9.8.3. Will keep poking to see. there is something it doesn't like. Take care Garrett On Aug 16, 2007, at 2:01 PM, Robert Osfield wrote: Hi Garret, I've used 64 bit Suse for several years without problems with osgText. Recently I've moved to 64bit Kubunto and don't see any problems either. I have had nothing come by that might suggest some latent 64 bit/linux issue. Do you have problems with osgtext running? Which version of freetype do you have? Robert. On 8/16/07, Garrett Potts [EMAIL PROTECTED] wrote: Hello All: I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. I have also tried the latest dev 2.1.5 with the same issues. I am still poking around but do not know if I can resolve this quickly. Take care Garrett ___ 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] Has anyone tried 64-bit SUSE enterprise
HI Garret, To build the examples you need to configure the cmake to do it, via: cd OpenSceneGraph; ccmake . Then you'll see in the console a list of options, one with be OSG_BUILD_EXAMPLES set by default to OFF, just toggle this to ON, then press 'c' to configure, the 'g' to generate the Makefiles. You'll see onscreen help provide too. The just type make in the console as usual. Robert. On 8/16/07, Garrett Potts [EMAIL PROTECTED] wrote: Hello Robert: Thank you for the fast response. Trying to figure out now how to enable builds of examples on the SUSE. I will try to run the osgtext example to see. I have the font set to so it uses the system font. The version of freetype installed on the enterprise is 9.8.3. Will keep poking to see. there is something it doesn't like. Take care Garrett On Aug 16, 2007, at 2:01 PM, Robert Osfield wrote: Hi Garret, I've used 64 bit Suse for several years without problems with osgText. Recently I've moved to 64bit Kubunto and don't see any problems either. I have had nothing come by that might suggest some latent 64 bit/linux issue. Do you have problems with osgtext running? Which version of freetype do you have? Robert. On 8/16/07, Garrett Potts [EMAIL PROTECTED] wrote: Hello All: I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. I have also tried the latest dev 2.1.5 with the same issues. I am still poking around but do not know if I can resolve this quickly. Take care Garrett ___ 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] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi Joan, The problems you describe look to most likely to be issues with display listing of the geometries. It could be that they are just poorly conditioned datasets - one triangle per geometry is certainly very very badly condidtioned and needs fixing to be able expect any sensible performance level, or it could be that the models are simply to big for the hardware/OGL driver to cope with. There might also be possibility of error in the data such as a primitive index that is invalid. This is also just speculation though... Robert. Robert, I think that there may be indeed some threading bug in the osgViewer. I have tested the files from Joan and if I view them using osgViewer, it starts up (no black screen) but hangs right away after displaying the first few frames or when I try to move the camera. This happens for all of the models here. If I do the same with osgproducerviewer, everything works and I am getting decent frame rates even - few hundreds FPS, even up to 1000 sometimes on my two 6800GS. The models are not that big, the largest has 117693 polygons and I am still getting 1000+ FPS with it with Producer. I have also checked the data files and the VRML files contain several meshes, few thousands triangles/quads each. Nothing extraordinary. I have experienced the hangs with osgViewer in our own application recently as well, but I couldn't reproduce them with the plain osgviewer binary, so I have ascribed it to some race condition in my code. Now these datafiles trigger it with plain viewer 100% each time on my PC. I am running a dual core Athlon (SMP machine) and the cards are configured using SLI, alternative frame rendering (AFR). Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJomn11XseNj94gRAqtPAKCz0RKZOA2BXaq6FU9yLVAOorEK8ACff8RU Uwh0Ezf1pHDeaHDDKA8jmb0= =P9SG -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Has anyone tried 64-bit SUSE enterprise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Potts wrote: Hello All: I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. I have also tried the latest dev 2.1.5 with the same issues. I am still poking around but do not know if I can resolve this quickly. Strange - I was running a 64bit Mandriva and it was working for me just fine. Do you happen to have an ATI card? They seem to not like osgText too much. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJ9On11XseNj94gRAp4vAJ9BouXHCU8BS/lpiOkAwOMW2AGdsQCcCmtS TjWYTwL0dD3etZnxC2l1gMA= =3rGE -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Has anyone tried 64-bit SUSE enterprise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Potts wrote: Hello: You might want to try and get a stack trace with gdb. If it turns out that you have vector iterators or OpenThreads in the stack trace, then it's probably a question of calling setText() while another thread is running the draw traversal. :). Wish I could. The setText is completly hosing everything. I have tried the gdb on the executable. I usually have to reboot. Reboot?? Whoa, now that is really a bad issue. Do you have problems displaying the stats in the osgviewer as well? Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJ/Hn11XseNj94gRAu8/AKDBDh1F64W405vLXCb407RBOYRuRACfc66n tqRF+r5T4CjEiOm7xr6BGPc= =l/OI -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Joan Slottow wrote: Jan ... I notice, from looking at the resultant .osg files, that the vrml translation is introducing a rotation to turn the z of the model up. Yes, this is done to make the viewing more convenient, the standard OSG coordinate system is z-up, not y-up as VRML. vrNav2 already does that for all models so I added a test there not to do it for .wrl models it loads. The first few models that I loaded worked fine. Then I ran into a problem. The problem seems to be related to the size or the number of Shapes in the vrml file. Also, it may be some kind of timing problem (in it taking too long to load the model). Please, see my reply to Robert - I think that you may have hit a bug in osgViewer. For me the viewer hangs completely after loading your data, however, the old osgproducerviewer displays everything fine. The problem thus cannot be in the plugin nor data (both viewers use the same). Moreover, I have seen these hangs with other (non-vrml data) recently too. I guess a threading bug was introduced in the renderer when Robert did some recent changes. BTW, I would be grateful if you could spare one or two of your files and add them to my test file on the OSG web site (zipped, please!). It would be a good test case with realistic data where people can verify that their installation of the plugin works OK. ... I also tried writing a vrml 2.0 file from VMD a popular program used to visualize chemistry molecules. That program wrote out an absolutely huge file with one Shape per triangle. That file can't be loaded. However, I can write a program to read in the vrml file as output by VMD and convert it to a more reasonable one that looks like the vrml files output by OpenDX. I did some playing around with that and that will also work. Of course, if you have a shape per triangle, the loading will be incredibly slow - that means you will have over 100k+ shapes in the largest file! And every shape is potentially a state change in the pipeline, that has to completely kill the performance. I think that your data are OK, there is a problem somewhere in the viewer at this point. I have ltrace on the program (gdb doesn't give me a meaningful stack) and I have found that it hangs on a mutex here: SYS_write(3, cull()\n, 7) = 7 SYS_gettimeofday(0xbfdef484, 0, 0xb7fb04cc, 0x8059530, 0x80593a8) = 0 SYS_gettimeofday(0xbfdef484, 0, 0xb7fb04cc, 0x8059530, 0x80593a8) = 0 SYS_futex(0x805900c, 1, 1, 0x8058f20, 0x805900c) = 0 SYS_write(3, end cull() 0x8058f20\n, 21) = 21 SYS_futex(0x80fda10, 0, 61, 0, 61 There is output to standard error output (probably debug message) and right away it gets blocked on a futex. It is very timing specific - in strace/ltrace I have managed to avoid the deadlock if I have enabled more printing - slowing the viewer down. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJwJn11XseNj94gRAgrUAJ9WjidpOadY+3lvw/ylengHC+z5dACeML89 0fVrNXhEVA1HOJ8M2CAj92E= =7lgh -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Has anyone tried 64-bit SUSE enterprise
hello Jan: Hmmm, funny you mention it. The SUSE enterprise is running on Mac Hardware and so yes it is an ATI board. I also have tried te osgtext example. It runs but is very slow. I do get the same crash issues with osgviewer stats hud where the text is changing on every frame which simulates what I am doing. It could be a driver issue. The MAC OSX handles it very well and I don't remember having any problems on the windows on the MAC running the bootcamp ATI drivers. Take care Garrett On Aug 16, 2007, at 3:02 PM, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Potts wrote: Hello All: I am having text/font issues under the 64-bit SUSE. If ever a setText is called on an osgText object there is a core dump that occurs. Note the code works fine on MAC's ad Windows. I think it might be related to 64-bit build on SUSE. I don't have much more details than this. Commenting out any of the setText code allows my application to run fine. I have also tried the latest dev 2.1.5 with the same issues. I am still poking around but do not know if I can resolve this quickly. Strange - I was running a 64bit Mandriva and it was working for me just fine. Do you happen to have an ATI card? They seem to not like osgText too much. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJ9On11XseNj94gRAp4vAJ9BouXHCU8BS/lpiOkAwOMW2AGdsQCcCmtS TjWYTwL0dD3etZnxC2l1gMA= =3rGE -END PGP SIGNATURE- ___ 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] Has anyone tried 64-bit SUSE enterprise
Hello Jan: Thank you for the insight on your experiences. Yes the stats in osgviewer produces the same problem and causes core dumps. If the osg example apps are static text where theyare set at load time and never change like in osgtext example then no crash, but is really slow to render. I think you are right that it's a ATI problem more than likely the drivers for SUSE. The MAC drivers work great. Take care Garrett On Aug 16, 2007, at 3:04 PM, Jan Ciger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Potts wrote: Hello: You might want to try and get a stack trace with gdb. If it turns out that you have vector iterators or OpenThreads in the stack trace, then it's probably a question of calling setText() while another thread is running the draw traversal. :). Wish I could. The setText is completly hosing everything. I have tried the gdb on the executable. I usually have to reboot. Reboot?? Whoa, now that is really a bad issue. Do you have problems displaying the stats in the osgviewer as well? Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJ/Hn11XseNj94gRAu8/AKDBDh1F64W405vLXCb407RBOYRuRACfc66n tqRF+r5T4CjEiOm7xr6BGPc= =l/OI -END PGP SIGNATURE- ___ 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] osgDotNet : Used from C#
Hi Christophe,
(B) Well in fact I tried this afternoon the local OSG copy patching
idea, but it doesn't seem to work. I can't see why... taking the
LightPoint issue :
{a} I've added two accessor methods in include/osgSim/LightPoint and
src/osgSim/LightPoint.cpp - that 'updates' native osg dll and library
{b} I've added those through I_Method and I_Method macros in
src/osgWrappers/LightPoint.cpp - that should be taken into account by
Generator when generating again
Generator/output/src/osgSim/LightPoint.cpp and .h
{a} worked perfecly but not {b} : the osgDotNet solution generation
still works but doesn't provide anything new into LightPoint class
definition...
For instance I don't understand why.
Did you rebuild the osgWrappers/osgSim DLL? If that builds without
error the osgDotNet generator should see your additions. Note that the
build of the osgWrappers DLLs is not enabled in the default CMake
configuration; you need to turn on BUILD_OSG_WRAPPERS.
If you've got a Linux box handy, genwrapper is pretty trivial to get
started with. Just make sure you've got boost, doxygen, and libxml2
packages installed, and the follow the example at
http://www.openscenegraph.org/projects/osg/wiki/GenWrapper. On Windows
it's a pain because you need to set up all the dependencies yourself.
Currently there is a rudimentary mechanism in the code generator to
add custom support code to
classes. In the absence of support for operator functions in
osgIntrospection, this could be used
to handle the NodeCallback issue, including virtual calls from C++
to C#.
I don't really understand what you mean by that ; can you tell me a
little more ?
Sorry... too many thoughts into too few sentences. :) Let me try to be
more explicit:
Take a look at the custom code items in the GeneratorConfiguration.cpp
file in the osgDotNet generator source. That mechanism is used to
insert arbitrary code into osgDotNet-generated wrapper classes, so
hand-coded wrapper functions to support NodeCallback::operator() could
be added there.
Currently genwrapper/osgIntrospection ignores operator functions, and
adding proper support for them is non-trivial, so this one-off
hand-coded approach is the best way to support them in osgDotNet right
now.
Virtual function invocation among wrappers, user-defined subclasses of
wrappers, and native code works in all directions by virtue of the
design of osgDotNet. This support also extends to hand-coded virtual
function wrappers if their implementations mimic the auto-generated
support code for virtual functions.
-Mike
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Has anyone tried 64-bit SUSE enterprise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Garrett Potts wrote: hello Jan: Hmmm, funny you mention it. The SUSE enterprise is running on Mac Hardware and so yes it is an ATI board. I also have tried te osgtext example. It runs but is very slow. I do get the same crash issues with osgviewer stats hud where the text is changing on every frame which simulates what I am doing. It could be a driver issue. The MAC OSX handles it very well and I don't remember having any problems on the windows on the MAC running the bootcamp ATI drivers. It is a long standing bad driver/OSG interaction. I have the same issue on my laptop with a FireGL T2 card and i586 since at least two years, likely longer. If there is any osgText in the scene, the viewer locks up in a busy loop, pegging the CPU at 100% load. Usually it wakes up after several minutes, though, without a reboot. I believe that it has to do with the way osgText is implemented - by rendering glyphs into many small textures which need to be generated and uploaded to the GPU when the node is first time rendered. The subsequent triggering of stats or help is immediate for me, only the first one is always a problem. I have solved this issue by implementing my own text widget using Cairo and Freetype. That way I have only a single quad with a single texture, regardless of how many characters and with what font I render. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxK0In11XseNj94gRAm6PAKDoMS/09jFYGSVRD0VlJqKjhCPbxQCfTTtD ciK3JQjZVltmuCBVbjPc3Eg= =Hy/D -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reusing the collada reader for physics
Hi, We're looking at using Collada for setting up scenes for physics based simulation. Collada is great because it integrates physics and graphics, but it is also evil for the same reason, since any Collada reader really should integrate well both with a physics engine and with a graphics engine. What would be the best way of using the osg collada reader for also setting up the physics? From the way the reader is designed now, as a plug-in that delivers nodes to the scenegrah, it isn't obvious how to connect to a physics library. I'm fond of the thought of seeing the support for collada graphics in osg being improved gradually until all the bells and whistle's are supported, and therefore I'm not particularly happy about developing yet another collada reader that is better suited for our needs, since we would have a hard time keeping it updated. Of course the same questions apply for a collada exporter.. /Ken Kenneth Bodin Umeå university, Sweden [EMAIL PROTECTED] -- Like Ornithology is good for birds, Philosophy of science and technology is good for scientists. -- Richard Feynman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with multiple screens
I am using OSG with VS 7.1. When I move my application window (i.e. CompositeViewer window) from one screen to another on a computer with multiple monitors, my application crashes. In particular, it seems as though it is taking an eternity for each frame to be processed. I am guessing that at each RESIZE (MOVE) event, I have to figure out which screen the application window is now on and update the GraphicsTraits accordingly. Is this right. If yes, could anyone please tell me how to achieve this. If not, please tell me what the problem is. Thanks -Prasant ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with multiple screens
What graphics card and OS are you using? Do you see the same behavior with osgviewer? I just tried dragging the osgviewer window from one screen to the other on my multi-head GeForce Windows XP system and didn't encounter any problems (other than the expected slight slowdown when the window overlapped both screens). -Paul I am using OSG with VS 7.1. When I move my application window (i.e. CompositeViewer window) from one screen to another on a computer with multiple monitors, my application crashes. In particular, it seems as though it is taking an eternity for each frame to be processed. I am guessing that at each RESIZE (MOVE) event, I have to figure out which screen the application window is now on and update the GraphicsTraits accordingly. Is this right. If yes, could anyone please tell me how to achieve this. If not, please tell me what the problem is. Thanks -Prasant ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDEM layers and CoordinateSystemNode
Hi guys, It seems as soon as I try to add a layer to a geocentric db - CoordinateSystemNode ==NULL; -t %SRC_TEX2% -t %SRC_TEX3% --layer 1 -t %SRC_TEX8%^ -d %SRC_ELE1% -d %SRC_ELE2% -d %SRC_ELE3%^ --no-terrain-simplification --geocentric --skirt-ratio 0.06 -l %NUM_LVL% -o %TGT_IVE% result in CoordinateSystemNode ==NULL -t %SRC_TEX2% -t %SRC_TEX3% --layer 0 -t %SRC_TEX8%^ -d %SRC_ELE1% -d %SRC_ELE2% -d %SRC_ELE3%^ --no-terrain-simplification --geocentric --skirt-ratio 0.06 -l %NUM_LVL% -o %TGT_IVE% result in a proper CoordinateSystemNode. Any ideas? Gert -- Gert van Maren Head of Research Development K2Vi Virtual Reality Software Data Interface Technologies Ltd Phone: +64 21 2855581 Email: [EMAIL PROTECTED] Web: http://www.k2vi.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] About the osgTerrain segments
what is the heightFile 's format, jpg? png? or others? thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
