Marcus Lindblom wrote: >Allen Bierbaum wrote: > > >>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? >> >> > >The plan was to provide stream _and_ url to loaders, so that they can >choose whether to load from stream or put stream to local disc (via the >file cache perhaps) before the "real" loader is invoked. > > > >>- 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. >> >> > >I haven't decided on explicit or implicit management of resolving this, >so I sort of left it out. > >Explicit management would be that the loader would by itself combine the > base-URL (http://server/content/model.wrl";) with the relative one >(i.e. "../foo/bar.jpg"). A URL class would help with that (it would be >very similar to boost::filesystem::path). It would mean changing >existing loaders a bit, but probably not much, and probably making >things clearer and more straightforward. > >Implicit management would perhaps work for one level of data, but it >would probably be ambigous if you go several levels down (at least, it >seems that to me if I think about it, someone else might be smarter). > > > >>- 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. >> >> > >IMHO, callbacks are kind of evil and hard to control. I'd suggest >something like the 'futures' concept that's being worked into C++0x. >I.e. you get a proxy object, which you can do a non-blocking query for >completion or a blocking wait to get the actual data. > > Could you provide a link to a discussion of this concept. It sounds like an implementation of an async completion token pattern but I hadn't heard of this for C++. I wonder how it compares to how boost.asyncio or twisted deffered objects work.
>I'm looking in to making such a primitive for our app, since we are >going to split it from two full-working threads to four (moving to >double dual core). > >So, if it turns out well, it's probably easy to add that to the >loader/resource manager. (I'd imagine that loading and graph-processing >is ideal candidates for parallellisation.) > > Yes, I agree. > > >>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. >> >> > >Cool. A general worker-thread system would be cool also. > >Point worth noting: I think the resource load/handling ought to be >careful in calling OpenGL, since we are sometimes rendering at the same >time as loading. Having it do that on startup is fine, but probably less >so during app run (at least until the async gl gets going proper). > > IMHO the loader should *never* call OpenGL. I would hope that it doesn't right now. Can anyone confirm this though? -Allen >>- 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. >> >> > >Yup. That ought to go into Comparison or something. Also, a list of >'completeness' for each loader would help out, I think. > > > >>Keep up the good work Marcus. I think your ideas look great. >> >> > >Thanks! :) > >/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 >Opensg-users@lists.sourceforge.net >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 Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
