64bit precision

Give them and the community a couple decades. We're already seeing prototypes for 3D.

 

SC or DF?

 

DF is still not finished yet? SC could be finished way before DF

 

If I remember correctly the major version is roughly the percentage of completion. If that's true it's 43% done.

 

Maybe CIG should just start over with SC, making it a roguelike with retro pixel graphics.

 

I'm sure a rogue like already exist somewhere

 

I have a feeling that DF reaching 1.0 is more likely. Time will tell...

 

To come back on topic and for sake of completion, here how kerbal got around the limitation:

 

EYE Precision

I Agree, but the human eye is capable of 27 order of magnitude. Eye is capable displaying from 10^-4 m. up to a supernova dot in nearby galaxies 2*10^22 m [source :Antonio J. Acosta]. Out of 42 orders of magnitude in total.

@neoshaman thx 4 the links!!

SC (funding-goals / people playing at any time 2016)
129,040,658 u$d / 300 = 430135 $ x player online

Is there a SC Unity team? Please PM me!

 

Well, the eye is capable of detecting whatever photons reach the retina, no matter the distance those photons traveled. The chance of photons reaching our retina after traveling long distances is more a property of light and the age/shape of our universe than the capability of our eyes to detect them.

 

So, in that case, is : 1,37*10^26m (observable universe approximation). Four more orders of magnitude, to add to the 27.

 

Maybe it's time we lay down the int and float to start using the type decimal it has the needed for the entire universe as it is 128bit in c#
https://en.wikipedia.org/wiki/Decimal_data_type
Now don't forget to translate it into floating origin coordinate for display.

 

Honestly, at first I thought he's talking about astronomic magnitude. But either way object's brightness has no relation whatsoever to float/double precision.

Aside from that, AFAIK eye is capable of catching inidividual photons (after eyes get used to darkness), and wiki says angular resolution is 0.02 degrees (0.3m at 1km distance).

https://en.wikipedia.org/wiki/Naked_eye

Is that a new fancy name for a fixedpoint?

Ints and floats map to CPU numeric types and have cpu/fpu instructions for majority of operations. Bignums and uncommon types will require multiple operations per number and will be slower. Bignums also will require very frequent memory allocations

 

No, but it does have to do with how far away we can see something. @Dave-Carlile was just stating that visual distance isn't (just) a property of the eye, so the capability of the eye has little to do with this problem.

 

Nobody says that the game must simulate human vision.
The main reason for using higher precision is streamlining dealing huge sizes without constant origin shifting.

Speaking of which.. even double precision won't be sufficient for very large universes.

I think it was mentioned in the last single/double precision thread, but
double precision gives you space of the size of solar system (or several of them).
Dealing with the whole observable universe will require quadruple precision, and 128bit floating point numbers. If you want to be able to land on any planet there, of course.

The size of observable universe is 93 billion lightyears.
The estimated size of the whole universe is said to be at least 250 times bigger than that... which will be 2.2 * 10^32 millimeters. That would mean the game engine iwll need 32 decimal digits precision to deal with something this big without origin shifting.

Of course, from practical standpoint it would make much more sense to just bind origins to individual star systems or galaxies.

 

So, wait, you're back to promoting shifting origins?

 

If I were writing a spacesim I wouldn't be using floats or doubles for interstellar coordinates either way.

With space speeds, which kind of origin shifting do you think would be more "fun" to deal with?:
1. One that happens once per 10 kilometers.
2. One that happens once per solar system.
3. One that happens once per galaxy.
4. One that never happens.

IIRC, space speeds are:
8 km/s to reach earth's orbit.
11 km/s to escape it.

#1 is major pain to deal with, because you'll be travelling a very dense grid and the shift will happen very often. Pinning origin to nearest large body makes much more sense, especially if you're supposed to walk on that body.

 

Or we could use the infinitely sized (and horribly performing) BigRational!

https://bcl.codeplex.com/wikipage?title=BigRational

 

Now we're getting a bit... irrational.

 

I'm finishing code to translate mesh to half edge and I'll try a planet prototype, those discussion sting too hard my curiosity I should try a 12 week challenge on this: Nomad space project

 

I'm fairly sure it is possible to make a quick and dirty prototype much faster (origin shfitng or not), as long as someone is paying for it, though.

 

Wow. Reading that article was eye opening. It had never occurred to me just how hiring, firing, and companies work.

