koobas.hobune.stream
Unity3d floating limits?
Hi there, Guys. I have a problem with Unity3d's floating limits. I'm making a realistic Space game, And therefore, I need alot of space. The planets are both big, and very far from each other. But my problem is: 1: I can't zoom enough up, Since everything is very big 2: There are those floating limits, And I can't click F to get to the planet quickly. Is there any way to modify the limits?
Thank you for reading.
You can't modify the limits. This has already been discussed a lot; do a search for "Unity space game scale" or similar.
You can't just modify the range of a 32bit float. Unity has nothing to do with the sizes of floats, as they are hardware dependent. As for realism in your scene, there's no point. You'll run into problems like you have here. You should decide a reasonable scale for your scene. If you need huge voids of empty space, then perhaps it can be programmed in, instead of trying to make a 1:1 scale of the universe. You can make it so the scene has invisible walls, and when the player hits the wall/collider, then planets/stars will move towards the player. This will keep the player in reasonable float ranges and it's in space so the illusion of you approaching planets will be the same when they are actually approaching you. My point is, you can't change float range so you'll have to rethink the design of your scene.
Well, I want to do it a way like, For example, the game $$anonymous$$erbal Space Program did. It was made with Unity and the solar system is a massive size. But I do not know how they did it.
You're trying:
base position (0,0,0) ----------------------------------------------------> far distance (out of float range)
Instead try:
base position (0,0,0) --- edge of chunk 1
edge of chunk 1 (new 0,0,0) --- edge of chunk 2
edge of chunk 2 (new 0,0,0) --- edge of chunk 3
There then is a new problem of how to store and refer to your new positions. You will probably have some sort of 3D index into all chunk data so your co-ords will become something like (i,j,k,x,y,z) where ijk are chunk indices which you can later translate on a hud to the user by converting those values to some BigInt system that can support values larger than 64 bits.
In short:
It's not going to be easy and it does cost more memory. You can reduce the memory using octrees or something like that where large empty spaces can be easily stored in a small amount of data. The theory is quite simple but if you're not an experienced developer I suggest trying something smaller scale until this sort of concept begins to be so obvious you don't need to ask about it. No insult intended, it's worth a shot if you feel you can tackle it. Good luck!
You do realize this question is over a year old right?
Yup. It was poorly answered to this point, hopefully someone who's looking to accomplish something similar will find it helpful.
