Re: [osg-users] getting translate rotate scale right.

[Gazi Alankus]

2009/1/15 Mark Sciabica 

>  Hi Gazi,
>
> It is true that OSG differs from your literature. That does not make OSG
> incorrect. In fact, the literature wasn't always dominated by the format
> you're promoting.
>

Hi Mark,

It's not just my literature, it's the dominant one that anyone starting to
learn about computer graphics today is exposed to. But you are right, it
seems the history had its debates.


>
>
> This link 
> http://steve.hollasch.net/cgindex/math/matrix/column-vec.htmlprovides some 
> history on the matter.
>

Great link to bookmark, thank you. It's interesting to see all the past
debate and origins of this.


>
> One format isn't correct, and the other incorrect. It's simply a
> convention, and one needs to be aware of the convention used in the context
> in which one is working. OSG assumes row vectors while OpenGL assumes column
> vectors, but OSG (like C++) uses row-major ordering while OpenGL uses
> column-major ordering. This combination makes OSG binary compatible with
> OpenGL but not notationally compatible. Perhaps binary compatibility and
> ease of coding was the reason for the convention chosen, or it could be
> other historical factors. We would have to get that answer from Robert.
> Whatever the reason, that's the convention OSG uses and it's in no way
> 'incorrect'.
>

I know, I should deal with it:). It's "incorrect" according to the sources I
mentioned, calling it just "incorrect" would be unfair. The implementation
reason is ease of coding of the matrix class.
http://www.openscenegraph.org/projects/osg/wiki/Support/Maths/MatrixTransformations
cites
the way c arrays are stored as the reason for this choice and agrees that
the choice was not in compliance with most books and the OpenGL manual. They
just wanted to be able to push the two dimensional array directly to OpenGL.
However, not abstracting this out in the matrix class, in my opinion, was
unfortunate. One way is to store them the way OpenGL does but treat them
logically the way OpenGL manual treats them in the class functions, which
would be the "right" way if OpenGL is right (implementation and
documentation-wise). A simple "the first index is the column and the second
index is the row" rule does this. Or, avoiding a two dimensional array, thus
not giving any inherent meaning to indices, and treating the one dimensional
array as a matrix stored in column-major order in the functions of the
matrix class would be even less error-prone. OGRE does it by flipping
indices in its matrix multiplication code and warns the users about the
matrix notation:
http://www.ogre3d.org/docs/api/html/classOgre_1_1Matrix4.html#_details

I believe this issue has to be actively documented in the OSG API reference,
too. Just like it should be actively documented that operator precedence for
^ and + is not the way it is in maths for cross product and addition of
vectors.


> Direct3D (and presumably any literature directed to it) uses the same
> row-vector convention as OSG so it's hard to convincingly paint OSG as some
> maverick API in this context.
>

The whole point I'm trying to make is that *this is unexpected for a good
number of people and should be actively documented in the API so that people
don't suffer*. My intention was not to defame OSG in any way and I don't
think I did that. I pointed out the disparity and that this could be a
reason for a bug (reply to Chris), and that this is not a non-issue (replay
to Paul). I'm sorry if it sounded any other way.

All is for less bugs and less headache for everyone. I swear, I love OSG and
its community.

Regards,

-Gazi



>
> Regards,
> Mark
>
>
> Gazi Alankus wrote:
>
> A correct transformation matrix (which is a 2D entity) according to math
> literature:
>
>  R11 R12 R13 Tx
> R21 R22 R23 Ty
> R31 R32 R33 Tz
> 0 0 0 1
>
>  That matrix stored in column-major order in 1D memory:
>  R11 R21 R31 0 R12 R22 R32 0 R13 R23 R33 0 Tx Ty Tz 1
>
>  That matrix stored in row-major order in 1D memory:
>  R11 R12 R13 Tx R21 R22 R23 Ty R31 R32 R33 Tz 0 0 0 1
>
>  If these are the things you dispute, that is an easier argument to deal
> with. Otherwise my response follows:
>
>
>  2009/1/15 Paul Fotheringham 
>  [...]
>
>>
>>  Eh? By what definition exactly?
>
>
>
>  
> http://fly.cc.fer.hr/~unreal/theredbook/appendixg.html
>
> http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/translate.html
>
> http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/rotate.html
>
>  Rotation matrix order:
> http://en.wikipedia.org/wiki/Rotation_matrix
>  Which is the order in the OpenGL man pages. If you create a simple
> rotation matrix in OSG and compare it to there, you'll see that it's
> transposed according to this definition.
>
>
>>  OpenGL is neither row-major or column-major.
>
>
>  http://en.wikipedia.org/wiki/Row-major_order
>  You can't store a well-defined multidimensional entity in one dimensional
> storage and 

Re: [osg-users] svn offline?

[Jean-Sébastien Guay]

Hi Ulrich,


Is anyone else having problems with the svn server?  I'm getting:


It just stalls for me (been trying to update for 5 minutes, Tortoise 
just sits there apparently not getting through to the server but also 
not getting any error). They've been having trouble with the server 
lately, perhaps this is another similar case.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] svn offline?

[Ulrich Hertlein]

Is anyone else having problems with the svn server?  I'm getting:


svn: OPTIONS of 'http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk':
Could not read status line: Connection reset by peer
(http://www.openscenegraph.org)

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] getting translate rotate scale right.

[Mark Sciabica]

Hi Gazi,

It is true that OSG differs from your literature. That does not make OSG 
incorrect. In fact, the literature wasn't always dominated by the format 
you're promoting.


This link http://steve.hollasch.net/cgindex/math/matrix/column-vec.html 
provides some history on the matter.


One format isn't correct, and the other incorrect. It's simply a 
convention, and one needs to be aware of the convention used in the 
context in which one is working. OSG assumes row vectors while OpenGL 
assumes column vectors, but OSG (like C++) uses row-major ordering while 
OpenGL uses column-major ordering. This combination makes OSG binary 
compatible with OpenGL but not notationally compatible. Perhaps binary 
compatibility and ease of coding was the reason for the convention 
chosen, or it could be other historical factors. We would have to get 
that answer from Robert. Whatever the reason, that's the convention OSG 
uses and it's in no way 'incorrect'.


Direct3D (and presumably any literature directed to it) uses the same 
row-vector convention as OSG so it's hard to convincingly paint OSG as 
some maverick API in this context.


Regards,
Mark


Gazi Alankus wrote:
A correct transformation matrix (which is a 2D entity) according to 
math literature:


R11 R12 R13 Tx
R21 R22 R23 Ty
R31 R32 R33 Tz
0 0 0 1

That matrix stored in column-major order in 1D memory:
R11 R21 R31 0 R12 R22 R32 0 R13 R23 R33 0 Tx Ty Tz 1

That matrix stored in row-major order in 1D memory:
R11 R12 R13 Tx R21 R22 R23 Ty R31 R32 R33 Tz 0 0 0 1

If these are the things you dispute, that is an easier argument to 
deal with. Otherwise my response follows: 



2009/1/15 Paul Fotheringham >

[...]


Eh? By what definition exactly?



http://fly.cc.fer.hr/~unreal/theredbook/appendixg.html 


http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/translate.html
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/rotate.html

Rotation matrix order:
http://en.wikipedia.org/wiki/Rotation_matrix
Which is the order in the OpenGL man pages. If you create a simple 
rotation matrix in OSG and compare it to there, you'll see that it's 
transposed according to this definition. 



OpenGL is neither row-major or column-major. 



http://en.wikipedia.org/wiki/Row-major_order
You can't store a well-defined multidimensional entity in one 
dimensional storage and say it's neither. If you do, the definition of 
the multidimensional entity becomes open to interpretation. Which 
actually is not, as explained in the next paragraph. 
 


It treats a transformation matrix as 16 floats, nothing more. Only
when one imposes a 4x4 structure of rows and columns on the 16
numbers does one then encounter the question "Which way shall I
order them?". At that point you choose row-major or column-major
as the description of how your data is stored in the matrix.


Yes, and the definition of the matrix multiplication operator in OSG 
makes it clear that the first index of the array is rows and second 
index is columns. Also if you look at the code closely, the first 
index is always referred to as rows. So, when you treat the indices as 
such, you see that the matrix being stored is actually a transposed 
version of a transformation matrix. Hence, you have to treat them as 
transposed transformation matrices to get your math right. 

 



> There is no such
> thing as
> "row-major matrix" since matrices are
> mathematical entities that have
> nothing to do with storage.

Yes there is, I've just described it above. It's storage that has
nothing to do with it i.e. OpenGL's view of it as 16 numbers, it's
how you construct your mathematical entity, your matrix, that
imposes one view or the other.


You don't construct the mathematical entity of transformation matrices 
based on how OpenGL stores matrices. The mathematical definition in 
the literature is clear, which is also used in the OpenGL man pages 
when talking about transformation matrices. 



I know it sucks, but it's just the way it is.
 
-Gazi 





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Disabling VSYNC

[Frederic Bouvier]

Hi Robert,

as far as I can see, only GraphicsWindowCarbon makes use of it (vsync)

-Fred

- "Robert Osfield" a écrit :

> HI Xam,
> 
> When setting up the GraphicsWindow you pass in a
> GraphicsContext::Traits object, this has a field vsync that defaults
> to true.
> 
> The other route would be to use putenv() in your app if you want to
> use env vars to control the driver.
> 
> Robert.
> 
> 
> On Tue, Jan 13, 2009 at 7:00 PM, Xam 
> wrote:
> > Is there any way to disable VSYNC inside OSG?
> >
> > I need a way to enable and disable vsync on my program with out
> using the nvidia driver override or environmental variables. The
> Nvidia Driver settings for Vsync should be set to "Use the 3D
> application setting"
> > I seem to remember that i was able to do that in previous versions
> of OSG when i was still using producer, I remember getting fps in the
> hundreds, but now i only get what ever my screen refresh rate is.
> After the removal of producer, i lost the ability to have vsync
> control.
> >
> > Any help would be appreciated,
> >
> > MS
> >
> > --
> > Read this topic online here:
> > http://osgforum.tevs.eu/viewtopic.php?p=4528#4528
> >
> >
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Long-standing Particle System File loading IOperformance trouble

[Jason Daly]

David Guthrie wrote:

We never create particle systems in code.  Artists create them in the delta3d 
particle system editor.  You can see all of your changes and tweaks in realtime 
and then save an osg file.  I don't see creating a particle system as a 
programming task at all.  It's an art asset.

I don't see why you would create them in code unless you have no other option.  
Even then, if you want more than 10 particle systems, you could easily write 
simple gui utility or just a simple text file to generate them in that amount 
of time.  Delta3D has one that is much better than a simple gui tool.
  


