@Korzalerke2147483647 Also, bookmarked the video. May or may not watch at a later date, I'm usually far more busy than someone of my boringness has any right to be.
Oh yea, also. If you make a cannon shooting stuff at a billion lightyers per second, just set the recoilForce to 0, unless you switch to the bullet camera, yea, you would get black
@XtarsTheExdarichGuy33106 game probably is too fast to think, like trying to catch a bullet shot straight ahead of you, if its slower you would catch and not die or generate those black polygons, and if you didnt catch you die and get those black polygons.
The farther you go (the closer the gun) the harder it is to catch it.
The faster you go (the faster the bullet) the harder you catch it.
If you go fast, but in the Region you would able to catch (bullet slows down due to distance and resistances) you will not get black polygons.
If you are far, but go slow (gun is extremely close but bullet travels really slow) you can catch it, and dont get black polygons
Remember, this is an insultingly simplified version, may not be correct. Im just a HJSON coder, not a JAVA coder used in Unity (which is the game engine for SimplePlanes)
The appearance of black polygons at high speeds and extremely far distances in Unity games might be due to precision issues in floating-point arithmetic. Unity uses 32-bit floating-point numbers to represent positions in the game world, and at great distances, the limited precision can lead to inaccuracies.
To mitigate this issue:
Use Double Precision:
Unity uses single-precision (32-bit) floating-point numbers by default. You can explore options or plugins that allow the use of double-precision (64-bit) numbers, which provide greater precision for distant calculations.
Implement Streaming and Level of Detail (LOD):
Instead of rendering the entire scene at once, consider implementing streaming techniques where only nearby objects are rendered in high detail. Also, use LOD systems to reduce the detail of distant objects.
Adjust Physics and Time Scale:
If the issue is related to physics calculations, consider adjusting the physics time step or time scale. This can sometimes alleviate precision problems during rapid movements.
Check Shaders and Rendering Settings:
Certain shaders or rendering techniques may not handle extreme distances well. Experiment with different rendering settings and shaders to see if any specific configurations contribute to the issue.
Use Floating-Point Workarounds:
Some developers implement workarounds, such as periodically repositioning the player closer to the origin to reset the floating-point precision. This can be done carefully to minimize player impact.
Keep in mind that handling extreme distances and high speeds in game development often involves finding a balance between precision and performance. Experimenting with the suggestions above can help identify the most suitable approach for your specific game requirements.
The appearance of black polygons at high speeds and extremely far distances in Unity games might be due to precision issues in floating-point arithmetic. Unity uses 32-bit floating-point numbers to represent positions in the game world, and at great distances, the limited precision can lead to inaccuracies.
To mitigate this issue:
Use Double Precision:
Unity uses single-precision (32-bit) floating-point numbers by default. You can explore options or plugins that allow the use of double-precision (64-bit) numbers, which provide greater precision for distant calculations.
Implement Streaming and Level of Detail (LOD):
Instead of rendering the entire scene at once, consider implementing streaming techniques where only nearby objects are rendered in high detail. Also, use LOD systems to reduce the detail of distant objects.
Adjust Physics and Time Scale:
If the issue is related to physics calculations, consider adjusting the physics time step or time scale. This can sometimes alleviate precision problems during rapid movements.
Check Shaders and Rendering Settings:
Certain shaders or rendering techniques may not handle extreme distances well. Experiment with different rendering settings and shaders to see if any specific configurations contribute to the issue.
Use Floating-Point Workarounds:
Some developers implement workarounds, such as periodically repositioning the player closer to the origin to reset the floating-point precision. This can be done carefully to minimize player impact.
Keep in mind that handling extreme distances and high speeds in game development often involves finding a balance between precision and performance. Experimenting with the suggestions above can help identify the most suitable approach for your specific game requirements.
@Graingy It's more or less that, since computers don't have infinite memory, floats can't represent every number, so they represents some of them and rounds the ones they can't.
Floats reserve more memory for really tiny numbers, so consequently they can't represent many of the really big ones, and so you need to round more often for those.
This is a problem for really precise stuff like calculating positions of polygons since the game can render polygons at coordinates 0.0000235 and 0.00004724 fine, but then you get to position number 29489359928384783395.0 and floats might not be able to represent that, so it rounds to the nearest coordinate it can represent which might be several kilometers away.
That's what causes all the weird gaps as you get farther and farther away from the center of the world (coordinates 0,0,0). There's a video on youtube explaining floating point numbers, I'd recommend you watch it if you want to understand this better.
Anyways, the computer doing actually know where things are closely enough to draw things properly.
If a better computer person sees thing and knows better, I would love to be corrected and learn something new!
@Yish42
Neither do I.
So, for the sake of simplicity, you have 6 digits.
0000
You need to mark a position, lets say something 5 meters from a the "center" or whatever it is.
so, 0005.00
10 meters?
0010.00
100 meters?
0100.00
999 meters?
0999.00
9999 meters?
9999.00
But what if you want to mark something as 10,000 meters away? It's only one more than 9999, but it needs another digit.
What I believe happens in a floating-point error (note, I have no researched this, this is just common sense and some stuff I think I heard ages ago. I could be wrong) is it either has to round, or cut off numbers.
10,000 must be turned to 10000.0
If 10,000 actually had a few extra millimeters, say 5 (10,000.05) those millimeters would be lost. The computer would forget they exist, or it might(?) round up one or so I think I've heard.
Again, I don't know this for certain, I could be wrong. Do your own research, I'd suggest.
Anyways, it stops measuring distance in millimeters and starts doing it in centimeters. Then meters. Then tens of meters. Then so on and so forth.
I think.
some black polygon? 
even more polygon 
white polygon 
a new design for wright airport!
@PlaneFlightX very average sp behavior ☠️☠️☠️
I wanted to recreate this but instead SimplePlanes ate my CPU
@Korzalerke2147483647 Also, bookmarked the video. May or may not watch at a later date, I'm usually far more busy than someone of my boringness has any right to be.
@Korzalerke2147483647 Yay I got something sort of right for once!
Yippee!
@XtarsTheExdarichGuy33106 Well, at least you admitted it. I'd suggest putting that in the original comment next time, however.
Oh yea, also. If you make a cannon shooting stuff at a billion lightyers per second, just set the
recoilForceto 0, unless you switch to the bullet camera, yea, you would get black@Yish42 yes, cant simplify wikipedia that much. Have somebody to work? Use it when you can
@XtarsTheExdarichGuy33106 dude are you using chatgpt
@XtarsTheExdarichGuy33106 game probably is too fast to think, like trying to catch a bullet shot straight ahead of you, if its slower you would catch and not die or generate those black polygons, and if you didnt catch you die and get those black polygons.
The farther you go (the closer the gun) the harder it is to catch it.
The faster you go (the faster the bullet) the harder you catch it.
If you go fast, but in the Region you would able to catch (bullet slows down due to distance and resistances) you will not get black polygons.
If you are far, but go slow (gun is extremely close but bullet travels really slow) you can catch it, and dont get black polygons
Remember, this is an insultingly simplified version, may not be correct. Im just a HJSON coder, not a JAVA coder used in Unity (which is the game engine for SimplePlanes)
The appearance of black polygons at high speeds and extremely far distances in Unity games might be due to precision issues in floating-point arithmetic. Unity uses 32-bit floating-point numbers to represent positions in the game world, and at great distances, the limited precision can lead to inaccuracies.
To mitigate this issue:
Use Double Precision:
Unity uses single-precision (32-bit) floating-point numbers by default. You can explore options or plugins that allow the use of double-precision (64-bit) numbers, which provide greater precision for distant calculations.
Implement Streaming and Level of Detail (LOD):
Instead of rendering the entire scene at once, consider implementing streaming techniques where only nearby objects are rendered in high detail. Also, use LOD systems to reduce the detail of distant objects.
Adjust Physics and Time Scale:
If the issue is related to physics calculations, consider adjusting the physics time step or time scale. This can sometimes alleviate precision problems during rapid movements.
Check Shaders and Rendering Settings:
Certain shaders or rendering techniques may not handle extreme distances well. Experiment with different rendering settings and shaders to see if any specific configurations contribute to the issue.
Use Floating-Point Workarounds:
Some developers implement workarounds, such as periodically repositioning the player closer to the origin to reset the floating-point precision. This can be done carefully to minimize player impact.
Keep in mind that handling extreme distances and high speeds in game development often involves finding a balance between precision and performance. Experimenting with the suggestions above can help identify the most suitable approach for your specific game requirements.
The appearance of black polygons at high speeds and extremely far distances in Unity games might be due to precision issues in floating-point arithmetic. Unity uses 32-bit floating-point numbers to represent positions in the game world, and at great distances, the limited precision can lead to inaccuracies.
To mitigate this issue:
Use Double Precision:
Unity uses single-precision (32-bit) floating-point numbers by default. You can explore options or plugins that allow the use of double-precision (64-bit) numbers, which provide greater precision for distant calculations.
Implement Streaming and Level of Detail (LOD):
Instead of rendering the entire scene at once, consider implementing streaming techniques where only nearby objects are rendered in high detail. Also, use LOD systems to reduce the detail of distant objects.
Adjust Physics and Time Scale:
If the issue is related to physics calculations, consider adjusting the physics time step or time scale. This can sometimes alleviate precision problems during rapid movements.
Check Shaders and Rendering Settings:
Certain shaders or rendering techniques may not handle extreme distances well. Experiment with different rendering settings and shaders to see if any specific configurations contribute to the issue.
Use Floating-Point Workarounds:
Some developers implement workarounds, such as periodically repositioning the player closer to the origin to reset the floating-point precision. This can be done carefully to minimize player impact.
Keep in mind that handling extreme distances and high speeds in game development often involves finding a balance between precision and performance. Experimenting with the suggestions above can help identify the most suitable approach for your specific game requirements.
@Graingy It's more or less that, since computers don't have infinite memory, floats can't represent every number, so they represents some of them and rounds the ones they can't.
Floats reserve more memory for really tiny numbers, so consequently they can't represent many of the really big ones, and so you need to round more often for those.
This is a problem for really precise stuff like calculating positions of polygons since the game can render polygons at coordinates
0.0000235and0.00004724fine, but then you get to position number29489359928384783395.0and floats might not be able to represent that, so it rounds to the nearest coordinate it can represent which might be several kilometers away.That's what causes all the weird gaps as you get farther and farther away from the center of the world (coordinates 0,0,0).
There's a video on youtube explaining floating point numbers, I'd recommend you watch it if you want to understand this better.
Anyways, the computer doing actually know where things are closely enough to draw things properly.
If a better computer person sees thing and knows better, I would love to be corrected and learn something new!
@Yish42
Neither do I.
So, for the sake of simplicity, you have 6 digits.
0000
You need to mark a position, lets say something 5 meters from a the "center" or whatever it is.
so, 0005.00
10 meters?
0010.00
100 meters?
0100.00
999 meters?
0999.00
9999 meters?
9999.00
But what if you want to mark something as 10,000 meters away? It's only one more than 9999, but it needs another digit.
What I believe happens in a floating-point error (note, I have no researched this, this is just common sense and some stuff I think I heard ages ago. I could be wrong) is it either has to round, or cut off numbers.
10,000 must be turned to 10000.0
If 10,000 actually had a few extra millimeters, say 5 (10,000.05) those millimeters would be lost. The computer would forget they exist, or it might(?) round up one or so I think I've heard.
Again, I don't know this for certain, I could be wrong. Do your own research, I'd suggest.
Anyways, it stops measuring distance in millimeters and starts doing it in centimeters. Then meters. Then tens of meters. Then so on and so forth.
I think.
@Graingy i dont speak in programer, can you explain to me in simple?
"That" as in going from a far-out view point back to, say, the KSC.
Usually an issue from craft on a interstellar/kraken launched path.
@Yish42 Yeah, there's all sorts of videos of errors from people doing that in KSP. That definitely sounds like a floating point error.
@XtarsTheExdarichGuy33106 Or Mac. I know mine would.
@Graingy i put the camera on for the gun,i shooted to the sky,and then i paused,changed camera,and this happen
@Graingy yes, i had fun with it. Good way to ovenize your phone
FeCK THE KRAKEN HAS SPREAD!
(Jokes aside, probably a floating point error?)