2009/1/15 Mark Sciabica
> Hi Gazi,
>
> It is true that OSG differs from your literature. That does not make OSG
> incorrect. In fact, the literature wasn't always dominated by the format
> you're promoting.
>
Hi Mark,
It's not just my literature, it's the dominant one that anyone starting to
l
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,
Is anyone else having problems with the svn server? I'm getting:
svn: OPTIONS of 'http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk':
Could not read status line: Connection reset by peer
(http://www.openscenegraph.org)
___
osg-users mailing l
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 form
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 b
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
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
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
representat
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
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 defe
--- On Thu, 15/1/09, Gazi Alankus wrote:
> From: Gazi Alankus
> Subject: Re: [osg-users] getting translate rotate scale right.
> To: "OpenSceneGraph Users"
> Date: Thursday, 15 January, 2009, 6:25 PM
> I can't tell you the right answer, but maybe this might
> help a little bit.
> [rant]
> OSG m
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
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 tha
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.
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
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
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 mu
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
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.openscenegra
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" decla
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 : gtomlin
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: Thu
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]
T
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 Up
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
Undefined base class??? That sounds very strange.
If you find the reason, that may help others.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Thu, 15 Jan 2009 15:41:54 +0100, Alexandre Amalric a
écrit:
> Hi Sukender,
>
> I already downloaded the late
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 ma
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
fstre
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
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 1
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 - Lig
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 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
Hi Sukender,
On Thu, Jan 15, 2009 at 12:06 PM, Sukender wrote:
> So, to avoid having two objects updated with 2 different time stamps, is it
> ok if I:
> - Fill matrix buffers with physics timestamped matrices (PUT - physics thread)
> - Update in a batch all the display matrices from the latest
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 do
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
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 f
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"?
Hi Sukender,
On Thu, Jan 15, 2009 at 10:48 AM, Sukender wrote:
> I like your idea. I'm not a threading expert, but won't this cost much? I
> mean locking/unlocking is quite expensive, as far as I know, and depending on
> the number of matrices to lock, this could cost much. Anyway much less tha
(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 wond
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 cre
(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
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! :)
M
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.
Hi Johan,
On Thu, Jan 15, 2009 at 9:22 AM, Johan Nouvel
wrote:
> We already have a ReaderWriter using zlib, reading from stream and from
> file, writing to file.
The svn + 2.7.x dev series has a zlib based .gz plugin. I doesn't
support .zip files though.
Does yours handle .zip and .tar.gz?
>
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
Hi Sukender,
On Wed, Jan 14, 2009 at 8:59 PM, Sukender wrote:
> Well, multithreading *is* an issue, but we need to address the problem.
> I guess the order of steps would be:
> - When it is time to update the physics, run the "physics update traversal"
> (say "PUT") in a physics thread
> - PUT
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 Colin,
On Thu, Jan 15, 2009 at 12:33 AM, wrote:
> Not sure if anybody has alraedy posted this but
Several yesterday posts already spread the news, but they were
embedded in another thread so not surprising you missed them.
> today Nokia announced that as of Qt 4.5 (March)
> Qt in full will
Hi Shayne,
The standard way to do this would be to use a Texture1D for the colour
banding and TexGenNode to compute the tex coords for you. See the
osgtexture1D example.
Robert.
On Wed, Jan 14, 2009 at 10:42 PM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC wrote:
> All,
>
>
>
> I have a req
Hi David,
I'm kinda surprised that you are using an external file for particle
effects, this really isn't how I'd tackle it. Is there are reason why
you aren't just creating the required particle system
programmatically?
Robert.
On Wed, Jan 14, 2009 at 9:13 PM, David Guthrie
wrote:
> It's bein
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.
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 docum
53 matches
Mail list logo