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. 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.) > 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). > - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
