Re: [osg-users] 2d library

[Mario Valle]

osgEgipt?

Oliver Schoenborn wrote:
Anyone know of an osg-based library that provides 2d stuff like arcs 
and circles and lines and symbols etc? I have some HUDs to make and it 
would be nice to not have to create all that from scratch. Thanks,

Oliver

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/



--
Ing. Mario Valle
Visualization Group  | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS)  | Tel:  +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax:  +41 (91) 610.82.82

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] 2d library

[Oliver Schoenborn]

Anyone know of an osg-based library that provides 2d stuff like arcs and 
circles and lines and symbols etc? I have some HUDs to make and it would 
be nice to not have to create all that from scratch. Thanks,

Oliver

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] 3D transformation

[Adrian Egli]

yes, have a look at quaternions math description, may use MatLab or
Wikipedia resources

2007/5/24, HEMANTH <[EMAIL PROTECTED]>:



osg::MatrixTransform * tT = new osg::MatrixTransform();

osg::Quat Q1(osg::DegreesToRadians(45.0),osg::Vec3(1,0,0));
osg::Quat Q2(osg::DegreesToRadians(45.0),osg::Vec3(0,1,0));
osg::Quat Q3(osg::DegreesToRadians(90.0),osg::Vec3(0,0,1));


tT->setMatrix(osg::Matrix::rotate(Q1*Q2*Q3)*osg::Matrix::translate(150,0,50));

osg::Matrix mat=tT->getMatrix();


does the above code creates a matrix that can rotate an object 45 degrees
along x-axis , 45 degrees along y-axis and 90 degrees along z-axis ?


--
*
K.HEMANTH
COMPUTER SCIENCE AND ENGINEERING(DUAL DEGREE)
ROLL.NO# 200402017
ROOM.NO# 399(OBH)
CONTACT NO# 9849229262
IIIT--HYDERABAD.

EMAIL:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
**

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Improving the performance of video texture

[Koh, Shalin]

Hi Robert,

Thanks for your suggestions.

> You are most likely CPU limited due to decompression, or bandwidth
> limited to the GPU.  You are already using PBO's so this will be
> making the bandwidth management as efficient as you'll probably get
> it.

I have found some good performance-related articles on the NVIDIA
developer website [http://developer.nvidia.com/], and are using them to
track down the cause of the bottleneck. 

Do you know of any useful profiling tools for detecting graphics
bottlenecks? I used gDEBugger during the early stages of development,
which indicated that texturing was a bottleneck. Making changes such as
using a PixelBufferObject and reusing the Image, instead of creating a
new one each time greatly increased the performance.

> Things to look at perhaps would be a round robin updating of the video
> textures, such that you only update all the textures in one frame.

This is a good idea; I'll investigate it further.

> The other thing you might be able to optimize is the viewers
> management of the screens, which viewer library do you use?

We are using our own custom viewing framework. Our application is
written in Java, and has a Java canvas showing each video. We've created
Java wrappers for the OSG objects we need, such as SceneView,
TextureRectangle. Each canvas has its own SceneView.

Shalin




DISCLAIMER:---
This Email may contain confidential and/or privileged information and is 
intended 
solely for the addressee(s) named. If you have received this information in 
error, or
are advised that you have been posted this Email by accident, please notify the 
sender by return Email, do not redistribute it, delete the Email and keep no 
copies.
--

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Improving the performance of video texture

[Koh, Shalin]

Hi Robert,

Thanks for your suggestions.

> You are most likely CPU limited due to decompression, or bandwidth
> limited to the GPU.  You are already using PBO's so this will be
> making the bandwidth management as efficient as you'll probably get
> it.

I have found some good performance-related articles on the NVIDIA
developer website [http://developer.nvidia.com/], and are using them to
track down the cause of the bottleneck. 

Do you know of any useful profiling tools for detecting graphics
bottlenecks? I used gDEBugger during the early stages of development,
which indicated that texturing was a bottleneck. Making changes such as
using a PixelBufferObject and reusing the Image, instead of creating a
new one each time greatly increased the performance.

> Things to look at perhaps would be a round robin updating of the video
> textures, such that you only update all the textures in one frame.

This is a good idea; I'll investigate it further.

> The other thing you might be able to optimize is the viewers
> management of the screens, which viewer library do you use?

We are using our own custom viewing framework. Our application is
written in Java, and has a Java canvas showing each video. We've created
Java wrappers for the OSG objects we need, such as SceneView,
TextureRectangle. Each canvas has its own SceneView.

Shalin




DISCLAIMER:---
This Email may contain confidential and/or privileged information and is 
intended 
solely for the addressee(s) named. If you have received this information in 
error, or
are advised that you have been posted this Email by accident, please notify the 
sender by return Email, do not redistribute it, delete the Email and keep no 
copies.
--

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Mouse cursor in Graphics window

[Mathias Fröhlich]

Hi Robert,

we need with flightgear an api to change the mouse cursor shape in a Graphics 
window.
I believe the best place to implement that would be in the osgViewers code 
where we already have the ability to switch it on an off.

Do you agree that we should add such an api to osgViewer::GraphicsWindow?

If so, I can see two possible implementations here:
1. With a fixed set of mouse shapes that are enumerated with an enum.
2. With an osg::Image as mouse shape.

The first api is way simpler and easier to implement. Sufficient for me ...

The second one is much more generic. That generic that I am sure the amount of 
code to handle various image formats will blow up the code very much. Also I 
am not sure if every gui api can make use of all kinds of possible 
osg::Images. So we may need to reject some of them for some reasons.

What do you think?

   Greetings

Mathias
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] OpenThreads lib name on Windows

[E. Wing]

Yes, there were a lot of reasons for that change. It sticks out like a
sore thumb compared to everything else and it makes dealing with
OpenThreads more complicated, both on the building side, but also on
the Finding (Using) side via CMake. CMake's FIND commands don't handle
Libname{extrastuff} very well and it's annoying to special case this.
The convention seemed unnecessary to us, so we dumped it. (I also
requested MEW dump the version name on the freetype library in his
binary set for the same reasons.)

Since we are facing massive ABI breakage anyway for the next release,
it seemed like as good a time as any to make the change.

If you really need to use the old format, I think you want to modify
the LIB_POSTFIX. (This is actually another compelling reason to
provide an option to build OSG against a prebuilt OpenThreads as the
LIB_POSTFIX setting will apply to everything in the build including
the OSG stuff.)


-Eric
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] collada dae plugin on windows

[biv]

whoops...I should have been more specific...I meant animation in the
sense of moving objects around(similar to the osganimate example)
without skeletal info...the problem is that we have model an animated
sequence in max and we would like to export to a format that osg
supports and retains the animation. we've done this befor but we had
to take about d different steps to get to osg so I was thinking that
collada would be the way to go...

On 5/24/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote:

On Thu, 2007-05-24 at 19:53 +0100, Robert Osfield wrote:
> On 5/24/07, Gerrick Bivins <[EMAIL PROTECTED]> wrote:
> > Does the collada plugin support animations?
>
> Not yet.  It'd need to know about osgCal to do this.

Well, even before this Cal3D would need to break itself up so that the
skeletal components could be used w/out using it's own model format. One
of us Cal3D guys just needs to sit down and do it... although, these
days, it really would make the most sense to do it this way ANYWAYS,
since you're going to end up supplying your own buffers in hardware...

Bah, now I'm just rambling. :)

> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: Windows CMake install problem

[E. Wing]

From: "Robert Osfield" <[EMAIL PROTECTED]>
Subject: Re: [osg-users] Re: Windows CMake install problem



Hi Eric,

In this case, the files in question aren't actually private, we still
want to install them.  How does that affect the issue of header
subdirectories under OSX?

Having the possibility of private headers is really useful though.

Robert.



Re: [osg-users] Re: Windows CMake install problem


So to clarify, my definition of Private Headers means that:
1) The public headers need to #include the private headers
2) The end user is not allowed to directly to #include the private
headers in their own code (hence why they are called 'private')
3) The private headers are "installed" since public headers need to
read them (but in a OS X framework, they get installed to a special
location to help enforce the private notion). I didn't get around to
installing the private headers in osgViewer because I wasn't yet sure
if they were actually private or just "project" headers (meaning they
are used to build osgViewer, but never need to be #included again),
plus I haven't gotten around to doing any install stuff yet anyway.

Does this fit with what's going on?

So OS X frameworks provide features to handle the above case and
provide two directories for headers:
Headers/ and PrivateHeaders/

So imagine we have the public header MyFoo.h and the private header
MyHiddenFoo.h in a framework called Foo.framework. The directory
layout looks like (ignoring multiple versioning and symbolic links):

Foo.framework/
   Headers/
   MyFoo.h
   PrivateHeaders/
   MyHiddenFoo.h

The file MyFoo.h is allowed to #include MyHiddenFoo.h via:
#include 

The private headers are free to #include public headers such as
#include 
They may also #include other private headers such as
#include 

Note that the path part is always the base name of the framework name
and doesn't change. This is the big requirement of frameworks. (This
is also why putting version numbers in the framework filename is a big
no-no as it will break the #include name.)

Now in your own code, say main.c, you are free to #include public headers, e.g.
#include 
but, if you try including a private header in your file like:
#include 
the compile will fail because it is not allowed to directly see the
private headers. This is enforced by the tool chain magic.

Obviously, how this maps to the standard Unix chain (e.g.
/usr/include) is that "private headers" are installed with the public
headers since the standard Unix tool chain doesn't have any method of
distinction and enforcement. You are trusted to not directly #include
things if they are considered private.

Thanks,
Eric
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

OS X threading issues (was: Re: [osg-users] Win32 CLOSE event)

[Stephan Huber]

Hi Robert,

Robert Osfield schrieb:
Exactly with threading models are causing problems now? 

SingleThreaded works
DrawThreadPerContext + CullDrawThreadPerContext doesn't work (dead lock 
when closing a window)
CullThreadPerCameraDrawThreadPerContext doesn't start up properly, the 
windows are created, but deadlock occurs before showing the first frame.


I tried to debug the issue today, but with no luck. If you have any 
pointers where to start I'll try my best the next days.


Stephan
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] TexGenNode & TexEnvCombine

[Weitz, Andrew C.]

Don,

I didn't realize you were another SAIC-er.  We just got things working
on our end.  We ended up scrapping the TexEnvCombine and replacing it
with a TexEnv decal.  We can then edit the image data's alpha values to
control transparency.

I'd love to meet up with you, but I actually telecommute from
California.  Not sure when I'll be back east next...

Andrew


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Donald Tidrow
Sent: Thursday, May 24, 2007 2:02 PM
To: osg users
Subject: Re: [osg-users] TexGenNode & TexEnvCombine

I mucked around with things on a very similar project, and finally wound

up using a second mask texture to cure that problem.  There might be 
another way to do it, but I kinda quit looking once I got something that

worked.

You know, I'm only a few miles away from you - how about we meet up over

here (or there) and I can show you what I did to solve the problem.

Don