I'll just jump in and say that I've used some particle systems from 
Delta3D in some of our work (we don't use Delta3D ourselves, but we work 
with other folks who do).


Loading the particle system from a .osg file and cloning it when needed 
is a pretty convenient way to handle this kind of task.


--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] getting translate rotate scale right.

[Gazi Alankus]

A correct transformation matrix (which is a 2D entity) according to math
literature:

R11 R12 R13 Tx
R21 R22 R23 Ty
R31 R32 R33 Tz
0 0 0 1

That matrix stored in column-major order in 1D memory:
R11 R21 R31 0 R12 R22 R32 0 R13 R23 R33 0 Tx Ty Tz 1

That matrix stored in row-major order in 1D memory:
R11 R12 R13 Tx R21 R22 R23 Ty R31 R32 R33 Tz 0 0 0 1

If these are the things you dispute, that is an easier argument to deal
with. Otherwise my response follows:


2009/1/15 Paul Fotheringham 
[...]

>
> Eh? By what definition exactly?



http://fly.cc.fer.hr/~unreal/theredbook/appendixg.html
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/translate.html
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/rotate.html

Rotation matrix order:
http://en.wikipedia.org/wiki/Rotation_matrix
Which is the order in the OpenGL man pages. If you create a simple rotation
matrix in OSG and compare it to there, you'll see that it's transposed
according to this definition.


> OpenGL is neither row-major or column-major.


http://en.wikipedia.org/wiki/Row-major_order
You can't store a well-defined multidimensional entity in one dimensional
storage and say it's neither. If you do, the definition of the
multidimensional entity becomes open to interpretation. Which actually is
not, as explained in the next paragraph.


> It treats a transformation matrix as 16 floats, nothing more. Only when one
> imposes a 4x4 structure of rows and columns on the 16 numbers does one then
> encounter the question "Which way shall I order them?". At that point you
> choose row-major or column-major as the description of how your data is
> stored in the matrix.


Yes, and the definition of the matrix multiplication operator in OSG makes
it clear that the first index of the array is rows and second index is
columns. Also if you look at the code closely, the first index is always
referred to as rows. So, when you treat the indices as such, you see that
the matrix being stored is actually a transposed version of a transformation
matrix. Hence, you have to treat them as transposed transformation matrices
to get your math right.



>
> > There is no such
> > thing as
> > "row-major matrix" since matrices are
> > mathematical entities that have
> > nothing to do with storage.
>
> Yes there is, I've just described it above. It's storage that has nothing
> to do with it i.e. OpenGL's view of it as 16 numbers, it's how you construct
> your mathematical entity, your matrix, that imposes one view or the other.


You don't construct the mathematical entity of transformation matrices based
on how OpenGL stores matrices. The mathematical definition in the literature
is clear, which is also used in the OpenGL man pages when talking about
transformation matrices.


I know it sucks, but it's just the way it is.

-Gazi
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Choice of body-specific coordinate system origin by dae(COLLADA) reader

[Paul Martz]

Bullet requires collision shapes to be centered on the origin. OSG models do
not necessarily have to be centered on the origin and often are not. You
might need to account for this difference using a translation in your own
code, so that the collision shapes coincide with the OSG visual
representation of the collision shapes.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Fabian
Aichele
Sent: Thursday, January 15, 2009 1:10 AM
To: OpenSceneGraph Users
Subject: [osg-users] Choice of body-specific coordinate system origin by
dae(COLLADA) reader


Hello, osg-users!
 
I have a question regarding the choice of the body-specific coordinate
system made by the COLLADA reader (daeReader/Writer in osgDB). 
When I import a geometry from a COLLADA document, the osgDB plugin returns a
osg::Group that contains the "nodes" declared in the COLLADA document
together with all the "geometries" used by the node declaration, plus
material properties etc.
 
That works fine, but there is one thing I haven't figured out yet: How does
the COLLADA importer decide where to put the "local" origin for a node
hierarchy imported from COLLADA? I have tested different geometries
consisting of 20 to about 50 triangle strips/fans/arrays, but the
body-specific coordinate system was chosen quite arbitrarily (at least I
couldn't figure out any pattern).
 
This is important for me to know since I use OpenSceneGraph to visualize a
rigid body simulation with the Bullet Physics engine, and I haven't managed
to get the OSG and Bullet coordinate systems "in sync".
 
Any hints or pointers to documentation/examples/earlier questions regarding
this are gladly accepted.
 
Thank you!
 
Fabian Aichele
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG Contracting Question

[Tomlinson, Gordon]

Whoops wrong control key

Steve place your details here

http://www.openscenegraph.org/projects/osg/wiki/Community/Contractors
 


Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

"Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
- Master Tambo Tetsura

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Steve
Gifford
Sent: Thursday, January 15, 2009 12:36 PM
To: OpenSceneGraph Users
Subject: [osg-users] OSG Contracting Question

This is slightly off topic, so I'll keep it short.  I'm curious to know
if anyone has contract work they need done with OSG.  I've been
following the project for years and even contributed a bit (TXP demo
databases, early versions of the TerraPage loader).

Now I'm an independent contractor and I'd enjoy contributing back a bit
to OSG.  Not enough to do it for free (I have my own projects), but if
there's something out there that would help OSG in general and you need
it done, I'd be interested.

-Steve Gifford
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG Contracting Question

[Tomlinson, Gordon]

Steve

Stick your details here
 


Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

"Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
- Master Tambo Tetsura

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Steve
Gifford
Sent: Thursday, January 15, 2009 12:36 PM
To: OpenSceneGraph Users
Subject: [osg-users] OSG Contracting Question

This is slightly off topic, so I'll keep it short.  I'm curious to know
if anyone has contract work they need done with OSG.  I've been
following the project for years and even contributed a bit (TXP demo
databases, early versions of the TerraPage loader).

Now I'm an independent contractor and I'd enjoy contributing back a bit
to OSG.  Not enough to do it for free (I have my own projects), but if
there's something out there that would help OSG in general and you need
it done, I'd be interested.

-Steve Gifford
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] getting translate rotate scale right.

[Paul Fotheringham]

--- On Thu, 15/1/09, Gazi Alankus  wrote:

> From: Gazi Alankus 
> Subject: Re: [osg-users] getting translate rotate scale right.
> To: "OpenSceneGraph Users" 
> Date: Thursday, 15 January, 2009, 6:25 PM
> I can't tell you the right answer, but maybe this might
> help a little bit.
> [rant]
> OSG matrices are not "correct" homogeneous
> transformation matrices.

Eh? By what definition exactly?

>They are
> transposed. When you come up with a solution that involves
> multiplication of
> transformation matrices on paper, you have to reverse the
> order of
> multiplications when implementing it with OSG to get things
> working.
> 
> This problem arises from the confusion that OpenGL stores
> matrices in
> column-major order and OSG treats that data as if it was
> stored in row-major
> order, effectively transposing the matrix.

OpenGL is neither row-major or column-major. It treats a transformation matrix 
as 16 floats, nothing more. Only when one imposes a 4x4 structure of rows and 
columns on the 16 numbers does one then encounter the question "Which way shall 
I order them?". At that point you choose row-major or column-major as the 
description of how your data is stored in the matrix.

> There is no such
> thing as
> "row-major matrix" since matrices are
> mathematical entities that have
> nothing to do with storage.

Yes there is, I've just described it above. It's storage that has nothing to do 
with it i.e. OpenGL's view of it as 16 numbers, it's how you construct your 
mathematical entity, your matrix, that imposes one view or the other.

Paul


  
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] getting translate rotate scale right.

[Gazi Alankus]

I can't tell you the right answer, but maybe this might help a little bit.
[rant]
OSG matrices are not "correct" homogeneous transformation matrices. They are
transposed. When you come up with a solution that involves multiplication of
transformation matrices on paper, you have to reverse the order of
multiplications when implementing it with OSG to get things working.

This problem arises from the confusion that OpenGL stores matrices in
column-major order and OSG treats that data as if it was stored in row-major
order, effectively transposing the matrix. There is no such thing as
"row-major matrix" since matrices are mathematical entities that have
nothing to do with storage.

So, if you have a linear algebra and theoretical computer graphics
background, every time you multiply matrices by hand in OSG you are likely
to make mistakes. Looking at your problem again with this light might help.

Just my 0.02. I didn't want to offend anybody, OSG is an amazing piece of
library. It just hurts me that there is such a fundamental issue with it.
[/rant]

Apart from that, docs for osg::Matrixd::getRotate() state:

"Note that this function assumes a non-scaled matrix and will return
incorrect results for scaled matrixces. Consider decompose() instead."

That would probably help.

-Gazi

2009/1/15 Dorosky, Christopher G 

>
> I thought I understood this just fine, but I apparently don't.
>
> I have a model that is half the size it needs to be. So, I need to scale
> it by 2.0 in all directions.
>
> It is also in the wrong position, so I need to translate it out to
> (1000, 2000, 3000);
>
> Once it is translated, I need to rotate it. This involves quats, but for
> simplicities sake, lets say the rotations are 10,20,30. Order is
> irrelevant, since I am just trying to print these things for now.
>
> So, I have a matrix transform. I set the matrix by:
>
> Mt->setMatrix(osg::Matrix::scale( scalevec) * osg::Matrix::rotate(
> rotquat) * osg::Matrix::trans (transvec));
>
> Seems fine.
> Then, if I print out the values, I get some goofiness.
>
> Using the matrix getScale(), getTrans(), getRot() routines, I get them
> and print out values.
>
> Trans is fine. Rot and scale are goofy.
> This doesn't entirely surprise me, since the order of operations is
> dependent.
>
> In the scene graph, it looks wrong.
>
> If I use a position attitude transform, and explicitly set the trans,
> rot, scale separately, then it works.
>
> Before, I would have had a series of matricies that looks like this:
>
> Scenegraph root ->trans->rot->scale->model;
>
> What's the right way to do this?
>
> I'm thinking a translate -> rotate -> -translate  is involved somehow.
>
> BTW if the scale is 1.0 in all directions, this works just fine.
>
> Thanks...
>
> Chris
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] getting translate rotate scale right.

[Dorosky, Christopher G]

As usual, when I spend a day or two on something, I figure out the
answer immediately after I post a question to this list.

Problem was, I was fooling with the matrix afterwards, and recomposing
it.

GetRotate and GetScale mess up if matrix has both.
Decompose is needed.

Heh... I just noticed that Gazi posted this as well.

Thanks

Chris

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Dorosky, Christopher G
Sent: Thursday, January 15, 2009 11:40 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] getting translate rotate scale right.


I thought I understood this just fine, but I apparently don't.

I have a model that is half the size it needs to be. So, I need to scale
it by 2.0 in all directions.

It is also in the wrong position, so I need to translate it out to
(1000, 2000, 3000);

Once it is translated, I need to rotate it. This involves quats, but for
simplicities sake, lets say the rotations are 10,20,30. Order is
irrelevant, since I am just trying to print these things for now.

So, I have a matrix transform. I set the matrix by:

Mt->setMatrix(osg::Matrix::scale( scalevec) * osg::Matrix::rotate(
rotquat) * osg::Matrix::trans (transvec));

Seems fine.
Then, if I print out the values, I get some goofiness.

Using the matrix getScale(), getTrans(), getRot() routines, I get them
and print out values.

Trans is fine. Rot and scale are goofy.
This doesn't entirely surprise me, since the order of operations is
dependent.

In the scene graph, it looks wrong.

If I use a position attitude transform, and explicitly set the trans,
rot, scale separately, then it works.

Before, I would have had a series of matricies that looks like this:

Scenegraph root ->trans->rot->scale->model;

What's the right way to do this?

I'm thinking a translate -> rotate -> -translate  is involved somehow.

BTW if the scale is 1.0 in all directions, this works just fine.

Thanks...

Chris
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] getting translate rotate scale right.

[Dorosky, Christopher G]

I thought I understood this just fine, but I apparently don't.

I have a model that is half the size it needs to be. So, I need to scale
it by 2.0 in all directions.

It is also in the wrong position, so I need to translate it out to
(1000, 2000, 3000);

Once it is translated, I need to rotate it. This involves quats, but for
simplicities sake, lets say the rotations are 10,20,30. Order is
irrelevant, since I am just trying to print these things for now.

So, I have a matrix transform. I set the matrix by:

Mt->setMatrix(osg::Matrix::scale( scalevec) * osg::Matrix::rotate(
rotquat) * osg::Matrix::trans (transvec));

Seems fine.
Then, if I print out the values, I get some goofiness.

Using the matrix getScale(), getTrans(), getRot() routines, I get them
and print out values.

Trans is fine. Rot and scale are goofy.
This doesn't entirely surprise me, since the order of operations is
dependent.

In the scene graph, it looks wrong.

If I use a position attitude transform, and explicitly set the trans,
rot, scale separately, then it works.

Before, I would have had a series of matricies that looks like this:

Scenegraph root ->trans->rot->scale->model;

What's the right way to do this?

I'm thinking a translate -> rotate -> -translate  is involved somehow.

BTW if the scale is 1.0 in all directions, this works just fine.

Thanks...

Chris
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Long-standing Particle System File loading IO performance trouble

[David Guthrie]

We never create particle systems in code.  Artists create them in the delta3d 
particle system editor.  You can see all of your changes and tweaks in realtime 
and then save an osg file.  I don't see creating a particle system as a 
programming task at all.  It's an art asset.

I don't see why you would create them in code unless you have no other option.  
Even then, if you want more than 10 particle systems, you could easily write 
simple gui utility or just a simple text file to generate them in that amount 
of time.  Delta3D has one that is much better than a simple gui tool.

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4673#4673





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG Contracting Question

[Steve Gifford]

This is slightly off topic, so I'll keep it short.  I'm curious to
know if anyone has contract work they need done with OSG.  I've been
following the project for years and even contributed a bit (TXP demo
databases, early versions of the TerraPage loader).

Now I'm an independent contractor and I'd enjoy contributing back a
bit to OSG.  Not enough to do it for free (I have my own projects),
but if there's something out there that would help OSG in general and
you need it done, I'd be interested.

-Steve Gifford
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Frame rate drop with osgPPU v0.3

[Art Tevs]

Hi Alexandre,

hmm, one of the main change between 0.2 and 0.3 was a deprecation of Shader 
class. When you use them you will get a warning that they are deprecated and 
ShaderAttribute has to be used. Maybe there are some print outs, which slowdone 
your machine. Also I have tried to solve some multithreading issues. You could 
try to run your application in SingleThreading mode to make sure that your 
problems are not multithreading related. Even if you think you use only single 
threading, that might not be the case. Per default osgViewer does run in 
CullDrawThreadPerContext which isn't stable on older version of osgPPU. You 
should run it in SingleThreaded to force real single threading mode.


Also start your app with OSG_NOTIFY_LEVEL=debug or info and check whats going 
wrong there. Maybe post the output here, so that we could try to find out, 
whats going on.

As to the getOrCreateOutputTexture(0) : the method should give you a correct 
pointer to a 2D texture (v0.2) even if your ppu isn't connected anywhere. The 
method also doesn't changes a lot to v0.3, hence I am not sure why it doesn't 
work for you. Maybe a problem somewhere else?


If you are not restricted to use osg 2.6 you can try the current osgPPU from 
the svn, which has no multithreading issues anymore (as far as I was able to 
test it ;) ). However you need osg somewhere from 2.7.8 or so, to be able to 
compile current osgPPU :(


Best regards,
art

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4671#4671





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Frame rate drop with osgPPU v0.3

[alexandre amyot murray]

Hi Art,

Do you think its possible that the version 0.3 of osgPPU affect the frame
rate considerably ?

Since  I merge to  v0.3 (I was using v0.2 before),  my application  runs
slowly  and I  get  a  lot of glitches  that  never happened  before.  The
code is exactly the same.

For now Im stuck to v0.2, but in this version if you attempt to do something
like this

osg::Texture * aTexure = aUnitInOut->getOrCreateOutputTexture(0)

it doesnt work, but in v0.3 its fine. Is there a simple way to correct this
bug from v0.2.

Thank you

Alex
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] altitude terrain shading...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Thanks Gordon. Good points for using a shader. Are there any performance
hits with doing this at a pixel level? I wouldn't think so since the shader
is pretty "thin"...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tomlinson,
Gordon
Sent: Thursday, January 15, 2009 9:07 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] altitude terrain shading...

With the Shader approach you still typically use a 1d texture, but can
have good control of what color a pixel gets and you can place palettes
in the texture etc.. Works well  


Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

"Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
- Master Tambo Tetsura

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Thursday, January 15, 2009 11:04 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] altitude terrain shading...

Thanks to everyone that responded to my inquiry. I'll try the TexGen
approach first and then do a shader at a later time...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Thursday, January 15, 2009 1:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] altitude terrain shading...

Hi Shayne,

The standard way to do this would be to use a Texture1D for the colour
banding and TexGenNode to compute the tex coords for you.  See the
osgtexture1D example.

Robert.

On Wed, Jan 14, 2009 at 10:42 PM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:
> All,
>
>
>
> I have a requirement to do some altitude shading (coloring) to a 
> terrain database based off a referenced altitude. In other words, I 
> would like to shade the terrain to be green below a given altitude and

> then shade it
brown
> at or above the given altitude. The reference altitude basically
represents
> the horizontal plane that intersects the terrain database. Any terrain
below
> the plane is shaded green and any terrain above the plane is shaded
brown.
>
>
>
> My question is, is there any support in OSG that will allow me to do 
> something like this? My terrain is a database built with VPB.
>
>
>
> Any input would be most appreciated.
>
> -Shayne
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Choice of body-specific coordinate system origin by dae(COLLADA) reader

[Jason Daly]

Fabian Aichele wrote:

Hello, osg-users!
 
I have a question regarding the choice of the body-specific coordinate 
system made by the COLLADA reader (daeReader/Writer in osgDB).
When I import a geometry from a COLLADA document, the osgDB plugin 
returns a osg::Group that contains the "nodes" declared in the COLLADA 
document together with all the "geometries" used by the node 
declaration, plus material properties etc.
 
That works fine, but there is one thing I haven't figured out yet: How 
does the COLLADA importer decide where to put the "local" origin for a 
node hierarchy imported from COLLADA? I have tested different 
geometries consisting of 20 to about 50 triangle strips/fans/arrays, 
but the body-specific coordinate system was chosen quite arbitrarily 
(at least I couldn't figure out any pattern).
 
This is important for me to know since I use OpenSceneGraph to 
visualize a rigid body simulation with the Bullet Physics engine, and 
I haven't managed to get the OSG and Bullet coordinate systems "in sync".
 
Any hints or pointers to documentation/examples/earlier questions 
regarding this are gladly accepted.


I don't believe the importer decides anything.  All of this information 
is in the file itself.  The root of the document's visual scene is 
placed at 0, 0, 0, and everything else is relative from there, according 
to whatever transforms are attached to the visual scene's nodes.  If 
you're seeing an arbitrary origin, it's probably because it was modeled 
that way (some of the COLLADA test models do have strange origins).


The only other influence on the coordinate system comes from the 
document's  setting in the global  tag.  This describes 
whether the document's contents are X_UP, Y_UP, or Z_UP.  This is used 
to adjust to the OSG coordinate system (which is Z_UP).


Hope this helps...

--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] altitude terrain shading...

[Tomlinson, Gordon]

With the Shader approach you still typically use a 1d texture, but can
have good control of what color a pixel gets and you can place palettes
in the texture etc.. Works well  


Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

"Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival" 
- Master Tambo Tetsura

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Thursday, January 15, 2009 11:04 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] altitude terrain shading...

Thanks to everyone that responded to my inquiry. I'll try the TexGen
approach first and then do a shader at a later time...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Thursday, January 15, 2009 1:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] altitude terrain shading...

Hi Shayne,

The standard way to do this would be to use a Texture1D for the colour
banding and TexGenNode to compute the tex coords for you.  See the
osgtexture1D example.

Robert.

On Wed, Jan 14, 2009 at 10:42 PM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:
> All,
>
>
>
> I have a requirement to do some altitude shading (coloring) to a 
> terrain database based off a referenced altitude. In other words, I 
> would like to shade the terrain to be green below a given altitude and

> then shade it
brown
> at or above the given altitude. The reference altitude basically
represents
> the horizontal plane that intersects the terrain database. Any terrain
below
> the plane is shaded green and any terrain above the plane is shaded
brown.
>
>
>
> My question is, is there any support in OSG that will allow me to do 
> something like this? My terrain is a database built with VPB.
>
>
>
> Any input would be most appreciated.
>
> -Shayne
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] altitude terrain shading...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Thanks to everyone that responded to my inquiry. I'll try the TexGen
approach first and then do a shader at a later time...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Thursday, January 15, 2009 1:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] altitude terrain shading...

Hi Shayne,

The standard way to do this would be to use a Texture1D for the colour
banding and TexGenNode to compute the tex coords for you.  See the
osgtexture1D example.

Robert.

On Wed, Jan 14, 2009 at 10:42 PM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:
> All,
>
>
>
> I have a requirement to do some altitude shading (coloring) to a terrain
> database based off a referenced altitude. In other words, I would like to
> shade the terrain to be green below a given altitude and then shade it
brown
> at or above the given altitude. The reference altitude basically
represents
> the horizontal plane that intersects the terrain database. Any terrain
below
> the plane is shaded green and any terrain above the plane is shaded brown.
>
>
>
> My question is, is there any support in OSG that will allow me to do
> something like this? My terrain is a database built with VPB.
>
>
>
> Any input would be most appreciated.
>
> -Shayne
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Vertex list indexing into another vertex list?

[Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW]

This would be a simplified (although not useful) example of the data:

Primary_vertex[0] = { 1.0, 1.0, 1.0 };

Secondary_vertex[0] = 0; // Index into primary_vertex list
Secondary_vertex[1] = 0; // Index into primary_vertex list
TexCoord[0] = { 0.0, 0.0 }; // Texture coord for Secondary_vertex[0]
TexCoord[1] = { 1.0, 1.0 }; // Texture coord for Secondary_vertex[1]

If I understand your suggestion, then the draw elements list would just
be {0, 0}, in which case the geometry would work, but it would also
apply TexCoord[0] to both vertices, which is not what was intended.  

- Ken

> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
> boun...@lists.openscenegraph.org] On Behalf Of Vincent Bourdier
> Sent: Thursday, January 15, 2009 5:14 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Vertex list indexing into another vertex
list?
> 
> Hi,
> 
> Maybe just use setVertexArray with the primary vertex list, and you
use
> the second list in a osg::DrawElementsUInt (or similar).
> In the DrawElementsUInt, you push your vertices indexes. So when the
> vertices data are modified, if they keep the same position in the list
> the geometry will update. (do not forget setUserData(DYNAMIC) )
> 
> There is a setVertexIndice() method but it is now deprecated... maybe
> something can replace it.
> 
> Same thing for the texture (if I understand well)
> 
> Hope this help.
> 
> PS : have a look on documentation
>
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs
> /a01369.html#4596d0e18fb5217a1306c324a2eaba72
> 
> Regards,
>Vincent.
> 
> 
> 
> 2009/1/14 Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW
> 
> 
> 
>   Is it possible to specify a vertex list by indexing into a
> different
>   vertex list?  Sorry if that's confusing, I'll try to explain a
> bit more.
> 
>   I've got some data that is organized in the following way:
> 
>   - A primary vertex list that is the regular xyz values you'd
> expect.
> 
>   - A secondary vertex list that is composed by indexing into the
> primary
>   vertex list.
> 
>   - A texture coordinate list that has a value for each 'vertex'
in
> the
>   secondary list.
> 
>   - Lastly, a list of indices into the secondary vertex list to
> define
>   some primitives.
> 
>   It looks like the data was set up this way so a vertex that
> exists in
>   multiple primitives can have a unique texture coordinate per
> primitive,
>   yet still only be transformed once.
> 
>   My initial approach was just to construct the secondary list by
>   replacing the index with a copy of the vertex it was
referencing.
> This
>   works except for one thing, the primary vertex list is not
> static.  By
>   that, I mean the values of the vertices themselves, the list
size
> itself
>   will not change.  So, the only approach I see is to basically
>   reconstruct the secondary vertex list every time the primary is
> updated.
>   This could be kind of rough, since I could potentially have many
>   secondary lists.  From what I've seen looking through OSG
headers
> and
>   mailing list postings it doesn't seem possible to do this
'vertex
> list
>   by indexing another', but I thought I'd ask just in case.
>   Thanks.
> 
>   - Ken.
>   ___
>   osg-users mailing list
>   osg-users@lists.openscenegraph.org
>   http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> 
> 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Wang Rui]

Hi Sukender, hi all,

I would first introduce the implementation of osgPhysics at present:

1. Create a World (derived from Group) instance.

2. Create some RigidActor (derived from Transform) instances and add them as
the World's children.

3. While the simulation running, the World will have a UpdateCallback to
update itself and all its children RigidActors (calling their update()
functions).
4. The matrix of each RigidActor will be got from
computeLocalToWorldMatrix() funtion, which is automatically called during
the culling traversal. And the object is rendered at specific position.

And it works fine with few objects and a single world. You may have a look
at the latest SVN version.

If the physics simulation is put into another thread and thus have one or
more PUTs parallel to the DUT, we may have to create a fix-sized queue for
maintaining matrices of every RigidActor. In this case, I suggest we create
a read callback and a write callback, to lock/unlock the queue during every
DUT, and dispatch them to RigidActor nodes. And the FIFO (first-in,
first-out) queue would have a *user-defined* size, and store
framestamp-matrices data. I don't deeply read all the posts but think my
thoughts a little samiliar with Robert's, but leave the decision to users.
So customers may set size of buffer to 2, like Sukender suggests.

This mechanism may only affect rigid actors and may be confusing if we have
more than one world (it's possible in PhysX). Maybe we have to discuss it
again and again and be coding again and again, to get the final result. I'd
like to first try to realize soft bodies with geometry shader / VBO in these
days. And Sukender and I would make an initial multi-threaded physics update
traversal and see its effects ASAP. :)

Cheers,

Wang Rui
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgAL + latest OSG SVN

[Jean-Sébastien Guay]

Bonjour Alexandre,

Erreur1error C2504: 'std::basic_fstream<_Elem,_Traits>' : classe 
de base non définieC:\Program 
Files\OpenSceneGraph\include\OsgDB\fstream31   


That's in fact a compile error in OSG, not related to osgAL in any way. 
What compiler/platform are you using?


Is there any chance you have an incomplete SVN working copy of OSG? 
Because the #include  at the top of the file should include the 
base class of osgDB::fstream...


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgAL + latest OSG SVN

[Sukender]

Undefined base class??? That sounds very strange.
If you find the reason, that may help others.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 15:41:54 +0100, Alexandre Amalric  a 
écrit:

> Hi Sukender,
>
> I already downloaded the latest osgAL SVN (
> https://osgal.svn.sourceforge.net/svnroot/osgal ) with the latest osg SVN
> version.
>
> I use the new CMAKE build system.
>
> Maybe am I missig an hidden parameter ;-)
>
> When I use osgAL 0.6.1 with OSG 2.6.0 it works fine, no errors about some
> fstream thing...
>
> *Salut Sukender,
>
> En fait mon souci c'est que j'ai voulu récupérer la dernière version d'osgAL
> (svn) et d'osg (svn) et en voulant compiler le projet osgAL (généré par
> CMAKE) j'ai une belle erreur :
>
> Erreur1error C2504: 'std::basic_fstream<_Elem,_Traits>' : classe de
> base non définieC:\Program Files\OpenSceneGraph\include\OsgDB\fstream
> 31
>
> Lorsque je compile osgAL 0.6.1 avec osg 2.6.0 tout marche bien. J'ai cru
> comprendre qu'il ya eut des changements dans osgDB à propos des caractères
> unicode (gestion de fstream).
> *
> *PS: le tutoiement ne me gêne pas du tout au contraire ;-)*
>
>
> 2009/1/15 Sukender 
>
>> Hi Alexandre,
>>
>> Did you also try the latest osgAL SVN (
>> https://osgal.svn.sourceforge.net/svnroot/osgal )? It works fine for me,
>> using OpenAL-Soft, WinXP SP3, MSVC8, in Debug.
>> Please not that there is a new CMake build system that you should (must?)
>> use.
>>
>> Sukender, also working on osgAL
>> PVLE - Lightweight cross-platform game engine -
>> http://pvle.sourceforge.net/
>>
>>
>> Le Thu, 15 Jan 2009 14:43:28 +0100, Alexandre Amalric <
>> alex.pix...@gmail.com> a écrit:
>>
>> > Hi osg-users,
>> >
>> > I recently downloaded latest svn version from osg and osgAL but I don't
>> > succeed to compile osgAL svn with OSG svn.
>> > There is an error about fstream, because of including osgDB::FileUtils in
>> > SoundManager.cpp.
>> >
>> > Has anyone tried to compile latest osgAL (svn) with latest OSG (svn) ?
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

Hi Robert, hi all,

Robert, I didn't say it before, but thanks for giving us your thoughts/ideas.

So there is, IMO, 3 viable solutions:

1. A simple thread safe matrix transform.
Benefits: Simple and fast.
Drawbacks: You may have t and t-1 matrices. Can't do 
interpolations/extraploations. That may fits some needs (OpenTissue as Ahmed 
explained?), but not be the common solution I guess.

2. A full thread safe timestamped matrix buffer (your idea), with an option to 
record matrices once each n-th physics frame.
Benefits: Can handle complex updates, like interpolations and such. Useable 
with any engine.
Drawbacks: Complex, and may consume RAM and CPU (reallocations of buffers when 
there is a lag).

3. A thread safe structure with 2 matrices + 1 time stamp
Benefits: Intermediate solution that fits most engines and usages.
Drawbacks: Physics engine must update all matrices on each update. Can't do 
interpolations/extraploations.

I suggest we provide the user multiple possible implementations (by the way of 
a pre-processor define?). Does that sounds good?


About getting the best framestamp (for solution 2), I think it is far safer to 
do a batch update to avoid having "t and t-1 matrices", as in solution 1. Or we 
may let the user do a custom processing by simply giving him/her the latest 
framestamp that is common to all buffers?

I'm waiting for comments! :)

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 13:42:54 +0100, Robert Osfield  a 
écrit:

> Hi Sukender,
>
> On Thu, Jan 15, 2009 at 12:06 PM, Sukender  wrote:
>> So, to avoid having two objects updated with 2 different time stamps, is it 
>> ok if I:
>> - Fill matrix buffers with physics timestamped matrices (PUT - physics 
>> thread)
>> - Update in a batch all the display matrices from the latest timestamp that 
>> is available over all buffers (display thread)
>> - Remove data that is before that timestamp on all buffers.
>
> I'd have one time stamp per matrix/value that is pushed in from the
> physics thread, and then the rendering thread pulls the appropriate
> matrix/maitrces/values according to the time stamp(s) that look most
> appropriate.
>
> One could also do a batch copy of from all the buffers to all the
> scene graph related values at one time.
>
> As for the data structure required, a custom ring buffer implemented
> on top of a std::vector<> would probably work just fine. However, I'm
> just waving my hands around, I haven't actually done much work with
> physics integration personally, others who've been there and done that
> would probably be best placed to give the low level recommondations.
>
>> Does that solution cost much RAM if we have a physics that run very 
>> frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest 
>> matrices since there is no reason for the physics to not update all objects?
>
> If you running at really high frequences then one would need to take
> in account how big these buffers might get, in which case you'd want
> to cut down the number of matrices/values you store, perhaps not even
> record them every frame, all the rendering thread needs to one
> matrix/value per frame.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgAL + latest OSG SVN

[Alexandre Amalric]

Hi Sukender,

I already downloaded the latest osgAL SVN (
https://osgal.svn.sourceforge.net/svnroot/osgal ) with the latest osg SVN
version.

I use the new CMAKE build system.

Maybe am I missig an hidden parameter ;-)

When I use osgAL 0.6.1 with OSG 2.6.0 it works fine, no errors about some
fstream thing...

*Salut Sukender,

En fait mon souci c'est que j'ai voulu récupérer la dernière version d'osgAL
(svn) et d'osg (svn) et en voulant compiler le projet osgAL (généré par
CMAKE) j'ai une belle erreur :

