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
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.
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
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:
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
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
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
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
(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
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
(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
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
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
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
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
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
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,
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) ?
--
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 -
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
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,
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
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
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
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
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
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]
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:
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
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
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
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
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
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
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
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
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
--- 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
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
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
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
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
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
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
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
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
___
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
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
48 matches
Mail list logo