Weitz, Andrew C. wrote:
> Thank you for the explanation, Tim.  It makes sense to me now.
> Unfortunately, your suggestion didn't work.  It caused my projected
> texture to disappear.
> 
> Just in case I explained my goal wrong, here's another shot:
> 
> I want my underlying terrain to always retain its original colors and
> alpha value (of 1).  I only want to control the opacity of my
projected
> texture.  With an opacity of 1, the projected texture will completely
> occlude the terrain.  With an opacity of 0, the projected texture will
> not be visible at all.  Is that possible with TexEnvCombine?
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tim Moore
> Sent: Wednesday, May 23, 2007 2:06 PM
> To: osg users
> Subject: Re: [osg-users] TexGenNode & TexEnvCombine
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Weitz, Andrew C. wrote:
> 
>>What do you mean by "TexEnvCombine::INTERPOLATE actually takes 3
>>arguments"?  Isn't INTERPOLATE an argument to the setCombine_RGB
>>function?  I must be missing something...
>>
>>
> 
> The INTERPOLATE function in the combiner has 3 inputs.
> 
> You are interpolating between two values, Operand0_RGB and
Operand1_RGB.
> What controls the interpolation? Operand2_RGB. Hence my suggestion to
> use the alpha channel of your projected texture to control the
> interpolation.
> 
> Tim
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFGVKzIeDhWHdXrDRURAhTqAJ9XxJij96HFIb7R/UQladz2WYH+bwCfS0YX
> Ko6YPMP1CMYzAqmoC566DXI=
> =knJ9
> -END PGP SIGNATURE-
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
> 

-- 
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
- Benjamin Franklin

++
|  Don Tidrow|
|  Visualization Software Engineer   |
|  SAIC  |
|  ph: 703-253-1094  |
++
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] TexGenNode & TexEnvCombine

[Donald Tidrow]

I mucked around with things on a very similar project, and finally wound 
up using a second mask texture to cure that problem.  There might be 
another way to do it, but I kinda quit looking once I got something that 
worked.


You know, I'm only a few miles away from you - how about we meet up over 
here (or there) and I can show you what I did to solve the problem.


Don

Weitz, Andrew C. wrote:

Thank you for the explanation, Tim.  It makes sense to me now.
Unfortunately, your suggestion didn't work.  It caused my projected
texture to disappear.

Just in case I explained my goal wrong, here's another shot:

I want my underlying terrain to always retain its original colors and
alpha value (of 1).  I only want to control the opacity of my projected
texture.  With an opacity of 1, the projected texture will completely
occlude the terrain.  With an opacity of 0, the projected texture will
not be visible at all.  Is that possible with TexEnvCombine?


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Moore
Sent: Wednesday, May 23, 2007 2:06 PM
To: osg users
Subject: Re: [osg-users] TexGenNode & TexEnvCombine

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Weitz, Andrew C. wrote:


What do you mean by "TexEnvCombine::INTERPOLATE actually takes 3
arguments"?  Isn't INTERPOLATE an argument to the setCombine_RGB
function?  I must be missing something...




The INTERPOLATE function in the combiner has 3 inputs.

You are interpolating between two values, Operand0_RGB and Operand1_RGB.
What controls the interpolation? Operand2_RGB. Hence my suggestion to
use the alpha channel of your projected texture to control the
interpolation.

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

iD8DBQFGVKzIeDhWHdXrDRURAhTqAJ9XxJij96HFIb7R/UQladz2WYH+bwCfS0YX
Ko6YPMP1CMYzAqmoC566DXI=
=knJ9
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/



--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
- Benjamin Franklin

++
|  Don Tidrow|
|  Visualization Software Engineer   |
|  SAIC  |
|  ph: 703-253-1094  |
++
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] collada dae plugin on windows

[Jeremy L. Moles]

On Thu, 2007-05-24 at 19:53 +0100, Robert Osfield wrote:
> On 5/24/07, Gerrick Bivins <[EMAIL PROTECTED]> wrote:
> > Does the collada plugin support animations?
> 
> Not yet.  It'd need to know about osgCal to do this.

Well, even before this Cal3D would need to break itself up so that the
skeletal components could be used w/out using it's own model format. One
of us Cal3D guys just needs to sit down and do it... although, these
days, it really would make the most sense to do it this way ANYWAYS,
since you're going to end up supplying your own buffers in hardware...

Bah, now I'm just rambling. :)

> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
> 

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Shaders not working

[Gerrick Bivins]

Hi Jason,
Looks like you are using cg shaders...I think if you want to use CG directly
you'll need to use the osgNV nodekit to load your shaders. The interface you
are attempting to use, uses GLSL(OpenGL Shading Language). Depending on the
complexity of your shaders it's pretty easy to convert your shader code from
CG to GLSL.
biv

On 5/24/07, Jason <[EMAIL PROTECTED]> wrote:


Hey everyone,

I'm having a little trouble running a vertex and fragment shader. When I
run my program it seems to be completely ignoring the shaders. I'm think I
missed something. I'm running with an osgUtil::SceneView (so not Viewer).
Here is the code I use to set up my shaders.

GraphicsPath::GraphicsPath()
   osg::Geometry(),
   mStateSet()
{
   setUseDisplayList(false);

   mStateSet = getOrCreateStateSet();
   osg::Program* program = new osg::Program;
   mStateSet->setGlobalDefaults();

   mStateSet->setAttributeAndModes(program, osg::StateAttribute::ON);

   Filename vertShaderSource("vertShader.cg");
   Filename fragShaderSource("fragShader.cg");

   osg::Shader* vertexShader   = new osg::Shader(osg::Shader::VERTEX);
   if(vertexShader->loadShaderSourceFromFile(vertShaderSource.name
().c_str()))
   {
  cout << vertShaderSource.name() <<" vertex shader loaded." << endl;
   }

   osg::Shader* fragmentShader = new osg::Shader(osg::Shader::FRAGMENT);

   if(fragmentShader->loadShaderSourceFromFile(fragShaderSource.name
().c_str()))
   {
  cout << fragShaderSource.name() <<" frag shader loaded." << endl;
   }

   program->addShader(fragmentShader);
   program->addShader(vertexShader);

   osg::Uniform* simTimeUniform = new osg::Uniform("simTime", float(0.0));
   simTimeUniform->setUpdateCallback(new SimTimeUniformVarying);
   mStateSet->addUniform(simTimeUniform);

   osg::Uniform* pastColorUniform
  = new osg::Uniform("pastColor", osg::Vec3(0.5, 0.5, 0.5));

   mStateSet->addUniform(pastColorUniform);

   osg::Uniform* futureColorUniform
  = new osg::Uniform("futureColor", osg::Vec3(0.0, 1.0, 0.0));

   mStateSet->addUniform(futureColorUniform);
}

I have also verified that the callback for my uniforms is firing off every
frame.

class SimTimeUniformVarying : public osg::Uniform::Callback
{
public:

   SimTimeUniformVarying():
  gti(GraphicsThreadInterface::getInstance())
   {
   }

   virtual void operator() (osg::Uniform* uniform, osg::NodeVisitor* nv)
   {
  uniform->set((float)gti->mSimTime.inSeconds());
   }

   GraphicsThreadInterface* gti;
};

Anyone ever have an issue like this with the shaders not working?

Thanks,
Jason

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] collada dae plugin on windows

[Robert Osfield]

On 5/24/07, Gerrick Bivins <[EMAIL PROTECTED]> wrote:

Does the collada plugin support animations?


Not yet.  It'd need to know about osgCal to do this.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Can't pick item that is attached to a PositionAttitudeTransform

[Robert Osfield]

Hi Brad,

It "should" work,  there shouldn't be anything extra you need to do to
get intersections, as far as the intersection traversal is concerned
its just treated as a standard osg::Transform like all the transform
subclasses.

I'm afraid you'll need to step through things with a debugger.

Robert.

On 5/24/07, Brad Colbert <[EMAIL PROTECTED]> wrote:




Hi folks,

My intersection test is not successful when I try to pick a Quad that is
under a PositionAttitudeTransform node.  It does work, however, if I use a
matrix to transform the vertices of the Quad when I build the quad and set
all of the transforms of the PositionAttitudeTransform node to 0.

What am I missing.  Is there a call that I need to make to transform the
picking action as well?

P.S.  The intersection works if I click below the object, but this may just
be that the vertices haven't been transformed by the
PositionAttitudeTransform when the intersection is calculated.

Thanks ahead for any help,
Brad


---
Brad Colbert
Renaissance Sciences Corporation
W: 480 290-3997
F: 425 675-8044
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Re: Shaders not working

[Jason]

Hi Jason,
Looks like you are using cg shaders...I think if you want to use CG directly
you'll need to use the osgNV nodekit to load your shaders. The interface you
are attempting to use, uses GLSL(OpenGL Shading Language). Depending on the
complexity of your shaders it's pretty easy to convert your shader code from
CG to GLSL.
biv

...

I don't think I'm using CG...that's just the extension I used
following an example online. Does the extension matter? I changed them
to .txt for now.

My shaders are very simple. Here they are, Vertex:


uniform float  simTime;
uniform float3 pastColor;
uniform float3 futureColor;

varying vec3 pointColor;

void main(void)
{
  gl_Position = vec3(gl_ModelViewMatrix * gl_Vertex);
  gl_Position.x = gl_Position.x + 1000.0;

  if (simTime > gl_Color.x)
  {
 pointColor = pastColor;
  }
  else
  {
 pointColor = futureColor;
  }
}

Fragment:
varying vec3 pointColor;

void main(void)
{
gl_FragColor = vec4(pointColor, 1.0);
}



On 5/24/07, Jason <[EMAIL PROTECTED]> wrote:


Hey everyone,

I'm having a little trouble running a vertex and fragment shader. When I
run my program it seems to be completely ignoring the shaders. I'm think I
missed something. I'm running with an osgUtil::SceneView (so not Viewer).
Here is the code I use to set up my shaders.

GraphicsPath::GraphicsPath()
   osg::Geometry(),
   mStateSet()
{
   setUseDisplayList(false);

   mStateSet = getOrCreateStateSet();
   osg::Program* program = new osg::Program;
   mStateSet->setGlobalDefaults();

   mStateSet->setAttributeAndModes(program, osg::StateAttribute::ON);

   Filename vertShaderSource("vertShader.cg");
   Filename fragShaderSource("fragShader.cg");

   osg::Shader* vertexShader   = new osg::Shader(osg::Shader::VERTEX);
   if(vertexShader->loadShaderSourceFromFile(vertShaderSource.name
().c_str()))
   {
  cout << vertShaderSource.name() <<" vertex shader loaded." << endl;
   }

   osg::Shader* fragmentShader = new osg::Shader(osg::Shader::FRAGMENT);

   if(fragmentShader->loadShaderSourceFromFile(fragShaderSource.name
().c_str()))
   {
  cout << fragShaderSource.name() <<" frag shader loaded." << endl;
   }

   program->addShader(fragmentShader);
   program->addShader(vertexShader);

   osg::Uniform* simTimeUniform = new osg::Uniform("simTime", float(0.0));
   simTimeUniform->setUpdateCallback(new SimTimeUniformVarying);
   mStateSet->addUniform(simTimeUniform);

   osg::Uniform* pastColorUniform
  = new osg::Uniform("pastColor", osg::Vec3(0.5, 0.5, 0.5));

   mStateSet->addUniform(pastColorUniform);

   osg::Uniform* futureColorUniform
  = new osg::Uniform("futureColor", osg::Vec3(0.0, 1.0, 0.0));

   mStateSet->addUniform(futureColorUniform);
}

I have also verified that the callback for my uniforms is firing off every
frame.

class SimTimeUniformVarying : public osg::Uniform::Callback
{
public:

   SimTimeUniformVarying():
  gti(GraphicsThreadInterface::getInstance())
   {
   }

   virtual void operator() (osg::Uniform* uniform, osg::NodeVisitor* nv)
   {
  uniform->set((float)gti->mSimTime.inSeconds());
   }

   GraphicsThreadInterface* gti;
};

Anyone ever have an issue like this with the shaders not working?

Thanks,
Jason

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Shaders not working

[Jason]

Hey everyone,

I'm having a little trouble running a vertex and fragment shader. When I run
my program it seems to be completely ignoring the shaders. I'm think I
missed something. I'm running with an osgUtil::SceneView (so not Viewer).
Here is the code I use to set up my shaders.

