iCE³ - clone of Minecraft

[Kalith]

Here's the log file. It looks quite all right for me...

Thank you. It look fine to me as well... Chunks are appropriately loaded and updated, so there must be something wrong in the way they are displayed. Have you tried to disable VBOs (by pressing the F4 key), and does that change anything ?

I've played a longer period because I've been building a house.
I still have the freeze-on-exit bug.

Glad to hear you have fun with it anyway
About the freeze, I can see from the log file that the LoaderThread is doing nothing when the world closes, and that's not a good thing.
I've uploaded the last svn version (0037) for you [here] : there is more output written in the log file when the world closes. It could help narrow down the problem.

Damn man, nice work!
How did you draw the graphics? OpenGL in an SFML context?

Thank you !
Yes, exactly. I let SFML handle the context, and draw the world using OpenGL calls (either in immediate mode or using vertex buffer objects, depending on the user's preference).

[easy]

I've tried the new SVN version you've provided, and it started even worse: I could not move my character 1 step further than the start position, because the game just crashed and the window has disappeared!

A couple of tried to disable VBOs, as you've suggested, but before I've deleted the previous saved world. This time it has started, but there were missing chunks:


Then I've made a tunnel through the mountain, looked back, and found a visibility bug:


On the other side of the mountain:


CPU usage:


Freeze on exit, log goes here:
https://legacy.sfmluploads.org/code/73

The mountains and the water also looks great! Congrats!

I'm using SFML Uploads this time. Really nice!

[Kalith]

I can confirm the visibility bug on my side as well. I thought I fixed it, but apparently no... I'll investigate this, thank you for the feedback.

About the freeze, the log file definitely confirms that there is something wrong with the loader thread. Along with the previous log file you posted, I now know that the main thread waits for it to end... doing nothing :\ Great !
When I find the time, I'll upload another verbose binary that will print informations about the loader thread's main loop instead of simply reporting which tasks are being executed.

Currently I'm working on improving the interface a little, by giving control of the mouse pointer using the Shift key as a toggle. The world menu is being rewritten to allow creation of a new world with a different name and a different seed, as well as loading previous worlds. The "save" menu item has been removed because saving is automatic now (I may provide a "safety save" option though, in case the user fears a crash).

When it's done, I may try to remove the custom code I've added to SFML, so I don't need to ship the modified version anymore. I hope that it'll help fixing your problems.

Glad you like the new terrain though

[bronddy]

How do you control who can build in your minecraft server? I've just made a minecraft server , but i don't know how i can control who can build and who cant? How can i give and take building rights?
____________________
affiliateelite ~ affiliateelite.com ~ adgooroo ~ adgooroo.com

[Kalith]

You'd better ask your question at the official Minecraft forums, [here].
That's out of topic here.

[Kalith]

New binary release, with the following change log (svn0041).
It contains several bug fixes and a reworked feature : the "world menu", from which you can create a new world or open a previous one.
This menu is clickable, so you have to free the mouse cursor to access it. This can be done by pressing the Shift key for now (I may change the default in the future though, and allow it to be customizable).
Also, I now have access to a native Win32 computer with a real graphics card (ATi), so I discovered a few bugs that wouldn't appear on my linux laptop.

Changelog :

Code: [Select]

- Fixed the ShowMouseCursor Lua function not blocking world events.
 - Native Win32 build targets updated.
 - Fixed VBO being destroyed in the LoaderThread, where there is no OpenGL context.
 - Texture filtering disabled for lighting texture to fix bad values at texture borders (ATI cards only ?).
 - Rewritten ZoneManager UI addon to WorldMenu : can now create a new world with a new seed and reacts to mouse clicks instead of key presses.
 - Pressing the Shift key toggles mouse grab (hide/show pointer) so the user can interact with the GUI.
 - Removed unnecessary code from Block.
 - Improved log file look and added more ouput regarding world clearing.

Finally, please note that from now on, I have much less time at my disposal as I need to work for my last year of Master degree.

@easy : "Fixed VBO being destroyed in the LoaderThread" may address your chunk loading problem (even though I doubt it).

Edit : The visibility bug mentioned in the previous post has been fixed in svn0042, so it will be available in the next release.

[easy]

Cool! Thanks! I'm gonna try it later, because acually now I'm working...

[Kalith]

You can now try the latest binary, from svn0050.
As said in my previous post, it contains the fix for the "visibility bug" along with many others (collision detection, player spawning, ...).

I've also reworked the terrain generation a little. I felt the world was too flat between the sea and the mountain, so I adjusted it a bit :

Screenshot took on my gaming rig & Windows XP, with a much better graphics card (HD4770, a few years old) and a worse processor (2.5GHz dual core from AMD).
As you can see, it runs fairly well with a large view distance (set to 256 here).
I also have Ubuntu installed on this machine, so I tested the precompiled binary and it works ok, no loading or freeze problem.
Your problem is either related to your distro or your hardware. I'm sorry I can't do more... (cool game by the way

[Kalith]

Bah, from Minecraft's 1.8 update patch :

New improved lighting — day/night cycles no longer require chunk updates. Lighting is updated via a texture, whose coordinates are the block's sky light and block light levels.

That's exactly the technique I used for light rendering so far.
Do you read this Notch ?

[OniLinkPlus]

Bah, from Minecraft's 1.8 update patch :

New improved lighting — day/night cycles no longer require chunk updates. Lighting is updated via a texture, whose coordinates are the block's sky light and block light levels.

That's exactly the technique I used for light rendering so far.
Do you read this Notch ?

He actually mentioned that update long before you even started this project. He just kept holding it off until the Adventure.

[Kalith]

Oh really ? I read most of his blog posts but can't remember any reference to something in that taste. Could you point me to where you read that ?
Hehe, I was feeling a bit proud of myself, then you just killed it Thank you for pointing that out anyway !

[Sylmael]

Hi Kalith, can you tell me how this texture lighting works? Nice work btw .

[Kalith]

Sure ! It's a technique that is very specific to the pre-calculated lighting system that this kind of game uses (the different lighting values of each block is updated only when the surrounding geometry changes or when lights move).

When you build your vertex data (or vertex buffer object), you specify three additional texture coordinates, along with the usual 2 coordinates used for actual texturing.
In the first one, you store the amount of sunlight, in the second one, the amount of block light, and in the third one, the occlusion value (this last one is not necessary, but you can improve a little the look of the occlusion that way). Then, in your program, you create a lighting texture that contains pre-calculated blended lighting :

Code: [Select]

// uiLightingArraySize_ : defines the quality of the lighting, I use 64 pixels, then :
//     uiLightingArrayRatio_ = 256u/uiLightingArraySize_
// Light::INTENSITY_TABLE : table containing light intensity, indexed by block raw lighting
//     (~distance from nearest lit block), I use an inverse exponential law : exp[-a*(255-i)]
for (uint s = 0; s < uiLightingArraySize_; ++s)
{
    Color mSun = mSunColor_*Light::INTENSITY_TABLE[s*uiLightingArrayRatio_];
    for (uint l = 0; l < uiLightingArraySize_; ++l)
    {
        float fLight = Light::INTENSITY_TABLE[l*uiLightingArrayRatio_];
        Color mLight = mSun + Color(fLight, fLight, fLight);
        mLight.Saturate();

        // Store additional information in the alpha component for occlusion
        mLight.a = Light::OCCLUSION_TABLE2[std::max(s, l)*uiLightingArrayRatio_];

        lLightingArray_->SetPixel(s, l, mLight);
    }
}

Here is the resulting texture (I increased the texture size to 128 pixels for you to see better, and added different colors for sunlight (blueish) and block light (yellowish)). On the left you have the texture in the middle of the day, and on the right the same texture at night :

Basically, you can see that, at night, only the block light remains, and sunlight vanishes.

Then, when I render the blocks, I bind this manual texture and use it in a shader to produce per pixel lighting :

vertex shader, extremely simple, just sends everything to the fragment shader properly :

Code: [Select]

void main()
{
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_TexCoord[1] = gl_MultiTexCoord1;
    gl_FrontColor  = gl_Color;
    gl_Position    = gl_ModelViewProjectionMatrix*gl_Vertex;
}

fragment shader :

Code: [Select]

uniform sampler2D light;
uniform sampler2D texture;

void main()
{
    vec4 cLight = texture2D(light, gl_TexCoord[1].xy);
    vec4 cTexture = texture2D(texture, gl_TexCoord[0].xy)*gl_Color;
    float fOcclusion = 1.0 - cLight.a*0.75*gl_TexCoord[1].z;
    gl_FragColor.rgb = cTexture.rgb*cLight.rgb*fOcclusion;
    gl_FragColor.a = cTexture.a;
}

The most important advantage is that you don't have to touch your vertex data when the sunlight changes. You only need to update the lighting texture with the modified "mSunColor_", which is much less intensive than re-updating each VBO of your scene, and allows for cheap continuous transitions.

[Sylmael]

Interesting, thanks for sharing. So when i have a chunk 16x128x16 blocks (xyz) i need only 16x16 pixels lighting texture? And how this technique deals with sun light that enters a cave. When this is a 2D texture it can describe light brightness for one block per pixel.. sorry but i am little confused here. But this topic is very interesting for programmer like me.

[Kalith]

Yes you got it wrong I'll try to be more clear :

For each block in the world, you have two lighting values :

• sunlight (call it 'sunlight'), from 0 to 255, tells you how much of the sunlight reaches this block
• and block light (call it 'light'), from 0 to 255, tells you how much light comes to this block from torches or local light sources

These two values have to be calculated in the CPU using some spreading algorithm, and stored in memory, every time a light moves or a block is destroyed/created.

The first approach I used (and so did Notch), was to use these two values to compute a "final light color", and store it in the vertex data.
The big problem comes when the sun color changes, when going from day to night for example : you have to re-update all your vertex caches to use the new sun color. And this is costly (only if you use a vertex caching mechanism though, like VBOs. If you render the world in immediate mode then it makes almost no difference).

So the trick is :
When you want to render your block, you create a vertex list, and to each vertex from that block, you associate two additional texture coordinates : (sunlight, light).
In the shader, you use these coordinates to sample a "lighting texture". In pseudo code, if the lighting texture is called 'texture', you have :

Code: [Select]

texture[sunlight][light]
... which is the resulting light value of your vertex (the "final light color" I was reffering to earlier).
Actually, you can do it without a light texture, and do all the calculations in the fragment shader. The texture is just a cache that contains already calculated values, that you built in the CPU before.

Edit : I've submitted a new commit to the SVN repository. You can now change the color of the sky and sunlight for the different times of the day. Here is a sample screenshot of the game at night with the modified colors :


Contrary to what one could think, the sun color at night is plain black. The blueish tint comes from the contrast with the warm color of the torch light down the cave.