Erreur1error C2504: 'std::basic_fstream<_Elem,_Traits>' : classe de
base non définieC:\Program Files\OpenSceneGraph\include\OsgDB\fstream
31

Lorsque je compile osgAL 0.6.1 avec osg 2.6.0 tout marche bien. J'ai cru
comprendre qu'il ya eut des changements dans osgDB à propos des caractères
unicode (gestion de fstream).
*
*PS: le tutoiement ne me gêne pas du tout au contraire ;-)*


2009/1/15 Sukender 

> Hi Alexandre,
>
> Did you also try the latest osgAL SVN (
> https://osgal.svn.sourceforge.net/svnroot/osgal )? It works fine for me,
> using OpenAL-Soft, WinXP SP3, MSVC8, in Debug.
> Please not that there is a new CMake build system that you should (must?)
> use.
>
> Sukender, also working on osgAL
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
>
> Le Thu, 15 Jan 2009 14:43:28 +0100, Alexandre Amalric <
> alex.pix...@gmail.com> a écrit:
>
> > Hi osg-users,
> >
> > I recently downloaded latest svn version from osg and osgAL but I don't
> > succeed to compile osgAL svn with OSG svn.
> > There is an error about fstream, because of including osgDB::FileUtils in
> > SoundManager.cpp.
> >
> > Has anyone tried to compile latest osgAL (svn) with latest OSG (svn) ?
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Alexandre AMALRIC   Ingénieur R&D
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] rendering ive model (shaders)

[Ümit Uzun]

Hi Selman Abi,

Firsty if you have textures in your hand seperatly you can use this code to
send textures in uniform variable,

  // Create a texture object
  osg::Texture2D * normal = new osg::Texture2D;
  normal->setImage( osgDB::readImageFile( "XXX" ) );
  normal->setWrap( osg::Texture2D::WRAP_S, osg::Texture2D::REPEAT );
  normal->setWrap( osg::Texture2D::WRAP_T, osg::Texture2D::REPEAT );
  normal->setResizeNonPowerOfTwoHint( false );
  normal->setMaxAnisotropy( 8.0f );

   // Set up the shader stateset, geode is your target model which shader
operaion will be implemented
  osg::StateSet * stateset = geode->getOrCreateStateSet();
  stateset->setTextureAttribute( BASE_TEX_UNIT, normal );

  // Them send this texture unit which normal texture already set. baseMap
is uniform variable which you will use in your vertex or fragment shader.
  stateset->addUniform( new osg::Uniform( "baseMap", BASE_TEX_UNIT ) );

Sending a texture to shader composes of this 3 steps.

If you haven't texture names and locations readymade, you may use 2 ways
which I know to get them. Firstly you can write texture visitors, and you
can traverse the texture nodes to get the textures information. I haven't
try this but it could work for you :)
Second you can convert your ive models to osg by osgconv and then you can
get the texture names by using only notepad.

Hope this helps.
Best Regards.

2009/1/15 selman duatepe 

> Hi Ümit,
>
> Actually, I want to know solutions of two combinations.
>
> Firstly, if textures are seperated from models, how can I pass the texture
> in uniform variables? I have lots of models and  I don't know whole
> information about textures (name, location vs.). Can I get information about
> model textures from ive model?
>
> Thanks Ümit.
>
>
> On Wed, Jan 14, 2009 at 4:37 AM, Ümit Uzun  wrote:
>
>> Hi Selman Abi,
>>
>> What do you mean you can't pass textures to shaders? Textures are
>> separated from models or they are integrated combination? If they separated
>> you can easily pass texture in uniform variables, or they are combined with
>> model like ive Terrain models there can be problem as you said.
>>
>> Best Regards.
>>
>> 2009/1/13 Lukas Diduch 
>>
>> Play around with the notify level for debug info.
>>> (from doc:)
>>>
>>> export OSG_NOTIFY_LEVEL=
>>>
>>>* ALWAYS
>>>* FATAL
>>>* WARN
>>>* NOTICE
>>>* DEBUG_INFO
>>>* DEBUG_FP
>>>* DEBUG
>>>* INFO, will also enable validation of shader programs
>>>
>>>
>>> On Tue, Jan 13, 2009 at 05:33:27PM +0200, selman duatepe wrote:
>>> > Hi everyone,
>>> >
>>> > I want to render *ive* model with textures by shaders. But, I can't
>>> pass the
>>> > textures to fragment or vertex shader.
>>> >
>>> > Any ideas?
>>> >
>>> > Thanks.
>>>
>>> > ___
>>> > osg-users mailing list
>>> > osg-users@lists.openscenegraph.org
>>> >
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>>
>> --
>> Ümit Uzun
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Ümit Uzun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: osgSWIG/Py available

[R Fritz]

osgswig only works with Windows Python 2.6--if pygtk works in that  
environment, try it there.


There's a lot of apps, btw, that doesn't work with Windows Python 2.6,  
because VS 2008 is needed to build plugins for it--there is no numpy,  
for instance.  Beware.


Randolph

On Jan 14, 2009, at 12:25 PM, Phan, Linh H wrote:


Hi,

 I'm trying to run the gtkoswidget.py example in python IDLE 1.2.1  
and I got stuck at gtk:



import sys
import pygtk
pygtk.require('2.0')
import gtk


Traceback (most recent call last):
 File "", line 1, in 
   import gtk
 File "C:\Python25\lib\site-packages\gtk-2.0\gtk\__init__.py", line  
38, in 

   import gobject as _gobject
 File "C:\Python25\lib\site-packages\gtk-2.0\gobject\__init__.py",  
line 30, in 

   from _gobject import *
ImportError: DLL load failed: The specified module could not be found.

Can someone tell me how I can fix this or where I can get a working  
gtk version?


Thank you,

Linh

-Original Message-
Dear OSG Community,

first of all a late Happy New Year! The osgSWIG team is happy to  
announce osgSWIG/Py 0.9.1 for Python 2.6 which corresponds to the  
OpenSceneGraph 2.6.1 version. There is an installer for Win32/Python  
2.6 or if you feel funky you can try to compile osgSWIG/Py straight  
from the source.


Please note that on Windows we can only support you with Python 2.6  
- hence build with Visual Studio 2008. And another note, we decided  
to only support stable releases, like 2.6.x or the upcoming 2.8.x  
releases as the maintenance of the interface files becomes more  
problematic. Be assured we are looking into some alternative ways to  
generate them :)


For those users looking for an update of the version including  
osgART (http://www.osgart.org) - please be patient, we are working  
on the release of osgART 2.x and would like to keep things in sync -  
there will be an update but not right now.


Please give the installer a spin - let us know of your problems in  
the issue tracker.


Now, head over to http://code.google.com/p/osgswig/

Cheers,

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgAL + latest OSG SVN

[Sukender]

Hi Alexandre,

Did you also try the latest osgAL SVN ( 
https://osgal.svn.sourceforge.net/svnroot/osgal )? It works fine for me, using 
OpenAL-Soft, WinXP SP3, MSVC8, in Debug.
Please not that there is a new CMake build system that you should (must?) use.

Sukender, also working on osgAL
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 14:43:28 +0100, Alexandre Amalric  a 
écrit:

> Hi osg-users,
>
> I recently downloaded latest svn version from osg and osgAL but I don't
> succeed to compile osgAL svn with OSG svn.
> There is an error about fstream, because of including osgDB::FileUtils in
> SoundManager.cpp.
>
> Has anyone tried to compile latest osgAL (svn) with latest OSG (svn) ?

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgAL + latest OSG SVN

[Alexandre Amalric]

Hi osg-users,

I recently downloaded latest svn version from osg and osgAL but I don't
succeed to compile osgAL svn with OSG svn.
There is an error about fstream, because of including osgDB::FileUtils in
SoundManager.cpp.

Has anyone tried to compile latest osgAL (svn) with latest OSG (svn) ?


-- 
Alexandre AMALRIC   Ingénieur R&D
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Removing the tgz, osgtgz and zip plugins

[Johan Nouvel]

Hi Robert,

Unfortunately our plugin read only .gz file, not .zip nor .tar.gz.

I didn't know about osg 2.7 .gz plugin, we always use osg 1.2. We hope to upgrade to 2.X in the next months, and I will 
closer look at CMake in the same time.


Regards,
Johan.

Robert Osfield a écrit :

Hi Johan,

On Thu, Jan 15, 2009 at 9:22 AM, Johan Nouvel
 wrote:

We already have a ReaderWriter using zlib, reading from stream and from
file, writing to file.


The svn + 2.7.x dev series has a zlib based .gz plugin.  I doesn't
support .zip files though.

Does yours handle .zip and .tar.gz?


But we compile it with our Makefile system, not with CMake.
I can post the source right now, if someone have time to do the OSG CMake
part.


The CMake part will be trivial - one only needs to look at the
existing CmakeLists.txt file for the src/osgPlugins/gz plugin, it's
pretty likely that it's more straight forward than your Makefile.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



--
Johan Nouvel, R&D Engineer
http://www.archivideo.com
tel : +33 (0)2 99 86 30 20
ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Robert Osfield]

Hi Sukender,

On Thu, Jan 15, 2009 at 12:06 PM, Sukender  wrote:
> So, to avoid having two objects updated with 2 different time stamps, is it 
> ok if I:
> - Fill matrix buffers with physics timestamped matrices (PUT - physics thread)
> - Update in a batch all the display matrices from the latest timestamp that 
> is available over all buffers (display thread)
> - Remove data that is before that timestamp on all buffers.

I'd have one time stamp per matrix/value that is pushed in from the
physics thread, and then the rendering thread pulls the appropriate
matrix/maitrces/values according to the time stamp(s) that look most
appropriate.

One could also do a batch copy of from all the buffers to all the
scene graph related values at one time.

As for the data structure required, a custom ring buffer implemented
on top of a std::vector<> would probably work just fine. However, I'm
just waving my hands around, I haven't actually done much work with
physics integration personally, others who've been there and done that
would probably be best placed to give the low level recommondations.

> Does that solution cost much RAM if we have a physics that run very 
> frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest 
> matrices since there is no reason for the physics to not update all objects?

If you running at really high frequences then one would need to take
in account how big these buffers might get, in which case you'd want
to cut down the number of matrices/values you store, perhaps not even
record them every frame, all the rendering thread needs to one
matrix/value per frame.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

Hi Ahmed,

> In my case i will have some of the nodes with time "t" and some with "t-1".

This may be not a problem with OpenTissue, but may be one for other engines. I 
think we should adress that problem.


> 2- what we want is a conversion from OSG scene node to PAL.
> this conversion will be done in the first step only.

So you build your OSG scene and then create a PAL equivalent? I must say this 
is a suprising approach! I have the intention of manually creating the 
physics... because in many applications, physics objects are not exactly what 
you see (they are often simplified). I suggest that your "OSG to physics" 
conversion should be an additional (and separated) feature for those who want 
to use it.


> I think it will be because DUT is much more faster than PUT.

This ay depend a lot on what you are simulating :) I personnaly won't made such 
an assertion for osgPhysics.

