I'm developing a C++ version of the Minecraft client. It's completely written from scratch and it only works with a Minecraft server.

Status 18.08.2011:
You can connect and walk around.
Movement in enclosed spaces is very ugly.


Status 22.08.2011:
Rendering improved to a point where I think the "not-blending" looks nice and will stay at it. I simply like the hexagons .
Now i gotta find pretty textures.
Displays all Mobs. Creepers are Robots and Skeletons are Ninjas. The rest is displayed as spheres.



Status 07.10.2011:
Need Ogre 1.8, since I use Texture Arrays now.
Different Keyboard Controls (wasd, neo2 and arrow keys. define your choice in minecraft.cfg)
Left Shift makes you move really fast
1024x1024 Texture Array of 7 or so textures
Minecraft 1.8 Support
messed up lighting somewhat. will fix sometime.




Features:

• You hover over water, even with the server forbidding flying
• Jumping causes you to teleport 2 meters up and walk around in the air for a second
• Very fast movement speed
• You cannot die... as the minecraft server just tells you, that you got zero life... and doesn't care that you keep doing whatever you were doing.

Planned Features:

• Aimbot
• show points where you can jump to without hurting yourself
• X-Ray Vision to find different resources
• Radar to track other players or Mobs
• Dodgebot (tries to keep you from getting hit by arrows)
• Rewrite shaders to get rid of the triangles at material borders
• Create pre-programmed paths that you can run along at incredible speeds
• Use the PolyVox Pathfinder to draw in-screen-paths for the player.

Source:
https://gitorious.org/polyclient
Source looks ugly at some points. Will be prettied up $someday.

What you need:

• Ubuntu64 is the only system I have tested it on so far
• Compile Ogre1.8 yourself
• install zlib1g-dev, cmake, libboost-all-dev and libasio-dev
• "mkdir build", "cd build", "cmake ..", "make", "cd ../bin", "./PolyClient"

First off, it's great to see an open-source project being developed using PolyVox. I've cloned the repository locally and am trying to build it. For the record, I'm using an openSUSE 11.4 (Tumbleweed) x86_64 system with all updated packages.

I have a few comments. Firstly, CMake checks for ASIO, OIS, OGRE etc. would be nice so that it fails properly at CMake-time rather than compile-time. Though I am glad to see you using the provided PolyVox CMake scripts so that find_project(PolyVox) 'just works'

Unfortunately, I am getting a compile error and even more unfortunately it's an error in a heavily templatised part of Boost The pertinent part of the error seems to be:The function seems to be getting a Game*& whereas it expects a Game* or a Game&. I'm using GCC 4.5.1 and Boost 1.46.1.

_________________
Matt Williams
Linux/CMake guy

Wow, that's really cool I think it's nice to take real Minecraft data and render it differently. Hard to believe it's Minecraft actually... it's kind of surreal.

Will you add transparentcy to the trees, as the black looks a bit strange? You should be able to do it without modifying PolyVox by looking at all the triangles in the generated mesh, splitting off the ones with the 'leaf' material, then rendering those as a seperate mesh.

And yes, I think the material blending between triangles would look nice. Maybe also smooth the mesh - I recently added a LowPassFilter class to PolyVox (still needs some work) which could be useful for this.

Cool stuff!

I never thought about that. Find*.cmake is cool, I never understood that feature . It's working now. Even thou ogre was messy, but I guess you know that as google result #1 for "find_project ogre" is your thread in the ogre forums



Actually I've seen a similar error before, it's really odd.. I'll try to setup a few virtual machines sometime soon and try out other systems... basically the problem is that a "this" pointer seems to be a pointer to a reference instead of just a pointer...
there's not much point in finding a quickfix, as this problem will occur in many other places, too.


Won't work... then you can see inside the tree-trunk since there are no polygons on the top of the trunk.
Or am I missing something here?
The Custom threshold feature would be great here

The problem is that minecraft still expects cuboid collisions... it will be nearly impossible to move for the player.
I could differentiate between movement and rendering. then it would just look smooth but "act" cuboid.
Actually I think that is the only way to make movement useful...
currently it's really horrible since I have no collision checking, I just wait for the server to tell me when I'm inside a wall ...

They all seem to work now, good job. The only problem I had is that on openSUSE, OGRE is installed to /usr/lib64 rather than just /usr/lib and so CMake couldn't find FindOGRE.cmake. This can be fixed simply by adding /usr/lib64/OGRE/cmake to the list of directories in your SET(CMAKE_MODULE_PATH) command.

It might seem silly that you've got to manually put in a list of places to search for a file called FindOGRE.cmake since you'd expect that FindOGRE's job would be to, well, find OGRE. This is due to OGRE not using the find_package system in the right way. Really, they should be installing a file called OGREConfig.cmake (which would simply include the header paths and libraries) in that directory since CMake knows to looks for files looking like that automatically - this is how we do it in PolyVox, look at the PolyVoxConfig.cmake file we install. FindFoo.cmake files are designed, not to be installed by the library but rather bundled along with any software that wants to use them. I tried to argue with the OGRE guys about providing a OGREConfig.cmake file but they say that they wanted people to copy FindOGRE.cmake into their own source tree. Therefore, the best way for you to do the 'finding OGRE dance' is to copy both FindOGRE.cmake and FindOIS.cmake into your polyclient source tree (in a directory called, e.g. cmake) and add that directory to CMAKE_MODULE_PATH instead. You can see us doing this in Thermite3D. There's more information in the find_package docs and on the wiki.

Sure, that make sense. I'll git pull every now and again to see if it's fixed. If you want me to test it out and any point, just let me know.

_________________
Matt Williams
Linux/CMake guy

You're right of course, I just didn't think about it properly



Ah, so the collision detection is handled by the server. I guess that makes sense as it's a real client and not simply a 'viewer'. Then yes it probably would seem strange to do that. Smoothly blending between the materials would still look nice, though.

Did that. Still works thanks, this really saves time getting it running on new systems... I have no clue why I was going through all the effort of adding library paths manually before...


I changed the rendering style somewhat. Instead of smooth blending I chose to split up any multi material triangles and create only single material triangles. It ended up looking hexagonalish.
There are still a few ugly glitches that cause voxel borders to be seen or stretch the texture along the y axis (up).

That is indeed pretty cool



Actually I had an idea a few days ago for another approach to texturing. Rather than using triplanar texturing, projecting the texture along three axis, and then blending the result, maybe it would be better to project the texture along just a single direction but choose a different direction for each pixel based upon the normal.

Basically, for each pixel you would build a plane from the pixel's surface normal and have that plane pass through the origin of the world. Then you would project your pixels world-space position on to this plane, and use the XY position on the plane as your UV coordinates. I haven't exactly worked through the maths, and maybe it doesn't even work, but it could be faster because you would only need one texture lookup pixel.

I think it would look strange on truly smooth terrain as the texture may get distorted, but on terrain with flat suurfaces (like yours) it would look better because there's no need for the blending.

Anyway, just a thought. I can probably try it on my cubic environments so if I do I'll let you know if it works...

cool stuff.

and a new update.
info in first post.
ogre 1.8 (from dev repos) required (which again needs boost from repos)



this works great. with some more math it might even be possible to use this on smooth terrain.