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. This
usage, so this shouldn't 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: [o
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
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
> > &
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
http://lists.openscenegraph.org/list
-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
os
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 a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anders Backman wrote:
> What is the feature list for osgCal these days?
> Im not following it in any detail, and I guess Im "home-blind" as we
> developed ReplicantBody and have been rather satisfied with that...
osgCal is quite low level - a simple
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
On Dec 8, 2007 8:42 PM, KSpam <[EMAIL PROTECTED]> wrote:
> > 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.
>F
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 r
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 in
Hi Jan,
On Dec 8, 2007 7:11 PM, Jan Ciger <[EMAIL PROTECTED]> wrote:
> Another good contender for integration would be some physics engine. I
> have experience with ODE, Bullet and the Opal wrapper, all three are
> reasonably usable with OSG (I have running code for this). However,
> physics integ
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:
> > Ano
-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
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.
Starting from scratch with a completely osg-native CA engine is a rather
large task which I dont thi
-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
-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, i
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
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.
Instead i think an osgPython or osgOQ are a place in the core, because
it's realat
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.
Hi All,
OK to round up the rough discussion so far:
Integration of osgOQ, osgCal and osgAL look doable without too much
effort, contributors to these projects open
to the idea of integration and helping towards this.
Physics would be a nice one too but longer term, need a concrete
imple
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Robert Osfield
> Sent: Monday, December 10, 2007 10:44 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Looking towards 2.4, and what might
> go into it.
>
&g
Hi Mike,
On Dec 10, 2007 5:24 PM, Mike Weiblen <[EMAIL PROTECTED]> wrote:
> What is a rough estimate for the 2.4 time frame? (weeks, months,
> mid-Feb, etc)
Not this month for sure. Possibly mid-late Jan if we keep the feature
additions modest.
> > General improvements to osgViewer and other l
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
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Robert Osfield
> Sent: Monday, December 10, 2007 1:07 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Looking towards 2.4, and what might
> go into it.
>
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 mont
On Dec 11, 2007 1:04 AM, Mike Weiblen <[EMAIL PROTECTED]> wrote:
> > Are you able to predict what areas this might cover?
>
> Geom shaders, plus some win32 build refinements.
Most excellent, Geometry shaders has been on my wish list for over a year ;-)
_
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 with this if needed.
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, and one cannot be divorced from the other.
> Furthermore, t
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
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
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 f
-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 syste
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Moles wrote:
> To be completely honest, character animation is such a huge issue unto
> itself that it probably deserves a lot of discussion and review before
> any steps are taken--but that's just my opinoin. Every time I'm forced
> to put any
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. osgCharac
On Tue, 2007-12-11 at 22:04 +0100, Jan Ciger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jeremy Moles wrote:
>
> > To be completely honest, character animation is such a huge issue unto
> > itself that it probably deserves a lot of discussion and review before
> > any steps are
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 exportin
-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 pytho
-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 the
-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
-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 i
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
__
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
> resolutio
-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
>> mach
> > 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.
H
-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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
> I wonder about a compromise... call an external application to do the
> change of resolution for us from within osgViewer just by issuing a
> system call.
That would be quite a hackery, IMO. Are you going to handle all the
issu
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 sc
-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 chan
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 chang
> > 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
>
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 this
> 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,
> thoug
-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
> > 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 destructo
-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.
>
A
-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
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 som
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.
69 matches
Mail list logo