Cheers,

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 12:51:02 +0100, Ahmed Nawar  a 
écrit:

> Hi Sukender,
>
>>"What happens if OSG updates the scene while the physics do the same???"
> In my case i will have some of the nodes with time "t" and some with "t-1".
> but this will be fixed in almost the second osg frame ( osg is much more fast 
> than physics)
> and because osg scene graph is separated from physics nodes. this will not 
> Affect the result of physics.
> (Else we have to buffer values.)
>
>
>>> So what we need to do,i think, is
>>> 1- a stander "PositionAttitudeTransform" like node. it is thread or not 
>>> thread safe.
>>> 2- A traversal that read the scene graph in the first step only and fill 
>>> the physics with its suitable form of node conversion.
>>>  Of course with or without our hints.
>
>> I'm sorry but I don't understand what you mean.
>
> 1- "PositionAttitudeTransform like node" is your "ThreadSafeMatrixTransform".
> In it we must make sure that when PUT change the data The DUT will not change 
> any value in it while draw.
>
> 2- what we want is a conversion from OSG scene node to PAL.
> this conversion will be done in the first step only.
> we can add a abstract conversion method and all nodes must overwrite it.
> (it must handle complex scene and this was not in my case.
> my case was PositionAttitudeTransform for each graph boxes and spheres i want 
> to simulate there behave)
>
>
>>So I'm wondering if DUT and PUT are mutually exclusive
> I think it will be because DUT is much more faster than PUT.
>
> thanks,
> Ahmed Nawar
> 
> From: osg-users-boun...@lists.openscenegraph.org 
> [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender 
> [suky0...@free.fr]
> Sent: Thursday, January 15, 2009 1:23 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started!
>
> Hi Ahmed,
>
>> I think the multi threading is a must [...]
>
> 100% agreed :)
>
>
>> I used an idea such as Sukender one but with out locking any thread.
>> This because I have one thread(physics) put data in a shared memory and one 
>> thread (OSG) read this data.
>
> Is it like a "ThreadSafeMatrixTransform"? What happens if OSG updates the 
> scene while the physics do the same???
>
>
>> So what we need to do,i think, is
>> 1- a stander "PositionAttitudeTransform" like node. it is thread or not 
>> thread safe.
>> 2- A traversal that read the scene graph in the first step only and fill the 
>> physics with its suitable form of node conversion.
>>  Of course with or without our hints.
>
> I'm sorry but I don't understand what you mean.
>
>
>> I can work with you on osgPhysics if you want.
>
> Well, that's if *you* want! :) Sice osgPhysics is opened to anyone.
> Feel free to discuss with us, or propose code changes. And if you want write 
> access to the SVN repository, then you should give us your SF.net UNIX name.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

Hi Robert,

So, to avoid having two objects updated with 2 different time stamps, is it ok 
if I:
- Fill matrix buffers with physics timestamped matrices (PUT - physics thread)
- Update in a batch all the display matrices from the latest timestamp that is 
available over all buffers (display thread)
- Remove data that is before that timestamp on all buffers.

But then, does the batch be done before, or during the display update traversal?

Does a kind of "circular buffer that can grow as vector<>" could be the best 
structure for the buffer (if we reserve enough at the begining)?

Does that solution cost much RAM if we have a physics that run very frequently 
(Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since 
there is no reason for the physics to not update all objects?

I suggest then our buffer to be a "Thread safe structure with 2 matrices + 1 
time stamp (latest one)".

Your thoughts? :)

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 12:21:47 +0100, Robert Osfield  a 
écrit:

> Hi Sukender,
>
> On Thu, Jan 15, 2009 at 10:48 AM, Sukender  wrote:
>> I like your idea. I'm not a threading expert, but won't this cost much? I 
>> mean locking/unlocking is quite expensive, as far as I know, and depending 
>> on the number of matrices to lock, this could cost much. Anyway much less 
>> that waiting for a complete traversal to end, of course! :)
>> Maybe our implementation could be a "ThreadSafeMatrixTransform"...
>
> Perhaps a custom or user data callback would be sufficient for
> managing the common data buffer, this way you could adapt the buffer
> for different purposes.
>
> As for the cost of the locking and unlocking - this is actually pretty
> low, you don't want to be doing thousands of locks/unlocks per frame,
> so if you do have a scene with many separate entities that are being
> modelled then having composite buffers that have a single mutex
> between them, and do a sync data to and from this buffer on batch
> rather than each buffer individually would avoid making too many
> lock/unlock calls.
>
> As for the interpolation vs choosing the most value, this is something
> that could easily be done via an option on the reading side - or
> simply have two different update callbacks that read from the buffers
> in different ways.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Ahmed Nawar]

Hi Sukender,

>"What happens if OSG updates the scene while the physics do the same???"
In my case i will have some of the nodes with time "t" and some with "t-1".
but this will be fixed in almost the second osg frame ( osg is much more fast 
than physics)
and because osg scene graph is separated from physics nodes. this will not 
Affect the result of physics.
(Else we have to buffer values.)


>> So what we need to do,i think, is
>> 1- a stander "PositionAttitudeTransform" like node. it is thread or not 
>> thread safe.
>> 2- A traversal that read the scene graph in the first step only and fill the 
>> physics with its suitable form of node conversion.
>>  Of course with or without our hints.

> I'm sorry but I don't understand what you mean.

1- "PositionAttitudeTransform like node" is your "ThreadSafeMatrixTransform".
In it we must make sure that when PUT change the data The DUT will not change 
any value in it while draw.

2- what we want is a conversion from OSG scene node to PAL.
this conversion will be done in the first step only.
we can add a abstract conversion method and all nodes must overwrite it.
(it must handle complex scene and this was not in my case.
my case was PositionAttitudeTransform for each graph boxes and spheres i want 
to simulate there behave)


>So I'm wondering if DUT and PUT are mutually exclusive
I think it will be because DUT is much more faster than PUT.

thanks,
Ahmed Nawar

From: osg-users-boun...@lists.openscenegraph.org 
[osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender 
[suky0...@free.fr]
Sent: Thursday, January 15, 2009 1:23 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started!

Hi Ahmed,

> I think the multi threading is a must [...]

100% agreed :)


> I used an idea such as Sukender one but with out locking any thread.
> This because I have one thread(physics) put data in a shared memory and one 
> thread (OSG) read this data.

Is it like a "ThreadSafeMatrixTransform"? What happens if OSG updates the scene 
while the physics do the same???


> So what we need to do,i think, is
> 1- a stander "PositionAttitudeTransform" like node. it is thread or not 
> thread safe.
> 2- A traversal that read the scene graph in the first step only and fill the 
> physics with its suitable form of node conversion.
>  Of course with or without our hints.

I'm sorry but I don't understand what you mean.


> I can work with you on osgPhysics if you want.

Well, that's if *you* want! :) Sice osgPhysics is opened to anyone.
Feel free to discuss with us, or propose code changes. And if you want write 
access to the SVN repository, then you should give us your SF.net UNIX name.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

Hi Ahmed,

> I think the multi threading is a must [...]

100% agreed :)


> I used an idea such as Sukender one but with out locking any thread.
> This because I have one thread(physics) put data in a shared memory and one 
> thread (OSG) read this data.

Is it like a "ThreadSafeMatrixTransform"? What happens if OSG updates the scene 
while the physics do the same???


> So what we need to do,i think, is
> 1- a stander "PositionAttitudeTransform" like node. it is thread or not 
> thread safe.
> 2- A traversal that read the scene graph in the first step only and fill the 
> physics with its suitable form of node conversion.
>  Of course with or without our hints.

I'm sorry but I don't understand what you mean.


> I can work with you on osgPhysics if you want.

Well, that's if *you* want! :) Sice osgPhysics is opened to anyone.
Feel free to discuss with us, or propose code changes. And if you want write 
access to the SVN repository, then you should give us your SF.net UNIX name.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Robert Osfield]

Hi Sukender,

On Thu, Jan 15, 2009 at 10:48 AM, Sukender  wrote:
> I like your idea. I'm not a threading expert, but won't this cost much? I 
> mean locking/unlocking is quite expensive, as far as I know, and depending on 
> the number of matrices to lock, this could cost much. Anyway much less that 
> waiting for a complete traversal to end, of course! :)
> Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Perhaps a custom or user data callback would be sufficient for
managing the common data buffer, this way you could adapt the buffer
for different purposes.

As for the cost of the locking and unlocking - this is actually pretty
low, you don't want to be doing thousands of locks/unlocks per frame,
so if you do have a scene with many separate entities that are being
modelled then having composite buffers that have a single mutex
between them, and do a sync data to and from this buffer on batch
rather than each buffer individually would avoid making too many
lock/unlock calls.

As for the interpolation vs choosing the most value, this is something
that could easily be done via an option on the reading side - or
simply have two different update callbacks that read from the buffers
in different ways.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

(coninued again... sorry for posting multiple times!)

I got a problem about using a kind of "ThreadSafeMatrixTransform"... What if 
"object 1" is updated, but not "object 2" when display update traversal (DUT) 
happens? Well we would see inconsistencies (like interpenetrations) too... So 
I'm wondering if DUT and PUT are mutually exclusive... What are your thoughts 
on this?

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 12:04:41 +0100, Sukender  a écrit:

