(Big worlds) Will ever a Built-In solution for Float Precision Loss be?

News & General Discussion
21

Remember, it’s not also just one float to put your graphics onscreen. It’s matrices of floats, cascaded at least several layers down even with a single GameObject, before you can see it.

Let’s see… just a stream of consciousness here… I’m sure I’m leaving out a TON of stuff… an individual vertex in your graphics, multiplied by xyz scale, multiplied by xyzw Quaternion rotation, added to the GameObject’s Transform position, then subtracted from the Camera’s Transform position, also multiplied by xyzw Quaternion rotation, and then the projection computation, another matrix operation, before finally you arrive at a final pixel answer.

Is your camera part of some rig, perhaps part of your spaceship with many parent Transforms? What about your spaceship? Is it one GameObject or a hierarchy of different ones? Each step is a full Transform matrix multiply operation.

Every one of those steps is sourcing some floating point imprecision and jitter, and that’s going to contribute to much more effective jitter much sooner than just putting a number into a float, adding to it, then pulling it out.

22

It is possible to have jitter at 9000 units if you’ve made a gameObject a child of the camera. Anybody that has tried to create a UI or crosshair using regular gameObjects would’ve spotted this. The solution is to either use one of Unity’s GUIs or render the gameObjects on another camera that’s always at 0,0,0.

23

That is what I mean when I say the problem isn’t Unity, but the programmer, when issues appear at distances as small as 1,000–9,000 units. The same applies to the points Kurt mentioned, along with basics like understanding that calculating a vector’s magnitude involves squared components, or using raycasts instead of spherecasts over long distances.

None of these are caused by Unity lacking double precision support. They’re programming issues, knowing how to design correct algorithms that respect mathematical constraints instead of stacking operations together and then complaining that the result is broken and not your fault, such as moving a transform in FixedUpdate or enabling an object before adjusting it.

Even if Unity added full double precision, sloppy code would only push the symptoms a little farther out. No hardware feature compensates for poor programming. The worst part is refusing to recognize this, insisting the code is fine, and blaming something else because theory != practice. Excuses replace problem solving, and they become a convenient way to avoid learning how to write correct code.

Because in the end, the discussion is focused on blaming Unity for these issues rather than improving the code to solve them.

24

you can always just put here literally 50 lines of code that supposed to run at 9000.

I tried everything you guys suggested, removing literally everything using only LateUpdate() gets the exact same problem at 9000. The object also originally was unparented, nothing changes, commenting scale - nothing changes, commenting setactive and it is by default active on scene - nothing changes.

Even if i would cast sphere, surprise nothing changes, because it is still casting, conceptually pretty much the same, as spherecast considered by some as “thick raycast”.

Anyways as i also mentioned, if you too was paying attention instead of making up things about me blaming Unity you would notice that i dont have problems with brush now, as i use one of proper solutions for “infinite” worlds, which never gets player in world coordinates to 9000 (nor 1000 if threshold is lower).

P.S.
As a bonus i can only say, no one argues that Unity is crap in this use case, but it still occupies it by being popular and rather syntax friendly, migrating to other engines
(which aren’t also easily AI code generative)
just because of this for indie godforsaken game is more time-consuming than dealing with “infinite” world problems the crutch ways

25

Well spoken sir.

26

A bit off topic, but here is a IEEE 754 “visualizer” IEEE-754 Floating Point Converter where you can find out the precision for various ranges. In your case for 9000 units, the decimal precision is around 0.001. In another words, for instance difference between 0x460ca003 (9000.003) and 460ca002 (9000.002) is 0.0009765625.

27


Oh-ho.
It also seems it is an engine problem after all in the Default Technical Abilities part after all.

Same dumb straight code concept, but C++ - works, and doesn’t jitter for a second on any movement made even at Unreal’s 4: 500 000 centimeters, which is even MORE than it gets completely unacceptable in Unity at its 2500 meters.

P.S.
Though I regret dipping into Unreal not prepared and before supper, even the blueprints in there felt lower level than any Unity C#, lol.

Conclusion:
If someone needs to build a big, but finite world, without messing with FloatingOrigin and its downstakes - Unreal is one of the choices, though despite hearing the 4th one can robustly compile for Web, it isn’t there by default in 4.27.2 it seems.

(and yes, Unreal by default has annoyances even bigger than Unity Domain Reloading, in that sense.
And it is easier to break the project, ruined the testing first one.
In Unity it is possible to open scripts right after creation, to not wait compiling, by double Enter)

Here’s the generated working Class (2 files) to move to hit pos for Unreal
to prove it is not a crutch bypass:
.cpp:

#include "SimpleFollower.h"

USimpleFollower::USimpleFollower()
{
	PrimaryComponentTick.bCanEverTick = true;
}

void USimpleFollower::BeginPlay()
{
	Super::BeginPlay();
}

