Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Has Unity Considered a 64 bit floating point upgrade?

Discussion in 'General Discussion' started by Arowx, Feb 2, 2016.

?

Would you like Unity to develope a 64 bit large world API?

  1. No way, 10km 32 bit is big enough for me think of the artwork dude?

    24 vote(s)
    13.4%
  2. Yes please, I want to use procedural techniques to build worlds, planets and entire solar systems?

    130 vote(s)
    72.6%
  3. What just 64 bit hell no think exponential we need 128bit or 256bit, you luddite!

    25 vote(s)
    14.0%
Thread Status:
Not open for further replies.
  1. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    I was reading about the Ashes of Singularity game, and the developers have build a 64 bit engine to cope with large worlds.

    Now I know that the developer of the Kurbal Space Program game (made in Unity) built their own 64 bit vector maths engine on top of Unity to allow the game to have a realistic solar system spanning scale.

    So has UT considered adding 64 bit maths, vectors, transforms, quaternions, physics to the engine so out of the box you can build planets and solar systems to scale? *

    *I think 64 bit maths precision limits the scale of things to around the level of the solar system not the galaxy.

    Support the idea Here
     
    Last edited: Feb 5, 2016
    AntonioModer and Wrymnn like this.
  2. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Not gonna happen.

    64bit float support is uncommon on GPUs and occasionally there's significant performance loss even if it is available with hardware acceleration.

    PhysX also doesn't support double precision.
     
    alexzzzz and Zuntatos like this.
  3. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    Um... No.
    For Yes: it's good for building large worlds and not thinking about translating nearby objects manually from double to single, sure.
    For No:
    It's bad for 32 bit systems as it'll increase RAM and CPU usage(quite a lot of latest Unity games can't run on 32 bit without crashing. Not sure if that's because of bad code, programmer lazyness or extraHQ textures, but this will mark out problems even further)
    Mobile platforms where each bit of performance is critical.
    neginfinity also has valid points for No.

    This shouldn't be in close future because there's too much Cons for too low profit. Let Unity first finish what they started already. Besides its only Pro can be immitated anyway, so... Why?
     
    Last edited: Feb 2, 2016
    AndrewGrayGames and Zuntatos like this.
  4. Neoptolemus

    Neoptolemus

    Joined:
    Jul 5, 2014
    Posts:
    52
    There are other ways around the problem. I guess in very niche, extreme cases you may have to go 64-bit, but for the most part there is almost always a way to do it if you think outside the box.
     
  5. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    What I listed aren't cons, but issues.

    double precision engine would've been a good thing, but because everything is heavily tied to gpus, hardware acceleration and those have problem with double precision... that'll get in the way. Also, modeling packages most likely are single precision most of the time.

    The idea isn't bad, it just won't happen any time soon.

    The other ways are origin shifting and extra "sector" coordinates.
    They are less elegant than double precision.
     
    Trexug likes this.
  6. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    And that's exactly its main cons: performance on modern hardware. Unless most hardware(including GPUs you mentioned) will support 64 bit it's bad. Besides it is twice as much data bottlenecking CPU->GPU sending (it's bottlenecked in some cases already as its usage is spiky like loading whole mesh's position buffer).

    Then why not change topic into "Unity, give us way to simulate extra sector coordinates with one command/component, like Transform64"? it'll be much easier to implement than changing core to 64 bit, will give same Pro and won't bring all of its cons(main one being performance).

    Ohhh, right, some fellow asset store dev might want to just go and make it. Why not?
     
  7. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    I also came across an interesting issue mentioned that 32 bit precision limits the speeds of objects in the game space. I think it was Space Engineers (or that type of game) and because they were using 32 bit physics they were limited to really slow (in space) velocities, so it's an instance where 32 bit slows down a game.
     
  8. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    Um... it can be set to only 1 million m/s, true, you can't reach speed of light. But... 1 million m/s for precise collisions is already overkill as no physics engine I know would be able even raycast needed distance in real time. And if you interpolate a collider... It won't matter 32 bit or 64 bit - it just won't lift it CPU-wise and loading-wise(that's main bottleneck because of which they have 300 m/s maximum current speed - it still not always loads everything in time). Thus the speed limit.

    P.S. oh, and noone forces you to use PhysX with their 32 bit ;)
     
  9. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    I think Unity would have double trouble if they'd try to. It's better to let it float as it is and use different methods such as e.g. map teleports on the edges of the world.
     
  10. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    Unfortunately Unity does. If they have made it easy to easily replace it with a better lib such as Bullet AND have it worked with standard Unity colliders, rigidbodies and so on (unless lib PhysX gets replaced with have no concept of particular thing), then, in fact, no one would force him to use PhysX.
     
  11. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    And then sell it for unreasonable price. That's one thing that infuriates me about AS, they don't let prices drop by natural market means, such as someone releasing a better product that is also cheaper (or even free). Let's say I make voxel terrain engine. Better than TerrainEngine, VoxelFarm and other systems like that. Now I want to sell it... for $5 a pop. On asset store I can't do that, Unity won't let me do that. This is main reason why prices on AS are so high and more importantly STAY high.
     
  12. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    It will happen eventually. After all, we are not using 8 bit graphics processors any more.

    Graphics cards and api seem to be the main limitation for the moment. It makes little sense for Unity to move to 64 bit before GPUs have made a move to support it.
     
    Zuntatos and Martin_H like this.
  13. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,083
    Just use floating origin if you need large worlds. It's not terribly difficult to implement.
     
  14. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    This. Hardware acceleration for single precision is significantly faster than double precision. Just as one example the GeForce GTX 960's single precision is rated at 2,308 GFLOPS but its double precision is only 72.1 GFLOPS.

    A similar discussion was brought up on the Unreal 4 forums and one of the developers commented that if you have the source for PhysX you can simply compile it to use double precision.
     
    AndrewGrayGames likes this.
  15. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    32 bit precision doesn't limit your speed. You'll hit tunneling problems, and as you start move away too far from origin, objects will start to shake. Speed is not really an issue.

    Checked the discussion, he doesn't say that. At least he doesn't say that as definite possibility and just makes an assumption.

    PhysX is heavily tied to hardware acceleration, so I think you can't "just recompile it". You probably could do that with Bullet or ODE, though.
     
  16. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    That may be so or it may be that enabling double precision disables hardware acceleration. Which in Unity's case wouldn't matter in the slightest as Unity's PhysX implementation doesn't support hardware acceleration whatsoever.
     
    hippocoder likes this.
  17. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    The solution is a nice origin shifting feature, Unity's side.

    Although Unity has been just recompiling it for a while and it currently doesn't support hw accel within Unity.

    Didn't respond to poll as I didn't think any of the choices led anywhere but the same place: arrowx wanting 64 bit without knowing fully what he's asking for :p
     
  18. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Hmm... it looks like PhysX system software has been deprecated and it is possible to get physx source code access....

    Still, I highly doubt that switching to double precision will be very easy.
     
  19. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    That's about normal with these threads. :p
     
    alexzzzz, Ostwind, Kiwasi and 2 others like this.
  20. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    1024 bit physics with hardware acceleration running on hydroponic-powered biocomputer built by nanomachines! In VR!

    ---

    Eitherway, I remember another thread about the subject,
    Basically... single precision float (32bit) gives you +-10km zone with 1cm precsision.
    Double precision float (64bit) gives you solar-system sized zone with 1cm precision.
    Long double (Or quadruple precision float or whatever - 128bit) precision gives you zone that 11 000 times bigger than observable universe where you can maintain 1cm precision.

    There's no reason to go above that, I think, at least for games.

    Either way, with non-float precision, physics libraries will probably go out of the window along with lightmap baking libraries. Space sim most likely will be using custom flight/planetary physics, with physx/whatever being applied to ship interiors and the engine will have to jump through hoops in order to convert visuals to single-precision float scale that can be handled by GPU.
     
  21. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    For the huge majority of games, it isn't really relevant. I agree with my good ole friend BoredMormon in that GPUs seems to be the main limitation at the moment, although that doesn't keep you from using double on the CPU side obviously. You'd just have to do some extra steps to submit stuff to the GPU in order not to have a considerable performance impact (assuming the game is GPU-bound). As an extra, the engine could check its capabilities and adapt accordingly, it sounds quite doable to me.

    Besides the technical plausibility and the fact that it really would solve the scale problem (or at least move it orders of magnitude away), it is something that only a very few games will take advantage of, and it's possibly going to be a major pain in the rear to do, so it wouldn't be a priority at the moment in my opinion, especially because there are many tricks to deal with that, and many feature that are much more essential still lacking in Unity.

    No game really needs an interactive area larger than what can be accurately represented by a single precision float.
     
    Kiwasi likes this.
  22. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Yep but it's still unsolved on Unity without origin shifting. A lot of Unity's stuff is being fixed up in prep for it though. I mean before then you need a robust way to stream in gi, navmesh, probes etc, and Unity's sorting that first since streaming implies we might not assume where you want things.

    On top of that they should be able to modify physx to better support offsetting everything and from there we should be good to go for some sort of origin shifting... just a guess!

    If not using many features then it's possible to do origin shifting now but it is expensive to perform.
     
    Ryiah and AlanGameDev like this.
  23. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    Yes, basically origin shifting is the way to go. It's surely expensive, and I see that these days devs want huge seamless worlds, what just makes the problem worse (actually, this wasn't a problem at all on the level-based days). But for the very few games that actually need the extra bits, even among these only a very minor fraction really would benefit substantially from avoiding origin shifting. There was a space game (not sure if it's Freelancer), that would shift the origin when the user is interacting with some UI, so the spike isn't noticeable. In a normal game, you generally have lots of opportunities to shift the origin without impacting the gameplay, and if for some reason the game didn't have such an opportunity, then just shift it anyway at expense of user experience... there's not much you can do about it and hopefully it won't happen often. It would still be much better than the 'loading' screen in the middle of GTA:VC in consoles, and that didn't affect the sales too much I believe :p.

    EDIT: You could also go truly relativistic and always keep the player at 0,0,0 and just move the stuff around it. I guess it's doable even with the built in physics. You'd have to calculate the velocity of the player manually (using physics engine information), and then spawn the 'static' stuff as kinematic and set all their speeds to be the opposite of the player speed. There's possibly going to be a prohibitively huge overhead though. Perhaps you could place all the 'static' stuff in a few objects (like chunks), but for the other stuff (e.g.: other ships) you'd have to correct their speed at each physics world tick (fixed update).
     
    Last edited: Feb 2, 2016
  24. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Spacesim with planetary landing. Any game with inter-city travel. Flight sims.

    You couldn't. Any decent physics engine uses some sort of optimization mechanism (space partitioning) and freezes any rigid body that is not moving. If you start moving the world around player, that stuff stops working. You'll want to move the smallest number of rigidbodies possible and you'll want to use origin that accomodates that.
     
    ThaiCat likes this.
  25. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    Nope, you most likely don't need all of that in the 'game simulation area' simultaneously. If you really need to simulate all of that, then you need a custom engine. There's no way a general purpose engine is going to address a problem that only one or two guys have, and especially because if you really need that, then your project is huge and probably multi-millionaire, so just hire some bad-ass coders to do a custom engine.
    Kinematic rigidbodies aren't much of a problem.
    There's a 'gravity' thing in every physics engine that is a kind of 'universal' acceleration. Have you ever though that your thrusters could just modify that vector? Basically, when you're in a spaceship in real life, the thrusters accelerate the universe in the direction they're pointing at. :D.

    I think the problem here is thinking outside the box. You won't be able to really simulate an entire universe in the next few decades of computer technology, you just have to think what you really need to be simulated.

    Think about what is in the 'radius of action' of the player.
     
  26. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
  27. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    Not sure if you're disagreeing... as a matter of fact KSP is a huge project and multi-millionaire, so I'm assuming you're agreeing.
     
  28. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    Okay. Provide links to these facts. Then I'll believe you.
     
  29. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    Don't mean to sound rude, but I have experience enough to say with certainty that KSP is a huge project. Don't you think it's huge?
     
  30. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    That doesn't work, though, and I suspect that you don't get it.

    In typical "on the ground" scenario, the world around you is mostly frozen and is not moving or being processed. Rigidbody only wakes up when interacted with.

    Similarly, in space similar optimizations can be employed.

    In any physics engine, you really DON'T want a force that can change randomly and unpredictably and affects every object in the world. You'll get severe performance hit, because typical optimizations employed by the engine will stop working, not to mention that the whole thing can just explode in your face.
     
  31. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    Okay. Got it. You're just making an assumption and don't have any actual facts.

    No.
     
  32. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Exactly, why would anyone believe that?

    If you have a good argument, back it up. If you can't back it up, you don't have the argument, just a belief.

    Nope. I'd expect that kind of project to have fairly simple core with loads of content bolted on.
    It is neither GTA nor Dwarf Fortress. So I wouldn't call it "huge".
     
  33. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    Pretty much every game uses the gravity vector... I'm not seeing exactly what is the wall you're hitting...

    @Ryiah: Also, FYI, Kerbal uses origin shifting. And doesn't simulate a large volume. So I don't know what exactly you're arguing. I don't know how much gamedev experience you have, but KSP is surely not something I'd consider <big~huge sized project.

    I'm just saying that, I've played with infinite volumes, and I did manage to solve all the limitations by thinking a little bit differently. The only thing that really annoyed the hell of me is centrifugal force, but the frame dragging effects are still a mystery even in real world, so I accepted that a rough approximation would be enough.
     
  34. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    I already explained that.
    In most games gravity vector is constant. That fact is used for world optimization - freezing non-moving rigidbodies (which are still affected by gravity, by the way), and collision space optimization for quick queries.

    You ARE familiar with ways to optimize collision queries, right?

    When you start changing gravity vector and move the world, you'll not be able to employ those techniques efficiently. And you will have a performance hit because of that.
     
  35. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    Yes, I'm aware. He had a one-hour demonstration at Unite 2013.



    What's your frame of reference? Other indie games? Or games in general?
     
  36. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    Indie games.

    @neginfinity how you're going to take advantage of rigidbody sleeping if you're simulating celestial bodies that are never static in relation to each other? I'm just trying to understand what you're trying to do that's being limited by single precision.
     
  37. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    I'll be taking my leave from this thread. OP's question has been answered, and I don't foresee any new or interesting info surfacing here. Plus I had enough "discussing" with "suddenly arrived forum paladin" recently and this thread seems to be going in the same direction.

    Have fun.
     
  38. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    What I really want isn't 64 bitness of physics. But multiple physics scenes. Main use case for that is authoritative server with several players being far away or in different instances. More to it: it's already in PhysX(and even Bullet), so it's just question of "will it ever be implemented or not".
     
  39. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    Right. Still it's a fairly simple game with the mechanics being primarily limited to creating and simulating vehicles. Strip those out and you're left with only moving around little green men on height-mapped spheres.

    Your statement was that games don't need everything in the "game simulation area" (which I assume means the currently active simulation area). While KSP isn't the best example I know you can have more than one vehicle active in the game world and it doesn't have to be local.
     
  40. AlanGameDev

    AlanGameDev

    Joined:
    Jun 30, 2012
    Posts:
    437
    I'm not discussing these polemic subjects in this forum any longer too (before people start offending me via PM)... It seems people read half my posts, then get angry and reply without reading further... I fail to see the where people are disagreeing with me besides subjective 'project size' classification and possibly prohibitive performance.

    All I can say is that I've used the Blender Game Engine long before Unity was released for Windows (in 2009 I think) and infinite volumes for games were discussed extensively in the respective forums but a creative solution always was found in the end. I used to participate in the local community in 2002~2008 (I started using BGE in 2004) but I'm sure you can find a lot of old threads on the Elysium forums about that...

    It's just that I opened a smile when I read people discussing about the same thing I used to discuss (as a total noob) 12 years ago with my good friends on a long dead forum, but we always ended up with a creative solution to the problems and everyone was happy.

    I've lost too much time here already, I've 2 games in final development stage to finish at this very moment. So I'm very sorry but even if you quote me I'm not going to reply, please accept my apologies in advance. I beg my leave.
     
  41. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    They started kerbal with humble means I'm pretty sure. Hopefully they can clarify for us as they do visit forums sometimes!
     
  42. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    We aren't getting angry. We're simply pointing out that your supposed facts are anything but. Just read the part of your post that @hippocoder quoted. It literally is written as "a matter of fact". Except it wasn't a fact. It was simply your opinion.

    Squad was a marketing firm. The project was the idea of one of their employees. He approached them on October 2010 with the intention to resign to work on his project but they counter-offered to let him develop it as a project for them as soon as his current work project was complete. The first public release was on June 2011.

    We would have to ask Felipe how many people were on the project from the very beginning but either way we're talking about taking a project from an idea to a public release in less than one year. That's a very quick time frame for a game and is a large part of why I don't consider it "huge".

    https://en.wikipedia.org/wiki/Squad_(company)

    According to the version history on their Wiki you could already construct and attempt to fly vehicles by that point.

    http://wiki.kerbalspaceprogram.com/wiki/Version_history#v0.7.3
     
    Last edited: Feb 2, 2016
    hippocoder likes this.
  43. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    I think origin shifting would be better than infinitely increasing memory consumption. Maybe unity could work on some tutorials for using the world origin as the center of a chunk.
     
  44. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    I eagerly await a time when we have SSDs without any (or at least insanely high) write cycle limitations so I can use a portion of the SSD as a "slow" memory bank. I bet a concept like that would be something @Arowx would love too.
     
    darkhog and Kiwasi like this.
  45. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    Unless it's epic tons of swapping and data... I wonder how much terabytes pass through RAM daily. If only 1 TB then even worst SSD could work instead of RAM and live over a year while good one could live 7 years! The only thing to think about is how to stretch out writes across as much surface as possible.
     
  46. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    Ryiah likes this.
  47. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    Yes, although I was thinking of it being an application-driven solution rather than OS-driven. Ideally for storing long term data that won't need frequent modification. One example being voxel data for a world as even with the ability to change the world you aren't typically modifying the majority of the voxels yet you still need to be able to read them back in quickly.
     
  48. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    I assume that's how large-scale voxel engines work already. Keep the current area in RAM, drop areas as they're no longer needed, stream in new areas as you move towards them. As long as your player moves around at speeds slower than you can stream more data for then it's all good for reading, and for writing you should only have to modify what's in memory and then write it back out when you can.
     
    Ryiah likes this.
  49. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,954
    Right. That's why I choose it as an example. It's fairly common.

    I'm not too familiar with other voxel-based games but Minecraft starts to fall apart very quickly if you're using an HDD for streaming voxel data. You almost always need an SSD once you step up to multiple players and/or minecart transportation.
     
  50. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    Do you prefer when moving too fast results in...

    1 - empty areas that load in as they can
    2 - the game freezing until the chunks load in

    Is there a way to avoid #2 with unity?
     
Thread Status:
Not open for further replies.