I prefer to use my own data.
Hehe, of course.
Here is my trading tool for Elite Dangerous:
I can tell you itās much more fun creating the jumping algorithms than collecting data, anyway the Standard Beta release makes it much more easy to find trade routes in-game. Making these tools somewhat obsolete, not to mention that it will be very hard to populate the market data once all the systems are in the game.
So I just splashed out some cash on the Beta 3. That may have daft, given the full (cheaper) release will not be far away but Iām impatient I guessā¦ 
Keeping my fingers crossed it runs with fps that will look slightly better than PowerPoint.
I shall report back once it has downloaded on my uber-slow internet.
Edit: Well, I have tested it out and I already like it quite a lot. Just a pity my laptop is not exactly running it brilliantly, but I was always being optimistic about that. 
The immersive cockpit and menus I absolutely love - one of the best implementations I have seen in any space game (imho). I like that flying is somewhat of a challenge, making me justifiably scared about trying to do any kind of combat right now. It feels like a game you have to take your time with to learn - something the gaming industry as a whole seems to be lacking currently.
On the whole, thumbs up! Just need to save for a better gaming machine now so I can run it without frequent stutteringā¦ Still holding back cash for I-Novaeās Kickstarter though, donāt worry.
3 Likes
Elite: Dangerous has an official release date nowā¦ 16/12/2014. As far as I can tell, itās made the community a bit jumpy that itās so soon! Weāll see how it goes, since they will be declaring an open day for review sites and the like.
I imagine itās going to be a lot like a continued beta. They have some huge expansion plans that rival Star Citizenās, but as long as they get some interesting missions planned out for launch then Iāll be game to start my stellar inquisition. I would like to see some further performance tweaks done to the variety of ships, I feel like far too much of combat is jousting and what feels like eternal loops since all ships are so closely matched. Also, bloody well tired of the AI trying to wreck into me (friendlies particularly in the combat zones).
So. . . turns out Frontier are axing offline play in the next update.
Popped into the forums to get a feel for the reaction.
Came out singed.
For the past few days I have had a really faulty internet connection. My internet will randomly disconnect for a minute. If I am playing singleplayer, and I am booted out because I lose connection, I am going to be pissed. This had better just be a simple synchronization with the server and should not require a constant internet connection.
This decision is not ideal, but if I donāt need a permanent internet connection, itās not the worst thing ever.
Funny you should bring this up, since Frontier Developments just announced that Offline Mode in Elite Dangerous has been canceled. This spawned a revolt on their forums, the thread is moving at around one post per minute since the announcement and is active at this time. (There never was Offline Play @TerranAmbass, didnāt see your post, sorry.).
On a lighter note I made my first ED video.
I thought this answer on planetary landing was very interesting.
How much of a technical challenge do you think planetary landings will be,
in comparison to the technical challenges of the game so far developed?
The landings themselves are not the technical issue, it is the
vast size of planets, and the prodigious amount of content required to
make them interesting. We can generate the landscapes procedurally, but
you need interesting things there to make them compelling.
Could not agree more. I think procedural generation of planets is not the technical hurdle it used to be.
But what once you landed on a planet? A somewhat dated movie called āAlien planetā ( http://www.imdb.com/title/tt0453446/ ), put forward some fascinating concepts that would fit very well in a procedural generated game.
But is would require pretty advanced AI to make it feel real.
Quite.
If I recall the old-forum-consensus correctly, the basic plan with Infinity was to not make planets interesting, beyond some curious ridge lines, but rather make them somewhere that players would want to build interesting stuff. This approach, of course, might not work as well in the current (as I understand it) instancing-based system of E:D.
Procedural generation was āsolvedā well enough to make a fun game with it in the original Elite. The hurdle is that real-scale planets donāt really fit very well in floating point coordinate systems. This is why Star Citizen has to put quite a lot of resources into upgrading CryEngine to double precision floats.
2 Likes
Never really understood why more precision is needed for planet based games. I understand that planets are big, but in essence all triangles are relative to the viewer, so as long as the precision is within the pixel boundaries everything should be ok.
Of course the mesh itself should not be very big but subdivided into smaller quad meshes (in order for the vertex coordinates not to be too large to lose precision).
I know there are a lot of articles about this, but they always make the premise that the meshes themselves are very large instead of a large collection of smaller meshes.
[quote=āasimo, post:133, topic:227ā]
I understand that planets are big, but in essence all triangles are relative to the viewer, so as long as the precision is within the pixel boundaries everything should be ok.[/quote]
The viewerās location in the game space (a planetary system) is the portion that needs to be represented in double precision. From there, all calculations relating to proximity must be in double precision (coarse occlusion, ship sensors, AI tracking, maps, etc). Those calculations can then be used to instance single precision meshes that describe the area local to the viewer. That mesh provides enough information for the purposes of interaction.
Even if meshes could be implemented in double precision thereās not much point in doing so because few games require more than the roughly 7 decimal digits of precision for the interaction space that single precision provides. Thatās centimeter resolution out to 1,000km, or millimeter resolution out to 100km. Using double precision values would be a waste of space on the GPU.
The challenge with an existing single-precision engine is going through and introducing the notion of world space vs display space as two different data types. Theyāre single everywhere, yet they need to be selectively switched to double. I would not envy such a personās job. It probably involves telling the compiler not to auto-promote singles to doubles in calculations, then changing some key variable from single to double and recompiling. Fix the errors. Recompile. Fix the errors. Recompile. Find something irreconcilable that requires a refactoring of some functionality. And so on. Real grunt work that can be done in parallel only as much as the engine is broken into discrete components.
Yes I think I am saying the same thing, The render part is single precision. Basically you translate the entire universe around the viewer before rendering. So the viewer is at pos (0,0,0) for display purposes but actually at (x,y,z) in double precision map.
Doing this, from double to single precision, is apparently not trivial. I base this on the assumption that if it was trivial everyone would be doing it by now; I program satellites not video games so to me this all seems a bit like rocket sci-ā¦ damn it I canāt use that idiom any more.
1 Like
In relative terms, itās trivial. However, not doing it is cheaper than doing it. Note that the type conversion isnāt necessary if you generate your data in single precision - which INS would undoubtedly do. Only a few values are in double precision. Locations of moving objects (planets, moons, ships), for the most part. The actual geometry of objects will be in single precision.
In the INS case, they can create the geometry for a patch of terrain once - centered on the camera - then allow the camera to move freely around near it. If the camera moves too far from the origin of that patch, the engine can bang out a new patch that is again centered on the camera.
If the cost of creating a new patch is greater than the cost of mathematically-shifting geometry, then old geometry could be reused. But the shifting process involves being able to get to the interesting portions of the old geometry. So if the optimization of the geometry precludes quick access to plucking out the interesting bits, then just generating a new patch from scratch is the way to go. It will obviously keep the code cleaner and simpler.
A long time ago I built a terrain generator that focused on the reuse idea. I found a little GIF animation that shows the way it worked (taken from K. Murotaniās web site).
Conceptually, yes. In practice, the camera can move around the single precision geometry of the local patch of terrain, traveling many kilometers from the display origin. Perhaps as many as 50km. Resetting the geometry such that the camera is at the origin need not happen every frame.
There are many ways to skin this cat, and Flavien may have an even more clever approach than Iāve described. Heās certainly been devoting a lot more time and effort to it than I have.
2 Likes
I havenāt got to that point with my procedural planet generation, but my next step would have probably been to have a secondary camera layer for the ship or close by objects and one for the actual planet. This way you are essentially removing the near/far clipping plane and depth buffer resolution problems; problems that surface when rendering a ship that is a few meters away and a planet that is a few hundred thousand km away with the same camera.
If you are interested at how far I got:
Looks cool. Can you get closer to the planet?
Reminds me of āLittle big adventureā.
Since the game is just about released, iāll give my thoughts for anyone wondering. Frontier developments is turning out to be somewhat of a disappointment for me. Their graphics programmers are great but some of the nonsense surrounding the game design is just that, nonsense. (hopefully it doesnāt turn out too similar for infinity). This thread is already aware of the issue some have with the decision to retcon offline mode out of the plan, right before release, despite it having been present in early versions of the alpha already. But what stands out more for me is how closely they mirror some of the actions typically attributed to shadier AAA devs most regard as anti consumer.
This is an online only game with a cash shop that sells basic paints for ships in the game, a game where when you bought in determines the cost of death (if you didnt fund the kickstarter your deaths, in open world pvp, will cost you twice as much as those who did), and where a last minute decision has meant that all possibilities for modding and playing the game once frontier shuts down servers are gone. Furthermore the progression in the game is terrible, it emphasizes exponential number increase and time sink over either having a fun, balanced progression, or having a balanced economy that makes sense. Bounty numbers and risk/reward in general is completely screwy with the idea of having a meaninglessly long progression prioritized over any other idea of balance.
The game has excellent space feel and i like how theyāve expanded on many of the original eliteās mechanics. But theyāve failed to make the now mandatory online aspect meaningful in any way. Thereās still barely any multilayer interaction to justify even playing in multiplayer, good luck playing with friends and like i said other players will have a cost advantage over you if you didnt buy it earlier enough. And whats stopping people from just going into solo mode to trade in safety, if that is possible it again defeats the purpose of online mode.
The flight model is alright, itās not really spacey but itās fun and works. Itās worth it for the great atmosphere but it could have been so much better.
The INS engine tackles that by rendering the planet using a ray tracing technique. If the planet occupies a certain set of pixels, the renderer checks to see what area of the planet that pixel covers. Then it figures out the procedural appearance of that area. Then it displays that pixel on the screen. Repeat for all other pixels occupied by the planet
It probably also supersamples so that the appearance of a pixel isnāt defined by a single location. For a planet that only occupies 100 pixels, each pixel might cover hundreds of thousands of square kilometers. The pixels of the planet would probably end up being random in each frame if only one sample of the procedural result was used for each pixel.
The really neat thing about doing things that way is that distant planets are rendered correctly, but consume a trivial amount of resources. So it scales exactly the way you want it to.