> I forgot to mention a thing about interpolating. Yes, this could be a nice 
> idea to interpolate (or extrapolate) data, but I think this is a great risk 
> for something that may not be very useful for common physics usage. I belive 
> that realtime engines generally run at something like 50 or 100Hz (one can of 
> course be much slower or much faster), so you may loose much time trying to 
> interpolate; and moreover you may introduce inconstistencies (such as objects 
> interpenetrating). So I guess simply reading the last matrix is enough.
> This is what I do in my engine (not multithreaded yet), and it works without 
> lagging. I simply created a main loop that takes care of running physics or 
> display when necesssary.
>
> Maybe you have a different point of view on that? I'd be happy to read!
>
> And what about other types of engines (non realtime)? I suppose interpolating 
> could be possible, but I still think we introduce simulation errors.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
>
> Le Thu, 15 Jan 2009 11:48:48 +0100, Sukender  a écrit:
>
>> Hi Robert,
>>
>> I like your idea. I'm not a threading expert, but won't this cost much? I 
>> mean locking/unlocking is quite expensive, as far as I know, and depending 
>> on the number of matrices to lock, this could cost much. Anyway much less 
>> that waiting for a complete traversal to end, of course! :)
>> Maybe our implementation could be a "ThreadSafeMatrixTransform"...
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>>
>>
>> Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield 
>>  a écrit:
>>
>>> Hi Sukender,
>>>
>>>
>>> On Wed, Jan 14, 2009 at 8:59 PM, Sukender  wrote:
 Well, multithreading *is* an issue, but we need to address the problem.
 I guess the order of steps would be:
 - When it is time to update the physics, run the "physics update 
 traversal" (say "PUT") in a physics thread
 - PUT
 - PUT
 - ...
 - When the times come to update the display, lock the physics thread so 
 that no PUT runs
 - Run the "display update traversal" ("DUT") in a display thread. During 
 this, copy physics positions/orientations to transforms.
 - Unlock the physics.
 - PUT (physics thread), cull and draw (display thread)
 - and so on.

 Am I right? I'm not sure about threads because here the PUT cant run when 
 DUT runs, so the interest is limited, even if cull and draw steps would be 
 in parallel of a PUT. Maybe there could be improvements. Any idea?
>>>
>>>
>>> I would suggest supporting decoupling of the rendering and physics
>>> threads as much as possible, without either one blocking the other.
>>> The way I would tackle this would be via thread safe data buffers that
>>> can be read by the rendering thread, and written to by the physics
>>> thread, this buffer would typically be a matrix (or similar transform
>>> representation) with a time stamp, new entries would be push to the
>>> end of buffer, and then the rendering thread would pull at the time
>>> interval required - perhaps interpolating between two entries or even
>>> estimating the position beyond last entry if physics is lagging
>>> behind.  This type of buffer need only have one mutex and would only
>>> be locked when the physics thread pushes data into it, and when the
>>> rendering thread pulls data from it.   This way neither threads should
>>> be halted and will run happily decoupled.
>>>
>>> Robert.
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

Hi Paul,

I'm not really sure the framerate would suffer. Actually this is what I do in 
my engine (I use ODE). There is absolutely no problem running 3 physics steps 
and then one display step. Of course this would depend on the complexity of the 
scene! Anyway, as explained in another post, I created a main loop that takes 
care of the "framerate" for each part (physics, display) and that fire off 
steps when necessary (without changing OSG code).
Anyway, threading would of course be better...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 00:18:19 +0100, Paul Martz  a écrit:

>> Well, is it possible to run "n times PUT", and then one time the
>> standard frame (update/cull/draw)? If so, there should be no
>> problem.
>
> It's possible to do it that way, but the display frame rate will suffer if
> the physics computation gets expensive. In my own work, I am stepping the
> physics simulation once, then calling osgViewer::Viewer::frame(), and I'm
> already seeing framerate issues when interactions get complex. If you want
> to step the physics simulation multiple times, it'll be even more of an
> issue. I think putting the physics simulation in a separate thread will make
> this less of a problem.
>
> It's also simpler, because it doesn't require osgPhysics to invade
> osgViewer, which I personally think is a bad idea. OSG has a lot of
> mechanisms that allow you to do physics without modifying the OSG code. I'm
> able to do a full Bullet physics simulation in my project, and haven't
> modified one line of OSG (just derived a few classes).
>
> Paul Martz
> Skew Matrix Software LLC
> http://www.skew-matrix.com
> +1 303 859 9466
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

(coninued...)

I forgot to mention a thing about interpolating. Yes, this could be a nice idea 
to interpolate (or extrapolate) data, but I think this is a great risk for 
something that may not be very useful for common physics usage. I belive that 
realtime engines generally run at something like 50 or 100Hz (one can of course 
be much slower or much faster), so you may loose much time trying to 
interpolate; and moreover you may introduce inconstistencies (such as objects 
interpenetrating). So I guess simply reading the last matrix is enough.
This is what I do in my engine (not multithreaded yet), and it works without 
lagging. I simply created a main loop that takes care of running physics or 
display when necesssary.

Maybe you have a different point of view on that? I'd be happy to read!

And what about other types of engines (non realtime)? I suppose interpolating 
could be possible, but I still think we introduce simulation errors.

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 11:48:48 +0100, Sukender  a écrit:

> Hi Robert,
>
> I like your idea. I'm not a threading expert, but won't this cost much? I 
> mean locking/unlocking is quite expensive, as far as I know, and depending on 
> the number of matrices to lock, this could cost much. Anyway much less that 
> waiting for a complete traversal to end, of course! :)
> Maybe our implementation could be a "ThreadSafeMatrixTransform"...
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
>
> Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield  
> a écrit:
>
>> Hi Sukender,
>>
>>
>> On Wed, Jan 14, 2009 at 8:59 PM, Sukender  wrote:
>>> Well, multithreading *is* an issue, but we need to address the problem.
>>> I guess the order of steps would be:
>>> - When it is time to update the physics, run the "physics update traversal" 
>>> (say "PUT") in a physics thread
>>> - PUT
>>> - PUT
>>> - ...
>>> - When the times come to update the display, lock the physics thread so 
>>> that no PUT runs
>>> - Run the "display update traversal" ("DUT") in a display thread. During 
>>> this, copy physics positions/orientations to transforms.
>>> - Unlock the physics.
>>> - PUT (physics thread), cull and draw (display thread)
>>> - and so on.
>>>
>>> Am I right? I'm not sure about threads because here the PUT cant run when 
>>> DUT runs, so the interest is limited, even if cull and draw steps would be 
>>> in parallel of a PUT. Maybe there could be improvements. Any idea?
>>
>>
>> I would suggest supporting decoupling of the rendering and physics
>> threads as much as possible, without either one blocking the other.
>> The way I would tackle this would be via thread safe data buffers that
>> can be read by the rendering thread, and written to by the physics
>> thread, this buffer would typically be a matrix (or similar transform
>> representation) with a time stamp, new entries would be push to the
>> end of buffer, and then the rendering thread would pull at the time
>> interval required - perhaps interpolating between two entries or even
>> estimating the position beyond last entry if physics is lagging
>> behind.  This type of buffer need only have one mutex and would only
>> be locked when the physics thread pushes data into it, and when the
>> rendering thread pulls data from it.   This way neither threads should
>> be halted and will run happily decoupled.
>>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Sukender]

Hi Robert,

I like your idea. I'm not a threading expert, but won't this cost much? I mean 
locking/unlocking is quite expensive, as far as I know, and depending on the 
number of matrices to lock, this could cost much. Anyway much less that waiting 
for a complete traversal to end, of course! :)
Maybe our implementation could be a "ThreadSafeMatrixTransform"...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield  a 
écrit:

> Hi Sukender,
>
>
> On Wed, Jan 14, 2009 at 8:59 PM, Sukender  wrote:
>> Well, multithreading *is* an issue, but we need to address the problem.
>> I guess the order of steps would be:
>> - When it is time to update the physics, run the "physics update traversal" 
>> (say "PUT") in a physics thread
>> - PUT
>> - PUT
>> - ...
>> - When the times come to update the display, lock the physics thread so that 
>> no PUT runs
>> - Run the "display update traversal" ("DUT") in a display thread. During 
>> this, copy physics positions/orientations to transforms.
>> - Unlock the physics.
>> - PUT (physics thread), cull and draw (display thread)
>> - and so on.
>>
>> Am I right? I'm not sure about threads because here the PUT cant run when 
>> DUT runs, so the interest is limited, even if cull and draw steps would be 
>> in parallel of a PUT. Maybe there could be improvements. Any idea?
>
>
> I would suggest supporting decoupling of the rendering and physics
> threads as much as possible, without either one blocking the other.
> The way I would tackle this would be via thread safe data buffers that
> can be read by the rendering thread, and written to by the physics
> thread, this buffer would typically be a matrix (or similar transform
> representation) with a time stamp, new entries would be push to the
> end of buffer, and then the rendering thread would pull at the time
> interval required - perhaps interpolating between two entries or even
> estimating the position beyond last entry if physics is lagging
> behind.  This type of buffer need only have one mutex and would only
> be locked when the physics thread pushes data into it, and when the
> rendering thread pulls data from it.   This way neither threads should
> be halted and will run happily decoupled.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Vertex list indexing into another vertex list?

[Vincent Bourdier]

Hi,

Maybe just use setVertexArray with the primary vertex list, and you use the
second list in a osg::DrawElementsUInt (or similar).
In the DrawElementsUInt, you push your vertices indexes. So when the
vertices data are modified, if they keep the same position in the list the
geometry will update. (do not forget setUserData(DYNAMIC) )

There is a setVertexIndice() method but it is now deprecated... maybe
something can replace it.

Same thing for the texture (if I understand well)

Hope this help.

PS : have a look on documentation
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01369.html#4596d0e18fb5217a1306c324a2eaba72

Regards,
   Vincent.


2009/1/14 Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW <
kenneth.sew...@wpafb.af.mil>

> Is it possible to specify a vertex list by indexing into a different
> vertex list?  Sorry if that's confusing, I'll try to explain a bit more.
>
> I've got some data that is organized in the following way:
>
> - A primary vertex list that is the regular xyz values you'd expect.
>
> - A secondary vertex list that is composed by indexing into the primary
> vertex list.
>
> - A texture coordinate list that has a value for each 'vertex' in the
> secondary list.
>
> - Lastly, a list of indices into the secondary vertex list to define
> some primitives.
>
> It looks like the data was set up this way so a vertex that exists in
> multiple primitives can have a unique texture coordinate per primitive,
> yet still only be transformed once.
>
> My initial approach was just to construct the secondary list by
> replacing the index with a copy of the vertex it was referencing.  This
> works except for one thing, the primary vertex list is not static.  By
> that, I mean the values of the vertices themselves, the list size itself
> will not change.  So, the only approach I see is to basically
> reconstruct the secondary vertex list every time the primary is updated.
> This could be kind of rough, since I could potentially have many
> secondary lists.  From what I've seen looking through OSG headers and
> mailing list postings it doesn't seem possible to do this 'vertex list
> by indexing another', but I thought I'd ask just in case.
> Thanks.
>
> - Ken.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Removing the tgz, osgtgz and zip plugins

[Robert Osfield]

Hi Johan,

On Thu, Jan 15, 2009 at 9:22 AM, Johan Nouvel
 wrote:
> We already have a ReaderWriter using zlib, reading from stream and from
> file, writing to file.

