Does it need to be OBJ or can it be a collection of vertices, faces, normals, colors, etc? You are right that the OBJ exporter has to do something like that anyways, but I’m not sure if we can access that in any practical manner prior to saving the file. Maybe @tim (who delas with some of the IO projects) can chime in on that.
If your app can be more agnostic about how it can accept data, then you could write your own. For example, you can try Iris to see how I do this to a json file compatible with threejs. While threejs has an OBJ loader which can come in handy, I prefer to represent the rhino scene in my own manner that allows me to export layers and other scene attributes that obj wouldn’t handle. Let me know if any of that is of interest, otherwise, we’ll see what @tim says.
I’m using OBJ simply because its the most compatible format outside of STL in my industry. Eventually once the custom viewer/encrypter/decrypter is done with it, it will need to spit out some kind of file, might as well be OBJ which is why I’m chasing down that avenue.
Our code isn’t currently structured for this, but we aren’t opposed to change. How do you think this should work from the perspective of a plugin developer?
(Fyi I’m not a plugin developer, I’m just poking around to write things i wish were in my various jewellery apps over the years for my team of 12 designers and 5 cad operators who all use rhino in some form or the other. My first nut to crack was creating a secure viewer app which was quite successful but required saving to disc then reading into my encrypter. Id prefer the output file never touch disc at all. From 3dm to obj to network stream directly into my secure viewer. )
[edit] Also it would be damn handy to be able to convert streams, currently I only work with one api that can do that “easily” in format