In the category of beyond 2.4, the community can look forward to an
OpenFlight export plugin. Should be submitted to OSG sometime in the
February-April '08 timeframe. So maybe it'll be in 2.6.
Its capabilities are pretty limited at the moment, but what is working works
well and looks promising.
Any volunteers, pretty please ;-)
Ask you and shall receive! :) Hell, less than 24 hours is a pretty
decent turnaround time...
Beat me to it... thanks.
I was going to ask the same questions I saw in your comments... should
the interface restore the original display mode in the destructor or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
Yep its working in 2.2, osgViewer is more rounded and complete in 2.2
than 2.0, and in SVN its a little bit further on still. Note quite
viewer/windowing nirvana yet, but the closest the OSG has come in its
history.
Ah,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Moles wrote:
On Tue, 2007-12-18 at 20:35 +, Robert Osfield wrote:
On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote:
I guess RandR it is then, because some people voiced the support for
changing the resolution on the fly. RandR
On Wed, 2007-12-19 at 22:13 +0100, Jan Ciger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Moles wrote:
On Tue, 2007-12-18 at 20:35 +, Robert Osfield wrote:
On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote:
I guess RandR it is then, because some people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Robert,
Robert Osfield wrote:
An external script that invokes the 3D app only works when entering an
application, not once its running, so it does have a bit of limited
applicability.
I understand that, however, how often do you need to change
Hi Jan,
On Dec 18, 2007 1:22 PM, Jan Ciger [EMAIL PROTECTED] wrote:
An external script that invokes the 3D app only works when entering an
application, not once its running, so it does have a bit of limited
applicability.
I understand that, however, how often do you need to change
That could work, but I am not sure whether it is actually worth the
trouble - the original poster only wanted to change the resolution
before starting the application, not during runtime, so this could be an
overkill. Perhaps a poll to figure out whether this is a one-off request
or a
For many games (particular on Windows of yesteryears) and applications,
I have changed resolutions and 3D effects once the application or game
has started depending on the frame rate performance. Thus if possible it
would be best to implement a feature into OSG to change resolution,
though how
For many games (particular on Windows of yesteryears) and applications,
I have changed resolutions and 3D effects once the application or game
has started depending on the frame rate performance. Thus if possible it
would be best to implement a feature into OSG to change resolution,
though
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
RandR support would be a reasonable way forward. SGI and other older
workstation class machines are not so prone to users wishing to change
resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92
this didn't
On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote:
I guess RandR it is then, because some people voiced the support for
changing the resolution on the fly. RandR is the only reasonable way how
to do this on Unix at the moment. The older X extensions change
resolution, but do not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lucas Goss wrote:
Hmm, that might be alright, though I don't really like writing shell
scripts, haha. Of course if that is an advantage for some they can
still do it that way, they don't have to use OSG's implementation. But
it would be nice to
Hi Jan,
On Dec 17, 2007 7:21 PM, Jan Ciger [EMAIL PROTECTED] wrote:
The reason for SDL's craziness and why I have suggested a shell script
is easy - you can make a some kind of X hack that works on your computer
using one extension, but I compile the program on my computer and it is
very
Hi Jan,
On Dec 17, 2007 8:21 PM, Jan Ciger [EMAIL PROTECTED] wrote:
That would be quite a hackery, IMO. Are you going to handle all the
issues with path, detection whether certain binaries are available or
not and potentially which versions they are in the application code?
An external script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
Hi Lucas,
On Dec 14, 2007 9:46 PM, Lucas Goss [EMAIL PROTECTED] wrote:
Would it be possible to implement setScreenResolution for X11? Was
it left out because it requires an X11 extension? I have some linux
machines that
Setting screen resolution isn't straight forward with X11 unfornately,
if it had been it'd already have been done. The generic interface for
setting resolution is in place, and implementation is done for Win32,
but on the X11 side we did a volunteer to go forth and implement it.
Hmm,
Hi Lucas,
On Dec 14, 2007 9:46 PM, Lucas Goss [EMAIL PROTECTED] wrote:
Would it be possible to implement setScreenResolution for X11? Was
it left out because it requires an X11 extension? I have some linux
machines that have older video cards that run the desktop ok at higher
resolutions, but
Would it be possible to implement setScreenResolution for X11? Was
it left out because it requires an X11 extension? I have some linux
machines that have older video cards that run the desktop ok at higher
resolutions, but run 3D much faster if the resolution is scaled down.
Lucas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Halliday wrote:
I've been using osgswig ( http://code.google.com/p/osgswig/ ) for a
project on a cave-type system combining python, vrjuggler, and osg.
osgswig supports python, ruby, java and lua, although I've only played
with the python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Daly wrote:
osgCal/Replicant are great, provided that you want to use Cal3D
characters only.
Why? Where is a problem about taking a character/animation from Collada
and creating the Cal3D skeleton structure from it on loading? That is
what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir Shabanov wrote:
Yes, it has different implementation. But what about skeletal
character with morphing face and maybe some particles around his body
(imagine a small devil). Different rendering methods are tightly
coupled here. And their
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Jeremy,
Jeremy Moles wrote:
Nothing more was ever implied given the code provided, so I'm not sure
why you even brought this up? The example is clearly a purposefully
succinct and shortened summation. What brings it up to speed is adding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir Shabanov wrote:
As I said before cal3d meshes are not used by osgCal for performance
and memory usage reasons. They are used at export stage to generate
ready to direct load meshes file. For compability loading from cal3d
.cmf-files is
Robert Osfield wrote:
On Dec 11, 2007 6:31 AM, J.P. Delport [EMAIL PROTECTED] wrote:
could we get support for multiple render targets (MRT) integrated into
2.4? I know some people are using hacky patches for this. Some patches
have been submitted, but they have to be reworked.
I can help
Hi,
John Donovan wrote:
Robert Osfield wrote:
If we can get a clean set of patches to support MRT then I'm for
reviewing/merging them :-)
Mea culpa... I implemented JP's hack into my source and it worked for what I
needed it for. Then I submitted a half-baked patch which Robert was right
On Tue, 2007-12-11 at 09:18 +, Robert Osfield wrote:
On Dec 10, 2007 8:27 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
One thing that should be kept in mind when using Cal3D is that in it's
current state, Cal3D isn't a skeletal system alone--it's a skeletal
animation system+mesh format,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
On Dec 10, 2007 8:27 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
One thing that should be kept in mind when using Cal3D is that in it's
current state, Cal3D isn't a skeletal system alone--it's a skeletal
animation system+mesh
2007/12/10, Jeremy Moles [EMAIL PROTECTED]:
I noticed there was a lot of Cal3D discussion going on here so I'd
figure I'd chime in and say a few things.
I have write access to Cal3D SVN I obtained a year or so ago when Palle
Raabjerg and myself rewrote the Cal3D Blender exporter, which we
2007/12/11, Jeremy Moles [EMAIL PROTECTED]:
How big is Cal3D? I ask in terms how much effort would it be required
to reimplement the unique parts not found in the core OSG?
It's hard to say--there's a lot of code in Cal3D supporting the mesh
format, XML loading, matrices, vectors,
2007/12/9, Jan Ciger [EMAIL PROTECTED]:
I am not sure what are you referring to when speaking about keyframe
animation, though. Do you mean 3D morphing of meshes? I would keep that
separate, it is a completely different beast with different problems
than skeletal animation. Animation of an
Jan Ciger wrote:
However, it doesn't solve any of the animation and skinning issues and
is completely useless by itself. I cannot imagine somebody bringing it
up to speed with other kits from this alone, for that you need
something actually usable to start from. This is why e.g. osgCharacter
Jan Ciger wrote:
Actually, I think that the focus should be on providing a meaningful API
to export to these languages. That could even mean a wrapper in order to
eliminate/minimize usage of pointers and some C++ functionality that is
difficult to translate (templates?). Once you have that,
Just want to share my experience with using Lua for building applications.
We have been using Lua fo building applications for quite some years now.
THe binding is using tolua++ where we have exported most of osg, openal++,
osgal, replicantbody, physics library etc...
We took the path of
Hi Cedric,
On Dec 10, 2007 10:48 AM, Cedric Pinson [EMAIL PROTECTED] wrote:
I would not like to have those node kit in the core of osg, because the
functionnality they provide is not the core of osg, they are adaptators
for others libs, and for me it should be a nodekit in a third party.
The
On Sat, 2007-12-08 at 14:07 +, Robert Osfield wrote:
Hi All,
After a two month break I'm now doing a purge of the submissions
backlog. I doubt I'll get all the way through before Monday, but on
Monday I'll tag the first dev release since 2.2 stable was made. This
dev release will be
Hi,
could we get support for multiple render targets (MRT) integrated into
2.4? I know some people are using hacky patches for this. Some patches
have been submitted, but they have to be reworked.
I can help with this if needed.
regards
jp
Robert Osfield wrote:
Hi All,
After a two month
Hi Paul,
On Dec 8, 2007 4:48 PM, Paul Martz [EMAIL PROTECTED] wrote:
It is one Node, OcclusionQueryNode, derived from Group. This node has a few
supporting classes that aren't exported. It also has a handful of small
NodeVisitors for utility purposes.
If we put this Node in a NodeKit rather
On Dec 8, 2007 9:12 PM, Anders Backman [EMAIL PROTECTED] wrote:
I would say that osgAL is working rather well with osg as for now.
OpenAL++ is a rather healthy abstraction rather than integrating OpenAL
directly into osg...
You get support for ogg-vorbis, streaming sound, capture (from input
Yes osgAL is tied with OpenAL++
And with Cmake it would be rather easy to make the ogg/vorbis integration a
simple choice in the Cmake gui.
/Anders
On Dec 9, 2007 1:28 PM, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Jan,
On Dec 8, 2007 7:11 PM, Jan Ciger [EMAIL PROTECTED] wrote:
Another
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rizzen wrote:
Good points Jan, though maybe we should have a compromise here. Thus OSG
supports two scripting languages, the best one for each scenario.
Scenario 1: Have Lua for embedded scripting via osgLua, which would go
well for the gaming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
I am aware of both osgCal and ReplicantBody body am not very
familiar with the code bases/current feature sets.
I would like to see consolidation of related functionality. There is
also the osgCharacter library out in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
I have been thinking about physics integration as well, but not
suggested it on this round as there wasn't a contender sitting of the
shelf ready to integrate.
Longer term I'd like to see physics integration, ideally in a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Anders,
Anders Backman wrote:
If the new osgCal, or whatever name it will have can make benefit of a
tight osg connection, together with the high-level functionality of rbody,
I think this is a good start.
Then when its working, it can
Hello Anders and Jan,
I agree, the most logical path (and I think we have discussed this quite a
few times before) is to merge osgCal (with its better rendering back-end),
with the higher functionality of ReplicantBody.
That would be excellent! I am sure I am not the only one who wanted at
be a showstopper for 2.4 integration.
-Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Robert Osfield
Sent: Saturday, December 08, 2007 7:08 AM
To: OpenSceneGraph Users
Subject: [osg-users] Looking towards 2.4, and what might go into it.
Hi All
]
[mailto:[EMAIL PROTECTED] On Behalf
Of Robert Osfield
Sent: Saturday, December 08, 2007 7:08 AM
To: OpenSceneGraph Users
Subject: [osg-users] Looking towards 2.4, and what might go into it.
Hi All,
After a two month break I'm now doing a purge of the
submissions backlog. I doubt
To: OpenSceneGraph Users
Subject: [osg-users] Looking towards 2.4, and what might
go into it.
Hi All,
After a two month break I'm now doing a purge of the submissions
backlog. I doubt I'll get all the way through before
Monday, but on
Monday I'll tag the first dev release
Hi!
Any chance for
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2007-October/003523.html
Regards
Panagiotis Papadakos
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi All,
After a two month break I'm now doing a purge of the submissions
backlog. I doubt I'll get all the way through before Monday, but on
Monday I'll tag the first dev release since 2.2 stable was made. This
dev release will be 2.3.0 and be the first concrete step towards the
final 2.4.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
Hi All,
After a two month break I'm now doing a purge of the submissions
backlog. I doubt I'll get all the way through before Monday, but on
Monday I'll tag the first dev release since 2.2 stable was made. This
dev
My own short list for contenders for integration are:
osgOQ - Occlusion Querry support
osgCal - Cal3D integration
osgAL - OpenAL integration
osgEphemeris would be a nice node kit to integrate for 2.4 as well.
___
osg-users mailing list
I would say that osgAL is working rather well with osg as for now.
OpenAL++ is a rather healthy abstraction rather than integrating OpenAL
directly into osg...
You get support for ogg-vorbis, streaming sound, capture (from input
devices) etc...
So I don't thing integrating osgAL would introduce
Jan Ciger wrote:
One has to ask
which scripting languages to go for - Lua and/or Python? Lua would be
the easiest to integrate in terms of being very self contained i.e.
which could stick the whole of the lua interpreter into the core OSG
distribution and one would hardly notice as its
54 matches
Mail list logo