In the end its about people, and talent.

 

Since it got dug out...

Here's that quick and dirty prototype. Double precision spaceflight prototype, that is.

Code:
https://github.com/NegInfinity/spaceflight-unity-demo

Just doulbe precision uncontrolled travel using newton mechanics.

And speaking of precision... I did a bit of math few days ago and figured out that for a space sim float128 type would generally do the trick. Basically, fixedpoint 128bit int would be sufficiently big to store coordinates in the enitre observable universe with 1 micron precision, but to deal with rounding errors and results of dividing such large number, a 128bit float would be a better choice than a 128bit int/fixedpoint. 113 bits of fractional parts will be sufficient to maintain high precision to a range that is 12 times larger than observable universe - with micron precision. Of course, just using sectors and space grids will be easier, because space is mostly empty anyway.

 

Double-precision needs to happen eventually. There are simply not enough digits in single-precision floating point numbers. Godot is already working on double-precision support, I may just abandon Unity and switch to Godot then. Unity is behind the times, even Minecraft used double-precision in 2011!

 

Why? The old phrase is don't wait to get to the universe, make it come to you..

That's the point of origin shifting, in practice even using single precision you can make infinite worlds you're only limited by the amount of memory (and some times loading screens in the case of the Witcher).. Physx precision matters far less when you're only observing large distances it's mainly player and relative NPC / ship positioning that matter.

Even if you were to give up relative performance due to 64-bit floats you'd still have to shift, I think you could cover roughly 30 stars or 1cm resolution up to a distance of 9X10 ^13 and in terms of distances between planets past the sun they'd show up as a couple of pixels on a 4K monitor if we're being realistic.

Not only to point out the even with hyperspace windows etc. trying to explore galaxies / planets etc. is a rather dull affair that a couple of hundred million dollar budget most likely couldn't fill.. It's bad enough trying to create enough content for 4KM's of terrain never mind anything else.

Unless science simulations are your thing it's a game and it's meant to be fun. As worlds (and games in general) are getting bigger the emphasis seems to be on size and in theory it's an attractive proposition, the issue being in practice it's as popular as a chocolate fire guard. So tons of fakery, maybe some level loading in places is not a bad idea.. Saves many a headache.!

 

Just understand that you'll cripple your performance by choosing double-precision over single-precision. Best case your average processor only takes twice as long to process a 64-bit floating point number over a 32-bit one, but your average graphics card takes 32 times longer!

 

Not enough for what?

There are definitely cases where double-precision helps and solves problems, no argument there. But generally, if your game is large enough that single precision doesn't give you the required level of accuracy over your whole map then you're going to need to stream and do other complicated things anyway, and when you're doing that you might find that origin shifting isn't that big a deal in context.

Yep. I ended up changing the design of the open world game I'm currently building because just making it "huge" and "open" also resulted in it feeling "empty" and "boring". No surprises there because it had just been a first-pass design - I usually don't expect to get those right! - but it demonstrates the point well. The new design is more flexible, more fun, provides better player guidance, and - incidentally - requires neither stream loading nor origin shifting.

 

Is there any value in sending double-precision numbers to your video card?

Stuff we see on screen is (or can be) defined in either screen space or camera space, and single-precision isn't going to have issues with those any time soon.

 

It's mostly a worst case scenario if the developer didn't implement it properly...

 

This needs to be pounded into the head of every indie trying to make an mmo. I don't know when or where the whole idea started that open world is some magic thing that offers value in and of itself, but so many people think it is.

 

I think it's a right of passage and invaluable as a base of experience, making an MMO large (in terms of scale) isn't that difficult.. Making a great one full of content is nearly impossible without a lot of funds and massive team behind you.

Although ultimatley I agree, sacrificing quality for size never pans out well and often results in failure.. Whether that be sales, or in many of my cases never actually seeing an end in sight..

 

It definitely has its upsides too, but I personally think it often makes games worse. It takes a lot of control out of the designers hands and, as I describe it, tends to "normalise the dynamic range of the game" as the design of everything has to take more stuff into account.

