El Miércoles, 28 de Marzo de 2007 07:16, hesicong2006 escribió:
> How can I convert the osg::Group to a osg::Transform node?
> And are there any better ideas?
It might be of help to you knowing that both osg::Transform and
osg::PositionAttitudeTransform inherit from osg::Group. Maybe writing a
I load a 3ds file using osgDB::ReadNodeFile function. And I get a Node
which I call it machineNode.
Now the machineNode have the structure in memory:
[group]BASE
[group]HEAD
[group]AUX_CLAMP
[geode]Box11
[geode]AUX_CLAMP
...
[group]MAIN_AXIS
Does anyone have any 1.2 compatible code that will do a fisheye or wide
angle lense effect? I'm playing around with osgdistortion right now but I'm
not able to get it to do what I want.
Thanks,
Lucas
___
osg-users mailing list
osg-users@openscenegraph
Yup, that worked like a charm! Thanks!
- Steve
On Tue, 27 Mar 2007, Paul Martz wrote:
Date: Tue, 27 Mar 2007 13:41:27 -0600
From: Paul Martz <[EMAIL PROTECTED]>
Reply-To: osg users
To: 'osg users'
Subject: RE: [osg-users] Just drawing a line?
Assuming "state" is your StateSet, call the fol
Assuming "state" is your StateSet, call the following method:
State->setMode( GL_LINE_SMOOTH, osg::StateAttribute::ON );
-Paul
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, March 27, 2007 1:29 PM
> To: osg
On 3/27/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
Hi Ulrich,
Sorry about this, I need to update the wrappers, will do shortly.
Updated wrappers now checked in.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph
Is there a way to set in the stateset (or other) a method for drawing an
anti-aliased line? I don't need to anti-alias the entire view.
- Steve
On Mon, 26 Mar 2007, Robert Osfield wrote:
Date: Mon, 26 Mar 2007 21:32:21 +0100
From: Robert Osfield <[EMAIL PROTECTED]>
Reply-To: osg users
To: o
well The problem is actually solved now.
it was a wierd problem actually hehe
in a tutorial told me to write
osg::Vec2Array* texcoords = new osg::Vec2Array(5);
(*texcoords)[0].set(0.00f,0.0f); // tex coord for vertex 0
(*texcoords)[1].set(0.25f,0.0f); // tex coord for vertex 1
(*tex
Hi Johanm
Help with what? I'm pretty confused about what you are looking for
advice or how the code segments relate to anything.
What is the problem you are seeing when you view the model?
Robert.
On 3/27/07, Johan Johnsson <[EMAIL PROTECTED]> wrote:
a very simple pyramide texcoord initializ
Hi Andrew,
I can't see an obvious reason why not doing a pre compile would fix
the memory problem you are seeing.
Unfortunately that is little I can do in terms of tracking down what
the problem might. Best I can recommend is to add debugging code into
osg::Geometry and locate the geometry caus
Hi Ulrich,
Sorry about this, I need to update the wrappers, will do shortly.
Robert.
On 3/27/07, Ulrich Hertlein <[EMAIL PROTECTED]> wrote:
Hi Robert,
Robert Osfield wrote:
> On 3/27/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
>> Nevermind, actually it was my fault, because the problem was
a very simple pyramide texcoord initialization.
osg::Vec2Array* texcoords = new osg::Vec2Array(5);
(*texcoords)[0].set(0.00f,0.0f); // tex coord for vertex 0
(*texcoords)[1].set(0.25f,0.0f); // tex coord for vertex 1
(*texcoords)[2].set(0.50f,0.0f); // ""
(*texcoords)[3].set(0.75f,
Hi Robert,
I was never able to find any problem with the data, although I did not
spend a huge amount of time looking. I was able to remedy the problem
(or so it seems so far) with another solution. In the past, I had been
using the database pager with setDoPreCompile(false). I tried changing
t
Hi Robert,
Robert Osfield wrote:
On 3/27/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
Nevermind, actually it was my fault, because the problem was the
executables not finding the DLLs. All the examples I tried have worked
correctly so far.
Now I can state that the old OSG's Makefile system *w
Hi All,
I made another little step towards the next OSG release today by
deprecated the old flt plugin. The source code for the old plugin is
still maintained under subversion, but in a deprecated tree, rather
than part of the trunk.
To check out the deprecated code:
svn co http://www.opensc
Hi Alberto,
On 3/27/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
Nevermind, actually it was my fault, because the problem was the
executables not finding the DLLs. All the examples I tried have worked
correctly so far.
Now I can state that the old OSG's Makefile system *works correctly*
with t
Hi Robert,
Robert Osfield escribió:
Hi Alberto,
On 3/27/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
The rest compiles fine. The problem now is that executables produced
(examples, viewer, ...) quietly do nothing, even they do not open any
window. No error messages are written to the console.
I need to PARTIALLY occlude some moving objects. Actually,
using the osg::Occluder class and looking at the osgoccluder
example, I realized that when my moving object move just a
little bit behind the occluder plane, it is hidden
completely...even though there is a large part of that
object that sh
Hi Alberto,
On 3/27/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
The rest compiles fine. The problem now is that executables produced
(examples, viewer, ...) quietly do nothing, even they do not open any
window. No error messages are written to the console. They just finish
execution after runn
Well that's simple Paul: the "DataFilePaths" object is a "std:deque"... so
you can use push_front() and push_back():
osgDB:getDataFilePathList().push_front("C:/My/path/to/check/first")
or
osgDB:getDataFilePathList().push_back("C:/My/path/to/check/last")
regards,
Emmanuel.
2007/3/27, Paul Ma
Oh duh. It returns a non-const reference. Sorry I didn't catch that. Thanks
for your reply.
-Paul
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Edgar Ellis
> Sent: Tuesday, March 27, 2007 8:03 AM
> To: osg users
> Subject: Re: [osg-users] osgD
Hi Paul,
You should be able to modify the list returned from getDataFilePathList().
Eg: getDataFilePathList().push_front( ... )
- Edgar
Paul Martz wrote:
On a related note, setDataFilePathList() clears out the current path
list. So, if an app calls this function, it essentially overrides any
On a related note, setDataFilePathList() clears out the current path list.
So, if an app calls this function, it essentially overrides any setting of
OSG_FILE_PATH, correct?
I poked around in osgDB and couldn't find an obvious way for an application
to simply append one or two paths to the file p
Hi Robert,
Robert Osfield escribió:
I've checked the file back out and remodifed and checked it in,
hopefully this should fix things.
Now I can retrieve the changes, thanks.
Does the rest of the OSG compile fine? Hows about execution?
The rest compiles fine. The problem now is that execut
Hi RJ,
By default the OSG uses the convention of +ve Z is up, +ve Y is north,
+ve X is east, which is consistent with the convention most commonly
used in vis-sim and is world centric coordinate frame.
The OpenGL eye coordinates have +ve Z out from the screen, +ve Y up,
+ve X to the right. The
Hi Guys,
I am having a hard time understanding the Coordinate system of different
nodes in the scene. Well here is an example : I have a "terrain Node "
and a " tank Node ". When i set up my default viewer the eye (camera) is
at origin looking in Z -ve direction and up is Y up . I want both of my
n
Great ! Indeed, this solve the problem.
thanks !
Emmanuel.
2007/3/27, Robert Osfield <[EMAIL PROTECTED]>:
Hi Emmanuel,
osgDB leaves the finding of files up to the plugins themselves, this
way they can decide whether the filename is a file at all (for
instance a psuedo loader) or use standard
Hi Emmanuel,
osgDB leaves the finding of files up to the plugins themselves, this
way they can decide whether the filename is a file at all (for
instance a psuedo loader) or use standard or custom file path
determination.
In most plugins you'll find lines like the following:
std::str
Hello everyone,
I'm using a plugin to read OSG nodes in .gz files I developed on my own. It
works perfectly well, but now I would like to use this plugin with the
DataFilePathList handling system in osgDB and I can't get it working this
way... I tried something like:
osgDB::FilePathList pathLi
Hi Alberto,
On 3/27/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
Sorry for the broken Makefile. I see that you checked the fix for CMake in
rev. 6403, but I can't find where did you check the changes for the old build
system.
Curious, I did modify the file, but must have missed checking it in
Hi Robert,
El Lunes, 26 de Marzo de 2007 17:59, Robert Osfield escribió:
>
> On 3/26/07, Alberto Luaces <[EMAIL PROTECTED]> wrote:
> I have reviewed your modified file and won't merge your change as
> it'll break the rest of the unix platforms (they don't have a gdi32
> lib). There is already Min
31 matches
Mail list logo
