Actually extracting data from Bryce files is fairly easy, the problem however is that it gives youi very little to actually work with. To understand this, its important to understand that Bryce is primarily a raytracer rendering engine, similar to PovRay except with a GUI rather than a SDL. Although Bryce and PovRay have facilities to import mesh objects, most Bryce models are constructed from boolean operations on primitive parametric shapes. Bryce never actually creates or stores the final constructed object in memory, what you see in the render is effectively an illusion that's created during the rendering process by calculating the points at the which the rays enter and leave various positive and negative objects. Therefore what you get from obp files and other Bryce formats is just a list of the primitive cubes, squares, cones etc. and their locations, boolean polarity, grouping etc. In order to create a physical mesh object from this information you would then have to effectively create the core of a full CSG modelling application, which is maybe 100 times more work that the simple file data extraction. The question then is why would you want constrain this code solely to the fairly small and static Bryce market when you could instead slap your own simple interface on it and sell it as an application independent modeller. Another major disadvantages about developing a Bryce (or any application)-only exporter is that you are constrained by the functionlity of Bryce itself. Even if there are more things that your modelling core can do, theres no point in implementing them as the Bryce exports will never support them and, if there are things that Bryce exports that are difficult to implement or pointless, omitting them still creates an apparent weakness in the product. Also important for Bryce modelling and export is the procedural texturing. Although its possible, to a degree, to emulate the procedurals from the information in the files in practical terms you would really need direct access to the sampling procedures in the raytracer itself in order to satisfy the requirements for a well featured export. For an application independent modeller, this isn't really an issue. Texturing can simply be left as an area that's not covered in the spec. Sometime last year my company approached DAZ with a view to possibly implementing our existing code as an exporter for Bryce, we had most of the elements for the CSG and isosurface operations and a solution for mapping onto an arbitrary CSG constructed topological surface without the problems associated with standard projections, so long as we could access the raytracer sampling. At the time we were told that the exporter work was nearly completed anyway. So maybe the next version will have a more advanced export options. Bill