Hi Brett, You can override the reading and writing at a high level by doing using a Registry::ReadFileCallback and WriteFileCallback. You could use this to intercept all the the write of .ive and adapt them.
Or just disable the change the ProxyNode's filename so that it includes an extension relating to your encrypted format. The other approach is to leave all the loaders as is, and just encrypted the vertex and image data. This would require an encryption that doesn't change the data size, but would enable you to use all the loaders as is, and just run a visitor over the scene grpah and decrypt/encrypt. Robert. On Fri, Oct 3, 2008 at 9:38 PM, brettwiesner <[EMAIL PROTECTED]> wrote: > OK. I have a workaround for my problem. I'll explain the original problem, > my solution and make a suggestion. > > Requirements: > A third party we have bought models from does not what their data to be > shipped unencrypted. So I have to encrypt it. > > Initial Solution: > My thought was that I'd like to just use the IVE loader to write a node to a > stream, then I'd encrypt that thereby getting an encrypted fast loading > file. So I tried that. I wrote a loader that use the IVE loader to get a > stream from a node, then I encrypted the stream and wrote it out. The loader > would also read in an encrypted file, decrypt it into a stream and pass that > into the IVE loader. All was well until I came across models with proxy > nodes (aka models that referenced other models). > > It turns out the IVE loader writes out .ive files for all it's proxy nodes. > There are several options that I can pass to the IVE loader that will make > it not write out external references, but I want it to. I just don't want > them to be written out as ".ive's"; I want them to be written out as my > encrypted file format. > > Workaround: > Because loaders don't have API's they can't be subclassed. Instead, I had to > do a little trickery. I'll use encryption as an example. When my loader is > active (ie: writing an encrypted file), I remove the real IVE loader from > the ReaderWriter list in the registry (but I keep around a pointer to it). I > register my loader as something that accepts the ".ive" extension. Now when > anyone tries to write out an ".ive" file, they will be using my loader. > Then I use the pointer to the real IVE loader to write the node to a > stream. When the IVE loader comes across a proxy node and wants to write out > an ".ive" file, it asks the registry for the IVE loader, which then gives it > back my loader. My loader gets the stream from the real IVE loader then does > the encryption and writes it out. At the end, my loader adds the real IVE > loader back to the reader writer list and then changed itself to no longer > accept ".ive's" as a valid extension. > > My suggestion: > This trickery could have been avoided if the logic for the IVE loader was in > a library that could be extended. The IVE loader has a little helper class > for every kind of node in OSG. These classes should be created with a > factory. Then I could subclass the IVE loader and replace the ProxyNode > helper class with my subclass and I'd be able to have an encrypted loader > that lives alongside the real IVE loader without any weird tricks. > > Imagine a library... osgDbIve. This would have headers in the include dir, a > lib in the lib dir, a dll in the bin dir. Then there would be one other > library, osgDB_ive which would be very small and only build the plugin. > Users could then subclass the loader logic since that is all contained in an > extendable API, and just write the small loader plugin . > > Thanks, > Brett > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
