Hi Gerrit,
Gerrit Voss wrote:
>
> Hmm, shader composition wasn't on Allen's list IIRC.
No, but you were talking about things in the works for 2, so I
generalized a little bit. ;)
> 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.
I need to have that solved in a more general way anyway, as I will be
dealing with very large datasets (>100 GB) points. For that I'm thinking
about a general CacheManager class that handles a memory cache of a much
larger dataset. It will handle asynchronous loading and priorities, and
maybe hierarchical assets (e.g. LODs or multi-level textures), not quite
decided whether it's better to leave that with the higher-level code.
I was thinking of having two coupled CMs, one for GfxMem and one for
main mem (and maybe another one for disk), that would limit the transfer
per frame to a give amount. For non-OOC ssytems you could use just one
for GfxMem.
I was thinking about having managed versions of textures and LODs to
avoid having to integrate it seamlessly into the existing code (OOC and
even large model handling needs some special preprocessing anyway).
> Unfortunately using driver memory directly seems not that easy as
> you need an active context.
Yup.
> 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.
Well, that has the same problem, no? If you do the traversal in a
separate thread there is no context, and even if there was there might
be another thread busy pushing data into the pipe which might not like
being interrupted.
> With this also goes early stage execution so we don't have to wait until
> the render traversal is finished.
Hm, you're thinking of what Performer called Cull_o_Draw? Is that
critical enough to warrant the complication of not being able to build a
full tree?
> That comes from the bbq terrain stuff, what kind of terrain are you
> doing ?
I have a student working on a master's project (starting right now), and
we're trying to implement the Seamless Patches paper
(http://wscg.zcu.cz/WSCG2007/Papers_2007/full/C43-full.pdf), as it seems
like a good and simple method for multi-resolution terrain. That would
also need the CacheManager. Application is our Army foot soldier
simulation system.
> 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.
I'm surprised that this is critical, given today's memory sizes. I think
a good gfxmem expulsion strategy is much more useful, and much less
complicated to get working right.
> As memory management is a quite wide topic what were you looking at ?
See above.
> 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)
Not sure I get that last part. In general, have you thought about
conventions to make this work to replace OpenGL fixed func? I.e., how to
integrate different kinds of light sources with surface shader and
geometry manipulation like skinned character? What you describe above is
a necessary component, but the actual application is not going to be
trivial itself, so it might make sense to start thinking about it. Or do
you not want to talk about it until it's published?
Yours
Dirk
------------------------------------------------------------------------------
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