void USimpleFollower::TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction)
{
	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);

	if (UWorld* World = GetWorld())
	{
		if (APlayerController* PC = World->GetFirstPlayerController())
		{
			FVector CamLoc;
			FRotator CamRot;
			PC->GetPlayerViewPoint(CamLoc, CamRot);

			FVector End = CamLoc + (CamRot.Vector() * Distance);
			FHitResult Hit;

			if (World->LineTraceSingleByChannel(Hit, CamLoc, End, ECC_Visibility))
			{
				if (AActor* Owner = GetOwner())
				{
					Owner->SetActorLocation(Hit.Location);
				}
			}
		}
	}
}

.h

#pragma once

#include "CoreMinimal.h"
#include "Components/ActorComponent.h"
#include "SimpleFollower.generated.h"

UCLASS(ClassGroup = (Custom), meta = (BlueprintSpawnableComponent))
class YOURPROJECT_API USimpleFollower : public UActorComponent
{
	GENERATED_BODY()

public:
	USimpleFollower();

protected:
	virtual void BeginPlay() override;

public:
	virtual void TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) override;

	UPROPERTY(EditAnywhere, BlueprintReadWrite)
	float Distance = 5000.0f;
};

P.S.S
Yes, I’m that obsessive after a long time when research idea sticks with an unanswered question in my understanding.
Though this code is fully AI generated and I was very idiotic at pseudo-coding in first project, which building died, probably that much, I could just carefully read the docs or smth, if I had ANY patience at the moment, and achieve same with same speed.

28

I can’t say why it isn’t working for you in Unity, but I’ve been involved in many projects where this was not an issue at such small distances, both personal and team projects, so it’s definitely not an engine problem.

If Unreal works for you, then by all means use it. I just don’t see why posting C++ Unreal code would interest anyone on the Unity forums.

29

Okay, at least some level of agreement.
Strange so you actually tried to move object to raycast hit pos in any Update()s standing at x: 2500 and more meters and didn’t had any issues? If possible, please record a 10 second .mov some time.

(For everyone: Skip text below, blind guesses and P.Ss)

I even tried to open a new project during active discussion, place things to same distance on one axis and just cast a ray from an empty object and move at hit pos the cube primitive, still had the issue.

Maybe something is wrong with newer versions or it is more common in URP Forward for some reason.
I completely don’t get why such simple code is such jittery for about a second and only at high distances in Unity.

But it is definitely some kind of precision problem, even if not float obvious one, or it would bug the same near origin.

My last guess is that Unity Raycasting is less robust
(if you really never had such issue with same/similar logic and its not false memories)
than Unreal’s one, if its not a Float only problem, as the problem is not only with moving models, but also with executing logic at the position, which constantly distorts to the same place as the cube/any gameobject, thus making impossible proper voxel destructions and decals.

By the way the suggestion of making a fake space close to origin from other guy sounded interesting, though it would’ve fixed the preview issue only, real position for modifications is still needed, though if its not float precision issue, I guess it’s possible to convert it without jitter to the high value for each axis.

Anyways, mentioned solution to make it real seems to be way too sophisticated and just wrong, not even a crutch, things tedious and the potential end project image didn’t look good and I dropped the project for multiple other reasons also.

P.S.
I guess given the extra overhead to just to be able to receive any dollars and at the same time analogous platforms almost dead, I should just polish at least the inventory system that I made manually without AI to be more proper for the Unity Asset Store and make it Free asset.

At least some constant “online” will happen on the separate thing I made, and it’ll not be auto-deleted because of low activity…

And I probably need to stop forever doing useless posts (given I have 2 shitpost accounts on YT anyways) on a kinda serious forum, though given activity is low here, maybe better than nothing, still not a biggest concern.

P.S.S
Okay, now literally all popular not region sites for games are dead in my place, amazing!
Newgrounds still work, though.
The Bingo of not possible to publish & keep, even a free game on any platform by default means is almost filled completely.
I should just become a professional hypocrite and a liar at this point and get a Middle job, I.g., I didn’t overgrow any full-fledged, even mobile project anyways.

30

It is an engine problem if the dumb/straight way doesn’t work, but same work in other engine and probably projects you worked on wasn’t that idiotic to let player go beyond 500-2500 meters, they were scene separated or not using raycasting for/or similar mechanics beyond it or didn’t needed precision of it.

It is definitely not definitely at least and at max bunch of other info.

I agree on being ignorant during active topic phase, but I was busy trying things and no one debunked this particular problem, still, and just in case I’m reminding I’m not the “hate engine” gang, I don’t have such issues with everything else happening in Unity.
I hoped the previous text btw, pointed out not a migration, given minuses, but I guess “Strong” (bold) to the text still pushed in the wrong direction.

Concluding the topic - Never, as the question is a bit incorrect, especially regarding to the real problem, and only solution is to be Double or Float 64, which is Double in C#. (to make it viable by default, excluding FloatingOrigin by the game dev himself)

Or the optimistic - if the architecture will be upgraded, ever.
(which is very low probability as such newer version will ruin compatibility, though maybe the cancelled Unity 7 was meant to ruin it kinda, even if not about transform positions being Double.)

31

I don’t understand why you think it’s an engine problem when I, teams I’ve worked with, and many other people don’t have this issue at such small distances. But sure, blaming something or someone else is always the easy way out.

