Hi all -- I've seen a couple of posts now implying that the next stable
release after 2.8 will be called "3.0". I wanted to open a discussion on
this so that we can get some clarification.
Unless the next stable release will break lots of backwards compatibility,
I'd opt for calling it "2.10", th
I am agree with this notation.
Paul Martz wrote:
Hi all -- I've seen a couple of posts now implying that the next
stable release after 2.8 will be called "3.0". I wanted to open a
discussion on this so that we can get some clarification.
Unless the next stable release will break lots of backw
Hi Paul,
This needs to be confirmed, but I think Robert's mind is to go to 3.0 to allow
the whole community to introduce things that "break backwards compatibility",
as you say. You even posted a thing on the thread "Ideas for OSG v3.0", where
Art Tevs told about reorganizing nodekits/plugins (
HI,
I agree on that the next version will still be 2.x. Only if we really go for a
completly different API (with almost no backward compatibility), then we should
go to 3.x
The previous thread just collected some ideas about how to manage future
releases of osg 3.x The idea was to go away from
Hi Paul,
Hi all -- I've seen a couple of posts now implying that the next stable
release after 2.8 will be called "3.0". I wanted to open a discussion on
this so that we can get some clarification.
I don't think this is the case. Robert has only referred to 3.0 when
talking about introducing
HI Paul,
My thoughts for OSG-3.x would be that it would be major rewrite of the
core scene graph and many of the additional components, and as such
would take a great deal of down time before anything near to level
functionality with OSG.2.x would be achieved. OSG-3.x is rather blue
sky thinking
Hi all,as an example of a concrete project for shaping OSG 3.0 I suggest
developing a ray tracing backend for meshes and point clouds (not only
volume rendering), probably using OpenCL.
Is there anyone else interested in this?
Marco
___
osg-users mailing
HI Marco,
On Thu, Feb 5, 2009 at 11:11 AM, Marco Fiocco wrote:
> as an example of a concrete project for shaping OSG 3.0 I suggest developing
> a ray tracing backend for meshes and point clouds (not only volume
> rendering), probably using OpenCL.
> Is there anyone else interested in this?
This
Hi Robert,
One thing that might help would be to make sure the exploration phase
consisted of several small tasks that were doable in a couple of weeks
of development. The outcome would be small demo and the key part -
knowledge about this new domain. Such projects could easily by
managed as s
Amen!... ;)
Joking aside, I agree but have a few comments/questions:
> If we don't keep up to date and pushing the technology I fear that
> game centric API's will drown out the needs of real high end graphics
> developers
1. True! IMHO, OSG 3 should address *some* (not *all*) aspects of game AP
Hi Nick,
GForge was created by some of the original SF team and is really good -
free to open source projects.
http://gforge.org/gf/
Yeah, that's what I meant, not exactly the same software but it looks
like it's exactly what we'd need to make an open OSGForge.
J-S
--
Hi JS,
I confirm that:
- SourceForge is open source
- Can be installed on a custom server
- Can contain Trac ( :) )
That would be a _*VERY*_ nice idea, even for OSG 2.x.
I'm definitely in favor of that idea.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Hi,
http://gforge.org/gf/
Yeah, that's what I meant, not exactly the same software but it looks
like it's exactly what we'd need to make an open OSGForge.
Hmmm, I just noticed that GForge only supports CVS? Is that true?
Perhaps there's an SVN plugin or something?
Anyways, I'll investiga
Hi Robert, hi all,
Do you think it could be worth trying a kind of "sandbox" server built on
SourceForge? This would help us to check what could be the future issues with
such a system. I don't have a "true" server (just my main machine with a
bandwith that fits for personnal usage, and that is
Hi JS,
Jose is actually setting up a virtual server for us, this should allow
us to add external users to have admin rights for helping maintain the
server. Once the server is set up, and the dust has settled after
2.8.0 we can look at exact what services we want to provide from the
sever.
Rober
Hi Sukender,
As I just mentioned in a reply to JS, the new virtual server should
give us a bit more flexibility w.r.t. setting up new services. I'll
not dive in any more on this topic right now as the release has to be
be primary focus.
Robert.
On Thu, Feb 5, 2009 at 2:38 PM, Sukender wrote:
>
GForge was created by some of the
original SF team and is really good - free to open source projects.
http://gforge.org/gf/
Nick
Jean-Sébastien Guay wrote:
Hi
Robert,
One thing that might help would be to make
sure the exploration phase
consisted of several small tasks that were
Hi folks,
>
> I've offered my (part-time) help in maintaining the OSG site to Jose
> Luis in the past, but he said since the server belonged to his school
> they would be reluctant to let an "outsider" get access to one of their
> servers. Perhaps when the server is moved to a virtual server,
Okay.
BTW, I don't find where to download SourceForge... I said it is open source...
or *WAS* is?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Thu, 05 Feb 2009 15:41:29 +0100, Robert Osfield a
écrit:
> Hi Sukender,
>
> As I just mentioned in a reply
Hi Sukender,
Okay.
BTW, I don't find where to download SourceForge... I said it is open source...
or *WAS* is?
In the GForge documentation it says that the public CVS repository for
SourceForge had not been updated for more than a year, so they made a
fork of it (which is GForge). It's poss
>> Hi all -- I've seen a couple of posts now implying that the next
>> stable release after 2.8 will be called "3.0". I wanted to open a
>> discussion on this so that we can get some clarification.
>
> I don't think this is the case. Robert has only referred to 3.0 when
talking
> about introduci
Hi Robert,
Jose is actually setting up a virtual server for us, this should allow
us to add external users to have admin rights for helping maintain the
server. Once the server is set up, and the dust has settled after
2.8.0 we can look at exact what services we want to provide from the
sever.
Hi,
Okay.
BTW, I don't find where to download SourceForge... I said it is open
source... or *WAS* is?
In the GForge documentation it says that the public CVS repository for
SourceForge had not been updated for more than a year, so they made a
fork of it (which is GForge). It's possible that
Hi,
I own a server with 100Mb where i host some vserver, i could help to
host a back up or any other services for osg related stuff.
About the osg forge, i am not sure i would want it, i explain why:
- more of them has no service for decentralized version control like
mercurial / git
- It cons
Hi Cedric,
In theory the idea is cool but if people dont fill the current wiki why
they will take energy to fill a forge ?
I think it requires no more energy than hosting your project on your own
site, or a site like SourceForge or Google Code. The difference is that
it would be centralized
Hi JS and Cédric,
I'm a bit more in favor of what JS says. I agree that when the Forge is down
it's really annoying, but centralizing all OSG related projects seem worth
using a kind of forge (or something else). We really should avoid them dying by
helping people maintaining them.
Sukender
PV
Anyway i will help to host if it helps
Cheers,
Cedric
Sukender wrote:
Hi JS and Cédric,
I'm a bit more in favor of what JS says. I agree that when the Forge is down
it's really annoying, but centralizing all OSG related projects seem worth
using a kind of forge (or something else). We really
Thank you very much Cédric.
However, I respect your point of view, and think that discussing a bit when
having different ideas avoids many mistakes. We may finally find an
intermediate or altered solution that fits most needs. I'm not really in favor
of building a fully custom server, as it will
Hi all,
i don't understand why we should rewrite the whole openscenegraph core? Is
the good old openGL and openscenegraph that faraway from openGL CL/openGL
ES/.. How long does it take to port the whole greate functionality from osg2
to osg3? And how would it be possible to port the application fo
Hi Sukender,
About GForge: it supports SVN,
Yes, I saw that the document I was reading was quite out of date. It
also supports a wiki, and 4.7 (which is in RC right now) has support for
MySQL (I would prefer the server to run only one database engine, and
I'm more familiar with MySQL than P
Hi Adrian,
Simply beacuse OSG 2 == OpenGL 2, and OSG 3 == OpenGL 3 (and such). That's
certainly an awful shortcut, but globally, that was Robert said. OSG 2 will
still live, and you may have your applications use OSG 2.26 (if such a version
exists), even when OSG 3 is out. But you would not be
Great thing! I'm also more used with MySQL. Could be interesting...
And yes, the open source seem sufficient to mee too.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Thu, 05 Feb 2009 21:10:31 +0100, Jean-Sébastien Guay
a écrit:
> Hi Sukender,
>
>> A
Hi Adrian,
i don't understand why we should rewrite the whole openscenegraph core?
Is the good old openGL and openscenegraph that faraway from openGL
CL/openGL ES/..
OpenGL ES and OpenGL 3.0 will drop the fixed pipeline. So OSG's core
functionality (state attributes for each fixed pipeline
Ok, i see. The OpenGL 3 API will completly change. And for this, we will
have to rewrite the OpenSceneGraph core. But the scene graph it selfs could
(may) be the same or very similar. that would be greate. i thought the we
will to rewrite the whole code, this would be much much much work, and even
Hi Adrian,
Ok, i see. The OpenGL 3 API will completly change. And for this, we will
have to rewrite the OpenSceneGraph core.
Well, the API will change but the old API will be deprecated, not
totally removed. The problem is that we don't know when the fixed
pipeline will be removed, once it'
eGraph (3D)
Sent: Thursday, February 05, 2009 12:59 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] 3.0 or 2.10?
Hi all,
i don't understand why we should rewrite the whole openscenegraph core? Is
the good old openGL and openscenegraph that faraway from openGL CL/openGL
ES/.. How long d
HI Adrian,
Writing the core scene graph is something that is likely to be
required to handle multiple backends, so rather than just OpenGL 2.0,
we'd need OpenGL 3.0 and OpenGL-ES and a mixture of OpenGL/OpenCL.
Currently we only map to OpenGL + extensions, we can't handle
wholesale changes to the
Hi Robert,
OpenGL 3 specs says that nothing has been removed (just features that become
deprecated). That mean OSG 2 is OpenGL 3 compatible (Well of course without new
features)... isn't it?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Fri, 06 Feb 2
Hi Sukender,
OpenGL 3 specs says that nothing has been removed (just features that become
deprecated). That mean OSG 2 is OpenGL 3 compatible (Well of course without new
features)... isn't it?
Relying on deprecated features is bad practice, since by definition
deprecated features may be rem
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender
Sent: Friday, February 06, 2009 1:14 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] 3.0 or 2.10?
Hi Robert,
Will there be (or should there be) an "OSG-3" branch in svn to allow
development to commence?
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.opens
Hi Paul,
On Fri, Feb 6, 2009 at 8:37 PM, Paul Martz wrote:
> Will there be (or should there be) an "OSG-3" branch in svn to allow
> development to commence?
I think this is premature. I'd rather see us highlight areas that
need research and then have a set of mini projects that go out scoping
t
Hi Paul and JS,
I was just wondering... not saying that we should try some ugly things like
supporting deprecated features! :)
The "forward-compatible context" seem an interesting thing though...
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Fri, 06 F
43 matches
Mail list logo