GraphicsPath::GraphicsPath()
  osg::Geometry(),
  mStateSet()
{
  setUseDisplayList(false);

  mStateSet = getOrCreateStateSet();
  osg::Program* program = new osg::Program;
  mStateSet->setGlobalDefaults();

  mStateSet->setAttributeAndModes(program, osg::StateAttribute::ON);

  Filename vertShaderSource("vertShader.cg");
  Filename fragShaderSource("fragShader.cg");

  osg::Shader* vertexShader   = new osg::Shader(osg::Shader::VERTEX);
  if(vertexShader->loadShaderSourceFromFile(vertShaderSource.name
().c_str()))
  {
 cout << vertShaderSource.name() <<" vertex shader loaded." << endl;
  }

  osg::Shader* fragmentShader = new osg::Shader(osg::Shader::FRAGMENT);

  if(fragmentShader->loadShaderSourceFromFile(fragShaderSource.name
().c_str()))
  {
 cout << fragShaderSource.name() <<" frag shader loaded." << endl;
  }

  program->addShader(fragmentShader);
  program->addShader(vertexShader);

  osg::Uniform* simTimeUniform = new osg::Uniform("simTime", float(0.0));
  simTimeUniform->setUpdateCallback(new SimTimeUniformVarying);
  mStateSet->addUniform(simTimeUniform);

  osg::Uniform* pastColorUniform
 = new osg::Uniform("pastColor", osg::Vec3(0.5, 0.5, 0.5));

  mStateSet->addUniform(pastColorUniform);

  osg::Uniform* futureColorUniform
 = new osg::Uniform("futureColor", osg::Vec3(0.0, 1.0, 0.0));

  mStateSet->addUniform(futureColorUniform);
}

I have also verified that the callback for my uniforms is firing off every
frame.

class SimTimeUniformVarying : public osg::Uniform::Callback
{
public:

  SimTimeUniformVarying():
 gti(GraphicsThreadInterface::getInstance())
  {
  }

  virtual void operator() (osg::Uniform* uniform, osg::NodeVisitor* nv)
  {
 uniform->set((float)gti->mSimTime.inSeconds());
  }

  GraphicsThreadInterface* gti;
};

Anyone ever have an issue like this with the shaders not working?

Thanks,
Jason
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] collada dae plugin on windows

[Gerrick Bivins]

Does the collada plugin support animations?

On 5/23/07, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:


This error is usually caused by linking against the dynamic libxml2 lib
on Windows instead of the static lib. If you link against the static
library (called libxml2_a.lib), you shouldn't get the error.

If you want to link against the libxml2 DLL, you'll need to rebuild the
DOM. First remove the constant "LIBXML_STATIC" from the preprocessor
defines in LIBXMLPlugin.vcproj, and if you're building the DOM as a DLL
(I'm not sure how OSG uses the DOM), change it to link against
libxml2.lib instead of libxml2_a.lib.

This is all rather confusing... I should write up some documentation for
this.

Gerrick Bivins wrote:
> Hi Robert and Anders,
> Yup. libxml2 is what I'm linking in. So is the solution to update
> collada dom? Ouch. I was hoping to be able to just use the installer
> for this "easy update" rather than the brute force route and building
> collada dom...Oh well.
> biv
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] 3D transformation

[HEMANTH]

osg::MatrixTransform * tT = new osg::MatrixTransform();

osg::Quat Q1(osg::DegreesToRadians(45.0),osg::Vec3(1,0,0));
osg::Quat Q2(osg::DegreesToRadians(45.0),osg::Vec3(0,1,0));
osg::Quat Q3(osg::DegreesToRadians(90.0),osg::Vec3(0,0,1));

tT->setMatrix(osg::Matrix::rotate(Q1*Q2*Q3)*osg::Matrix::translate(150,0,50));

osg::Matrix mat=tT->getMatrix();


does the above code creates a matrix that can rotate an object 45 degrees 
along x-axis , 45 degrees along y-axis and 90 degrees along z-axis ?



--
*
K.HEMANTH
COMPUTER SCIENCE AND ENGINEERING(DUAL DEGREE)
ROLL.NO# 200402017
ROOM.NO# 399(OBH)
CONTACT NO# 9849229262
IIIT--HYDERABAD.

EMAIL:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
**

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Can't pick item that is attached to a PositionAttitudeTransform

[Brad Colbert]

Hi folks,
 
My intersection test is not successful when I try to pick a Quad that is under 
a PositionAttitudeTransform node.  It does work, however, if I use a matrix to 
transform the vertices of the Quad when I build the quad and set all of the 
transforms of the PositionAttitudeTransform node to 0.
 
What am I missing.  Is there a call that I need to make to transform the 
picking action as well?
 
P.S.  The intersection works if I click below the object, but this may just be 
that the vertices haven't been transformed by the PositionAttitudeTransform 
when the intersection is calculated.
 
Thanks ahead for any help,
Brad
 
---
Brad Colbert
Renaissance Sciences Corporation
W: 480 290-3997
F: 425 675-8044
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] OpenThreads lib name on Windows

[Michael Henheffer]

Hi Paul,


How can a developer create a project that links with OpenThreads, and 
can be built with both OSG v1.2 and OSG v2.0? The only solution I can 
think of is to have two sets of project/solution files, basically 
identical except for the change in OpenThreads library name...


I think what you are looking for could be done by adding a source file 
containing something like this:


   #ifndef OSG_VERSION
   #include 
   #endif

   #ifdef _DEBUG
   #define OSG_LIB(___lib___) #___lib___ "d.lib"
   #else
   #define OSG_LIB(___lib___) #___lib___ ".lib"
   #endif

   #if (OSG_VERSION_MAJOR <= 1 && OSG_VERSION_MINOR <= 2)
   #pragma comment(lib, OSG_LIB("OpenThreadsWin32"))
   #else
   #pragma comment(lib, OSG_LIB("OpenThreads"))
   #endif


It should remove the need to add the library to the project file.

I hope this helps,

Michael
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

On 5/24/07, Robert Osfield <[EMAIL PROTECTED]> wrote:

I don't plan on going through all the plugins myself though, my RSI
won't cope with that I'm afraid.


Forgot to say... need a willing helper.  Might I suggest modifying one
plugin (i.e. ive) and osgViewer to work, then submit this for review,
then once we have this refined I can give the go ahead for it being
rolled out to all plugins.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

oups... I pressed "Send" too fast :-)

I just wanted to say:

Good point ! you're right: unloading the readerwriter seems useless in most
cases... (at least for me :-) ) [except maybe if someone has multiple
version of the same plugin changing dynamically... but that would be a bit
weird I guess :-)]

So, are you planning to had this C function to all plugins now ?...

I guess the same behavior could be used internally to register the
DotOsgWrappers too... I'll test that tomorrow.


Well if it works, then a macro helper for users mains, and then C
functions entry points in the plugins would be a good step forward.

I don't plan on going through all the plugins myself though, my RSI
won't cope with that I'm afraid.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

oups... I pressed "Send" too fast :-)

I just wanted to say:

Good point ! you're right: unloading the readerwriter seems useless in most
cases... (at least for me :-) ) [except maybe if someone has multiple
version of the same plugin changing dynamically... but that would be a bit
weird I guess :-)]

So, are you planning to had this C function to all plugins now ?...

I guess the same behavior could be used internally to register the
DotOsgWrappers too... I'll test that tomorrow.

Manu.


2007/5/24, Emmanuel Roche <[EMAIL PROTECTED]>:




2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:
>
> You can't unload a static plugin... so why would you want to unload
> the readerwriter?
>
> On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> > In this case, I think we should add two functions: one to register the
>
> > readerwriter and an other to unregister it... no ? (I don't see how to
> > provide the same functionalities than the Register..Proxy in a single
> > function call...)
> >
> > Manu.
> >
> >
> >
> >
> > 2007/5/24, Emmanuel Roche <[EMAIL PROTECTED]>:
> > > I'm not sure to understand : what would be this function for ? to
> register
> > the plugin in static mode ? so every sample and projects would have to
> call
> > the needed functions when starting its process (checking for static
> mode):
> > is this what you're thinking about ?
> > >
> > >
> > > Manu.
> > >
> > >
> > > 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > > > HI Manu,
> > > >
> > > > My thought about using C functions would be for them to be unique
> for
> > > > each ReaderWriter i.e :
> > > >
> > > > extern "C" {
> > > >
> > > >   void osgdb_ive(void)
> > > >   {
> > > >   }
> > > >
> > > > };
> > > >
> > > > Would be added to the ive plugin, and the same goes for the other
> > > > plugins.  One could possible do this via a macro when doing the
> proxy
> > > > instantiation just to simplify the source code.   Could you try
> this
> > > > as a quick hack and let me know how you get on.
> > > >
> > > > The .osg plugin and its dozens of DotOsgWrappers is more of a
> > > > challenge, but will be solvable using something similar.
> > > >
> > > > Robert.
> > > >
> > > >
> > > >
> > > > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > > > Well, things aren't going that well unfortunately:
> > > > >
> > > > > I've just realize that every plugin that use even a single
> > > > > RegisterDotOsgWrapperProxy return the exact SAME symbol for this
> > object...
> > > > > and I cannot find anyway to tell gcc to include the same symbol
> from
> > > > > multiple libraries (or worse from multiple objets files in a
> single
> > library
> > > > > in the case of osg...): This means for example that we can't
> link with
> > > > > osgdb_osgText and osgdb_osgFX at the same time for example...
> :'(
> > > > >
> > > > >
> > > > > concerning the automation of the process, indeed, it's quite
> heavy...
> > but I
> > > > > doubt there is any C function to retrieve the mangled name
> internally
> > > > > the best solution would be to use small scripts just after core
> and
> > plugins
> > > > > libs construction to find all the needed symbols and then to
> include
> > them
> > > > > for each sample...
> > > > >
> > > > > and for other projets... hmm... well... we can still use the
> generated
> > > > > symbols but I don't see anything better for the moment :-)
> > > > >
> > > > > Manu.
> > > > >
> > > > >
> > > > > 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > > > > >
> > > > > > Hi Many,
> > > > > >
> > > > > > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > > > > > Hmmm yet it works fine for plugin with their single
> > > > > > > RegisterReaderWriterProxy object !! :-)
> > > > > > >
> > > > > > > --> I managed to start osgviewer with a .ive file !!! :-D
> > > > > > >
> > > > > > > So considering the symbol lists I already have for windows I
> would
> > say
> > > > > that
> > > > > > > the only "problematic" plugins (in the "common" and "image"
> series
> > at
> > > > > least)
> > > > > > > are osg and osgParticle
> > > > > >
> > > > > > Good to hear that you've made further progress.  It would be
> nice to
> > > > > > be able to automate some of this leg work.  I do also wonder
> about
> > the
> > > > > > possibility of use a C functions in the plugins to allow one
> to grab
> > > > > > the sybmol with the name manging, this might help the process
> of
> > > > > > making things more automated.
> > > > > >
> > > > > > W.r.t .osg plugin and others of its type they all use an proxy
> > > > > > mechanism for registering the ReaderWriter ( read.write files)
> and
> > the
> > > > > > DotOsgWrappers (read/write the objects), its the later which
> is
> > > > > > different from the rest of the plugins.
> > > > > >
> > > > > > Robert.
> > > > > > ___
> > > > > > osg-users mailing list
> > > > > > osg-users@openscenegraph.net
> > > > > >
> > http://openscenegraph.net/mailman/listinfo/osg-users
> 

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

I quite like the macro option.  It makes sense.

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

yes but... thinking about it:

