Build A World - new massive game, using Irrlicht

[sodandk]

[devsh]

new linux bins are up

[sodandk]

[devsh]

irrlicht had fixed function pipeline....

Aaaaand its gone!

[kklouzal]

irrlicht had fixed function pipeline....

Aaaaand its gone!

*facepalm*

[sodandk]

[kklouzal]

Reminds me of Chernobyl

[sodandk]

DevSH typed a bit on the keyboard:
Removed all fixed function renderers and rewrote the 4 most basic material types in shaders.
Removed 50% of deprecated OpenGL calls, and rewrote shader callbacks to grab uniform locations at shader compilation time.

framerate went up by 15%

[sodandk]

lots of Industrial blocks added:
click gallery https://www.facebook.com/media/set/?set ... 875&type=3

[sodandk]

when you reach max vram usage, the frame rate goes down, so keep to normal view-distance or whatever distance fits your card.
also next update will have more vram savings.

[devsh]

No deferred rendering.. simply because the lighting is not calculated every frame (we have wayy to many lights for that)

So no benefit to deferred shading. In fact deferred would slow the game down as we'd have to write Ambient, Normals, Specular, Diffuse and other attribs to a GBuffer which would take up 100+mb (which is a no-no on Intel cards). VRAM is very precious to us, deferred would be a waste.

We do however make LARGE use of reclaiming the DepthBuffer attached to one or multiple render targets (which gets filled up at no cost), so the only bit of deferred shading are:
-fog
-sky
-occlusion culling
-Anti Aliasing (used to exist)
-soft particles

dynamic lights (lights that move) are kept small deliberately.. so they are rotor lights, warning lights, explosions, torches etc.

The instanced rendering would have lower memory consumption, in this game the improvements would be quite big because of lots of reuse of blocks and model geometries.

WRONG: batching stuff as much as possible leads to less SceneNodes, MeshBuffers etc. hence less CPU work. Also having separate shaders for material types and a few separate textures forces us to split up the mesh buffers into more and more Nodes and MeshBuffers. Right now there are plans to make regions 64x64x64x instead of 32x256x32 to increase the polycount inside a region.

Instanced rendering is no saviour here, as you need to record the positions of the instances (no you cant instance render individual blocks, waste of fillrate, vertex processor and memory for positions), even repeated patterns are destructible so separate memory must be maintained for each mesh.

Instance rendering will only be used on non-blocks, should the memory consumption prove too great in batches (i.e. batches of flowers, powercups, etc.)
Batching is always preferable (for the sake of Intel).

Instance rendering may prove very useful with dynamic (moving) things (explosion debris flying through the air) and deforming meshes (skinned animated characters and animals).

May I assume these core improvements, rewriting stuff in shaders and removed lots of deprecated calls, will be sent upstream to the Irrlicht engine?

maybe some day when someone downloads our irrlicht build and makes a diff of it with 1.8.2
Our irrlicht is OpenGL geared, so DX drivers dont work/compile, texture format conversions are gone, 30 pixel formats are added and no care is being given to compatibility of texture functions with DX. We dropped the extra RAM copy of every texture, so you cant lock() and unlock() (we have async openGL buffers and calls for that). We have 3DTextures which dont have driver functions to add them (you simply new CTexture3D and call addTexture() on driver). Etc. etc.

but nadro has his own vision for FVF and core 3.2+, so I guess you'll just get a whole lot of backward compatibility and overhead (for keeping the DX drivers functional)

(Framerate goes down to around 20fps when moving camera while watching from a building in a city with view distance on very far at night, and lots of city lights. This with using a Radeon HD 7870!!)
You probably need deferred shading to keep system requirements reasonable, good fluid player experience.

All the lights except moving ones are static, and hence handled by a CPU lightmapper. Your FPS is 20 because:
a) you have less than 2GB of VRAM (sodan's card cant do very far in a city either because he only has 1.2GB of VRAM)
b) your gfx card is pushing 10 million polygons
c) your CPU is slow
d) you're not on weighted average transparency setting
e) occlusion culling doesnt work cause nothing is occluding (looking from top down!)

Btw, next update framerate is up by 13% so far (and not finished with OGL 3.2 rewrite either!)

[devsh]

i'm more interested in the rendering of the actual geometry right now, and the light mapper seems to be very dependent of how you represent the world (flat polygons, normal maps, displacement maps etc)

the current version wouldnt work with normal maps as it doesnt save data about the direction of the light coming in

so its not simply the case of putting the CPU algorithm on the GPU

[sodandk]

Any way the CPU lightmapper can be converted into a GPU lightmapper?
A task like that seems very good for a graphics processor instead of a CPU.

there are basically 2 ways to do this
1) port the lightmapper to OpenCL
2) use shadercode for global illumination

We have been thinking about both for a while, but will be further down the pipeline.
One big BUT is that the current world has unlimited number of lights. You can make a cube
of 100.000 lights and the game still runs just fine. That might be a heavy task with another lightsystem.

currently, the lightmapper/regionbuilder is multithreaded, so more cpu-cores = world builds faster, but
it would be quite interesting to see what OpenCL would be able to do.

[sodandk]

We have planned to let it run in a modified version in OpenGL ES.

There are some big different areas in gameplay. Some of us are now focussing on. Userroles, functional blocks etc.,
Some of the areas are more or less done, and some haven't begun dev yet.

The main 4 areas (with sub-areas) are:

* Survival
Start from Scracth
Explore the world
Learn the game

* Big World
Take part in the modern world
Work with energy, machines and farming
Be ready for conflicts and coorporation

* Designer Mode
Unleash your imagination and build your own wonder
Team up with other builders
Free access to all blocks
(Model Library / Web)

* Missions
Player vs. Player games
Tasks and Achievements
Puzzles and Games
Educational Lessons for schools

There are many details beneath each area.


and here are some screenshots of progress of functional blocks:
doors, sliding doors etc. and we are adding buttons, switches, local connecting powerlines, levers, pistons, springs and many more.



























and some rotating dynamic lights

[sodandk]

and we are at 1.8.1-baw