Hi Cristoph, I should probably go ahead and send you the code that I have on the cache stuff, since it seems as you are doing something quite similar. Will just have to check with the powers that be. That is, if you don't mind depending on boost-serialization/iostreams/filesystem. Anyhow, it might be good inspirational read if you manage to get through it. :).
Caching to a local mirror, is sort-of what I do today anyway, so those things might be useful. I also perform a hash-calculation, so you could probably use that by only fetching the hash remote and see if it matches, before using the local copy. My cache-class keeps a map of all cached (in your case local) files and their hash-values, so it should be easy to convert into something more useful. On loading from remote, some sort of datasource / content-provider is necessary. I don't know how to access this in the best way, as there are some conflicts: - Protocols (http/file/ftp) - Archives (zip/rar) - Data 'layers': (gzip/bzip2/encryption) - Different 'mount' points, esp. within the file protocol. (i.e. what the PathHandler does but in a more general fashion) - Relative paths in general (i.e. vrml's imagetexture links) Nothing new, but it needs adressing if a system for this is to be robust. Oh, and my opinion is that the SceneFileHandler-classes need very little change, if any. (Currently, I have a special case for vrml, since I need to hash linked textures as well). I think it ought to be possible to work around that by using some boost::iostream-adaptor in the custom ImageReadCallback-function and compute the hash-value as the files are requested & read. I don't know what plans you guys have made though. But I love to discuss this, as I've been (at least mentally) struggling with the proper way of handling it for some time. Btw, what do you mean by OpenSG nodes not being serializable into .osb? Cheers, /Marcus Christoph Fünfzig wrote: > 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. > ------------------------------------------------------------------------- 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
