|
|
| Page 1 of 1 |
sausje
Banned
Posts: 17716
Location: Limboland, Netherlands
|
 Posted: Mon, 21st Nov 2011 22:50 Post subject: I-Novae engine |
|
 |
Engine developed for the space mmo "Infinity" (www)
http://inovaestudios.com/technology.htm
Looks promising for Freelancer kind of game finally 
Proud member of Frustrated Association of International Losers Failing Against the Gifted and Superior (F.A.I.L.F.A.G.S)
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
sausje
Banned
Posts: 17716
Location: Limboland, Netherlands
|
| Posted: Mon, 21st Nov 2011 22:57 Post subject: |
|
|
Well, we can all hope 
Proud member of Frustrated Association of International Losers Failing Against the Gifted and Superior (F.A.I.L.F.A.G.S)
|
|
| Back to top |
|
|
garus
VIP Member
Posts: 34197
|
| Posted: Tue, 22nd Nov 2011 00:17 Post subject: |
|
|
snip
Last edited by garus on Tue, 27th Aug 2024 21:33; edited 2 times in total
|
|
| Back to top |
|
|
|
|
| Posted: Tue, 22nd Nov 2011 00:26 Post subject: |
|
|
I'm quite sure that everything is right on that end, but the space ship is WAY too big 
|
|
| Back to top |
|
|
sausje
Banned
Posts: 17716
Location: Limboland, Netherlands
|
| Posted: Tue, 12th Jun 2012 10:19 Post subject: |
|
|
Looks like Inifinty is maybe going to use kickstarter!!
| Keith Newton wrote: | | I think my next blog post will be about kickstarter |
| Sausje wrote: | | @inovae_keith Are you going to try to kickstart Infinity? That would be awesome news. |
| Keith Newton wrote: | | @sausje85 We're currently evaluating the possibility of doing so |
If this is really going to happen, then FINALLY we will have a proper spacegame again soon™
Proud member of Frustrated Association of International Losers Failing Against the Gifted and Superior (F.A.I.L.F.A.G.S)
|
|
| Back to top |
|
|
sausje
Banned
Posts: 17716
Location: Limboland, Netherlands
|
| Posted: Tue, 29th Jan 2013 19:43 Post subject: |
|
|
Last blog post showed some really nice screenshots of their work in progress:
http://www.infinity-universe.com/Infinity/index.php?option=com_content&task=view&id=120&Itemid=26
| Quote: | I know that unfortunately, the rate of our updates has not been satisfying recently (as in: in the past 1-2 years), but the good news is that we should soon be ready to increase our communication significantly. We are also planning to launch a Kickstarter in Q1 2013 to fund our projects. More news about this will come as the deadline approaches, but for the time being I want to post an update about what I've been working on recently: improvements to the terrain engine, and particularly atmospheric scattering..
Limitations
In the tech demo 2010, atmospheric scattering was computed by solving the scattering equations in the vertex shader. This involved a discrete integral (basically a loop of many samples along the viewing ray). The code itself was custom made but heavily influenced by papers such as Nishita et al. (1993) and Sean O'Neil's work (2004). The number of samples were reduced to the minimum to keep a good framerate.
The dependency on the vertex shader lead to tricky problems: the planet mesh must be sufficiently tesselated to avoid artifacts due to the low density of triangles, since shading is then interpolated between the triangle's vertices at the pixel level. To avoid this problem, it would have been possible to evaluate the scattering equations at the pixel level.. but it would have been too slow.
In addition, even in the vertex shader, the limited amount of samples along the ray generated some quality problems at sunset or in the "transition" zone between the day & night, when you were looking at the planet from space. To avoid this problem, I had to artificially increase the tesselation/level-of-detail of the planet from space.
There was another annoying problem with the old atmosphering scattering algorithm, but it's a bit more subtle to understand. Because of the low amount of samples, when you were standing at ground level looking at the horizon, the sky's scattering amount did not match the ground's scattering amount. Basically, the sky color wasn't perfectly matching at the horizon between the sky and the ground. When the colors were saturated this was mostly invisible.. but if you paid attention and knew where to look, it was definitely noticeable.
This is why we've decided it was time to revisit atmospheric scattering and use a more modern algorithm.
Precomputed Atmospheric Scattering
In 2008, Eric Bruneton and Fabrice Neyret, from the INRIA(France) posted a new paper titled "precomputed atmospheric scattering". It quickly caught a lot of attention in the graphics community, since for the first time it allowed a physically-accurate rendering of the sky in the pixel shader, without using any major trick. This is what we decided to use. For the curious, here's the link to the article ..
With this new algorithm, rendering the sky in the pixel shader involves a bunch of parameter computations, and then sampling a precomputed 4D texture. Unfortunately there's no native support for 4D textures on modern video cards/gpus, so the 4D texture is actually encoded as a stack of 3D textures all packed into one big volume texture. It gets complex really fast..
One problem with this algorithm is that, as its name says, it relies on precomputing all the scattering equations. This step can be done off-line and stored into a texture file, or on-the-fly as needed using the gpu. But the calculations take up to a second or two. That doesn't sound so bad, but that's the price you have to pay for each planet that has an atmosphere. If a spaceship was to enter in a system that contains 20+ planets (with atmospheres), your computer would "freeze" for a minute. That's a bit of an extreme case, but even if we assume a more reasonable 5 planets, that's still a freeze of 10 seconds. Clearly unacceptable. That's why I've implemented a level-of-detail system on atmosphere tables, where a lower-resolution/detailed atmosphere is used when the camera is far away from the planet, and switches to the high-res table once it's calculated. At the moment the calculations are still done once-at-a-time, so you still get a 1-2s freeze when it happens, but in the future I'm planning to spread this calculation over multiple render frames, so it should be unnoticeable.
Terrain engine updates
In the past months I've also done some significant updates to the planetary/terrain engine. It's still far from being perfect, and there are still a lot of improvements to do in the upcoming months.. but it's shaping up. It was pretty difficult to integrate it with our new material system, but in the end I think it was worth the trouble. For example, one of the benefits we have from using our new material system is that we don't have to write different shaders for different planets, or to have multiple variants for DirectX and OpenGL. It also supports new lighting effects, such as lighting from multiple stars, or even reflection of a moon on another planet. This can make some beautiful nighttime pictures, as demonstrated below..
Precision limits
By far the most difficult task when updating the terrain engine, was to finally address the precision limits. I already mentionned that a few times in the past or on the forums, but basically, artifacts were showing up on the ground when the camera was at a very low altitude (think: simulating walking). This is because a lot of the calculations were hitting the limit of floating-point calculations in 32 bits. Therefore we have to use 64 bits, or apply tricks, whenever possible.
Artifacts fall in three major categories:
Lighting due to the limitation of procedural noise octaves level: this required us to use fp64 on the gpu, or to emulate it when it's not available. Let me tell you: that shader code is really ugly. I wish all gpus supported fp64 natively.. unfortunately we'll have to wait many years for that to happen..
Texture wobbling: some textures, such as grass, are tiled (repeated) millions of times over the whole surface of a planet. The precision of texture coordinates is also quite limited which generated some weird wobbling when you landed on a planet. I had to do some wrapping magic to fix this problem.
Cracks/gaps in geometry: sometimes the vertex coordinates do not match perfectly between adjacent terrain patches, even when we use fp64. Our idea here is to duplicate geometry and apply "stitches" between adjacent patches. I haven't implemented this yet, but it's one of my next tasks.
Performance
Unfortunately at this stage, we are not happy with the performance of the terrain engine. We're planning to reserve a bit of time to make a round of optimizations before we release a new tech demo. All the pictures in this journal were taken in 1920x1200 with SMAA antialiasing, on a Radeon HD 6870. Framerate was an average 30 fps.. we'd like to double that number at the very least. There's also still some work to do on the texturing, to avoid that sharp transition between grass and snow seen on the mountain picture, or avoid too noticeable repeating patterns in the textures. Shadows will also come back soon. |
Proud member of Frustrated Association of International Losers Failing Against the Gifted and Superior (F.A.I.L.F.A.G.S)
|
|
| Back to top |
|
|
| Page 1 of 1 |
All times are GMT + 1 Hour |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB 2.0.8 © 2001, 2002 phpBB Group
|
|
 |
|
I've been following Infinity for a while now and the premise looks/sounds excellent (I especially love that you can fly into the atmosphere of a planet, that was sorely missed from Freelancer/X-series) but I honestly don't think it's ever coming 