- if we build in static mode this means that we already know what plugins
will be used at compile time. So the code can be changed instead of changing
the symbols to include... What I mean is : instead of trying to play with
those unfriendly symbols (depends on architecture, compiler, platform,
etc... ?), since we ARE already linking with the plugin libraries anyway, on
could simply do something like:

In main project or sample file:

#ifdef OSG_LIBRARY_STATIC
extern "C" {
 extern void register_ive();
extern void unregister_ive();
 };
#endif

main() {

 #ifdef OSG_LIBRARY_STATIC
  register_ive();
 #endif

  // do what you want

   // clean and quit:
#ifdef OSG_LIBRARY_STATIC
 unregister_ive();
#endif

  return 0;
}

at the end of the ReaderWriterIVE.cpp file:

extern "C" {

 IVEReaderWriter* re_ive;

 void register_ive(void)
 {
 re_ive = new IVEReaderWriter;
Registry::instance()->addReaderWriter(re_ive);
  }

 void unregister_ive(void)
  {
Registry::instance()->removeReaderWriter(re_ive);
 }

};

... I've just tested this and it works.. :-) no need to find the symbol for
the ive plugin anymore, no additional includes, just a few more code
lines... But I think this is the most friendly solution to all coders, no ?

With good macros this could even become something like:

DECLARE_PLUGIN("ive")

main() {
  REGISTER_PLUGIN("ive")

  // do what you want

 UNREGISTER_PLUGIN("ive")
}

Manu.


2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:
>
> On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> > I'm not sure to understand : what would be this function for ? to
register
> > the plugin in static mode ? so every sample and projects would have to
call
> > the needed functions when starting its process (checking for static
mode):
> > is this what you're thinking about ?
>
> One would only ever use this function for the symbol it generates, its
> purely a helper to you when you statically link.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:


You can't unload a static plugin... so why would you want to unload
the readerwriter?

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> In this case, I think we should add two functions: one to register the
> readerwriter and an other to unregister it... no ? (I don't see how to
> provide the same functionalities than the Register..Proxy in a single
> function call...)
>
> Manu.
>
>
>
>
> 2007/5/24, Emmanuel Roche <[EMAIL PROTECTED]>:
> > I'm not sure to understand : what would be this function for ? to
register
> the plugin in static mode ? so every sample and projects would have to
call
> the needed functions when starting its process (checking for static
mode):
> is this what you're thinking about ?
> >
> >
> > Manu.
> >
> >
> > 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > > HI Manu,
> > >
> > > My thought about using C functions would be for them to be unique
for
> > > each ReaderWriter i.e :
> > >
> > > extern "C" {
> > >
> > >   void osgdb_ive(void)
> > >   {
> > >   }
> > >
> > > };
> > >
> > > Would be added to the ive plugin, and the same goes for the other
> > > plugins.  One could possible do this via a macro when doing the
proxy
> > > instantiation just to simplify the source code.   Could you try this
> > > as a quick hack and let me know how you get on.
> > >
> > > The .osg plugin and its dozens of DotOsgWrappers is more of a
> > > challenge, but will be solvable using something similar.
> > >
> > > Robert.
> > >
> > >
> > >
> > > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > > Well, things aren't going that well unfortunately:
> > > >
> > > > I've just realize that every plugin that use even a single
> > > > RegisterDotOsgWrapperProxy return the exact SAME symbol for this
> object...
> > > > and I cannot find anyway to tell gcc to include the same symbol
from
> > > > multiple libraries (or worse from multiple objets files in a
single
> library
> > > > in the case of osg...): This means for example that we can't link
with
> > > > osgdb_osgText and osgdb_osgFX at the same time for example... :'(
> > > >
> > > >
> > > > concerning the automation of the process, indeed, it's quite
heavy...
> but I
> > > > doubt there is any C function to retrieve the mangled name
internally
> > > > the best solution would be to use small scripts just after core
and
> plugins
> > > > libs construction to find all the needed symbols and then to
include
> them
> > > > for each sample...
> > > >
> > > > and for other projets... hmm... well... we can still use the
generated
> > > > symbols but I don't see anything better for the moment :-)
> > > >
> > > > Manu.
> > > >
> > > >
> > > > 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > > > >
> > > > > Hi Many,
> > > > >
> > > > > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > > > > Hmmm yet it works fine for plugin with their single
> > > > > > RegisterReaderWriterProxy object !! :-)
> > > > > >
> > > > > > --> I managed to start osgviewer with a .ive file !!! :-D
> > > > > >
> > > > > > So considering the symbol lists I already have for windows I
would
> say
> > > > that
> > > > > > the only "problematic" plugins (in the "common" and "image"
series
> at
> > > > least)
> > > > > > are osg and osgParticle
> > > > >
> > > > > Good to hear that you've made further progress.  It would be
nice to
> > > > > be able to automate some of this leg work.  I do also wonder
about
> the
> > > > > possibility of use a C functions in the plugins to allow one to
grab
> > > > > the sybmol with the name manging, this might help the process of
> > > > > making things more automated.
> > > > >
> > > > > W.r.t .osg plugin and others of its type they all use an proxy
> > > > > mechanism for registering the ReaderWriter (read.write files)
and
> the
> > > > > DotOsgWrappers (read/write the objects), its the later which is
> > > > > different from the rest of the plugins.
> > > > >
> > > > > Robert.
> > > > > ___
> > > > > osg-users mailing list
> > > > > osg-users@openscenegraph.net
> > > > >
> http://openscenegraph.net/mailman/listinfo/osg-users
> > > > > http://www.openscenegraph.org/
> > > > >
> > > >
> > > >
> > > > ___
> > > > osg-users mailing list
> > > > osg-users@openscenegraph.net
> > > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > > http://www.openscenegraph.org/
> > > >
> > > ___
> > > osg-users mailing list
> > > osg-users@openscenegraph.net
> > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > http://www.openscenegraph.org/
> > >
> >
> >
>
>
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
___
osg-users mailing list
osg-users@openscenegraph.net

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

You can't unload a static plugin... so why would you want to unload
the readerwriter?

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)

Manu.




2007/5/24, Emmanuel Roche <[EMAIL PROTECTED]>:
> I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?
>
>
> Manu.
>
>
> 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > HI Manu,
> >
> > My thought about using C functions would be for them to be unique for
> > each ReaderWriter i.e :
> >
> > extern "C" {
> >
> >   void osgdb_ive(void)
> >   {
> >   }
> >
> > };
> >
> > Would be added to the ive plugin, and the same goes for the other
> > plugins.  One could possible do this via a macro when doing the proxy
> > instantiation just to simplify the source code.   Could you try this
> > as a quick hack and let me know how you get on.
> >
> > The .osg plugin and its dozens of DotOsgWrappers is more of a
> > challenge, but will be solvable using something similar.
> >
> > Robert.
> >
> >
> >
> > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > Well, things aren't going that well unfortunately:
> > >
> > > I've just realize that every plugin that use even a single
> > > RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
> > > and I cannot find anyway to tell gcc to include the same symbol from
> > > multiple libraries (or worse from multiple objets files in a single
library
> > > in the case of osg...): This means for example that we can't link with
> > > osgdb_osgText and osgdb_osgFX at the same time for example... :'(
> > >
> > >
> > > concerning the automation of the process, indeed, it's quite heavy...
but I
> > > doubt there is any C function to retrieve the mangled name internally
> > > the best solution would be to use small scripts just after core and
plugins
> > > libs construction to find all the needed symbols and then to include
them
> > > for each sample...
> > >
> > > and for other projets... hmm... well... we can still use the generated
> > > symbols but I don't see anything better for the moment :-)
> > >
> > > Manu.
> > >
> > >
> > > 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > > >
> > > > Hi Many,
> > > >
> > > > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > > > Hmmm yet it works fine for plugin with their single
> > > > > RegisterReaderWriterProxy object !! :-)
> > > > >
> > > > > --> I managed to start osgviewer with a .ive file !!! :-D
> > > > >
> > > > > So considering the symbol lists I already have for windows I would
say
> > > that
> > > > > the only "problematic" plugins (in the "common" and "image" series
at
> > > least)
> > > > > are osg and osgParticle
> > > >
> > > > Good to hear that you've made further progress.  It would be nice to
> > > > be able to automate some of this leg work.  I do also wonder about
the
> > > > possibility of use a C functions in the plugins to allow one to grab
> > > > the sybmol with the name manging, this might help the process of
> > > > making things more automated.
> > > >
> > > > W.r.t .osg plugin and others of its type they all use an proxy
> > > > mechanism for registering the ReaderWriter (read.write files) and
the
> > > > DotOsgWrappers (read/write the objects), its the later which is
> > > > different from the rest of the plugins.
> > > >
> > > > Robert.
> > > > ___
> > > > osg-users mailing list
> > > > osg-users@openscenegraph.net
> > > >
http://openscenegraph.net/mailman/listinfo/osg-users
> > > > http://www.openscenegraph.org/
> > > >
> > >
> > >
> > > ___
> > > osg-users mailing list
> > > osg-users@openscenegraph.net
> > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > http://www.openscenegraph.org/
> > >
> > ___
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
>
>


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osg::Viewer multi-thread operation

[Robert Osfield]

On 5/24/07, Paul Martz <[EMAIL PROTECTED]> wrote:

> >Is it a no-op if the
> > threading model is SingleThreaded?
>
> Yes indeed.

So, from the way I read the original poster's problem, he could still
experience a crash in the SingleThreaded case, because his own separate
thread is changing the scene graph out from under the Viewer while OSG is
processing the old scene graph.

In addition to stopThreading(), I'd think he would also need to block or
gate his separate thread so that it only swaps out the scene graph after
draw() completes and before update() starts. Or is this not necessary
because of reference counted memory?


Ooo, you are correct.  You'll still need to stop the viewer's frame
loop from running, doing stopThreading isn't enough...

Bascially one will need to stick some kind of syconization step into
the frame loop.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] OpenThreads lib name on Windows

[Robert Osfield]

On 5/24/07, Paul Martz <[EMAIL PROTECTED]> wrote:

Under the new CMake system, the OpenThreads library name on Windows has
changed from OpenThreadsWin32.dll to OpenThreads.dll. Was there a reason for
this change?


I didn't make the decision, but my guess it was naturally fell out
from using a consistent scheme for all OSG related libs.


How can a developer create a project that links with OpenThreads, and can be
built with both OSG v1.2 and OSG v2.0? The only solution I can think of is
to have two sets of project/solution files, basically identical except for
the change in OpenThreads library name...


Could you use an env var in the project file?

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re:[osg-users] Example Problems/Questions

[belthil]

Hi!

I just have an answer for your first question. In fact the keyboard is 
still working in the new versions of OSG. But the stats and the help are not 
included in the viewer anymore. Knowing that now, to have a viewer, you have to 
write:

osgViewer::Viewer viewer;

If you want to have the stats again, and the help, you have to write these two 
lines of code:

viewer.addEventHandler(new osgViewer::StatsHandler);
viewer.addEventHandler(new osgViewer::HelpHandler);


Bye bye.

Belthil

Créez votre adresse électronique [EMAIL PROTECTED] 
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] Picking very small text

[Jason Beverage]

Sweet, I'll give that a shot, thanks Robert!

Jason

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Thursday, May 24, 2007 10:16 A
To: osg users
Subject: Re: [osg-users] Picking very small text

Use osgUtil::IntersectionVisitor in SVN/1.9.x, it uses doubles :-)

