> >> (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. Trying to ty it into the writers sounds somewhat ugly for me. > 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). Matthias -- +---------------------+----------------------------+ | VREC GmbH | | | Matthias Stiller | | | Robert-Bosch-Str. 7 | tel: +49 6151 4921034 | | 64293 Darmstadt | web: http://www.vrec.de | | Germany | mail: [EMAIL PROTECTED] | +---------------------+----------------------------+ ------------------------------------------------------------------------- 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
