Matthias Stiller wrote: >>>> (And, since you can read-back data, you could implement that as >>>> well, if you really needed to retrieve it and send/store it >>>> somewhere.) >>> This might get very nasty when you want to save the scene as a OSB >>> file to disk. Maybe the thread trying to write to disk is not the >>> one that renders the scene ? >> What I meant was that you could call a function to "restore" the >> object's data from OpenGL (obviously from a thread with an active >> gl-context). That must be done between renderings in the same >> context, of course. > > As far as I understand the reason to use this feature is to save memory. > If you are going to "restore" all data at once the primary reason to > save memory has gone.
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. 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. > Trying to ty it into the writers sounds somewhat ugly for me. Me too. I would expect the user to manually restore data before saving. >> Once you've done that, you would be back to today's state of things >> (dat both locally and in OpenGL), and can happily save and render in >> different threads. >> >> Does it make sense? > > Don't get me wrong, I do not disagree with you, it would be a really > nice feature in theory. But I guess the time needed for a stable > implementation might not be short ... and I fear that it will take > quite a time until it would be stable enough for use ( not accounting > that it will not increase the codes understandability). 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). 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.) Cheers, /Marcus ------------------------------------------------------------------------- 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