On 5/24/07, Jason Beverage <[EMAIL PROTECTED]> wrote:
> All,
>
> I am working with an OSG project that renders geospatial data in 2D
with
> longitude as my X coordinate and latitude as my Y coordinate.  I also
> have some osgText::Text nodes that I place in the scene that have
> character size mode set to screen.
>
> The issue that I'm having is that when I am zoomed far away, I can
pick
> the text using the mouse using an IntersectVisitor most of the time,
but
> sometimes when I zoom close into the text, I can't successfully pick
the
> text.  My gut feeling is that I'm running into a floating point
> precision problem as the glyph quads are all stored in floats and the
> IntersectVisitor also uses floats internally.
>
> Does anyone have any ideas for solutions to this problem?
>
> Thanks!
>
> Jason
>
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Example Problems/Questions

[paul1492]

I can not say I've used much of the latest OSG code (I'm generally using 1.2), 
but I've attempted to run 1.9.4 examples and have some questions/problems.

1) What happened to the on screen help that used to appear for the examples. It 
seems most of the keyboard actions no longer work. For example 's' and 'h' to 
name two?
2) When I hit 's' 3 times in osgviewer, a message "Scene Stats to do.." 
appears. Are there plans to add scene stats for 2.0?
3) When I run 'osgsequence', the on screen HUD seems to imply that hitting 's' 
and 'l' will have some effect. The only thing I see them doing is printing a 
message to the terminal window. Is it intended to have an action on the scene 
graph?
4) When I run 'osgdelauney' and hit the 'n' key 10 times, the HUD text appears 
messed up.
5) The main README file in the OpenSceneGraph says you need to do the following 
to build OSG:
  cd OpenSceneGraph
  ccmake .
  make
  sudo make install

Do you really mean "ccmake"?  If so, then it would be helpful for us old-time 
Linux OSG users if there was better documentation with the build on how to 
create the GNUmakefiles. When I typed "ccmake", I got a screen-based windowing 
environment in which I didn't know what I was doing.

Paul


   
Pinpoint
 customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

yes but... thinking about it:

- if we build in static mode this means that we already know what plugins
will be used at compile time. So the code can be changed instead of changing
the symbols to include... What I mean is : instead of trying to play with
those unfriendly symbols (depends on architecture, compiler, platform,
etc... ?), since we ARE already linking with the plugin libraries anyway, on
could simply do something like:

In main project or sample file:

#ifdef OSG_LIBRARY_STATIC
extern "C" {
extern void register_ive();
extern void unregister_ive();
};
#endif

main() {

#ifdef OSG_LIBRARY_STATIC
 register_ive();
#endif

 // do what you want

 // clean and quit:
#ifdef OSG_LIBRARY_STATIC
unregister_ive();
#endif

 return 0;
}

at the end of the ReaderWriterIVE.cpp file:

extern "C" {

IVEReaderWriter* re_ive;

void register_ive(void)
{
   re_ive = new IVEReaderWriter;
   Registry::instance()->addReaderWriter(re_ive);
}

void unregister_ive(void)
{
   Registry::instance()->removeReaderWriter(re_ive);
}

};

... I've just tested this and it works.. :-) no need to find the symbol for
the ive plugin anymore, no additional includes, just a few more code
lines... But I think this is the most friendly solution to all coders, no ?

With good macros this could even become something like:

DECLARE_PLUGIN("ive")

main() {
 REGISTER_PLUGIN("ive")

 // do what you want

UNREGISTER_PLUGIN("ive")
}

Manu.


2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:


On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> I'm not sure to understand : what would be this function for ? to
register
> the plugin in static mode ? so every sample and projects would have to
call
> the needed functions when starting its process (checking for static
mode):
> is this what you're thinking about ?

One would only ever use this function for the symbol it generates, its
purely a helper to you when you statically link.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] osg::Viewer multi-thread operation

[Paul Martz]

> >Is it a no-op if the
> > threading model is SingleThreaded?
> 
> Yes indeed.

So, from the way I read the original poster's problem, he could still
experience a crash in the SingleThreaded case, because his own separate
thread is changing the scene graph out from under the Viewer while OSG is
processing the old scene graph.

In addition to stopThreading(), I'd think he would also need to block or
gate his separate thread so that it only swaps out the scene graph after
draw() completes and before update() starts. Or is this not necessary
because of reference counted memory?
   -Paul

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?


One would only ever use this function for the symbol it generates, its
purely a helper to you when you statically link.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

In this case, I think we should add two functions: one to register the
readerwriter and an other to unregister it... no ? (I don't see how to
provide the same functionalities than the Register..Proxy in a single
function call...)

Manu.




2007/5/24, Emmanuel Roche <[EMAIL PROTECTED]>:


I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?

Manu.

2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:
>
> HI Manu,
>
> My thought about using C functions would be for them to be unique for
> each ReaderWriter i.e :
>
> extern "C" {
>
>   void osgdb_ive(void)
>   {
>   }
>
> };
>
> Would be added to the ive plugin, and the same goes for the other
> plugins.  One could possible do this via a macro when doing the proxy
> instantiation just to simplify the source code.   Could you try this
> as a quick hack and let me know how you get on.
>
> The .osg plugin and its dozens of DotOsgWrappers is more of a
> challenge, but will be solvable using something similar.
>
> Robert.
>
>
>
> On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> > Well, things aren't going that well unfortunately:
> >
> > I've just realize that every plugin that use even a single
> > RegisterDotOsgWrapperProxy return the exact SAME symbol for this
> object...
> > and I cannot find anyway to tell gcc to include the same symbol from
> > multiple libraries (or worse from multiple objets files in a single
> library
> > in the case of osg...): This means for example that we can't link with
> > osgdb_osgText and osgdb_osgFX at the same time for example... :'(
> >
> >
> > concerning the automation of the process, indeed, it's quite heavy...
> but I
> > doubt there is any C function to retrieve the mangled name internally
> > the best solution would be to use small scripts just after core and
> plugins
> > libs construction to find all the needed symbols and then to include
> them
> > for each sample...
> >
> > and for other projets... hmm... well... we can still use the generated
> > symbols but I don't see anything better for the moment :-)
> >
> > Manu.
> >
> >
> > 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> > >
> > > Hi Many,
> > >
> > > On 5/24/07, Emmanuel Roche < [EMAIL PROTECTED]> wrote:
> > > > Hmmm yet it works fine for plugin with their single
> > > > RegisterReaderWriterProxy object !! :-)
> > > >
> > > > --> I managed to start osgviewer with a .ive file !!! :-D
> > > >
> > > > So considering the symbol lists I already have for windows I would
> say
> > that
> > > > the only "problematic" plugins (in the "common" and "image" series
> at
> > least)
> > > > are osg and osgParticle
> > >
> > > Good to hear that you've made further progress.  It would be nice to
> > > be able to automate some of this leg work.  I do also wonder about
> the
> > > possibility of use a C functions in the plugins to allow one to grab
> > > the sybmol with the name manging, this might help the process of
> > > making things more automated.
> > >
> > > W.r.t .osg plugin and others of its type they all use an proxy
> > > mechanism for registering the ReaderWriter (read.write files) and
> the
> > > DotOsgWrappers (read/write the objects), its the later which is
> > > different from the rest of the plugins.
> > >
> > > Robert.
> > > ___
> > > osg-users mailing list
> > > osg-users@openscenegraph.net
> > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > http://www.openscenegraph.org/
> > >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Picking very small text

[Robert Osfield]

Use osgUtil::IntersectionVisitor in SVN/1.9.x, it uses doubles :-)

On 5/24/07, Jason Beverage <[EMAIL PROTECTED]> wrote:

All,

I am working with an OSG project that renders geospatial data in 2D with
longitude as my X coordinate and latitude as my Y coordinate.  I also
have some osgText::Text nodes that I place in the scene that have
character size mode set to screen.

The issue that I'm having is that when I am zoomed far away, I can pick
the text using the mouse using an IntersectVisitor most of the time, but
sometimes when I zoom close into the text, I can't successfully pick the
text.  My gut feeling is that I'm running into a floating point
precision problem as the glyph quads are all stored in floats and the
IntersectVisitor also uses floats internally.

Does anyone have any ideas for solutions to this problem?

Thanks!

Jason

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] OpenThreads lib name on Windows

[Paul Martz]

Under the new CMake system, the OpenThreads library name on Windows has
changed from OpenThreadsWin32.dll to OpenThreads.dll. Was there a reason for
this change?
 
How can a developer create a project that links with OpenThreads, and can be
built with both OSG v1.2 and OSG v2.0? The only solution I can think of is
to have two sets of project/solution files, basically identical except for
the change in OpenThreads library name...
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
303 859 9466
 
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osgdem

[Robert Osfield]

The triangulation is based on grids that are they simplified.

On 5/24/07, Neus Aparicio <[EMAIL PROTECTED]> wrote:

!Hi! I am using osgDem and I want to know that type of
triangulation uses, as well as if it uses the
piramidal form to show imagenes or quadtree.

thanks

Neus Aparicio Ferrando




¡Descubre una nueva forma de obtener respuestas a tus preguntas!
Entra en Yahoo! Respuestas.
http://es.answers.yahoo.com/info/welcome
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osg::Viewer multi-thread operation

[Robert Osfield]

On 5/24/07, Paul Martz <[EMAIL PROTECTED]> wrote:

Hi Robert -- What does viewer.stopThreading() do?


Errr, well you could read the method name it errr stop viewer threads.


Is it a no-op if the
threading model is SIngleThreaded?


Yes indeed.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osg::Viewport --> getViewport() function removed ?

[Robert Osfield]

HI Manu,

I deprecated the functions to avoid problems with code making the
assumptions about the type of data stored in osg::Viewport.  I did
this part of work moving Viewport across to using doubles rather than
ints, this in turn is related to resize support into osgViewer.

We could potentially re-enable the getViewport methods for backwards
compatibility.

Robert

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

Hello there,

I've just noticed that osg::Viewport::getViewport() isn't defined anymore
(in OSG 1.9.4 at least)  (both definition with int&s and double&s are inside
a #if 0 - #endif section...) Is this normal ???


Manu.


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

I'm not sure to understand : what would be this function for ? to register
the plugin in static mode ? so every sample and projects would have to call
the needed functions when starting its process (checking for static mode):
is this what you're thinking about ?

Manu.

2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:


HI Manu,

My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :

extern "C" {

  void osgdb_ive(void)
  {
  }

};

Would be added to the ive plugin, and the same goes for the other
plugins.  One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code.   Could you try this
as a quick hack and let me know how you get on.

The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.

Robert.



On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> Well, things aren't going that well unfortunately:
>
> I've just realize that every plugin that use even a single
> RegisterDotOsgWrapperProxy return the exact SAME symbol for this
object...
> and I cannot find anyway to tell gcc to include the same symbol from
> multiple libraries (or worse from multiple objets files in a single
library
> in the case of osg...): This means for example that we can't link with
> osgdb_osgText and osgdb_osgFX at the same time for example... :'(
>
>
> concerning the automation of the process, indeed, it's quite heavy...
but I
> doubt there is any C function to retrieve the mangled name internally
> the best solution would be to use small scripts just after core and
plugins
> libs construction to find all the needed symbols and then to include
them
> for each sample...
>
> and for other projets... hmm... well... we can still use the generated
> symbols but I don't see anything better for the moment :-)
>
> Manu.
>
>
> 2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
> >
> > Hi Many,
> >
> > On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> > > Hmmm yet it works fine for plugin with their single
> > > RegisterReaderWriterProxy object !! :-)
> > >
> > > --> I managed to start osgviewer with a .ive file !!! :-D
> > >
> > > So considering the symbol lists I already have for windows I would
say
> that
> > > the only "problematic" plugins (in the "common" and "image" series
at
> least)
> > > are osg and osgParticle
> >
> > Good to hear that you've made further progress.  It would be nice to
> > be able to automate some of this leg work.  I do also wonder about the
> > possibility of use a C functions in the plugins to allow one to grab
> > the sybmol with the name manging, this might help the process of
> > making things more automated.
> >
> > W.r.t .osg plugin and others of its type they all use an proxy
> > mechanism for registering the ReaderWriter (read.write files) and the
> > DotOsgWrappers (read/write the objects), its the later which is
> > different from the rest of the plugins.
> >
> > Robert.
> > ___
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
>
>
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Picking very small text

