date:20070816

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] RFC: API additions for osg::ImageStream?

Hi Hartmut,

On 8/15/07, Hartmut Seichter <[EMAIL PROTECTED]> wrote:
> this is intended to be a discussion starter. I am currently adapting
> osgART to integrate better with OpenSceneGraph 2.x and I am removing all
> the indirections we have in osgART to use live video via
> ImageStream/Image. As I assume some of you might also want to use live
> video within simulations the current interface of ImageStream is suboptimal.

For video is also suboptimal so I'm certainly open to seeing to evolve further.

It just so happens that I was talking to a client yesterday about live
video feed in the quicktime plugin so it would seem the planets are
aligned :-)

> Two questions basically:
>
> - are there any objections about having a method open() which basically
> connects the image stream to a device or an image file. start() is kind
> of "late" because open() might pull up dialogs for configuration. This
> also would mean a new StreamStatus READY (like in GStreamer).

The general design on Image/ImageStream is that the plugins create the
ImageStream objects tying them to a specific file (or source), and its
been assumed to far that once constructed by the plugin the
Image/ImageStream would be ready to use.

If you introduce an open() would this be with a parameter?  Would you
also need a close()?

> - using -1 as return of getLength to indicate a live source? Or have a
> flag with a getter (bool isLive() const)?

Return a getLength of MAX_FLT for live might make more sense, or pehaps 0.

I would suggest having an enum or string for the video source type of
ImageStream.

For live streams functions like rewind, looping, pause and the time
methods are all irrelevant, so perhaps one should break ImageStream up
into several classes -
a MovieStream class, and LiveStream which subclass from ImageStream.

> Configuration of live sources is hard to generalize, thus I am hesitant
> to suggest anything for that: any takers?

Well you know more about live streams than I do so could provide a bit
of scoping out of what types of configuration you are currently having
to set?

I was hoping that we'd be able to encode all the info for the live
video stream as a std::string that can be passed to the plugin via the
normal filename route.
Robert.
___
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...

2007-08-16 Thread Adrian Egli

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#

2007-08-16 Thread Christophe Medard

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).

Is that the main explanation of (A), or is there something else ?
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.
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#.
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

2007-08-16 Thread [EMAIL PROTECTED]

Thanks Robert.

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: 
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] RefCount setSceneData

Hi Robert,

Robert Osfield wrote:
> Could you provide a code example that reproduces the issue that you
> perceive.  Please specify which version of the OSG you are using.

i modified the teapot example, code below: (using OSG 2.1.4)

 // construct the viewer.
 osg::ref_ptr viewer = new osgViewer::Viewer;

 osg::ref_ptr pot = createTeapot();

 std::cout << "ref: " << pot->referenceCount() << "\n";
 // add model to viewer.
 viewer->setSceneData( pot.get() );

 std::cout << "ref: " << pot->referenceCount() << "\n";

 viewer = NULL;

 std::cout << "ref: " << pot->referenceCount() << "\n";

 return 0;

the output of the ref counts in my case is:
ref: 1
ref: 3
ref: 2

but IMHO should be 1,3,1

regards,
Michael.


___
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:
> 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.

i want the RTT camera to render non of it's child nodes, but still 
update the attached texture (so that the texture becomes blank).

setting a cullmask to the camera, to cull it's children, did not give 
the desired effect.

hope i could put myself clear this time,
thanks,
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

On 8/16/07, Michael Ebner <[EMAIL PROTECTED]> wrote:
> the output of the ref counts in my case is:
> ref: 1
> ref: 3
> ref: 2
>
> but IMHO should be 1,3,1

I have just tried you code segment in the latest in SVN and get:

ref: 1
ref: 3
ref: 1

Try 2.1.5, or the SVN version as last week I was refactoring the way
that the osgViewed handled osgViewer::Renderer, and amoung other
things removed a circular reference that had been introduced when
Renderer first came about in 2.1.4.

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 want the RTT camera to render non of it's child nodes, but still
> update the attached texture (so that the texture becomes blank).

Well its pretty simple then just switch off the children by setting
their NodeMask, or use an osg::Switch as a child of the osg::Camera.

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 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?

2007-08-16 Thread filip.holm

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

