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

2009-01-15 Thread 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


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

2009-01-15 Thread 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


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

2009-01-15 Thread 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
dguth...@alionscience.com 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] altitude terrain shading...

2009-01-15 Thread 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 shayne.tuel...@hill.af.mil 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] OT: but Qt goes LPGL...

2009-01-15 Thread Robert Osfield
Hi Colin,

On Thu, Jan 15, 2009 at 12:33 AM,  co...@mve.com 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] DatabasePager failed when loading ive with outside image

2009-01-15 Thread 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] [osgPhysics] Project osgPhysics started!

2009-01-15 Thread Robert Osfield
Hi Sukender,


On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr 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] Removing the tgz, osgtgz and zip plugins

2009-01-15 Thread 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' metis...@gmail.com wrote:

On Thu, Dec 18, 2008 at 4:43 AM, Ulrich Hertlein u.hertl...@sandbox.de 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, RD 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!

2009-01-15 Thread 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 suky0...@free.fr 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 robert.osfi...@gmail.com 
 a écrit:

 Hi Sukender,


 On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr 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!

2009-01-15 Thread 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 pma...@skew-matrix.com 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!

2009-01-15 Thread 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 suky0...@free.fr 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 suky0...@free.fr 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 
 robert.osfi...@gmail.com a écrit:

 Hi Sukender,


 On Wed, Jan 14, 2009 at 8:59 PM, Sukender suky0...@free.fr 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!

2009-01-15 Thread 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!

2009-01-15 Thread 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!

2009-01-15 Thread 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 robert.osfi...@gmail.com a 
écrit:

 Hi Sukender,

 On Thu, Jan 15, 2009 at 10:48 AM, Sukender suky0...@free.fr 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!

2009-01-15 Thread 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 ahmed.na...@bibalex.org 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!

2009-01-15 Thread Robert Osfield
Hi Sukender,

On Thu, Jan 15, 2009 at 12:06 PM, Sukender suky0...@free.fr 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!

2009-01-15 Thread Robert Osfield
Hi Sukender,

On Thu, Jan 15, 2009 at 10:48 AM, Sukender suky0...@free.fr 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] Removing the tgz, osgtgz and zip plugins

2009-01-15 Thread 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
openscenegr...@archivideo.com 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, RD 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


[osg-users] osgAL + latest OSG SVN

2009-01-15 Thread 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 RD
===
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] osgAL + latest OSG SVN

2009-01-15 Thread 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


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

2009-01-15 Thread 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 pyshell#3, line 1, in module
   import gtk
 File C:\Python25\lib\site-packages\gtk-2.0\gtk\__init__.py, line  
38, in module

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

   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] rendering ive model (shaders)

2009-01-15 Thread Ü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 selmanduat...@gmail.com

 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 umituzu...@gmail.com 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 lukas.did...@nist.gov

 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] osgAL + latest OSG SVN

2009-01-15 Thread 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 suky0...@free.fr

 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 RD
===
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] [osgPhysics] Project osgPhysics started!

2009-01-15 Thread 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 robert.osfi...@gmail.com a 
écrit:

 Hi Sukender,

 On Thu, Jan 15, 2009 at 12:06 PM, Sukender suky0...@free.fr 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

2009-01-15 Thread 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 alex.pix...@gmail.com 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 suky0...@free.fr

 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] osgAL + latest OSG SVN

2009-01-15 Thread 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 fstream 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] [osgPhysics] Project osgPhysics started!

2009-01-15 Thread 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] Vertex list indexing into another vertex list?

2009-01-15 Thread 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
 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] altitude terrain shading...

2009-01-15 Thread 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 shayne.tuel...@hill.af.mil 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] altitude terrain shading...

2009-01-15 Thread 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 shayne.tuel...@hill.af.mil 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] Choice of body-specific coordinate system origin by dae(COLLADA) reader

2009-01-15 Thread 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 up_axis setting in the global asset 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...

2009-01-15 Thread 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 shayne.tuel...@hill.af.mil 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


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

2009-01-15 Thread 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] [osgPPU] Frame rate drop with osgPPU v0.3

2009-01-15 Thread 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] OSG Contracting Question

2009-01-15 Thread 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] Long-standing Particle System File loading IO performance trouble

2009-01-15 Thread 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] getting translate rotate scale right.

2009-01-15 Thread 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] getting translate rotate scale right.

2009-01-15 Thread 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


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

2009-01-15 Thread 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 christopher.g.doro...@lmco.com


 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.

2009-01-15 Thread Paul Fotheringham
--- On Thu, 15/1/09, Gazi Alankus ala...@gmail.com wrote:

 From: Gazi Alankus ala...@gmail.com
 Subject: Re: [osg-users] getting translate rotate scale right.
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 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] OSG Contracting Question

2009-01-15 Thread 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] OSG Contracting Question

2009-01-15 Thread 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] Choice of body-specific coordinate system origin by dae(COLLADA) reader

2009-01-15 Thread 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 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] getting translate rotate scale right.

2009-01-15 Thread 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 osg_u...@yahoo.co.uk
[...]


 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] Long-standing Particle System File loading IOperformance trouble

2009-01-15 Thread 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] Disabling VSYNC

2009-01-15 Thread 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 maxim.serebren...@usma.edu
 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] getting translate rotate scale right.

2009-01-15 Thread 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 osg_u...@yahoo.co.uk 
mailto:osg_u...@yahoo.co.uk

[...]


Eh? By what definition exactly?



http://fly.cc.fer.hr/~unreal/theredbook/appendixg.html 
http://fly.cc.fer.hr/%7Eunreal/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


[osg-users] svn offline?

2009-01-15 Thread Ulrich Hertlein
Is anyone else having problems with the svn server?  I'm getting:

quote
svn: OPTIONS of 'http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk':
Could not read status line: Connection reset by peer
(http://www.openscenegraph.org)
/quote
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] svn offline?

2009-01-15 Thread 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


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

2009-01-15 Thread Gazi Alankus
2009/1/15 Mark Sciabica msciab...@itracs.com

  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 osg_u...@yahoo.co.uk
  [...]


  Eh? By what definition exactly?



  
 http://fly.cc.fer.hr/~unreal/theredbook/appendixg.htmlhttp://fly.cc.fer.hr/%7Eunreal/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