[Jason Beverage]

All,

I am working with an OSG project that renders geospatial data in 2D with
longitude as my X coordinate and latitude as my Y coordinate.  I also
have some osgText::Text nodes that I place in the scene that have
character size mode set to screen.

The issue that I'm having is that when I am zoomed far away, I can pick
the text using the mouse using an IntersectVisitor most of the time, but
sometimes when I zoom close into the text, I can't successfully pick the
text.  My gut feeling is that I'm running into a floating point
precision problem as the glyph quads are all stored in floats and the
IntersectVisitor also uses floats internally.

Does anyone have any ideas for solutions to this problem?

Thanks!

Jason

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] osgdem

[Neus Aparicio]

!Hi! I am using osgDem and I want to know that type of
triangulation uses, as well as if it uses the
piramidal form to show imagenes or quadtree.

thanks

Neus Aparicio Ferrando


   

¡Descubre una nueva forma de obtener respuestas a tus preguntas!
Entra en Yahoo! Respuestas.
http://es.answers.yahoo.com/info/welcome
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

RE: [osg-users] osg::Viewer multi-thread operation

[Paul Martz]

Hi Robert -- What does viewer.stopThreading() do? Is it a no-op if the
threading model is SIngleThreaded?
   -Paul


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Robert Osfield
> Sent: Thursday, May 24, 2007 2:38 AM
> To: osg users
> Subject: Re: [osg-users] osg::Viewer multi-thread operation
> 
> Hi,
> 
> First up, you shoudl be able to get rid of the 
> viewer.realize() from your ReloadScene, realize is just for 
> window creation.
> 
> Second the OSG isn't designed to be used the way you are 
> wanting to use it, the design is that you have single 
> threaded update, and this is who you current implementation works.
> 
> Now, you could do some hacking, such as stopping the 
> threading on the viewer, setting the scene, then restarting 
> any threading.
> 
> void ReloadScene(osg::Group* newRoot)
> {
>bool threading = viewer.areThreadsRunning();
>if (threading) viewer.stopThreading();
> 
>viewer.setScene(newRoot);
> 
>if (threading) viewer.startThreading(); }
> 
> I have never tried this... but you are welcome to try
> 
> Robert.
> 
> On 5/24/07, hesicong2006 <[EMAIL PROTECTED]> wrote:
> > I have these code segments like this:
> >
> > osgViewer::Viewer viewer;
> > void ReloadScene(osg::Group* newRoot)
> > {
> > viewer.setScene(newRoot);
> > viewer.realize();
> > }
> >
> > void main()
> > {
> > ...(set up osg::Viewer)
> > while(viewer.done)
> > {
> > viewer.frame();
> > };
> > }
> >
> > ReloadScene() will be executed in another thread at any time when 
> > scene reload is needed. It works sometimes, but most times it will 
> > crash my application, and "xx object is read only" 
> exception is throw. 
> > I think this is happened when viewer.frame() is executing 
> and at this 
> > time
> > ReloadScene() tries to change the scene, but this is not 
> allowed, so 
> > the exception is occurred. I solved this problem by add some trick:
> > osgViewer::Viewer viewer;
> > bool isReloadSceneRequired;
> > void ReloadScene(osg::Group* newRoot)
> > {
> > isReloadSceneRequired=true;
> > }
> >
> > void main()
> > {
> > ...(set up osg::Viewer)
> > while(viewer.done)
> > {
> > if(isReloadSceneRequired==true)
> > {
> >viewer.setScene(newRoot);
> >viewer.realize();
> >isReloadSceneRequired=false;
> > }
> > viewer.frame();
> > };
> > }
> > It works, but I don't like this code style. Does osg provide some 
> > features which other thread can do all the scene update work before 
> > viewer.frame()? Or some other advises?
> > Thanks all in advance!
> >
> > ___
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] osg::Viewport --> getViewport() function removed ?

[Emmanuel Roche]

Hello there,

I've just noticed that osg::Viewport::getViewport() isn't defined anymore
(in OSG 1.9.4 at least)  (both definition with int&s and double&s are inside
a #if 0 - #endif section...) Is this normal ???


Manu.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Poser in OpenSceneGraph

[Anders Backman]

One path would be to import it into 3DSMax, create a skeleton, and
export it as Cal3D animation, and use ReplicantBody/osgCAL to do the
animation/rendering.

/Anders


On 5/24/07, Claudio Arduino <[EMAIL PROTECTED]> wrote:

Hi!!
there is a method to load in OpenSceneGraph a Poser animation of virtual man
that walk?
If it's possible,i want to load the animation without to must load each
single frame of the walk...
I thought for example to export the animation in a .bvh file but i don't
know if exist a openscenegraph plugin for load bvh files...
Thank!!!

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/




--



Anders Backman   Email:[EMAIL PROTECTED]
HPC2N/VRlab  Phone:+46 (0)90-786 9936
Umea university  Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax:  +46 90-786 6126
  http://www.cs.umu.se/~andersb
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

HI Manu,

My thought about using C functions would be for them to be unique for
each ReaderWriter i.e :

extern "C" {

 void osgdb_ive(void)
 {
 }

};

Would be added to the ive plugin, and the same goes for the other
plugins.  One could possible do this via a macro when doing the proxy
instantiation just to simplify the source code.   Could you try this
as a quick hack and let me know how you get on.

The .osg plugin and its dozens of DotOsgWrappers is more of a
challenge, but will be solvable using something similar.

Robert.



On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

Well, things aren't going that well unfortunately:

I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(


concerning the automation of the process, indeed, it's quite heavy... but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and plugins
libs construction to find all the needed symbols and then to include them
for each sample...

and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)

Manu.


2007/5/24, Robert Osfield < [EMAIL PROTECTED]>:
>
> Hi Many,
>
> On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> > Hmmm yet it works fine for plugin with their single
> > RegisterReaderWriterProxy object !! :-)
> >
> > --> I managed to start osgviewer with a .ive file !!! :-D
> >
> > So considering the symbol lists I already have for windows I would say
that
> > the only "problematic" plugins (in the "common" and "image" series at
least)
> > are osg and osgParticle
>
> Good to hear that you've made further progress.  It would be nice to
> be able to automate some of this leg work.  I do also wonder about the
> possibility of use a C functions in the plugins to allow one to grab
> the sybmol with the name manging, this might help the process of
> making things more automated.
>
> W.r.t .osg plugin and others of its type they all use an proxy
> mechanism for registering the ReaderWriter (read.write files) and the
> DotOsgWrappers (read/write the objects), its the later which is
> different from the rest of the plugins.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

Well, things aren't going that well unfortunately:

I've just realize that every plugin that use even a single
RegisterDotOsgWrapperProxy return the exact SAME symbol for this object...
and I cannot find anyway to tell gcc to include the same symbol from
multiple libraries (or worse from multiple objets files in a single library
in the case of osg...): This means for example that we can't link with
osgdb_osgText and osgdb_osgFX at the same time for example... :'(


concerning the automation of the process, indeed, it's quite heavy... but I
doubt there is any C function to retrieve the mangled name internally
the best solution would be to use small scripts just after core and plugins
libs construction to find all the needed symbols and then to include them
for each sample...

and for other projets... hmm... well... we can still use the generated
symbols but I don't see anything better for the moment :-)

Manu.


2007/5/24, Robert Osfield <[EMAIL PROTECTED]>:


Hi Many,

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> Hmmm yet it works fine for plugin with their single
> RegisterReaderWriterProxy object !! :-)
>
> --> I managed to start osgviewer with a .ive file !!! :-D
>
> So considering the symbol lists I already have for windows I would say
that
> the only "problematic" plugins (in the "common" and "image" series at
least)
> are osg and osgParticle

Good to hear that you've made further progress.  It would be nice to
be able to automate some of this leg work.  I do also wonder about the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.

W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Robert Osfield]

Hi Many,

On 5/24/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)

--> I managed to start osgviewer with a .ive file !!! :-D

So considering the symbol lists I already have for windows I would say that
the only "problematic" plugins (in the "common" and "image" series at least)
are osg and osgParticle


Good to hear that you've made further progress.  It would be nice to
be able to automate some of this leg work.  I do also wonder about the
possibility of use a C functions in the plugins to allow one to grab
the sybmol with the name manging, this might help the process of
making things more automated.

W.r.t .osg plugin and others of its type they all use an proxy
mechanism for registering the ReaderWriter (read.write files) and the
DotOsgWrappers (read/write the objects), its the later which is
different from the rest of the plugins.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

Hmmm yet it works fine for plugin with their single
RegisterReaderWriterProxy object !! :-)

--> I managed to start osgviewer with a .ive file !!! :-D

So considering the symbol lists I already have for windows I would say that
the only "problematic" plugins (in the "common" and "image" series at least)
are osg and osgParticle


Manu.


2007/5/24, Emmanuel Roche <[EMAIL PROTECTED]>:


Okay, here are some news:

- under linux we can use the command 'nm' to retrieve the symbol table
from a static library:

ie:  nm libosgdb_osg.a > osg.symbols will write the file osg.symbols

then we can retrieve the "valuable" symbols with sed:

- for osgViewer:
sed -n -e
"s/RegisterWindowingSystemInterfaceProxy/RegisterWindowingSystemInterfaceProxy/p"
osgViewer.symbols > osgViewer.sym

-for the plugins:
sed -n -e "s/RegisterReaderWriterProxy/RegisterReaderWriterProxy/p" -e
"s//RegisterDotOsgWrapperProxy/RegisterDotOsgWrapperProxy/p" osg.symbols >
osg.sym

for osgViewer I get something like:
 W _ZN37RegisterWindowingSystemInterfaceProxyC1Ev
 W _ZN37RegisterWindowingSystemInterfaceProxyD1Ev

I created a simple scons project from osganimate source file, with the
following file system structure:
test_project
  build
osganimate
  src
osganimate.cpp
  Scontruct