2007-08-16 Thread Joan Slottow

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 
reasonable one that looks like the vrml files output by OpenDX.  I did some 
playing around with that and that will also work.


Joan Slottow



___
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 wr

[osg-users] Coordinate systems

2007-08-16 Thread Dave Pugmire

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] osgDotNet : Used from C#

2007-08-16 Thread Mike Wittman

Hi Christophe,

 

Thanks for your comments on osgDotNet.  

 

Regarding (A1): you'll need to build the Debug osgDotNet assemblies and use 
them with the Debug OSG DLLs.  If you do that you should be able to see native 
OSG state when you've stepped into the osgDotNet and OSG code.  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.

 

(B): IMO weaknesses in osgDotNet or osgIntrospection should be addressed in 
their respective codebases rather than as patches to the core OSG.  Burdening 
Robert with unnecessary work due to this project would not be a good way to 
ensure his continued support. :)

 

Just patching your local copy of OSG can be done, but I'd advise against it 
because it's fragile and contravenes the project goal of maintaining a similar 
API between C# and C++.


 

For public attributes, support just needs to be added to osgDotNet to handle 
these.  Some work has been done towards this end, but it's not there 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#.

 

 

Mike Wittman

[EMAIL PROTECTED]  

___

Seismic Micro-Technology, Inc.

8584 Katy Freeway, Suite 400 / Houston, Texas 77024

Tel.  +1 (713) 464-6188

Fax. +1 (713) 464-6440

Web:  www.seismicmicro.com http://www.seismicmicro.com> 

___

Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY 
for more information.

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Thursday, August 16, 2007 5:46 AM
To: osg-users@lists.openscenegraph.org
Subject: [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).
 

 Is that the main explanation of (A), or is there something else ?

 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. 

 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#. 

 Will the mere patching of the osg release (as for the LightPoint) 
work in th

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#

2007-08-16 Thread Christophe Medard

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

2007-08-16 Thread Jean-Sébastien Guay

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 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

Re: [osg-users] Has anyone tried 64-bit SUSE enterprise

2007-08-16 Thread Jean-Sébastien Guay

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] Has anyone tried 64-bit SUSE enterprise

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.


> 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()


I only update a text object within the update traversal of the scene  
graph.  Thank you for the suggestion though.

I am also suspect about the version of freetype being compiled in.  I  
am downloading the latest and greatest release form freetype.org and  
will try that instead of the system freetype.


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] 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#

2007-08-16 Thread Mike Wittman

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

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

2007-08-16 Thread Kenneth Bodin (Holmlund)

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

2007-08-16 Thread Prasant Vajjalu Rekapalli

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] Reusing the collada reader for physics

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kenneth Bodin (Holmlund) wrote:
> Hi,
> We're looking at using Collada for setting up scenes for physics based 
..
> 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 was thinking about the same issue because we would like to move over
to a COLLADA-based production pipeline. What would be good enough is a
possibility to register a callback to be called, whenever an object is
loaded, passing the root node of the corresponding DOM subtree. Then it
would be easy to parse out the required parts, either manually or using
the COLLADA DOM and feed them into the physics engine.

> 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.

I do not believe that the Collada loader for OSG will ever support
physics - it doesn't really make sense, OSG is a scene graph and physics
could be implemented in many different ways.

> Of course the same questions apply for a collada exporter..

For example, the Blender exporter for Collada exports physical
properties too (e.g. the collision bounding volumes and masses).
However, that is likely because Blender includes its own physics engine
already.

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFGxL0Xn11XseNj94gRAnrPAJ4jqLjEXOwNuwww85KxAu7tlFPVkgCcC4/R
3sicnPvkF0n49A4zyuJ6/zE=
=X+uT
-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] Problem with multiple screens

Hi Prasant,

take a look at your driver settings first, sounds to me like you are 
using "single display performance mode", as shown here:

http://i189.photobucket.com/albums/z201/paloooz/Untitled-1-12.png

(something like that should apply for ATI cards too, although i don't 
know the exact setting)

regards,
Michael.


Prasant Vajjalu Rekapalli wrote:
> 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
> 

___
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

2007-08-16 Thread Paul Martz

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

2007-08-16 Thread Gert van Maren

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

Re: [osg-users] Has anyone tried 64-bit SUSE enterprise