Build A World - new game just launched on Kickstarter
For all who might be interested, we would like to present the new sandbox construction game Build A World, that we have been developing over the past 18 months. We welcome any questions, comments or suggestions on our facebook page (see below), where you can also follow our progress.
Build A World is an indie-game, and everybody involved are pitching in with a specific set of skills. We are at the moment seeking alternative finance via the funding platform http://www.kickstarter.com/projects/.../build-a-world, in order to speed up the development - including a Linux version of the game. You can follow and/or donate to our project there.
Since this is phoronix and we all love graphics, drivers and compilers and benchmarks
I may as well post a few technical notes, remember all the rendering tech makes it through the linux build first and then is approved and merged into the general build. So there is a guarantee and the Linux version of Build a World will never be behind on graphics compared to other platforms.
Minimum System Requirements
OS: 32bit Linux with Kernel 2.6 or greater, 32bit Windows XP or greater, Mac OSX subject to manpower
Dual Core 2.1Ghz CPU
1GB of RAM Linux, 1.5GB of RAM on Windows
256mb Graphics Card with OpenGL 3.0 capability
(with exception of Intel HD Graphics from Arrandale generation of core-i CPUs)
Internet Connection for a few seconds to login
Constant 56kb/s internet connection for Cloud Servers
BIG MASSIVE NOTICE: RECOMMENDED SYSTEM REQUIREMENTS ARE THE MINIMUM HARDWARE THAT YOU NEED TO PLAY THE GAME IN MAXXED OUT SETTINGS!!!!!!!
Current Recommended System Requirements as they stand
OS: 32bit Linux with Kernel 3.0 or greater, 64bit Windows XP or greater, Mac OSX subject to manpower
Quad Core 2.7Ghz CPU with hyperthreading (i5 or i7)
2GB of RAM Linux, 3GB of RAM on Windows
1GB NVIDIA or AMD Graphics Card with OpenGL 4.2 capability (Tessellation Shaders)
And also here is a list of all the rendering tech in the game
Tessendorf GPU-FFT based water (1)
Using the same technique as Crysis 1 and 2 for simulating the waves on an ocean surface, but accelerated by the GPU (and the displacement map is 4x larger)
Radix-2 FFT is running in SM 3.0 Complex Water Shaders
Water has many settings, micro detail normal maps are used to augment resolution. Water supports dynamic reflections and refraction. There is a choice of adaptive software or hardware tessellation for actual vertex displacement Simple DLAA
To provide Anti-Aliasing despite the Off-Screen Rendering pipeline, we use DLAA as a post process HDR
HDR seems to be a requirement in modern games, what would be lights without the glow around them?? Dynamic Resolution Rendering (2)
Standard approach on consoles, we dynamically scale the viewport so resolution varies in order to ensure smooth gameplay. This comes especially handy in large forest fires when you're walking through the burning forest because how much of the screen is occupied by particles causing a bottleneck in fillrate. The resolution adjustment system makes sure that the resolution is only dropped as much as necessary in order to achieve 24 FPS while moving.
The GUI is rendered at native resolution at all times Occlusion Queries Culling (3)
The polycount for the entire world while looking out over the ocean can be as high as 5 million.
This was optimized by a complex hardware occlusion query system which determined which regions of the map are visible, it works so well that the rendered polycount inside houses is around 80 thousand
It also makes sure reflections are not rendered if no water surface is visible Very Large Simulated Fires (3500 simultaneous blocks on fire)
Our fires spread from flammable block to flammable block (one of the greatest sights is oil floating on water while burning), this enables you to burn down entire forests. Burning blocks emit huge smoke stacks which will soon be collision simulated through sampling or cone tracing mip mapped fluid flow resistance fields (like opacity) to provide realistic interaction with obstacles. 100k+ Particles run in realtime even on the old 8800M Nvidia card with only 196mb of dedicated memory. Superfast SSE3 Optimized Particle System -- going to be offloaded to a separate thread with enough HH:MM:SS and $$
In the beginning the framerate was struggling because the rendering thread had to do weightlifting with animating loads of particles, the performance of the C++ code was improved 3 times over by using SSE3 ASM instructions to enhance FLOPS throughput.
We use SSE radix sorting to sort the particles when needed (certain types of OIT allow us not to do so)
This CPU cost will stop affecting the framerate once the particle animation is offloaded to a separate thread. Radiant Flux Volumes
We store the lighting for many possible empty points (light probes in the new lighting system) in space so dynamic objects are lit accordingly to the lights and obstacles in their surroundings. Particle Lighting
This Radiant Flux Volume also makes the smoke pickup the lighting appropriately, sometimes this results in shafts of shadows through the smoke or smoke lit by surrounding lights (the fire itself) Soft Particles Forced On At All Times
Building on the research in the work using the Z-Buffer to feather out the hard Z-fail edges by assuming a volumetric billboard, most of the Z-clipping is not visible. I use a cosine based, (like tukey windowing function) function which has a smooth differential without any violent breaks. It is even enabled for the Intel Cards, because in this completely destructable world there is no way to prevent particles from intersecting geometry like in standard video game productions. GPU billboards
The particle camera-alignment and rotation due to rolling motion are not carried out on the CPU, this makes sorting a lot faster because each particle is represented by 1-vertex with a fat-attribute buffer. The billboards/quads are extruded and transformed in the vertex and geomet High Quality animated particles
The particles are not just images, they are video sequences which are stored in 2D texture arrays. This enabled PERFECT mip mapping (3d texture does not, mip maps blend separate animation frames together) and inter-frame interpolation. The flames are actually dancing, and the smoke is rolling. Simple Indirect Lighting
Søren's intial light engine which enables you to have shadows, indirect light shining into caves and COUNTLESS light blocks. Light blocks have ranges of up to 20 blocks and the light transfer is shadowed. This means that if you build a house and place a light in one room, it does not leak through the wall into the next one. Anisotropic Opacity and Fluid Flow Volumes (8)
Building on the basis of pre-integrated hierarchical opacity, I derived a encoded representation of the world which is dynamically updated. The Fluid Flow volumes are not only used to determine the soft collisions of smoke puffs with geometry, but will also be used for accelerating path-finding, AI, collision detection, free space detection, various optimizations and visibility checking (could be used instead of occlusion queries). Order Independent Transparency as Weighted Average
Because of the availability of alpha-blended glass blocks, aquariums, etc. it seemed very important to explore ways to render transparency which did not require sorting every triangle. Weighted average has its shortcomings in fillrate and brighter objects showing through. This is why we need more developer time to explore two more alleys of OIT. Note: OIT was always limited to tech-demos, never featured in a full fledged game (with exception of depth peeling) Joystick/Gamepad Rumble (Linux only right now)
Since you're running around with a drill, and the game is supposed to be ported to PS4 sometime, I thought it would be useful to provide consistent experience across both. So why shouldnt a PC player enjoy the knowledge of which drill they are using from the magnitude of virbrations in his hands or navigating through the world with something more comfortable than WASD keys.
Intelligent Renewable Energy Electricity Generation Simulation
Part of a bigger, AND MORE EPIC power system which is core to the game, there is the physical and graphical response of the game logic to the actual inputs. In no other game did the render output affect the game logic, here if the solar panels are in shadow they do not generate electricity and if there is no free room for the air to move in front of the wind turbine then there must be no wind and therefore no electricity! (should stop cheaters from hiding their fragile wind-farms in caves)
Realtime Atmospheric Scattering (7) -- Development Taking Place
The game has a night-day cycle, and also will feature a realistic skydome with amazing sunsets and sunrises. Furthermore, the output of the skydome synthesis is the main driver behind the new rendering system which will light the world based on the luminosity of the sky. Spherical Harmonics Irradiance Transfer for support of insane amounts of lights and global illumination (4,5,6) -- Development Taking Place
This is the most meaty piece of Next-Gen technology in the game. After months of research and design, a vision for a system has been consolidated which is a hybrid of the approaches towards Global Illumination used by CryEngine 3 and Unreal Engine 4.
This puts the renderer almost on par with CryEngine 2 and Unreal Engine 4
CryEngine 3 uses Light Propagation Volumes where a camera frustum volume is subdivided much into more detailed and cascaded subregions which contain light probes which contain the lighting distribution from all directions encoded as Spherical Harmonics.
We have need for a similar Volume of Light Probes to provide lighting information to any dynamic object which may move through it. The VRAM requirement for significant detail for the actual blocks was prohibitive
Also we wanted faint possibility of specular indirect lighting, having seen the Cryril Crassin paper "Sparse Voxel Octree Cone Tracing for Realtime Indirect Illumination" and it amazed me.
Obviously we cannot require the hardware necessary to perform the cone-tracing necessary to calculate lighting for every pixel, every frame. Also OpenGL 4.2 would be required to handle the Sparse Voxel Octree structure
Hence I designed a new system which would take the best of both worlds, use the GPU for the intial cone tracing but use it for the primary light (rejecting the need for shadowmaps) and to actually use the environment map to provide lighting which matches the atmospheric conditions. It uses the GPU to precompute lightmaps for the intial light, downloads the data to CPU and performs injection and gathering of indirect light for 2 BOUNCES of indirect providing INSANE global illumination. The light distributions are stored as spherical harmonics instead of gaussian lobes.
A lot of the work is actually complete, cone distributions and SH synthesis, the deriviation of math for Triple Product Integration and Double Projection (so I can have normal mapping, enviornment skylight being multiplied with Ambient Occlusion).
Main pains is the non-blocking fast transfer of data like the opacity volumes and direct lighting results to CPU for refining with Indirect Lighting and back to GPU. Also the fact that the SH coefficient between vertices in a quad is completely flawed so that one can see the individual triangles, forced me to sidetrack to develop a DYNAMIC LIGHTMAP SPACE ALLOCATOR which adds complexity to the system be requiring me to manage allocated rows in a lightmap and provide the meshes with another set of texture coordinates.
There are already some test images generated with the new AO and shadowing technique.
Sparse Voxel Octrees are really turning out to be THE DATA STRUCTURE, so will most probably be used in a ton of different places to reduce memory consumption and improve performance.
Realtime-Raytraced Shadows for Dynamic Lights (Head lamps, rockets) -- Development Taking Place
Using the left-over Opacity field and cone tracing functionality, one can trace a cone in order to produce perfectly anti-aliased soft shadows Low Frequency Realtime Glass Reflections (reflections true to surroundings)
We have a spherical harmonic describing the ambient occlusion at every vertex, this is basically the same as having a reflection map at every point. the AO can be used to mask out the skydome reflections. Spherical Harmonic Based Radiance Volumes
A great improvement (and the cause of the VRAM requirement) to the original Radiant Flux Volume which is being used to light our dynamic objects, only this time the AO*Skydome+LocalAndIndirectLighting are encoded as a spherical harmonic which "saves" the directions of lights. This enables very good lighting (insanely good lighting) and the use of Normal Maps. Radiance Volumes Compression
Improvement to the above so the VRAM requirements drop, most probably involving the synthesis of a sparse voxel octree for the radiosity data for SH coefficients other than 0
From my intial designs on that matter, it would appear that DX11 is not a prerequisite for reading from such a structure on GPU. It only is if SVO is constructed on the GPU.
Fluid Flow Particle Simulation -- Development Taking Place
Not ACTUAL Navier-Stokes simulation, but takes into account the resistance to smoke flow through forests and will prevent smoke going out of caves THROUGH their roofs. Normal Mapping, Parallax Mapping, Parallax Displacement Mapping and Tessellation Displacement Mapping
Insanely detailed blocks:
Geometry through the Parallax and Displacement Effects (containers don't look like plastered on photos, tons of detail)
Lighting through the Spherical Harmonics (able to use the stored light directions to convolve against the normal map) OpenCL and offloading Indirect Lighting
Uses all the spare computing power you have (no other game or game middleware does this) independent of Hardware manufacturer (i.e. no NVIDIA dependent CUDA implementations) in order to not burden your CPU with the indirect Lighting Pass. The Indirect Lighting will be spread to all other OpenCL and C++ computing devices before the application will resort to using the rendering GPU (if OpenCL capable)
REAL boost to Nvidia Optimus Laptops Phong Tessellation to smooth characters and animal geometry
We save on polycount and CPU/GPU time spent skinning the animated mesh by reducing vertex count and reconstructing a smoothed high-poly version on the fly in the GPU shader from already crunched animation algorithms... also dependant on the model's size on screen - fully adaptive Video RAM requirement reduction
By employing different forms of DDS compression and sparse structures on our volumetric textures (opacity volume, and the biggest consumer of VRAM -> the Spherical Harmonic Based Radiance Volumes) Hybrid Sunlight Shadow techniques (shadowmapping or conetracing)
I already find myself having to add a large bright spot into the sky to simulate the sun being a lot brighter than ambient light, there is a possibility that this can be factored out and we can have very HQ shadows and spend less memory on the spherical harmonic for omnidirectional-per-vertex and per-probe AO Mixed Resolution Particle Rendering (11)
In order to make the fires run faster (they are magnificent, spectacular and awesome) the fillrate bottleneck needs to be reduced. Rendering the sufficiently close fire particles which take up a lot of the screen at lower resolution could save a lot of fillrate and improve FPS in heavy particle rendering scenarios even by factors of up to 2x Order Independent Transparency as Depth Peeling
The almost perfect solution for machines with extra 40mb of VRAM spare. The blending equation is totally satisfied, objects of varying transparency appear to be in correct order. This method is compatible with ALL GPUs which clear the current minimum requirements to play the game. Order Independent Transparency as Linked List Alpha Buffer (OpenGL 4.1)
The ideal way to render transparent geometry, pixel perfect and close to the ideal solution. Only downside? Compute shaders required! Volumetric Light Shafts Godrays (9,10)
For the extra bling, I want lightshafts as I am walking through the forest. This has been purposely put off until the violent evolution of the particle system, emitters and rendering has stopped, so that once implemented the smoke stacks from burning trees and glass will produce their own shafts. Bicubically Interpolated geometry for Waterfalls -- Code Awaiting Resurrection
We already had nice shaders for waterfalls which had animated water rushing down them, but the generation of the meshes was overlooked (devs are crazy overworked 24/7) and fell down the priority list. In the future they will be smooth meshes (waterfalls will not be blocky) that can have tessellation shaders doing the heavy adaptive work and displacement mapping to break the illusion the waterfall is a smooth marble sculpture, an animated texture so it doesn't look like its just an image scrolling down. Parallax mapping to break the smoothness and make things stick out, normal mapping to light the thing to give it more depth. Compute Shader based image Blur
Blur has always been very slow, because it was implemented as a gather operation. Large blur kernels with lots of samples caused cache trashing in the pixel shader crippling the performance. I would love very large halos around lights like in Crysis 2 Ultra at cost not related to the radius of the blur. GPU Skinning
Using the CPU to move around thousands of points in relation to tens of bones for multiple mobs every frame is a waste. Vertex skinning has proven to be a very cheap solution to such a problem AND allows to store the mesh as a VBO in VRAM resulting in less memory transfer between CPU<->GPU every frame and improves the FPS by a lot. Replacement of DLAA with SMAA
DLAA has not worked as great as expected due to a lot of high frequencies in the textures (very detailed). Also it was one of the first things implemented when we did not know whether using the depth buffer is necessary (due to water rendering and particles we use it anyway). Naturally an Anti-Aliasing approach based solely on color analysis is inferior to one supplemented with the depth information. It would be nice to use an AA method which uses the depth info. Better Tone-Mapping Operator
The equation that we use to adapt the camera exposure is not perfect, there is a lot of research into colorimetry and auto-exposure that needs to be taken advantage of