and as Scontruct file:
Program("build/osganimate","src/osganimate.cpp",
CPPFLAGS=['-g0','-O3','-pthread'],
LIBPATH=["/usr/local/lib","/home/kenshin/dev/libraries/linux32/gcc-4.1.2/OSG-static-release/lib","/home/kenshin/dev/libraries/linux32/gcc-
4.1.2/OSG-static-release/lib/osgPlugins-1.9.5"],
CPPPATH=["/usr/local/include","/home/kenshin/dev/libraries/linux32/gcc-
4.1.2 /OpenSceneGraph-svn/include"],
LIBS=['osgdb_osg','osgDB','osgFX','osgParticle','osgViewer','osgGA','osgUtil','osgText','osgManipulator','osgSim','osg','OpenThreads','GLU','GL'],

CPPDEFINES=['OSG_LIBRARY_STATIC','OT_LIBRARY_STATIC'],

LINKFLAGS=['-u_ZN37RegisterWindowingSystemInterfaceProxyD1Ev']
)

--> As you may see the command to force gcc to include a symbol is thus
'-u'+symbol

linking with either the "D" or the "C" version give the save result...
and... IT WORKS ! :-D
... I mean at least for the registering of the osgViewer stuff...


unfortunately it is not the case for the plugins yet :-(...

in fact, as valuable symbols for the osgdb_osg plugin, I retrieve
something like:
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE

 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWra

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[Emmanuel Roche]

Okay, here are some news:

- under linux we can use the command 'nm' to retrieve the symbol table from
a static library:

ie:  nm libosgdb_osg.a > osg.symbols will write the file osg.symbols

then we can retrieve the "valuable" symbols with sed:

- for osgViewer:
sed -n -e
"s/RegisterWindowingSystemInterfaceProxy/RegisterWindowingSystemInterfaceProxy/p"
osgViewer.symbols > osgViewer.sym

-for the plugins:
sed -n -e "s/RegisterReaderWriterProxy/RegisterReaderWriterProxy/p" -e
"s//RegisterDotOsgWrapperProxy/RegisterDotOsgWrapperProxy/p" osg.symbols >
osg.sym

for osgViewer I get something like:
 W _ZN37RegisterWindowingSystemInterfaceProxyC1Ev
 W _ZN37RegisterWindowingSystemInterfaceProxyD1Ev

I created a simple scons project from osganimate source file, with the
following file system structure:
test_project
 build
   osganimate
 src
   osganimate.cpp
 Scontruct

and as Scontruct file:
Program("build/osganimate","src/osganimate.cpp",
CPPFLAGS=['-g0','-O3','-pthread'],
LIBPATH=["/usr/local/lib","/home/kenshin/dev/libraries/linux32/gcc-4.1.2
/OSG-static-release/lib","/home/kenshin/dev/libraries/linux32/gcc-4.1.2
/OSG-static-release/lib/osgPlugins-1.9.5"],
CPPPATH=["/usr/local/include","/home/kenshin/dev/libraries/linux32/gcc-4.1.2/OpenSceneGraph-svn/include"],

LIBS=['osgdb_osg','osgDB','osgFX','osgParticle','osgViewer','osgGA','osgUtil','osgText','osgManipulator','osgSim','osg','OpenThreads','GLU','GL'],
CPPDEFINES=['OSG_LIBRARY_STATIC','OT_LIBRARY_STATIC'],

LINKFLAGS=['-u_ZN37RegisterWindowingSystemInterfaceProxyD1Ev']
)

--> As you may see the command to force gcc to include a symbol is thus
'-u'+symbol

linking with either the "D" or the "C" version give the save result...
and... IT WORKS ! :-D
... I mean at least for the registering of the osgViewer stuff...


unfortunately it is not the case for the plugins yet :-(...

in fact, as valuable symbols for the osgdb_osg plugin, I retrieve something
like:
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperProxyC1EPN3osg6ObjectERKSsS5_PFbRS2_RNS_5InputEEPFbRKS2_RNS_6OutputEENS_13DotOsgWrapper13ReadWriteModeE
 W _ZN5osgDB26RegisterDotOsgWrapperProxyD1Ev
 W
_ZN5osgDB26RegisterDotOsgWrapperPro

Re: [osg-users] Impostors display issue

[Robert Osfield]

I don't have time to go through stuff.

On 5/24/07, belthil <[EMAIL PROTECTED]> wrote:


Hi Robert!

Well, i looked at the osgimpostor demo but i didn't find the answer to
my issue in it. The code i wrote is the one of the demo. But why do you
recommend not to use impostors on modern machines? They seemed great for 3D
models that are not like spheres. Are they a too old technology? Have they
been replaced by a new technology (maybe sprites, billboards and/or LODs)?

Belthil


 Créez votre adresse électronique [EMAIL PROTECTED]
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Win32 CLOSE event

[Robert Osfield]

Hi Stephan,

On 5/24/07, Stephan Maximilian Huber <[EMAIL PROTECTED]> wrote:

One question:

Does the close happen on the main-thread on the other platforms (linux /
win32)? On Mac OS X the close-request of the window is handled in the
main-thread.


Yes, its the main thread that calls the close on the window.  I used
this approach to make sure that the threading was well controlled,
with the graphics threads sitting on barriers. But.. this does make
the assumption that the graphics thread completes before the exit from
renderingTraversals(), since the introduction of the
DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext this
is no longer strictly true.  I will have think about this possibility.

Exactly with threading models are causing problems now?

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Poser in OpenSceneGraph

[Claudio Arduino]

Hi!!
there is a method to load in OpenSceneGraph a Poser animation of virtual man
that walk?
If it's possible,i want to load the animation without to must load each
single frame of the walk...
I thought for example to export the animation in a .bvh file but i don't
know if exist a openscenegraph plugin for load bvh files...
Thank!!!
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Impostors display issue

[belthil]

Hi Robert!

Well, i looked at the osgimpostor demo but i didn't find the answer to my 
issue in it. The code i wrote is the one of the demo. But why do you recommend 
not to use impostors on modern machines? They seemed great for 3D models that 
are not like spheres. Are they a too old technology? Have they been replaced by 
a new technology (maybe sprites, billboards and/or LODs)?

Belthil

Créez votre adresse électronique [EMAIL PROTECTED] 
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Win32 CLOSE event

[Stephan Maximilian Huber]

Robert Osfield schrieb:

HI Stephan,

Its frustrating to here my fixes didn't cure things under OSX.  From
the stack traces its clear there is a deadlock, but as to the cause...
well I don't know.  I have a dual core machine here, and aren't able
to reproduce the problem.

At the beginning of June I'll be doing some pair wise programming with
a student, he'll be bringing along his G5 so we will hopefully be able
to doing some serious testing on it.  This is rather later in the day
for 2.0, but there a chance I might be able to find a 11th hour fix
then.

BTW, what happens when apps like osgwindows run?


I can observe the issue with osgviewer, i tried osgwindows too, all the 
same.


If I find some time this weekend I'll try to debug the code.

One question:

Does the close happen on the main-thread on the other platforms (linux / 
win32)? On Mac OS X the close-request of the window is handled in the 
main-thread.


cheers,
Stephan
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Impostors display issue

[Robert Osfield]

On modern machines I wouldn't recommend the use of Impostor except in
very specific circumstances.  If you really want to use them see the
osgimpostor demo.

On 5/24/07, belthil <[EMAIL PROTECTED]> wrote:


Hello!

I'm using impostors in my application. I searched the mailing list for
mails and the osgimpostor example that could answer the issue i have, but
not one can answer.
To test the impostors, i just use them on 3 osg::Sphere. So for one
osg::Sphere i wrote the following code:

osg::ref_ptr impostor = new osgSim::Impostor();
impostor->setImpostorThreshold(DistVisu/2);
impostor->addChild(PlanetGeode.get()); /*PlanetGeode contains the
osg::Sphere*/
impostor->setRange(0,0.0f,DistVisu);
impostor->setCenter(PlanetGeode.get()->getBound.center());

But at runtime, i have white quads instead of the images that should
have been cached by the impostors.

Then i thought it was because i forgot those 3 lines:

osgSim::InsertImpostorsVisitor ov;
root->accept(ov); /*root is an osg::Group that contains the three
impostors*/
ov.insertImpostors();

But those lines did not change anything, i still have the 3 white quads.
And when i rotate the scene, i can see that the 3 quads do not point the
viewer. In a while, when rotating, the 3 white quads are replaced by the
osg::Sphere, and then the "LOD" does not seem to work anymore: when i move
away from the 3 osg::Sphere, the spheres does not disappear but stay
displayed until they are as big as one pixel.
Did i forget something in my code that makes the impostors not working
properly? And why the quads (the cached images) do not rotate toward the
viewer like billboards?

I thank you in advance!

Belthil



 Créez votre adresse électronique [EMAIL PROTECTED]
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] Impostors display issue

[belthil]

Hello!

I'm using impostors in my application. I searched the mailing list for 
mails and the osgimpostor example that could answer the issue i have, but not 
one can answer.
To test the impostors, i just use them on 3 osg::Sphere. So for one osg::Sphere 
i wrote the following code:

osg::ref_ptr impostor = new osgSim::Impostor();
impostor->setImpostorThreshold(DistVisu/2);
impostor->addChild(PlanetGeode.get()); /*PlanetGeode contains the osg::Sphere*/
impostor->setRange(0,0.0f,DistVisu);
impostor->setCenter(PlanetGeode.get()->getBound.center());

But at runtime, i have white quads instead of the images that should have 
been cached by the impostors.

Then i thought it was because i forgot those 3 lines:

osgSim::InsertImpostorsVisitor ov;
root->accept(ov); /*root is an osg::Group that contains the three impostors*/
ov.insertImpostors();

But those lines did not change anything, i still have the 3 white quads. 
And when i rotate the scene, i can see that the 3 quads do not point the 
viewer. In a while, when rotating, the 3 white quads are replaced by the 
osg::Sphere, and then the "LOD" does not seem to work anymore: when i move away 
from the 3 osg::Sphere, the spheres does not disappear but stay displayed until 
they are as big as one pixel.
Did i forget something in my code that makes the impostors not working 
properly? And why the quads (the cached images) do not rotate toward the viewer 
like billboards?

I thank you in advance!

Belthil

Créez votre adresse électronique [EMAIL PROTECTED] 
1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] osg::Viewer multi-thread operation

[Robert Osfield]

Hi,

First up, you shoudl be able to get rid of the viewer.realize() from
your ReloadScene, realize is just for window creation.

Second the OSG isn't designed to be used the way you are wanting to
use it, the design is that you have single threaded update, and this
is who you current implementation works.

Now, you could do some hacking, such as stopping the threading on the
viewer, setting the scene, then restarting any threading.

void ReloadScene(osg::Group* newRoot)
{
  bool threading = viewer.areThreadsRunning();
  if (threading) viewer.stopThreading();

  viewer.setScene(newRoot);

  if (threading) viewer.startThreading();
}

I have never tried this... but you are welcome to try

Robert.

On 5/24/07, hesicong2006 <[EMAIL PROTECTED]> wrote:

I have these code segments like this:

osgViewer::Viewer viewer;
void ReloadScene(osg::Group* newRoot)
{
viewer.setScene(newRoot);
viewer.realize();
}

void main()
{
...(set up osg::Viewer)
while(viewer.done)
{
viewer.frame();
};
}

ReloadScene() will be executed in another thread at any time when scene
reload is needed. It works sometimes, but most times it will crash my
application, and "xx object is read only" exception is throw. I think
this is happened when viewer.frame() is executing and at this time
ReloadScene() tries to change the scene, but this is not allowed, so the
exception is occurred. I solved this problem by add some trick:
osgViewer::Viewer viewer;
bool isReloadSceneRequired;
void ReloadScene(osg::Group* newRoot)
{
isReloadSceneRequired=true;
}

void main()
{
...(set up osg::Viewer)
while(viewer.done)
{
if(isReloadSceneRequired==true)
{
   viewer.setScene(newRoot);
   viewer.realize();
   isReloadSceneRequired=false;
}
viewer.frame();
};
}
It works, but I don't like this code style. Does osg provide some
features which other thread can do all the scene update work before
viewer.frame()? Or some other advises?
Thanks all in advance!

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Improving the performance of video texture rendering

[Robert Osfield]

Hi Koh,

You are most likely CPU limited due to decompression, or bandwidth
limited to the GPU.  You are already using PBO's so this will be
making the bandwidth management as efficient as you'll probably get
it.

Things to look at perhaps would be a round robin updating of the video
textures, such that you only update all the textures in one frame.

The other thing you might be able to optimize is the viewers
management of the screens, which viewer library do you use?

On 5/24/07, Koh, Shalin <[EMAIL PROTECTED]> wrote:




Hi,

In our application, we are using OpenSceneGraph to render 8 video streams
simultaneously. We need to achieve 25 FPS, but at the moment are getting
around 18 to 22 FPS. There are a few things we can optimise, such as the
video decoding, threading, etc. Getting better hardware is not out of the
question, but as a first step, does anyone have any tips for improving the
performance of the texture rendering side of things?

I've got two NVIDIA Quadro FX 3500 graphics cards (connected to a screen
each), two dual-core AMD Opteron 2214 Processors, and 3GB of RAM, running
Windows XP 32 bit. Our application displays 4 video streams in each screen.

To draw the video, we're using a TextureRectangle, and updating its Image
whenever the video data changes.

Image* image;
if(m_textureRect->getImage() != NULL) {
  image = m_textureRect->getImage();
} else {
  image = new Image();
  image->setPixelBufferObject(new PixelBufferObject(image));
  m_textureRect->setImage(image);
}
image->setImage(m_imageWidth, m_imageHeight, 1, 4, m_pixelFormat,
GL_UNSIGNED_BYTE, imageData,
Image::AllocationMode::NO_DELETE);

For our sample video:
  m_imageWidth = 720;
  m_imageHeight = 576;
  m_pixelFormat = GL_BGRA;

I've been looking into GPU/OpenGL profiling tools. We've got gDEBugger, and
I was looking at NVIDIA NVPerfKit (but our graphics card doesn't appear to
be compatible). Are there any other tools worth looking at?

Thanks,
Shalin
DISCLAIMER:---
This Email may contain confidential and/or privileged information and is
intended solely for the addressee(s) named. If you have received this
information in error, or are advised that you have been posted this Email by
accident, please notify the sender by return Email, do not redistribute it,
delete the Email and keep no copies.
--
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Tessellator build failed under cygwin

[Robert Osfield]

Hi Brian,

Good to hear you've got things compiling.  Could you send me the
modified CMakeLists.txt files (zipped up to avoid inlining).

W.r.t hang, could you check different threading models. i.e.

 osgviewer --SingleThreaded cow.osg

Cheers,
Robert.

On 5/24/07, Brian Keener <[EMAIL PROTECTED]> wrote:

Dang I found it.

Robert I got around this error keeping Tesselator from building by using the
current SVN (as I mentioned trying to test the new Windows hag you fixed to see
if it helped Cygwin) and then because of some additional parameters I found
when using the old GNUmakefiles I added these option to all the
CMAKE_CXX_FLAGS.. Options:

-DWIN32 -DNOMINMAX -W -Wall -mnop-fun-dllimport -DOSG_LIBRARY

and bingo - Tessellator built after that.  I don't know which fixed it or why
or even if this is a correct fix but it built.

I also to get a complete build had to change the reference for wsock32.lib to
wsock32.a in Cmakelists.txt in the main trunk of OSG.  I think this needs to be
(but I don't know MingW) wsock32.lib for MingW and wsock32.a for Cygwin (but I
don't know Cygwin either).

I also had to change the condition for whether to add osgviewerMFC in the
examples/CMakelists.txt so that it included a check for UNIX (which did
nothing) along with its check for WIN32 whcih then added osgviewerMFC.

Unfortunately after all this the test apps like osgviewer and osganimate and
osgwindows still hang on close in Cygwin but at least it compiles again.

I notice as well under the old GNUmakefile builds that when linking say osgUtil
there were options as follows:

c++  -O2 -W -Wall -L../../../lib/CYGWIN32  -L/usr/local/lib -shared
-Wl,--out-implib,libosgUtil.dll.a -Wl,--export-all-symbols  CubeMapGenerator.o
CullVisitor.o

which was represented in the old make/makedefs as:

  SHARED= -shared \
  -Wl,--out-implib,lib$(TARGET_BASENAME).dll.a \
  -Wl,--export-all-symbols

I assume these would go in the CMAKE_SHARED_LINKER_FLAGS but how would you
represent them and do we need them.

bk



___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: Windows CMake install problem

[Robert Osfield]

Hi Eric,

In this case, the files in question aren't actually private, we still
want to install them.  How does that affect the issue of header
subdirectories under OSX?

Having the possibility of private headers is really useful though.

Robert.

On 5/24/07, E. Wing <[EMAIL PROTECTED]> wrote:

So, I'm really behind on this discussion thread. I need some
clarification on things. On install, where are the private headers
supposed to install to (if at all)?


So here's the thing. I introduced the LIB_PRIVATE_HEADERS because I
was anticipating something might need to be done with them,
particularly for the OS X frameworks. The OS X framework structure has
a special designated section just for these things. But there are
rules/limitations surrounding headers in general.

So my presumption is that the end user never #include's a Private
header directly (hence 'private'). A public header might need to
#include a private header. If this is the case, I think the #include
in the public header needs to be like:
#include 

So if a public header has a "api" subdirectory in this string, e.g.
#include ,
I believe it will break the framework badly.


Thanks,
Eric
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] svn externals and https

[Robert Osfield]

On 5/23/07, Martin Spott <[EMAIL PROTECTED]> wrote:

Nothing special at all:

foehn: 23:03:55 ~> cat /etc/SuSE-release
SuSE Linux 7.3 (i386)
VERSION = 7.3
foehn: 23:04:04 ~> svn --version
svn, version 1.4.0 (r21228)
   compiled Oct 29 2006, 11:40:17
[...]

foxtrot: 23:08:21 ~> cat /etc/debian_version
3.1
foxtrot: 23:08:28 ~> svn --version
svn, Version 1.1.4 (r13838)
   übersetzt May 14 2005, 01:44:22
[...]

zuluviz: 14:08:59 ~> uname -a
SunOS zuluviz 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-880 Solaris
zuluviz: 14:09:05 ~> svn --version
svn, version 1.4.0 (r21228)
   compiled Sep 17 2006, 22:06:00
[...]


Thanks for the info..  I'm running svn 1.2.3 on Suse 10.0, no problems so far.

Could it be a network setup issue?

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] referenced textures?

[Robert Osfield]

Hi Mike,

I'm afraid there isn't support for the plugins reusing already loaded
textures as the plugins are completely self contained - they don't
know about the existance of anything previous loaded.

The closest you can get is to post process the scene graph to replace
the duplicate state.  See the osgUtil::Optimizer and
osgDB::SharedStateManager.

Robert.

On 5/23/07, Dunhour, Mike (CIV) <[EMAIL PROTECTED]> wrote:

Hello

  Art non-programming related

Osg - ive files

  Setup 5 tiled textures used as diffuse colors  = 200k
1 large texture used to lightmap scene   = 1meg

Problem
  Ive file contains imbedded lightmap for each use with diffuse
resulting in large file.

  Osg format has each diffuse with same lightmap listed as texture
units.  Much smaller as only one copy of lightmap needs to be saved in
'images' folder.

  However on loading of .osg the lightmap appears to be recopied into
memory each time it is read in the .osg file, so large amounts of ram
still needed on copies of the same bitmap data.

Question?
  How can osg simply reference a texture already in memory, so after the
first loading of the lightmap other textures using it do not reload but
simply reference the already loaded texture.

Thank you   Mr. D

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Release schedule for 2.0, end of of May, early June!

[Robert Osfield]

On 5/24/07, E. Wing <[EMAIL PROTECTED]> wrote:

> Would it be possible to get the XCode projects in shape for under of
> May?  I can introduce others to having write access if this would
> help.

So I think I will be able to get the Xcode projects fixed in time for
the release. But if anybody wants to help and wants Subversion write
access, I'm happy for the help.


I'll see if Stephan is still up for it ;-)

If any other OSX users feel like pitching in with the
OpenSceneGraph/XCode build then please raise you hand.

Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] I need data compile first after scene load before visualisation.

