09-10-2020, 11:28 PM
Hello,
I was wondering if you could supply a basic spec on how the SoH format is constructed. The spec doesn't need to be super detailed, but information about if it's compressed (and what algorithm is used), general structure of the file like vertex data, then uvs, then index array, then normals, etc.
I tried reverse engineering the format myself but the furthest I got was figuring out that the first 2 bytes were likely a version identifier, next 4 bytes are an int denoting the size of a data blob, and then the rest of the data blob is mostly unknown. There's a good chance that the first 4 bytes of the data blob are also a version identifier but there's no way to really tell. All of the data seems to be strewn about in a way I can't really glean from trial and error, and even something as simple as changing a single vertex changes a ton of the data.
I tried using the designer multiple times but i'm just over it not working the way i want it to, and having to deal with manually texture mapping every individual face since everything is bugged, and it is actually far easier for me to bypass it entirely by creating tools to export/convert from other editors. I would really like to be able to contribute nice looking buildings/ships that other people could use but unfortunately it's just an absolute pain to do anything other than an untextured blob at present.
Ideally it would be nice if you could implement gltf/glb importing as well, since STL is an ancient format that isn't particularly useful for anything, and/or fix the 3DS import to actually properly respect UVs instead of shoving them off way into the corner randomly (although i'd still have to use an external converter to go from GLB->3DS), that would also be great.
Thanks
I was wondering if you could supply a basic spec on how the SoH format is constructed. The spec doesn't need to be super detailed, but information about if it's compressed (and what algorithm is used), general structure of the file like vertex data, then uvs, then index array, then normals, etc.
I tried reverse engineering the format myself but the furthest I got was figuring out that the first 2 bytes were likely a version identifier, next 4 bytes are an int denoting the size of a data blob, and then the rest of the data blob is mostly unknown. There's a good chance that the first 4 bytes of the data blob are also a version identifier but there's no way to really tell. All of the data seems to be strewn about in a way I can't really glean from trial and error, and even something as simple as changing a single vertex changes a ton of the data.
I tried using the designer multiple times but i'm just over it not working the way i want it to, and having to deal with manually texture mapping every individual face since everything is bugged, and it is actually far easier for me to bypass it entirely by creating tools to export/convert from other editors. I would really like to be able to contribute nice looking buildings/ships that other people could use but unfortunately it's just an absolute pain to do anything other than an untextured blob at present.
Ideally it would be nice if you could implement gltf/glb importing as well, since STL is an ancient format that isn't particularly useful for anything, and/or fix the 3DS import to actually properly respect UVs instead of shoving them off way into the corner randomly (although i'd still have to use an external converter to go from GLB->3DS), that would also be great.
Thanks