I'm currently writing an LWO2/LXO converter for Houdini, using .bgeo format, and I ran into an issue with one of my test files. To debug, I implemented a .geo writer alongside the .bgeo writer, and to my surprise, that file loaded correctly. After not finding any discrepancies by reading the files side-by-side, I decided to make a .bgeo to .geo converter as well, to check my sanity. Again, to my surprise, the .geo file that was output from the conversion process loaded correctly, so I'm out of ideas.

For privacy reasons, I cannot post the test file's contents nor the code, but I might be able to divulge small portions of the data for use in debugging. I am using the .geo/.bgeo file format version 5, as referenced in the GPD.txt that came with Houdini when I downloaded it last week.

That is an older bgeo format, pre H12 (which is confusing since that isn't mentioned in that directory!)

The new format is JSON-based; there is a header in the HDK and which doesn't use a license: http://www.sidefx.com/docs/hdk16.5/_u_t___j_s_o_n_parser_8h_source.html [www.sidefx.com]

Also, check out $HFS/houdini/public/hgeoand $HFS/houdini/public/binary_json

Hmm. I guess if .bgeo isn't maintained, I can create yet another converter. *sigh*

I don't suppose that there is a formal description of the format, similar to GPD.txt? Or must it be gleaned from the implementation?

Dolphiniac
I don't suppose that there is a formal description of the format, similar to GPD.txt? Or must it be gleaned from the implementation?

Sorry, there's no formal description of the format right now. It'd be nice if there were one, but it'd be a lot of work to put together a full spec handling every case, especially with things like shared volume data and packed primitives. If I recall correctly, there are also a couple optimizations in bgeo that aren't in geo, and a couple optimizations that are only done in certain cases, so be careful. Feel free to ask any specific questions you have, though, and I can try to check.

I figured out the issue, and for now, I'm electing not to convert to the new format, since it would be too much investment at this time to decode an entirely new (compared to V5) and undocumented format.

Apparently, when specifying “Runs” of primitives, it is illegal in BGEO to have a RunLength of 1. Not so in the equivalent V5 ASCII, but in the binary. So I just conditionally wrote the “Run” PrimKey and RunLength if the RunLength was greater than 1.