Micha Mettke

Tough year so far. Got hit with a triple punch of hard lessons. Each feeding and worsen the others in effect. Took quite a bite out of me. Mentally and physically.

One of them was wasting a year of my life with FBX. An absolute shit file format that should never be used my anyone. Should have pulled a stop way earlier and just use gltf but in combination the overload just didn't let me see clearly for a long time.

Nov 4 at 8:33pmWeb
Show threadNeil HenningNov 4

@vurtun that’s shit man but hang in there.

Sometimes we need the dark to appreciate the light.

Show threadslembckeNov 5
@vurtun Uff. Sorry to hear that. Hope things start getting better.
Show threaddbat Nov 5
@vurtun it happens. One gets tunnel vision and it's hard to shake. Don't be too hard on yourself.
Show threadFeliceDec 13

@vurtun Understandable. You look for standards and often the commercial, proprietary ones seem like they're widely supported, but it turns out that that's only because other people thought the same thing and tried to support them so their app/tool/game would have less friction for its users.

The real win is the dev community coming up with open formats, adopting them widely, iterating on them to make them sound, then pressuring companies to start supporting them and maybe contributing to them.

Show threadMicha MettkeDec 14

@Felice Agree. Just wish formats would be tighten up. Less room for "laziness" on encoding side required to be handled by everyone parsing.

Gltf nails down axis, handedness and unit which is better than FBX free for all. However transformation can have values in ranges different than meter which causes problems with converters expecting values in meter range.

Show threadFeliceDec 15
@vurtun I actually did some thinking on that particular problem a while back and decided the ideal universal unit is the decimillimeter, which is a nonstandard name for the metric unit equal to 1/10th of a millimeter or 1/10000th of a meter. This, because an inch becomes exactly the integer value 254dmm by metric↔imperial standards, so there's no rounding error. Further, divisions below the inch are generally in powers of 2, which means the fractional part of a float or fixed can be accurate.
Show threadFeliceDec 15
@vurtun Unfortunately this does still leave the problem that metric is decimal and thus has rounding errors for parts below the dmm, sigh. But at least at that point, you're talking parts so small that errors aren't significant for real-world objects being modeled.
Show threadFeliceDec 15
@vurtun And no, no, I don't expect anyone to make use of this supposed wisdom. 😓
Show threadFeliceDec 15

@vurtun Oh, I just had an afterthought: It's so sad that an inch turned out to be 254dmm and not 256dmm. It'd be cool if a byte could represent the fractional inch. Oh well.

Mind you the world just needs to switch to metric, ffs, so that none of this matters, ugh.

Show threadMicha MettkeDec 16

@Felice oooh interesting. While writing some of the gltf code I thought about a tiny metric as well. Similar to time with uint64. But I didn't know about the almost 256dmm (254dmm) units for inch and the perfect division below as powers of 2. That is really cool.

Ok at least like you said at that metric below 100 µm we are far beyond reasonable. Would be interesting why no one has done it so far. Even 32-bit integer should be reasonable for it.

Show threadFeliceDec 17

@vurtun The reason no one's ever done something before is often purely reflexive, i.e. simply put, it's literally only because no one's ever done it before.

A lot of problems have only been considered by very small number of people interested in, and capable of, solving them.

Sometimes you just need to get, or 𝘣𝘦, the right person interested in solving the problem.

I always encourage people 𝘯𝘰𝘵 to assume there's a good reason it hasn't been done, and to ask around or try it out themselves. 🙂

Show threadFeliceDec 17

@vurtun By the way, I think heretofore people have mostly been looking to quantize large models' components as optimally and practically as possible, to conserve space, not preserve accuracy.

E.g., on early console hardware like the original Xbox, the Gamecube, the PS2, and technically the PSP as well, it was frequently advantageous to break objects up into local spaces that had barely-tolerable resolution balanced with the size of the space, so fixed-point encodings like X8Y8Z8 could be used.

Show threadFeliceDec 17
@vurtun I think it's only recently, maybe the last 10-15 years, that people have started trying to find ways to represent large domains with both high accuracy and precision. Space sims probably drive a lot of this. I don't know what they use but I would assume a hierarchy of fixed-point spaces that objects move between. That's basically the open-world method, so I assume space sims are like that too. But that's very different from a model file with interop goals, of course.
Show threadFeliceDec 17
@vurtun (Side note: I think you might already know a lot of this, so forgive me if I'm telling the sea about moisture. 😉)
Show threadTom ForsythDec 17

@Felice @vurtun Not sure what you mean by "a hierarchy of fixed-point spaces". Coz that's just long fixed point.

Size of observable universe = 93 billion light years = 9*10^26 meters = 90 bits in meters.

So with 128 bits you can represent that space at about 4 femtometers precision, which is about 8 times the size of a proton. Should be enough :-)

Show threadFeliceDec 17
@TomF @vurtun Because any optimal representation would want to avoid needing that many bits per component. So models only use, say, x16y16z16, x11y11z10, or x8y8z8 local spaces, with just transforms being represented in larger numbers of bits. Even space should be subdivided into sectors, in which each model lives, which in turn are found using the higher bits of the true absolute address. This also lets you use a sparse data structure where only sectors with stuff in them have storage.
Show threadTom ForsythDec 18

@Felice @vurtun Sparse storage - of course. But 128 bits is not very big for world coordinates - just do it.

Whatever model coordinates you use are completely separate. Of course use whatever makes sense, including boring old float32. "Zero" is a useful and well-defined place in model coords.

Show threadFeliceDec 18
@TomF @vurtun I don't think I'd ever use float for models. That would just be lazy and wasteful, plus you could never really be sure about eliminating seams between parts/submeshes unless you deliberately avoided using the full exponent range and/or the full mantissa, at which point just use int/fixed anyway. We solved this problem 25 years ago; there's no reason to bring it back to life and waste (V)RAM. Floats are only for sector-local transforms like physics, particle systems, and T&L stuff.