@olse said: nice thank you. in the meanwhile i got the solution myself but thank you very much, anyway ;)i havent looked so far but is there an easy way to import higher resolution textures with for example 32x32pixel without making a new material?
Resizing the terrain.PNG will automatically resize all of the subtextures. The blockskin assumes there are 16 textures pernrow per column and does all the math for their actual size past that.
Alright got it down to this, it’s rendering a 320x320x64 volume, -160 -> 160 in both the x and z directions.
I don’t think I’ll be doing much more with the re-write as it’s gotten to the point where it will function perfectly as a simple block-plugin without needing more input. more advanced features can be added if others want to step up (such as a threaded mesher, fixing the textures on the MarchingCube algorithm, or fixing the texture wrapping on the greedy mesher).
Sourcecode is available here: GitHub - Sleaker/Cubed: JME3 Cubes plugin re-write. All code not specifically detailed otherwise is licensed under MIT. Originally based on: https://github.com/jMonkeyEngine-Contributions/cubes - if you would like to incorporate it into the current Cubes etc please attribute the changes I’ve made. I believe destro had the original in BSD.
Hm… a maximum of 256 textures… I can see how one would want to extend that one day.
I can’t speak for Destroflyer, but I suggest you try to integrate your code into his, let SVN create a patch, and send that patch to him.
Unless he’s going to do this anyway.
I doubt any third person would do that right, he’d have to learn the ins and outs of his and your code before doing so.
@toolforger said: I doubt any third person would do that right, he'd have to learn the ins and outs of his and your code before doing so.
This has all the same texture limitations as the original implementation I didn’t make really any changes to the naive renderer, I just abstracted it out to allow for alternate ways to handle the meshing. The big change is how the Chunks are handled via paging. This is one of the things that needs to be fixed into the current implementation as the current is a static array that can’t change.
I was able to get TextureArray working, so the greedy mesher is fully functional now. I uploaded the changes to the stock shader that are necessary to get this to work. It does require opengl3.0, but the code can easily be swapped back in the plugin to uploading vector2s and the shader will inherently work with a texture atlas. The way BlockSkins register was re-written though, and there is a bit more going on in the background for use with the texture array.
Here’s a picture of it all working together. As discussed earlier, even with random terrain like this, the naive mesher resulted in about 4.4 million verts, and 2.2 million tris (some are probably culled by JME3 automatically). Where-as the greedy implementation results in 1.2 million verts and only 620k tris, which seems like a pretty significant reduction given that with the naive meshing I was starting to get close to the graphics card’s limitation given the test area.
Is this plugin still in development or has it stopped? Looks like it could be awesome!
@KingPepe said: Is this plugin still in development or has it stopped? Looks like it could be awesome!
I posted my code up on github. It’s in a respectable state to be used as a basis for an actual game/app. I’m not too familiar with what all goes into pluginizing something so I wanted to kind of stay away from that to start with. I haven’t had much time to enhance it recently though. If you mean the original version called Cubes, I think development on it has mostly stopped.
I still plan to develop Cubes a little bit further, I just dont find the time for it. So I can’t really tell you when there will be an update, when I have some spare time, I’ll give it a look. 
Wow gratz to both sleaker and destro for this, I’ll be playing around with your updates sleaker! Thanks!
Hi, I’ve been doing some fiddling tov Cubed, the Sleaker’s thingie and it seems nice to use yet quite simple. I’ve yet to test Cubes once it gets the SLeaker’s mesher. For now I’m playing with Terrain Generators (ping me about it and I’ll post screenies), but there is a question that had been poking me :
What kind of code structure do you use? What kind of pattern?
Hey guys, just announcing there will be an update soon. 
It will contain a few internal optimizations, as well as custom shape support - Yes! Cubes will no longer only support … cubes^^
I also use a new texture for the tests. Preview:
Is the library aware of the difference between a cube (can occlude, can be occluded) and a noncube (does not occlude anymore, can still be occluded)?
Yes.
@toolforger said: Is the library aware of the difference between a cube (can occlude, can be occluded) and a noncube (does not occlude anymore, can still be occluded)?
There is no cubes… Its just the surface.
I hacked in a way to have a skin rotate the textures on specific faces, to be able to “rotate” an entire block like the logs and pistons in Minecraft. I don’t think it was possible in the code you had so far. Are you interested in my code, or is there a way to do this already?
I did something similar, and it wasn’t too hard to implement. I created a class called SidedTexture that you can assign a texture string to as well as the desired faces. I also changed up the block registry and stuff so that there can be a theoretically infinite number of unique blocks, all specified by JSON file.
The plugin is meant to make voxel worlds easy to make, though. Might as well support the most commonly-used things from the start. The infinite-block-types thing would also be nice, especially if it can be done in a custom texture atlas so people only have to load the images and feed them into this stuff, rather than aligning everything manually.
This looks really cool.
Could the license (like BSD or GPL) be put on the wiki page and/or in the jMonkey Plugin description?
I couldn’t find what it is licensed under.
EDIT: I see it has a New BSD license; I saw it during the installation of the plugin
Can see it here - http://jmonkeyplatform-contributions.googlecode.com/svn/trunk/cubes/license.txt
@destroflyer - looking cool. Were you able to pull in any of my changes to how chunks work? It’s pretty necessary to have non-positive chunk locations.
@sleaker said: @destroflyer - looking cool. Were you able to pull in any of my changes to how chunks work? It's pretty necessary to have non-positive chunk locations.
Hi sleaker, have created a working in progress project called Greedy Vox, based off your greedy render and destroflyer framework, plus roleary documentation, currently working on a chunk manager for an infinite world, impressive work from you both (sleaker and destroflyer), had to rewrite some of the greedy render code to implement a block texture atlas (16 x 16) blocks using GLSL100 shader, also rewrite code of the framework to use your non-positive chunks (Hash Map) to implement removing and placing blocks across all chunks with a one dimensional byte array of blocks, without any optimisation and still a prototype working progress, was able to render 121 million blocks with ease, also can render a minecraft multi-player chunk radius (21, 16, 21) of 16 x blocks, with noise generated terrain and multiple block types plus shadowing, all while rendering over 300fps, thank you guys for sharing your work and happy to share if anyone is interested.