[Thibault Genessay]

Hi

On 5/24/07, GMD GammerMaxyandex.ru <[EMAIL PROTECTED]> wrote:


I need data compile first after scene load before visualisation. Otherwise
FPS drops down a lot at first visualisation. After that everything is all
wright.
How can I correct(fix) it? There are not such problems in the version
osg1.2.

I've already tested osgUtil::SceneView::COMPILE_GLOBJECTS_AT_INIT



I've already had issues with of that kind, so rather than kindly asking the
video card to preload the gl objects, I forced it to load them by drawing a
frame but not displaying it. This is possible using an osg::ColorMask
because it discards the pixels at the very last moment: it bypasses all
driver optimizations that would otherwise prevent the geometries and the
textures from being uploaded in the video card.

I've tried it with relatively small scenes and it works great.

The sequence looks like:

before the first frame:
// save the root state set
mySavedStateSet = root->getOrCreateStateSet();
// switch on all nodes to precache
root->setNodeMask(~0);
foreach (node) node->setNodeMask(~0);
// create a dummy stateset
osg::StateSet* ss = new osg::StateSet;
ss->setAttributeAndModes(new osg::ColorMask(false,false,false,false),
osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE);
root->setStateSet(ss);

draw the frame

after the first frame
// restore the root state set
root->setStateSet(mySavedStateSet);
// restore the node mask, switches etc.
[...]

then run your application normally

Hope this helps

Thibault
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] osg::Viewer multi-thread operation

[hesicong2006]

I have these code segments like this:

osgViewer::Viewer viewer;
void ReloadScene(osg::Group* newRoot)
{
   viewer.setScene(newRoot);
   viewer.realize();
}

void main()
{
   ...(set up osg::Viewer)
   while(viewer.done)
   {
   viewer.frame();
   };
}

ReloadScene() will be executed in another thread at any time when scene 
reload is needed. It works sometimes, but most times it will crash my 
application, and "xx object is read only" exception is throw. I think 
this is happened when viewer.frame() is executing and at this time 
ReloadScene() tries to change the scene, but this is not allowed, so the 
exception is occurred. I solved this problem by add some trick:

osgViewer::Viewer viewer;
bool isReloadSceneRequired;
void ReloadScene(osg::Group* newRoot)
{
   isReloadSceneRequired=true;
}

void main()
{
   ...(set up osg::Viewer)
   while(viewer.done)
   {
   if(isReloadSceneRequired==true)
   {
  viewer.setScene(newRoot);
  viewer.realize();
  isReloadSceneRequired=false;
   }
   viewer.frame();
   };
}
It works, but I don't like this code style. Does osg provide some 
features which other thread can do all the scene update work before 
viewer.frame()? Or some other advises?

Thanks all in advance!

___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

[osg-users] I need data compile first after scene load before visualisation.

[GMD GammerMaxyandex.ru]

I need data compile first after scene load before visualisation. Otherwise FPS 
drops down a lot at first visualisation. After that everything is all wright.
 How can I correct(fix) it? There are not such problems in the version osg1.2. 

I've already tested osgUtil::SceneView::COMPILE_GLOBJECTS_AT_INIT
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Re: OSG 1.9.5 static build on linux 2.6

[E. Wing]

On 5/23/07, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> And changing this 'MODULE' variable tout "STATIC" leads to the
construction
> of static plugin libs ! bingo !
>
> I guess someone should include somewhere the test done for the core libs
to
> decide here if we should have "SHARED" or "STATIC"... what was this
'MODULE'
> used for in fact ??



I missed most of the thread, but unlike Windows and ELF, Mach-O makes
a hard distinction between a dynamic library and loadable bundle
(a.k.a. plugin a.k.a module). CMake handles this by providing SHARED
vs. MODULE. Don't use/mix-up SHARED with MODULE or Mach-O derived
systems will break.

-Eric
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Re: [osg-users] Geometry extraction

[PCJohn]

Ok, I will do so. Thanks.


Alberto Luaces napsal(a):

El Miércoles 23 Mayo 2007, PCJohn escribió:

What is the best way to extract triangles from osg?

Use an custom osg::TriangleFunctor  [...]

And if I want normals, materials, and texCoordinates too?


Then I think you'll have to walk over all the Drawables of the Geode(s) you 
are interested and, in the case of Geometry drawables, extract from their 
primitive sets the arrays you want ( coordinates, normals, UV coordinates...)


At least that is what I am currently doing  :\


___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/