>>51415508
Every model has a "center" that all points are defined relative to.

If you were dumb enough to repeatedly do low precision transformations, then yes, you will see rounding errors. The normal way to do it is to store the original model and apply only one set of transformations.

not if you translate/rotate the original data every time

>>51415508
Well the way it works is that you load the original model up in memory and apply different transforms to it. So if it is rotating, you rotate it by 0, 1,2, etc.

But yeah if you apply a bunch of transforms after each other you are gonna have problems.

In short, no.

>>51415557
>>51415585

So if I have a skeletal animation does it allways use the original data and applies the transformation from the original data every time/frame anew or does it use the data of the mesh one step/frame before?

are they not a bunch of vectors?

>>51415650
I don't think the amazing kreskin surfs /g/ so you're going to have to answer that for yourself unless you want to supply enough information to answer your question.

All depends on the format, but you pretty much got it.
It's more complicated than "rounding", they use floating point numbers usually, which pretty much means scientific notation for computers. The numbers are stored in a format that looks like
A.AAAA x10^BBB
Of course they don't use base 10, they used binary or whatever instead.

This also means that points farther away from the origin are less precise, but scaling a model up or shrinking it down has little to no effect on the overall precision of the points, since that becomes relative (imagine multiplying a number in scientific notation by 10, it wouldn't effect the significant figures, it would just change the exponant by +1)

...and yes, in theory, a lot of manipulations would cause the model to lose accuracy do to rounding error. It would take thousands to billions of manipulations before it becomes noticeable (depending whether the software uses single floats or double floats)

>>51415656

If you scale down a vector illustration (make it tiny) and scale it up again in Adobe Illustrator it will be fucked up and warped. You might have to repeat a bunch of times to see full effect, can't remember.

>>51415743

hmmm... I don't fully understand them then, thnx

>>51415743
that's because illustrator is not preserving that objects' original 'grid', and instead effectively converting it to a coarser grid

repeating won't make a difference, only scaling it smaller will

>>51415787
>>51415782
it works similarly to a bitmap graphics editor (gimp/paint/photoshop), if you scale down an image, part of the data must be discarded in order to fit in the smaller set of pixels, scaling it back up without the original data at hand results in a 'pixellated' or 'blurred' appearance, depending on scaling method

>>51415508
A common approach is to maintain the original coordinates, and a minimum sequence of transformations to create the current shape. Imagine you just have a single point:


POINT (0, 1, 5)


Then the data structure to keep track of it might be...

POINT (0, 1, 5)
SCALE (2, 2, 2)
TRANSLATE(5, 0, 0)

Then what is rendered on the screen is a point at 5, 2, 10, and you never lose your original data, so rounding errors don't accumulate.

Obviously not every transformation can be represented compactly but this is the approach used by many 3D systems for representing scaling, translation, and rotation.

>>51415508
Renderers get around this problem by applying at most two or three transform matrices to the model when it is rendered (and those matrices can also be pre-multiplied so you end up with a single one.)

You then do a matrix multiplication with each vertex of the mesh and the matrix. This takes in a 3D (actually 4D but we won't get into that) vertex and spits out 2D screen coordinates plus a depth value which will be used by the rasterizer later to build the Z-buffer.

I'm not aware of any common mesh animation scheme where the transformed vertices from the last frame are used as the basis for the next frame. Transform feedback is more designed for things like particle systems than for mesh animations.

>>51415508
Also, some model formats actually use integers for the vertex coords (MD2 uses an 8-bit integer for each axis, where each increment is scaled to 1/256 the size of the bounding box on that axis,) but those are always converted to floats before rendering because GPUs are specifically designed for floating-point math and until recently didn't have integer instructions at all.

Modern formats don't use integers anymore because you can end up with vertex swim (anyone who has looked closely at Quake 2 will know what I'm talking about.)

>>51415508
>After a bunch of times rotating and moving a 3d mesh around wouldnt it start to warp and lose its original form?

You don't modify the original to rotate. You store the rotation+translation in a 4x4 matrix and apply it to your original model. If the rotation changes even slightly then you recalculate the 4x4 matrix and apply it to your original model again.

>>51417397
honestly I loved that effect on the idle ogro of cube 1, and then later sauerbraten, it was sort of charming