It is currently Sat Aug 22, 2020 3:30 am


All times are UTC




Post new topic Reply to topic  [ 15 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Polyclient. The compatible alternative.
PostPosted: Fri Aug 19, 2011 7:25 am 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
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.
Attachment:
screenshot08182011_185304068.jpg
screenshot08182011_185304068.jpg [ 77.09 KiB | Viewed 30451 times ]


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.

Attachment:
screenshot08222011_132631243.jpg
screenshot08222011_132631243.jpg [ 50.22 KiB | Viewed 30413 times ]


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.

Attachment:
screenshot10072011_103255547.jpg
screenshot10072011_103255547.jpg [ 169.17 KiB | Viewed 30209 times ]



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"


Last edited by ker on Fri Oct 07, 2011 9:11 am, edited 3 times in total.

Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Fri Aug 19, 2011 4:32 pm 
Developer
User avatar

Joined: Sun May 11, 2008 4:29 pm
Posts: 198
Location: UK
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:
Code:
polyclient/src/Game.cpp:25:82:   instantiated from here
boost/bind/bind.hpp:313:9: error: no match for call to ‘(boost::_mfi::mf1<void, Game, asio::error_code&>) (Game*&, const asio::error_code&)’
boost/bind/mem_fn_template.hpp:163:7: note: candidates are: R boost::_mfi::mf1<R, T, A1>::operator()(T*, A1) const [with R = void, T = Game, A1 = asio::error_code&]
boost/bind/mem_fn_template.hpp:184:7: note:                 R boost::_mfi::mf1<R, T, A1>::operator()(T&, A1) const [with R = void, T = Game, A1 = asio::error_code&]
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


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Fri Aug 19, 2011 8:06 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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!


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Fri Aug 19, 2011 10:21 pm 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
Quote:
Firstly, CMake checks for ASIO, OIS, OGRE etc. would be nice so that it fails properly at CMake-time rather than compile-time.

I never thought about that. Find*.cmake is cool, I never understood that feature :D. 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 ;)

Quote:
Unfortunately, I am getting a compile error and even more unfortunately it's an error in a heavily templatised part of Boost


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.

Quote:
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.

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 :D
Quote:
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.

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 :D...


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Sat Aug 20, 2011 10:39 am 
Developer
User avatar

Joined: Sun May 11, 2008 4:29 pm
Posts: 198
Location: UK
ker wrote:
milliams wrote:
Firstly, CMake checks for ASIO, OIS, OGRE etc. would be nice so that it fails properly at CMake-time rather than compile-time.
I never thought about that. Find*.cmake is cool, I never understood that feature :D. 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 ;)
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.

ker wrote:
milliams wrote:
Unfortunately, I am getting a compile error and even more unfortunately it's an error in a heavily templatised part of Boost
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.
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


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Sat Aug 20, 2011 1:04 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
ker wrote:
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?


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

ker wrote:
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 :D...


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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Mon Aug 22, 2011 11:51 am 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
Quote:
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.


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).


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Mon Aug 22, 2011 9:08 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
ker wrote:
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.


That is indeed pretty cool :-)

ker wrote:
There are still a few ugly glitches that cause voxel borders to be seen or stretch the texture along the y axis (up).


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...


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Tue Aug 23, 2011 4:52 am 

Joined: Sat Sep 18, 2010 9:45 pm
Posts: 189
cool stuff.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Polyclient. The compatible alternative.
PostPosted: Fri Oct 07, 2011 9:15 am 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
and a new update.
info in first post.
ogre 1.8 (from dev repos) required (which again needs boost from repos)

David Williams wrote:
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...


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


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


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 post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net