The svn + 2.7.x dev series has a zlib based .gz plugin.  I doesn't
support .zip files though.

Does yours handle .zip and .tar.gz?

> But we compile it with our Makefile system, not with CMake.
> I can post the source right now, if someone have time to do the OSG CMake
> part.

The CMake part will be trivial - one only needs to look at the
existing CmakeLists.txt file for the src/osgPlugins/gz plugin, it's
pretty likely that it's more straight forward than your Makefile.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Removing the tgz, osgtgz and zip plugins

[Johan Nouvel]

Hi all,

We already have a ReaderWriter using zlib, reading from stream and from file, 
writing to file.
But we compile it with our Makefile system, not with CMake.
I can post the source right now, if someone have time to do the OSG CMake part.

Cheers,
Johan.

Robert Osfield a écrit :

Hi Michael,

Using libzip would be reasonable thing to do.  Thanks to the Cmake
build system it's easy to pick up on optional dependencies, and if you
don't have them that plugin simply won't compile so it won't affect
end users that don't need the functionality.

Cheers,
Robert.

On Sun, Jan 4, 2009 at 5:18 PM, Michael Bosse'  wrote:

On Thu, Dec 18, 2008 at 4:43 AM, Ulrich Hertlein  wrote:

On 17/12/08 10:56 AM, Jason Daly wrote:

Ulrich Hertlein wrote:

I agree that the implementation is hacky but the functionality is
definitively useful (speaking for zip files only):
- they are a common way to distribute a complete model (non-OSG objects,
textures, etc.)
- they can be easily created by the artists, no need to have OSG
installed
- usable by other packages; .osg, .osga, and .ive are leaf file
formats if you will

That, and couldn't they be re-implemented using zlib (which is already
necessary for the png plugin)?

That's probably the prefered solution for everybody.

One problem that might rise up is that not all plugins support reading from
std::stream but require to read directly from a file.

/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Before I start working on this in my spare time, would it be
acceptable to utilize libzip in the final plugin? Libzip depends only
on the use of zlib and has a complete implementation of the zip file
format. Otherwise, using only zlib would result in a very nontrivial
and redundant implementation of a zip utility library.


"It is only necessary to make war with five things: with the maladies
of the body, with the ignorances of the mind, with the passions of the
body, with the seditions of the city, with the discords of families."
- Tacitus

"The desire for safety stands against every great and noble
enterprise." - Tacitus

"Those who would give up essential liberty to purchase a little
temporary safety deserve neither liberty nor safety." - Benjamin
Franklin

"Numquam ponenda est pluralitas sine necessitate." - William of Ockham
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



--
Johan Nouvel, R&D Engineer
http://www.archivideo.com
tel : +33 (0)2 99 86 30 20
ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Robert Osfield]

Hi Sukender,


On Wed, Jan 14, 2009 at 8:59 PM, Sukender  wrote:
> Well, multithreading *is* an issue, but we need to address the problem.
> I guess the order of steps would be:
> - When it is time to update the physics, run the "physics update traversal" 
> (say "PUT") in a physics thread
> - PUT
> - PUT
> - ...
> - When the times come to update the display, lock the physics thread so that 
> no PUT runs
> - Run the "display update traversal" ("DUT") in a display thread. During 
> this, copy physics positions/orientations to transforms.
> - Unlock the physics.
> - PUT (physics thread), cull and draw (display thread)
> - and so on.
>
> Am I right? I'm not sure about threads because here the PUT cant run when DUT 
> runs, so the interest is limited, even if cull and draw steps would be in 
> parallel of a PUT. Maybe there could be improvements. Any idea?


I would suggest supporting decoupling of the rendering and physics
threads as much as possible, without either one blocking the other.
The way I would tackle this would be via thread safe data buffers that
can be read by the rendering thread, and written to by the physics
thread, this buffer would typically be a matrix (or similar transform
representation) with a time stamp, new entries would be push to the
end of buffer, and then the rendering thread would pull at the time
interval required - perhaps interpolating between two entries or even
estimating the position beyond last entry if physics is lagging
behind.  This type of buffer need only have one mutex and would only
be locked when the physics thread pushes data into it, and when the
rendering thread pulls data from it.   This way neither threads should
be halted and will run happily decoupled.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DatabasePager failed when loading ive with outside image

[Rick Appleton]

Sorry for the delays, but here I am.

Robert, I've not been able to test my issue with the Registry turned off. It 
simple takes too long and a non-variable amount of time to see if that would 
avoid the issue. We were getting the crash when running for anything between 2 
and 24 hours.

As far as I can gather the OP here has tested this though, since he states the 
crash does not occur if he disables Image caching.

Hope to help,

Rick

--
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=4638#4638





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OT: but Qt goes LPGL...

[Robert Osfield]

Hi Colin,

On Thu, Jan 15, 2009 at 12:33 AM,   wrote:
> Not sure if anybody has alraedy posted this but

Several yesterday posts already spread the news, but they were
embedded in another thread so not surprising you missed them.

> today Nokia announced that as of Qt 4.5 (March)
> Qt in full will be available with LPGL licensing - great!

Good news indeed.  Finally GTK and QT are level footing licensing wise.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] altitude terrain shading...

[Robert Osfield]

Hi Shayne,

The standard way to do this would be to use a Texture1D for the colour
banding and TexGenNode to compute the tex coords for you.  See the
osgtexture1D example.

Robert.

On Wed, Jan 14, 2009 at 10:42 PM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC  wrote:
> All,
>
>
>
> I have a requirement to do some altitude shading (coloring) to a terrain
> database based off a referenced altitude. In other words, I would like to
> shade the terrain to be green below a given altitude and then shade it brown
> at or above the given altitude. The reference altitude basically represents
> the horizontal plane that intersects the terrain database. Any terrain below
> the plane is shaded green and any terrain above the plane is shaded brown.
>
>
>
> My question is, is there any support in OSG that will allow me to do
> something like this? My terrain is a database built with VPB.
>
>
>
> Any input would be most appreciated…
>
> -Shayne
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Long-standing Particle System File loading IO performance trouble

[Robert Osfield]

Hi David,

I'm kinda surprised that you are using an external file for particle
effects, this really isn't how I'd tackle it.  Is there are reason why
you aren't just creating the required particle system
programmatically?

Robert.

On Wed, Jan 14, 2009 at 9:13 PM, David Guthrie
 wrote:
> It's being done in the main loop, but we would actually prefer to load assets 
> up front and cache them.
>
> Loading resources in a background thread queue is something I would like to 
> do, but either way, that still has latency, plus there is no reason to have 
> to load a particle system more than once, especially if it's being used 
> repeatedly. Our main problem is that thing like bullet hits and explosions 
> are used repeatedly, and may get instanced many times over a short period of 
> time.  Even if we load them in the background, we would still be loading the 
> same file many times needlessly.
>
> --
> Read this topic online here:
> http://osgforum.tevs.eu/viewtopic.php?p=4618#4618
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPhysics] Project osgPhysics started!

[Ahmed Nawar]

Dear All,

  I used "OpenTissue" for some physics simulation application with osg for 
rendering.
Vista.bibalex.org
As i red the PAL will support OpenTissue sooner.



I think the multi threading is a must, it is the future,
because we must use all of our cores specialty in such heave application.
My problem with the physics simulation is that the render time only take much 
time.
So what about OpenTissue calculation. it is not a real time physics engine.

I used an idea such as Sukender one but with out locking any thread.
This because I have one thread(physics) put data in a shared memory and one 
thread (OSG) read this data.
And because it is not necessary to draw all nodes of osg in the same time step 
of physics.
I don't care, draw as much and as fast as you can,this is my case.
And this help me a lot spatially in make the navigation in osg very fast.

But what is the shared memory. It is of course the position of every node.

So what we need to do,i think, is
1- a stander "PositionAttitudeTransform" like node. it is thread or not thread 
safe.
2- A traversal that read the scene graph in the first step only and fill the 
physics with its suitable form of node conversion.
 Of course with or without our hints.
So we don't want to "modifying the OSG code much". and use multi threading.

of course if we can modified the osg nodes to handle the PAL.
it will use much less memory and be more fast for one thread.
But it will be much more difficult to make it multi threading. So overall speed 
will be less.

I can work with you on osgPhysics if you want.
I am in Egypt :)



Thanks,
Ahmed Nawar
Software Engineer,
ICT Department,
Bibliotheca Alexandrina,
P. O. Box 138, Shatby,
Alexandria 21526, Egypt,
Tel: +(203) 483 , Extension: 1463,
Email: ahmed.na...@bibalex.org,
Web Site: www.bibalex.org,



From: osg-users-boun...@lists.openscenegraph.org 
[osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz 
[pma...@skew-matrix.com]
Sent: Thursday, January 15, 2009 1:18 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] [osgPhysics] Project osgPhysics started!

> Well, is it possible to run "n times PUT", and then one time the
> standard frame (update/cull/draw)? If so, there should be no
> problem.

It's possible to do it that way, but the display frame rate will suffer if
the physics computation gets expensive. In my own work, I am stepping the
physics simulation once, then calling osgViewer::Viewer::frame(), and I'm
already seeing framerate issues when interactions get complex. If you want
to step the physics simulation multiple times, it'll be even more of an
issue. I think putting the physics simulation in a separate thread will make
this less of a problem.



It's also simpler, because it doesn't require osgPhysics to invade
osgViewer, which I personally think is a bad idea. OSG has a lot of
mechanisms that allow you to do physics without modifying the OSG code. I'm
able to do a full Bullet physics simulation in my project, and haven't
modified one line of OSG (just derived a few classes).

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Choice of body-specific coordinate system origin by dae (COLLADA) reader

[Fabian Aichele]

Hello, osg-users!

I have a question regarding the choice of the body-specific coordinate system 
made by the COLLADA reader (daeReader/Writer in osgDB). 
When I import a geometry from a COLLADA document, the osgDB plugin returns a 
osg::Group that contains the "nodes" declared in the COLLADA document together 
with all the "geometries" used by the node declaration, plus material 
properties etc.

That works fine, but there is one thing I haven't figured out yet: How does the 
COLLADA importer decide where to put the "local" origin for a node hierarchy 
imported from COLLADA? I have tested different geometries consisting of 20 to 
about 50 triangle strips/fans/arrays, but the body-specific coordinate system 
was chosen quite arbitrarily (at least I couldn't figure out any pattern).

This is important for me to know since I use OpenSceneGraph to visualize a 
rigid body simulation with the Bullet Physics engine, and I haven't managed to 
get the OSG and Bullet coordinate systems "in sync".

Any hints or pointers to documentation/examples/earlier questions regarding 
this are gladly accepted.

Thank you!

Fabian Aichele___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org