Hi,

On Fri, 2009-01-30 at 10:14 -0600, Dirk Reiners wrote:
>  Hi Allen,
> 
> Gerrit Voss wrote:
> > Hi,
> >
> > On Thu, 2009-01-29 at 13:35 -0600, Allen Bierbaum wrote:
> >   
> >> What is the plan for OpenGL 3.0 and OpenSG?
> >>
> >> At one point I remember hearing someone suggest the bold idea of
> >> making OpenSG 2.0 be OpenGL 3.0 only.  The idea being to remove a lot
> >> of code from OpenSG and focus on the high performance code paths that
> >> OpenGL 3.0 exposes.  Is there still anything thinking in this
> >> direction?
> >>     
> > 3.0 only might be a little to harsh for now as AFAIK it requires some
> > quite recent hardware and drivers only just seem to appear. I haven't
> > tried to enable it yet.
> >   
> My take: we talked about that before last SIGGRAPH, when everybody they 
> would release 3.0 soon. Well, they did, but it wasn't anywhere near what 
> everybody expected. There are pretty much no new features in what's now 
> '3.0', especially none of the major changes in the object model and none 
> of the old cruft has been removed. Therefore IMHO 3.0 hasn't happened yet.
> 
> Drivers are a separate issue. Yes, they're not ubiquitous, but I think 
> that would change quickly if there was a point.
> > And as I'm quite unhappy that I still did not resolve your old questions
> > I would rather look into/finalize those first (with an eye on 3.0).
> >   
> Are you talking about the shader composition or the memory management?

Hmm, shader composition wasn't on Allen's list IIRC. 

It was more about all these memory and download things. I have
a rough idea how to delay rendering, the bigger question is to figure
out until when ? I was about to play with the pbo stuff and see if it
has an impact on the texture downloads.

Unfortunately using driver memory directly seems not that easy as
you need an active context.

The one thing high on my list is quite generic access to the glcontext
during the traversal so that data prep/download can go on as early as
possible.
With this also goes early stage execution so we don't have to wait until
the render traversal is finished.

That comes from the bbq terrain stuff, what kind of terrain are you
doing ?

The other thing high on my list was the forget data after downloading.
That requires some tweaking to work with the MT and Cluster syncs, but
I have a reasonable good idea what is needed.

As memory management is a quite wide topic what were you looking at ?

> The latter is high up on my list too, so let me know before you start 
> doing something.
> 
> The former is more in your court. Can you give us an update on where 
> you're at with it? We have some stuff in the works (skinned characters, 
> seamless-patch terrain) that would benefit from it.

The basics are there, currently I'm looking into the merge/override
logic. The shaders now basically follow the OpenGL model so
you can have program parts that compile separately and are finally
linked together. You already can distribute them hierarchically in
the graph but right now they are only merged together (by linking),
hence the need for more logic ;-) It probably needs some low-level
interface for direct use (e.g. activating/deactivating these shaders
directly and not through the  general draw mechanism)


I hope to have that one sorted soon (e.g. before IEEE VR). If it is
not that pressing we can have a look than so I can see more use cases.



kind regards,
  gerrit


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to