In any case, keep thinking that way: that if you can’t do something with a tool when many other people can, it’s not a skill issue but the tool’s fault and that some other tool is better. The forums are full of people who think like that, so one more won’t make any difference. I’m sure many great game developers have made amazing games using that kind of thinking. Good luck with your project, you’re certainly going to need it.

32

Many different ways floating point precision can show up. I had to use stacked cameras. For a game with a high-power sniper rifle that could shoot 2000 meters. I needed three cameras at 60x zoom.

Having stacked cameras makes arbitrary rotations hard.

33

the reply above of other guy also answers your question why.

Maybe if I would’ve changed methods to cast only when needed and once per time, which would change end user response it would be not noticeable much, but it is limitation then, and if I needed to make own snapping and just snap both preview and edits in a custom grid - it is a crutch.
Whole point of Engines to make the creation process easier and give abilities.
I don’t know what kind of arguments you do need if other people also having issue and I pointed that out even before this reply.

Maybe the core issue in my case was accumulating issue because the whole concept of using any kind of Update(), but just imagine 2 devs one of which need to solve bunch of other things, even if the particular problem i had is easy solvable, and the imaginary Unreal dev - which don’t have such issue.

Maybe Unity in such theoretical “2 devs 2 engines” case would still compensate with C# and faster iteration speeds, it still doesn’t fully push down engine responsibility being limited.

If Unreal even 4th really uses also World shifting underhood by default it would’ve been nice to see it in Unity, even if Vectors would still be FP32, but probably Unreal does both for a reason, and it is wet dreams.

To prove your point really, open up Unity, do the thing on 2500 meters, put code here, record 10 sec .mov or just rename the ‘.’ extension to it.

You bring zero evidence and much blame, being overprotective of the same phrase “Not engine fault”, I agree my stuff is idiotic, but sometimes it reaches Middle, if you expect most devs to be perfect, considering most devs haven’t even earnt minimum payout limit - I don’t know what you want then and with what I should agree, nor do, if I’m far from Senior.

From my part I can only try Godot, it has the same FP32, if it doesn’t have the issue, it is a very confirmed Engine limitation, I don’t know maybe you don’t like the text with “fault” one, but I’m not even the first who brought the more Reddit rhetoric that means the same in my opinion as “limitation” in this context, as I remember.

34

And just in case, there never was direct blaming the tool/engine section, if literally being angry about basically a SINGLE variable type which is used in engine is blaming the entire engine and tool, you just have some kind of trigger about that.

If you still missed that I fixed my problem during topic, I did the FloatingOrigin and stopped having the issue, though it is just a bypass/crutch, basically, so I don’t understand the skill/composture issue part thing - either.

Tbh, i don’t even know what is the argue now about and why are you pushing so hard about the definition of my character, I’m indeed a negative person, but always and in personal life also, not with a single feature only.

Btw, all full game projects is dropped anyways, so no luck needed also.
But okay I guess that is just how internet works (concentrating only on negative parts) and maybe some context loss also.

35

Marking the solution cancels for some reason, maybe because it is low quality or can be marked as insufficient by other ppl, etc.

So ppl can go to initial edited post, it is bloated (despite the try back then to compress it), but covers pretty much at least a one way to manually avoid any kind of Float Precision problems, also covering Voxel Terrain a bit.
(though I don’t recommend going the too much AI in the end, the speed in exchange for immense pain is not worth it).

In short - FloatingOrigin, especially if infinite procedural generation is needed.

As extra info I forgot to mention, given World-Building was discontinued, probably we shouldn’t wait any improvements in max robust distance, or that kind of stuff, either.

36

I’ve been unmarking your posts as solution as they’re just nonsense and no one should be taking what you post as a solution.

To be fair you’ve also posted zero video evidence of the issue, nor provided an example scene for anyone to analyse.

You have the burden of proof here, not us. So until you prove the issue and provide a demonstration of such for examination, nothing you say carries any truth as of yet.

37

okay i’ll record the Unity one also now, here the Godot for now.
Turned out it is Float 64 also, so okay the tech debate on my side is lost 2/3, if we dont consider FP32 a problem in Unity

38

You also need to post your example as a .unitypackage for analysis.

A video of the issue doesn’t prove what the issue is, only that there is an issue.

39

okay im wrong, Godot 4 is Float 64 already, so not fair kinda, edited prev one

40

In that regard, I have decided to treat posts marked as “solution” as meaning the topic is resolved for the original poster. This is a recurring issue that irritates me and keeps me wondering whether I should unmark certain solutions. Someone posts a question like:

  • Why can’t I fly by waving my hands?
  • Different people reply by explaining gravity.
  • Then the OP marks one of their own replies as the solution, usually something completely nonsensical, saying something like: “It’s not possible because I’m a Virgo, and according to astrology Virgos interfere with Saturn being aligned with Jupiter, which makes flying impossible.”

As irritating as that is, I’ve decided to treat “solutions” as meaning the issue is resolved for the OP, not as a real solution for anyone else reading the topic. Still, it would be good to have an official answer on this: how should we treat “solutions” that aren’t actually solutions?