Well, from the technical point of view of the header of the post, it can’t be solved as it would’ve meant to migrate vector used for engine transform position to Float 64/Double
That’s a fair perspective. Though I feel like it can change depending on context and intent. A troll could easily mark misinformation as a solution, for example.
OP is touting their solution posts as fact when they have zero proof to back it up. I feel like that degrades the quality of the forum and feel as if it should be unmarked.
Though if moderation/Unity staff want to make a clear ruling I’ll have no issues with that.
Okay I lost. it seems there is no problem in a new empty project, which is double strange given i made an empty new test already before and had the issue.
Maybe something was corrupted on my side or it was an issue of older specific version, 6.3 seems to work fine?
you won it turned out to be some kind of tech problem on my side, regarding the 2500 meters whine at least
Here is the working code, it seems the extra calculations and screen to point things or smth maybe was the problem after all:
using UnityEngine;
public class LateUpdateCamRefMoveToHitPos : MonoBehaviour
{
public GameObject GameObject;
private void LateUpdate()
{
if (Physics.Raycast(transform.position, Vector3.forward, out var hitInfo))
{
GameObject.transform.position = hitInfo.point;
}
}
}
Tested in regular update also, works still fine.
Just put it on camera.
So the solution to such problems is strip down all the unnecessary calculations, I guess
Tested on 100 000 also works quite fine even in just Update(), beyond is yellow warning in inspector about float precision so no point further, as it is obviously bad to let player go beyond that
It’s not about winning or losing, it’s about realizing that things that are impossible and never happen to anyone else happen to you not because of someone else’s fault, Unity’s, a tool’s, or anything external, but because there’s something you did wrong. This would have saved you two months of development time.
Instead of making excuses like “there’s a difference between theory and the real world”, “it’s an issue that happens only to me”, or any other claim that blames something external, especially when people are telling you it’s not, start with a different question. Don’t ask what is wrong, assume that you are wrong and focus on finding out why.
The forum is full of posts from people who believe they’re right and assume there must be a bug or that the theory doesn’t apply to them, even in the simplest cases, like “the for loop is bugged in C#” or “GetComponent doesn’t work”. That mindset is the worst thing for productivity: not only do you fail to move forward, but you also delay or completely miss learning from the mistakes you’ve made.
Though it is healthy reaction thinking something is wrong
(but whining in the process and working in the wrong directions is questionable maybe, more a psychology question. Yet, I guess it was very stupid from outside perspective)
, especially for amateurs, and considering most people who stumble upon Discussion that way, when understanding game dev literally requires all skill sets ran away (I think).
In my head I had evidences (though they are also text only ones too) of not recommended practices and tests when visuals get distorted when falling under map/level, so I assumed the FloatingOrigin is the only way.
Don’t know about other people, but being blatant and wrong in the end, disqualifies putting the first reaction “something is wrong” on the technical aspect of a precision, I guess.
The root of this was not understanding that cause and effect are two different things. Just seeing an issue doesn’t actually tell you what the root of the issue is.
You seemed more focused on arguing with more experienced users than you were at actually trying to uncover the root of your problem.
In the end you just wasted everyone’s time, including your own.
I’d say it is one of the roots, the emotional state is awful when working with AI assist too much, basically already having to describe most key details anyways, and last two weeks waking up was also awful, started recovering only today, plus I’m overall anxious person, even little triggers like physically pulse through me when I’m anxious already, plus social isolation.
Plus one on being not careful in extracting useful directions from replies (especially during process 2 months ago) can be admitted to the root you’ve described.
You are going a step too far with that “root cause”, lol.
You should just find the cause of the bug, because that’s a task you need to get used to no matter how the code comes to be.
Technically it was a combination of two problems, objectively yes it was unoptimized code problem and relying on what AI spits out, solution is above, btw, marked.
Strange that there is no button to open it in one click, at least I didn’t find
Floating point data types store real numbers in a way that makes it impossible to store every number correctly. Some numbers will be stored correctly in their entirety, but some will only be stored approximately with some error, and the number doesn’t have to be large or even outside the range of precision (ie 7 digits for single precision) for that to happen. For example “1.02” is really “1.019999980926513671875”. You can see this with the following visualizer.
When you perform math operations on floating point numbers you’re taking the final result and saving it back into a floating point data type, and since the data type can’t perfectly represent every real number you end up compounding errors on top of errors with every math operation you perform. If it helps think of it like saving a JPEG. That first time the image might look just fine but with each additional save the artifacts build up until they start to become visible. If you do it enough they will eventually make it impossible to even see the original image.
The 0.1 example is fundamentally a base-representation issue: some decimal fractions (like 0.1) cannot be represented exactly in binary, so floating-point must approximate them. Floating-point arithmetic then introduces additional rounding error due to finite precision, but the initial inexactness comes from the base-2 system, not from floating-point arithmetic itself.
Computers use base-2 (binary), not base-10. In any base system, only fractions whose denominator’s prime factors divide the base can be represented exactly.
In base-10, the prime factors are 2 and 5. Therefore, fractions whose denominators contain only 2s and/or 5s can be written exactly:
- 1/2=0.5
- 1/4=0.25
- 1/5=0.2
- 1/8=0.125
- 1/10=0.1
But numbers like 1/3 cannot be represented exactly in base-10:
- 1/3=0.3333…
In base-2, the only prime factor is 2. So only fractions whose denominators are powers of 2 can be represented exactly:
- 1/2=0.1
- 1/4=0.01
- 1/8=0.001
But values like 1/5 and 1/10 cannot be represented exactly in binary:
- 0.1=0.0001100110011…
The infinite expansion of 0.1 in binary is a mathematical inevitability of base-2 systems, not specific to floating-point representation.
There was dividing in the problematic code of the screen width, height by 2 (as I remember) to get the raycast origin point from camera, I don’t know why it was even used in the GPT output, given asked separately it doesn’t do such strange calculations, maybe it got obsessed with from camera screen casting instead of transform forward.
Anyways given the topic is brought again, I remembered that I also already have a package to support and it had initially almost infinite capabilities plan.
Bonus fact: The topic wasn’t even about bugfixing, so the above last two messages are more about floating point again, actually.
Probably I wouldn’t suffer much if there was Double in the engine, as I was ready to limit map boundaries.
P.S.
Thinking of volume based basic level editor for quick rooms, corridors, doors, stairs, ladders.