Volumes Of Fun http://www.volumesoffun.com/phpBB3/ |
|
Polyclient. The compatible alternative. http://www.volumesoffun.com/phpBB3/viewtopic.php?f=18&t=256 |
Page 1 of 2 |
Author: | ker [ Fri Aug 19, 2011 7:25 am ] |
Post subject: | Polyclient. The compatible alternative. |
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 [ 77.09 KiB | Viewed 30444 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 [ 50.22 KiB | Viewed 30406 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 [ 169.17 KiB | Viewed 30202 times ] Features:
Planned Features:
Source: https://gitorious.org/polyclient Source looks ugly at some points. Will be prettied up $someday. What you need:
|
Author: | milliams [ Fri Aug 19, 2011 4:32 pm ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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 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.
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&] |
Author: | David Williams [ Fri Aug 19, 2011 8:06 pm ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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! |
Author: | ker [ Fri Aug 19, 2011 10:21 pm ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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 . 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 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 ... |
Author: | milliams [ Sat Aug 20, 2011 10:39 am ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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 . 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 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. |
Author: | David Williams [ Sat Aug 20, 2011 1:04 pm ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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 ... 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. |
Author: | ker [ Mon Aug 22, 2011 11:51 am ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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). |
Author: | David Williams [ Mon Aug 22, 2011 9:08 pm ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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... |
Author: | beyzend [ Tue Aug 23, 2011 4:52 am ] |
Post subject: | Re: Polyclient. The compatible alternative. |
cool stuff. |
Author: | ker [ Fri Oct 07, 2011 9:15 am ] |
Post subject: | Re: Polyclient. The compatible alternative. |
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. |
Page 1 of 2 | All times are UTC |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |