you wouldn't want data like that though, that's really inefficient/bad 😄
you wouldn't want data like that though, that's really inefficient/bad 
Kthe thing is we often use int vectors in graphics programming to limit imprecision and then cast to floats later when needed for float-only ops, at least in my experience
KIt just makes so much sense for game dev and restricting to the full number + floating point is hard then
KUnfortunately... I'd love if there's be a way to make that efficient automatically
Tyou provide tooling that helps instruct users on how to setup AoS like data systems
Tor which manages it ECS style
KWell... There's ways that make that more 
magic but that's way out of scope and also I don't want to derail this further
magic but that's way out of scope and also I don't want to derail this furtherTeven things like
double in games is generally a sign of "you're doing something wrong"Tand that's largely done because game engines like Unity don't provide tooling or instructions on how to properly handle concepts like floating origin
and world chunking
and world chunking
Tso people naively do the worse thing
KYeah. I'm not that concerned with Vector3<Complex> working well, but I'm somewhat concerned with Vector3<sbyte> at least being viable
TWhat real world scenario is there for a
Vector3<sbyte>?KYou're probably still doing something wrong and Vector3<float> is probably 90% + another like 2-5% being Vector3<Half> but...
Aproblem is, how do you express global positions without using a double. sure, at a local scale, the chunking works absolutely fine, but especially to multiplayer, having a global position is pretty important. i thought about ways of trying to get around it but couldn't come up with anything that worked well.
KConsole games, small cellular automata, that kind of thing
Tyou specify it as a 2 part system
1 is the coordinate of the cell you're in
2 is the position in that cell
1 is the coordinate of the cell you're in
2 is the position in that cell
Toften the coordinate of the cell is integer based, and the position in the cell is floating
Mtanner is right
Tit makes it highly efficient and works well with proper world chunking systems
oct trees, quad trees, binary space partitioning, ECS, etc
oct trees, quad trees, binary space partitioning, ECS, etc
Myou store a chunk position and a position within the chunk
Ai managed to get that working at a local scale, but not a global one. i couldn't find a way to make it work well in a server
the problem wasn't the positioning, it was the physics engine
the problem wasn't the positioning, it was the physics engine
Myou wouldn't want ints for that either!
Ayou'd need to have separate simulations for each chunk, and then that leads to a whole load of problems for when two chunks overlap
Myou need a complex system of constraints
Mthis is a hard problem
Ayeah. the physics engine was the one thing i couldn't find a solution for
Aeverything else worked fine, just not physics
Aany system i came up with had some fatal flaw
Tthat's exactly what you want, you explicitly want to run physics based around the center of each chunk
explicitly so you avoid precision problems
and then you handle the edge case of crossing a chunk boundary specially, often by doing a 2 step simulation in those edge cases
explicitly so you avoid precision problems
and then you handle the edge case of crossing a chunk boundary specially, often by doing a 2 step simulation in those edge cases
Myou won't want to run all those simulations on the same thread anyway
Mso you have to deal with synchronicity
KWell... As long as nothing is bigger than one cell you should be fine
A2 step simulation?
Tit results in a highly efficient and precise system, especially for localized data in the users view
and allows some level of error the farther you are away from the user, where less precision is fine because the visual fidelity is already lost
and allows some level of error the farther you are away from the user, where less precision is fine because the visual fidelity is already lost
Astuff i need to look into, i know nothing about physics engines, i just use bepu and hope that it works
Mi think what tanner means is, do one side against a cached copy of the other side, then the other side against the result of the first one
Athat was another problem i faced, i made my chunks 1x1x1 because i could, and it gave the most amount of precision
but i realized that it would cause even more problems with the physics engine. the problem is in my game is that it's entirely reasonable for something to be larger than one chunk
but i realized that it would cause even more problems with the physics engine. the problem is in my game is that it's entirely reasonable for something to be larger than one chunk
Aunless i make the chunks large enough to cause precision problems
Tnot understanding these examples. none of these would really be working on a
many might work with
Vector3<sbyte> in particularmany might work with
byte[] thoughAalthough i did a fair amount of testing and 20km^3 seemed to not have too many precision problems, and it seems large enough to be the reasonable limit for a single object's size, so i can impose an arbitrary limit that says that something cannot be bigger than 20km in size
Ai see
i think
maybe
i think
maybe
Tone of the neat things about chunking is that when paired with an oct tree
you can make your chunks as fine or as coarse grained as you like
the entire point, in general, is that you have an overall world center
that entire world exists between
you then subdivide that and each sub chunk also exists in their own
you can make your chunks as fine or as coarse grained as you like
the entire point, in general, is that you have an overall world center
that entire world exists between
[-1, +1]you then subdivide that and each sub chunk also exists in their own
[-1, +1] world spaceKIt's fairly reasonable to have a cell use
sbyte for offsets.
Vector2<byte> in either of those to say where on the screen you are. Assuming a simplistic screen-space 2D world here.sbyte for offsets.
Ttypically you end up with a chunk that is pretty small. In minecraft its 16x16m
TIn Skyrim its about a similar size
K(Vector3 also works in automata or maybe as Z index for console games, but irrelevant for this example I think)
Ai see
Ahmm. interesting. there isn't much online about chunking so i just rolled my own system which seemed to work. ideally chunks would be relatively small, but since my game allows for things to be literally massive, smaller chunks could cause big problems for those sorts of objects
Abut if there's ways around that then that's great
Ta two step system is effectively one that acknowledges you're crossing the boundaries between two cells
and so you can either allow some minor loss near the edge
you can compute for both cells, and interpolate
you can compute within the realm of the parent chunk in the oct tree
or you can even create a temporary origin between both and recompute to avoid loss
and so you can either allow some minor loss near the edge
you can compute for both cells, and interpolate
you can compute within the realm of the parent chunk in the oct tree
or you can even create a temporary origin between both and recompute to avoid loss
Toften its some kind of minor interpolation to avoid issues, but it often involves slightly more work than the normal physics processing