Where can I find documentation for the RLE encoding used in exported JSON geometry, for example:


All 160 prims in this example consist of 80 verts each, so am not sure why this as RLE not just says [160, 80], maybe with some additional prefix bits to indicate this is an RLE'd value…

If I look at the data array as hexdump, I can reconcile the first few bytes, but it would be really, really helpful not having to try to reverse engineer this and get some official word of wisdom about this format, please! I could not find documentation about this anywhere…

Can you post the whole file?

The “nvertices_rle” array above indicates that there are 6 polygon curves with 202 vertices, then 40 with 201 vertices, then 18 with 202 vertices, then 18 with 201, then 17 with 202, 18 with 201, 30 with 202, 8 with 201, then lastly, 5 with 202 vertices. If it were 160 polygon curves each with 80 vertices, it would be [80, 160]. You might want to double-check in the Geometry Spreadsheet, and maybe make sure that you don't just have a lot of repeated vertices, i.e. multiple consecutive vertices on the same point.

I'm not sure where your hex dump is coming from. Is it from somewhere in a bgeo? Is it from somewhere in memory? The new data structure in Houdini 16.0 for representing polygons in memory is extremely complicated when viewed from the bits, and the bgeo format probably is too, but in a completely different way.

Ah, I see what you did to get the “hex dump”. Yeah, you're reading too much into it, haha.

Off on a tangent that you may or may not find interesting:

If there were something more to read into it, that also wouldn't be the bit order. In a byte stream of CA 06 C9 28, the nybbles are in order: A, C, 6, 0, 9, C, 8, 2. One step further, hexadecimal A is written in binary as 1010, but the bits are actually in the order 0, 1, 0, 1. This is because bit 0 (the bit that's worth 2^0) comes first, followed by bit 1 (the bit worth 2^1), followed by bit 2 (worth 2^2), then bit 3 (worth 2^3), else one would have to do a bunch of extra processing to effectively reverse the bits all the time. In files, the distinction usually only matters for things like compression algorithms and naturally bit-packed data, because not many other things store data in non-byte-aligned ways. Even the human genome standard uses a 3GB ASCII file instead of encoding the A's, C's, G's, and T's in 2 bits each, which is kind of sad, but I guess people can always compress/decompress the file with common compression programs. In memory, there are a number of glorious and sometimes anxiety-inducing bit-hacks that have come in handy, but that's another matter.

Thanks, Neil & apologies for slow response! It turned out that I somehow made an export of the wrong node and hence the values didn't match and sent me off on this fruitless journey trying to make sense…

Re: hexdump & bitstream: As you figured out, this was just of the data in nvertices_rle. The way I learnt writing binary is MSB first (even though in the RAM it might be LSB first, but that's IMHO counterintuitive), and MSB first matches directly to the hex nybbles (e.g. C = 1100, not 0011). Anyhow, both have their use…