Well... As long as nothing is bigger than one cell you should be fine
Well... 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>many might work with
byte[]although 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]
KIt's fairly reasonable to have a cell use
sbyte for offsets.
Vector2<byte>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
Aor you can even create a temporary origin between both and recompute to avoid lossinteresting, this did actually cross my mind but i dismissed it as i didn't think it would work, but on second thought i don't see why it wouldn't work
Tbyte isn't sufficient for most screen coordinates (or even depth space in the world)
but, that's something that a
but, that's something that a
Point2D(not to mention working with byte/sbyte is slow, you really want
intbut it often involves slightly more work than the normal physics processingdoesn't matter how much effort it takes, if it works it works
my big problem was that i couldn't come up with anything that would work, but this has given me some ideas
ill keep researching and coming up with new systems to see if i can get it working. good, performant chunking is absolutely paramount for me
Acheers guys!
KI get the idea about a point type, but I feel like it's more an escape hatch and not really a good solution
TI don't think its an escape hatch, it's good and proper design
Vectors fundamentally have a length, direction, and can be normalized. Those are core and fundamental operations of the type
and features which an integer can't support
Vectors fundamentally have a length, direction, and can be normalized. Those are core and fundamental operations of the type
and features which an integer can't support
TVectors and Points are similar, but different
one is an offset (timespan), while the other is an exact location (datetime)
one is an offset (timespan), while the other is an exact location (datetime)
KThat's the thing I kind of disagree with. Ie cellular automata. I can absolutely calculate the distance to another cell even in this integer world
TYou can then also expose features on Point, like Distance
in a way that works better and is more efficient for integers
namely, Distance is then the manhattan/taxi cab, rather than euclidean distance
in a way that works better and is more efficient for integers
namely, Distance is then the manhattan/taxi cab, rather than euclidean distance
Ti.e. you don't return the hypotenuse, which can't be represented as an integer
Tyou return the stepping amount in the x/y direction as a pair
Twhich is to say, you return the sides required to compute the hypotenuse
KAnd while I agree that we like to think this way, just like with datetime and timespan, really datetime and points are also just kind of an offset that we pretend are absolute
KTthey aren't offsets and aren't intended as such
a DateTime describes a precise point in time, its not variable
a DateTime describes a precise point in time, its not variable
Ta point likewise describes a precise position in an infinite grid of where the center is 0, 0
KImo separating those is more annoying to work with in many corner cases and makes little improvement for the other cases
TI should have clarified
Euclidean vectorim with kai here
Kespecially in gamedev contexts
Kas much as its not rigorously correct
Pcan i throw a gigantic cat into this bag that may make you think harder
TI hard disagree here (but of course, its ultimately not my engine)
You are basically pushing yourself into the same buggy holes that make most C/C++ engines terrible
and why most people complain about these concepts everywhere else
You are basically pushing yourself into the same buggy holes that make most C/C++ engines terrible
and why most people complain about these concepts everywhere else
KAnd vector describes a pointer from some origin (often 0,0) to somewhere. You can also think of it as a pointer between to geometrical positions but...
And it's the same with datetime, it's "absolute" in that we all agree that it's relative to some origin, just like the 0,0 of the proposed integer point type
And it's the same with datetime, it's "absolute" in that we all agree that it's relative to some origin, just like the 0,0 of the proposed integer point type
Tseparate the concepts and help your users achieve success
Pwhat if we added colour APIs, these are typically done with """vector""" types (see unity)
Pthese are very much not a euclidean vector
Kpoint and vector arent fundamentally different concepts theyre different representations of the same concept
Tsee reasons why the BCL designed and approved a separate type for
Colorwhich is a rank-1 dimension-N list of scalars
