+- Hazeron Forums (https://hazeron.com/mybb)
+-- Forum: Shores of Hazeron (https://hazeron.com/mybb/forumdisplay.php?fid=1)
+--- Forum: Design Studio (https://hazeron.com/mybb/forumdisplay.php?fid=19)
+--- Thread: Requesting the spec for the SoH format (/showthread.php?tid=2443)
Requesting the spec for the SoH format - xelivous - 09-10-2020
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
RE: Requesting the spec for the SoH format - danthemanisme95 - 09-11-2020
STL format is valuable because of 3D Printing. If you go to any 3D printing file exchange site such as https://www.thingiverse.com/ you'll find thousands of spaceships, buildings, and various other creations just waiting to be imported and "Decked Out." Its value to players and content creators for in game design has yet to be fully realized.
RE: Requesting the spec for the SoH format - QuakeIV - 09-12-2020
I have no objections to the STL thing just because a lot of models meant for 3d printing appear to be STL which provides a rather large supply.
RE: Requesting the spec for the SoH format - Raymoo - 09-15-2020
I also wish it was easier to get good texture unwrapping or UV importing. It seems like the hardest thing to get good results with in the Designer, particularly when you have connected faces that are not coplanar and don't fit neatly into one of the available projections.
RE: Requesting the spec for the SoH format - Interfect - 10-16-2020
(09-10-2020, 11:28 PM)xelivous Wrote: 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've worked out that the files are compressed and I think checksummed with a trailing 4-byte checksum, which is why so much of the data changes when you change just a tiny bit of the design, and why editing just 1 byte makes the modified file not open. The underlying compression is using QT's qCompress/qUncompress functions, but I tried feeding the whole blob with and without the length prefix and checksum to qUncompress and qUncompress just always said the data had been courrupted (presumably because the checksum didn't match). So I think Haxus's wrapper function (which seems to be called AuUncompress) is doing some other transformation before qUncompress-ing the blob.
If someone can work out what that is (or if Haxus cares to share), we can write a tool to dump the actual design data from a compressed file and start working out how things are represented.
If anyone happens to have a debug build of the client laying around that I could borrow, that might help speed things up.