Ok, this is messed up. 3DGS math isn't accurate at all.
I am trying to get accurate distance between my subjects. I tried doing it the long way first: Code:

---

distance=sqrt((pow(my.z-you.z,2))+(pow(my.x-my.x,2)))

---

using the pythogorian theorum, but the math wasn't making sense. So I searched and found the function vec_dist.. cool..... only not.
ok, the easy one 3^2 + 4^2 = 5^2 so 3,4,5 makes a full triangle:

3DGS gets that right if that's all there is too it. but how often will it all be lined up with the origin. Ball B is at 3,2,3 making it's x and y 3,2 making that line 3.605551 (if it's z was at 0) but 3DGS gets 3.605469.

with the correct number, when we move it up on z the true distance from the origin should be 4.690416 but 3DGS gets 4.689453.

In my actual experiments I couldn't even get the first 3 decimals to match. It works here for some reason though.

any idea why that's happening? I am writing a program to show proof of concept for something and I can't do it accurately if all the math is screwed up.
please let me know what I can do.
(I haven't tried A7 or lite-C) but also don't think I should need to.

thanks

3dgs uses the fixed data type for its calculations, meaning there are 22 bits for the part before the comma and 10 bits for the places after the comma. The precision is about 0.001. However, if you do some computing additional floating point errors will occur. Errors of about 0.01 can occur any time and you can hardly prevent that with c-script. The only thing that comes to my mind is using greater distances, i.e. instead of (3,2,3) you could use (300,200,300).

Additionally you could change to lite-c and use another datatype or write a .dll for this purpose.

zeitwerk's right about all the error stuff, afaik.

with lite-C you could use floats or doubles, and they are MUCH more accurate (i use quaternion calculations a lot and doubles saved me there -- i managed to increase accuracy by about 2500%).

you may know this already but you didn't mention it: if you were calculating them manually you would need more than just the x and z, unless you were making a pseudo-2D game

good luck,

julz

thanks. I probably am going to write a dll for a lot of this stuff. I was thinking of making the entire scale a lot bigger, but I wasn't sure if that would help.
I'll take a look at the quaternion calcuations and see if any of that would be worth it for me to use.
For now I'll bump up my scale and see if that helps, then I'll make the dll.
thanks for the reply.

I had a thought about your problem. I havne't proved it correct, but I guess this should increase accuracy for distances smaller than 1000 quants by at least three decimal points. Try this function:
Code:

---

function vecDist(&vec1,&vec2)
{
	var dist[3];
	vec_diff(dist,vec1,vec2);
	if (vec_dist(dist) < 1000)
	{
		vec_scale(dist,1000);
		return(vec_dist(dist) / 1000);
	} else {
		return(vec_dist(dist));
	}
}

---

that's a good idea, that way I can keep the "physical" scale whatever I want and still have the clarity before doing the actual math.

I was planning on writing a dll for this app anyway, but I'll probably put that in my arsanel for future stuff.
thanks

I'm not sure why a thousandth of a quant is such a big deal, but anyways...

AFAIK, most distance() functions do as Zeitwerk just suggested. They scale down the distance to a more usable range. Imagine if offset xyz = {9999.999, 8402.385, 19305.295}. Squaring all these numbers, adding 'em, and then finding the square root of that large number can be very slow and not 100% accurate. Therefore th numbers are all scaled down by a determined amount. Sometimes those trailing decimals will be cut down a bit...

A calculator doesn't have to worry about time. Games do. In most games the distance between the player an objects is checked every frame by many entities, so the function needs to be fast.

g'day

i don't mean for u to use quaternions (i don't see uses for them here) but to use lite-C doubles and floats they're much more accurate than vars. lite-C's the same as C (almost exactly) and you can access other APIs such as directX or whatever (even OpenGL if you use it in legacy mode) so unless u need C++ or another higher-level language, lite-C will probably vastly reduce your need for dlls.

still, if you're making a dll anyway, i don't see why not just making sure u know other options ^^

julz