Hi All,
Marcus Lindblom wrote:
>
> I'm just saying it might be a nice feature to have, since it would allow
> you to save/send/clusterify the scene graph even after you have released
> the memory.
True, but it would make the whole system fairly complicated and brittle.
> The primary reason is to save memory during normal app run (to reduce
> process footprint & swapping). But, a save of the scene graph (due to
> debugging or whatever) will require some disc access anyway so
> temporarily increased memory usage might be tolerated in that context.
But I guess for debugging you could live with the increased memory footprint
too.
> Me too. I would expect the user to manually restore data before saving.
The problem that I see is making sure that the frame has actually been
rendered.
Integrating that into a multi-threaded rendering pipeline gets messy.
> I agree with you completely. If this is to be implemented it would
> require some brainpower. But I do believe it can be done within
> reasonable limits. I have to think on it a bit. (And it might make sense
> to do it only with the OpenGL 3.0 API, to simplify things).
Actually, that's a good question. I'm not sure if OpenGL 3 even allows you to
read back the texture data.
> I don't know how big the typically clustered scenes are, but I'd expect
> this could be used to increase the amount of renderable geometry per
> node, especially if the computer does other things as well. (As we do,
> we have a lot of computation going on, so we can't reserve the entire
> 2gb of RAM to the graphics subsystem.)
The way I look at it it would make sense as something that's explicitly
triggered by the app, i.e. at some point it tells OpenSG: "BTW, I don't need
the
images in memory any more, let's get rid of them". At that point OpenSG would
just release all the images' memory and be optimistic that they really meant
it.
;) After that point you couldn't save the scene any more or add cluster nodes.
I could see that being possible, and there should be a way to make clusterable,
too. Would that be useful?
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