For example, areas in an open world game can't be often designed just for a specific part of a game, they have to be a part of a world. So instead of "design an area for a chase scene with <these details>", that chase scene is just one of a list of bullet points which will involve collectibles, pathing between other places, maybe side-quests, and a bunch of other game-specific stuff. That can also be a bit of an immersion breaker in some cases, at least for me, when you're supposed to be somewhere new but it's right next door to places you're well familiar with (or heck, sometimes you've already been there).

 

The funny thing is that most people who want to make these games that require origin shifting, never even get to the hard parts. Like the fact that you have to reconcile multiple offsets on the server, and that the offset can potentially change in the middle of some multi part transaction like combat projectiles, or that the client might be dealing with objects with a different offset then it's own.

It's all doable but just solving the basic client side part is a very small part of the overall picture once you get to the end.

 

For me it comes down to content, pure and simple. I'm reasonably confident that if we had the time and budget to make literally hundreds of square kilometers of interesting content then, while the artists and designers were doing that, the tech team could go to down on solving the tech issues to make it all work together.

But, since we don't have the time, budget and resources to make that much content then we'd be wasting our time writing systems to support it. The compromise that we've made here is to have the occasional loading screen which, because of the new design of our map, has near zero impact on gameplay.

 

I've noticed this a lot with the recent lego games. They all have an open world section to them. Which is basically full of very generic quests. Ultimately it just comes across as filler. I honestly prefer a traditional level selection screen, as opposed to having to wander through generic cityscapes. I also get that the target audience is my kids, not me.

Gating is an important tool in any designers toolbox. And giving that away to make a game open world often makes the gameplay worse.

 

To give a positive example, Farcry 4 has done an excellent job of its world design. It also has a bunch of bespoke areas for certain sequences of the game.

Another positive example is Batman: Arkham franchise, which works so well partially because the open world is kept small. "Open world" does not have to be like GTA or Skyrim.

 

Shadow of Mordor did it well too. The game was based in a series of small valleys, and you had to complete certain questlines to get from one valley to another. But within the valley you could do whatever you liked. That said, they didn't balance the content, so a direct frontal assault led to dying multiple times, with associated penalties. So attacking several less important targets first was essential to success.

 

I had this discussion with myself my entire career:
- at first the idea of big infinite world was appealing
- as I got older and better I realized that was a stupid idea, would take enormous resources and big team and will end up boring and empty
- then I got older and more experience except where it mattered the most (programming), but I also realized making any sort of random game does not cut it anymore, I really wanted that big fat infinite game.

My take is that people who say it's not possible are just not interested in the genre, and there is an audience for boring empty game, I like no man's sky FIGHT ME!

Anyway, I'm still working on it, and I'm currently stuck at a simple problem, I need to find a way to make position hash on a sphere to control gameplay and generation on a planet.

That's generally where people say this is why you shouldn't do it, because it's hard, and why some starting person give up, because they really want the result to be handed to them, I say that's no excuse. Those are valid reason to ponder, but ultimately, you are the dev, you do you, and that's what's important. I'm older now, I know better when I need to chase my windmill, call me Don Quixote!

Now if only people stop arguing the idea is bad, when I told them about it, and actually help me solve the hash problem, because the quality of the idea is irrelevant to the problem I'm having lol

 

Welcome to the guild of necromancers.

Go ahead and switch already instead of talking about it.

Just FYI the amount of Godot prophets I saw on unity forums by now firmly convinced me to stay the hell away from godot engine. I'm not sure what the deal with this, but this amount of proselytizing users isn't normal. (Does it have monthly quotas on number of converts or something?)
--------

It can simplify rendering of large scale scenes. VERY large scale scenes. For example, with double precision floats you can specify sun as pointlight and render solar system scale scenes without camera stacking. Won't work on galatic scale. ZBuffer will have higher precision as well.

 

(ugh, can we please not make Godot the next Unreal? I'd like us to be able to occasionally discuss other engines too. We are game developers, we use engines, we like them. But every time someone uses another engine as a "threat", (UNITY SHOULD DO X OR I WILL SWITCH TO ...), something that I may have been guilty of in the past as well, nothing productive comes out of it and it annoys everyone to the point where every time another engine is mentioned, instead of discussion we have loud groans from almost everyone)

 

It looks pretty nice. Not enough aliens for me. ... also... why hasn't this game figured out how not to have any LOD `popping` where objects are very noticeably suddenly switching between LOD levels all over the place, including close-up trees and mountains in the distance? What's the point going 64-bit and having artefacts that we saw 10-20 years ago? Also not sure how long I could roam about on all these very similar planets without getting bored eventually?