Marcus Lindblom wrote: >Hi, > >I've tried to summarize ideas and provide a proposal on FileIO. This >also serves as a little example on how such a page might look. > >http://opensg.vrsource.org/trac/wiki/Dev/FileIO > > The page looks like a good start. I have a couple of comments to discuss.
- How do we balance using a stream interface with using external utilities that can only take filenames or file handles? Does anyone know a good way to deal with this? - I like the idea of using ContentProviders. What if we kept some type of "loader" state around with all the loading calls so when you are loading a file and come to a texture reference for "my_texture.jpg" the loader state would be able to resolve this to a url? That could be the idea you have already, I may have just missed it. - While we are doing this, could we create an external threaded "resource manager" or sorts that could do async data loading and processing. We have multi-threaded support, we may as well use it. :) What I am thinking here is that when you want to load a new file into the system you could tell the resource manager and continue on with your application (or block if you really want to). Then the resource manager would go out and load the models in a separate thread and notify you when complete. The notification could be through a callback and we could make sure it only occurs at certain times during execution when the main thread calls an update method or something on the resource manager. I have done something similar to this (but not generic) for a couple of applications and it works out great. This is also how many game systems work so there may be some things to learn from that direction. - New loaders: I think we should make a list of all loader formats that we currently support, ones that other scenegraphs support and OpenSG does not, and ones that no one supports. Then we can look at that list and prioritize the loaders that we would like to have in OpenSG. If the loaders already exist in another scene graph we should look at porting their code. In some cases porting the code could be very straight forward and may not take much time. It could be a great project for users that want to contribute to the project. Keep up the good work Marcus. I think your ideas look great. -Allen > >Cheers, >/Marcus > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Opensg-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/opensg-users > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
