Hi Marcus, thanks for your files. And thanks Allen for the hint on BOOST.asio I will give it a try.
Marcus Lindblom wrote: > Hi Christoph, > > Well, the loader setup is embarrasingly simple, so I can share that > wihout worries. See the attached bsFileSys.xxx files (it requires > boost::filesystem, but that is not necessary, merely a convenience). > The zip-datasource implements this for a zip-archive (to read from > directories within a zip-file) by using ZipIOs. The latter works > somewhat ok but I need to reconfigure our app a lot to make it truly > usable for us (we have some relative paths & includes in scripts that > mess things up quite a bit currently). > > What I really wanted was a good virtual file system with zip and > whatnot-support, but I haven't been able to find anything like that on > the net. I could also imagine using URI's and a xml-alike content > resolver framework, but neither of this is top-priority at all. > Our goal, is to implement a SceneFileHandler which can access files over URLs. This should be possible to achieve by a factory of different istreams. Inside the different SceneFileTypes the read resources like for example material files (MTL) or textures should be accessed also over the same factory. > The cache system is not really what you're looking for, I think. It > serves to speed up reloading previously read & optimized content as > gzipped .osb files (not a single cache, but individial files), for > faster subsequent runs (tristripping and sharing opts can take time, > esp in debug). I'm using boost-iostream there, to add a > gzip-(de)compressor to the original data-stream (usually from file) to > reduce disk-access, which is the limiting factor for us. It does not > work when loading the zipped .osb-files, as the > boost-gzip-decompressor cannot provide random access to the file. (I > probably could get away with decompressing to memory and reading from > that, but I need to figure out how large the decompressed file is.. > which I should be able to figure out by checking the streampos.. hmm > :) .. > Yes, that could be a workaround for cases where random access is difficult. Similar to caching into OSB files, another convenience function would be to have a local mirror function which saves all scenes and resources locally. Different from caching into OSB, is that it would work also with OpenSG nodes, which are not fully integrated into OpenSG (i.e. cannot serialize into OSB). Needless to say, that it should be without big changes inside the SceneFileTypes.. > Anyway, since it, at the moment, doesn't work with .osg & zipped cache > files, it will need some work before it should be released. It also > depends on the boost::iostreams library, which may not be ideal, but > since OpenSG 2.0 seems to be boost-dependent anyway, it might not > matter much when push comes to shove. :) Do you mind, if I go for a SceneFileHandler which is able to access remote files and to write a local mirror upon request. The problem seems quite similar to your caching into OSB.. Only there are some more changes inside the different SceneFileTypes, I guess. Regards, Christoph ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
