Cubes – A Block World Framework [Update Preview]

EDIT: Actually, I figured out the issue. Sorry about that!

Hi Destroflyer,

I already toyed with your plugin and have to say it works realy good, but I stumbled across some smaller issues why I can’t use it for my hobby project like the issue with the negative coordinates.

As the source is available on the community google code repository I wondered if it is ok with you when I fork your work and do some alterations for my project.

Of course I will make my changes available to you so you can see what I do with your baby :slight_smile:
But as a warning I don’t have much time so my work is slow.

No need to reinvent the wheel and the more people use/work with one plugin the longer it is kept alive

Hi Destroflyer,

I’ve been playing with your plugin and it works great.
I wanted to compare the performance of a block world between my desktop PC and my Android mobile. However, when I launch the application on my mobile an exception appears saying:

OpenGl ES does not support 32-bit index buffers. Split your models to avoid goin over 65536 vertices.

So my question is, does this framework work in android? If yes, what I’m doing wrong or what I need to change to run this framework in my mobile??.

Thanks!

@galvez6000
A blind guess is the index buffers are integer based and should be shorts. You’ll find this in whatever the custom mesh class is in the library. You likely need to adjust the maximum chunk size appropriately.

I’ve never used the plugin, so this is a complete guess. I’m sure either you or someone else can verify this though.

Yes it uses integers

[java]
private static Mesh generateMesh(){
Mesh mesh = new Mesh();
mesh.setBuffer(Type.Position, 3, BufferUtils.createFloatBuffer(vertices));
mesh.setBuffer(Type.TexCoord, 2, BufferUtils.createFloatBuffer(textureCoordinates));
mesh.setBuffer(Type.Index, 1, BufferUtils.createIntBuffer(indices));
mesh.setBuffer(Type.Normal, 3, BufferUtils.createFloatBuffer(normals));
mesh.updateBound();
return mesh;
}
[/java]

I was making some changes to facilitate better random terrain generation and wanted to know how I would go about getting my changes included into the main repository?
I’m familiar with git, but haven’t done anything in svn, and I’m working on some changes to how Noise is defined and handled to allow it be extensible as was listed on the projects eventual goals.

Thoughts?

I was in a similar situation several times, and I simply prepared an SVN-formatted patch and posted it in the forum.
I made sure that the patches were formatted as source code so they’d be readable.
I never got complaints, so I guess it’s okay for the occasional contribution/change request.

@toolforger said: I was in a similar situation several times, and I simply prepared an SVN-formatted patch and posted it in the forum. I made sure that the patches were formatted as source code so they'd be readable. I never got complaints, so I guess it's okay for the occasional contribution/change request.

Cool, one of my biggest concerns right now is the BlockManager being static. From experience, static block registries cause absolute hell when you start getting into more advanced triggers/manipulation and unit testing. This is one of the things that I’d highly recommend for the singleton pattern. Though at this point the BlockManager is just a shell cause it doesn’t really do any type checking or duplicate registration verification etc.

Nice to hear, people are using my framework - Your changes and opinions are more than welcome. I think, the best solution would be to just send me your code - I will then try to see which changes fit and will adapt the svn. :slight_smile:

1 Like

So the first thing I started working on was better meshing & blockstore methods. I have a test going right now with 2 different ways to generate the mesh naive and greedy. Thanks to @roleary for posting up code on doign the greedy stuff. I’ve adapted it to work with textures as it was rotating them all wonky. The last thing I have left to fix is texture wrapping on the texture atlas, right now it just bleeds over into the other textures.

Here’s the tri difference though in a couple of my examples:
Naive Meshing:

Greedy Meshing:

You can see that there is a big reduction in tris, mostly due to rendering the sides/bottom at the moment which you wouldn’t necessarily do in a fully loaded world (haven’t gotten that far yet). If anyone is interested in helping out I can throw my code up on github.

I’m hoping that this can eventually replace the current ‘Cubes’ framework in jme3, as it has a number of significant issues I mentioned earlier in this thread.

3 Likes

So great, loooking forward to this a lot. I will post what can be done with the engine as soon as I can. And also may contribute with a TMX parser for 2D to 3D tilesets mapping.

How do you place textures when the triangles are “optimized”/missing?

I had the same question (but couldn’t word it that succinctly).
I can currently imagine three different approaches.

That’s looking very cool :slight_smile: I also wonder how you place the textures.
I still want to code the part where the mesh is created a little bit more dynamic, so there can be multiple approaches available (naive, greedy, maybe something smoothed, …).
Unfortunately, Cubes isn’t a project with a high priority for me at the moment, but I’ll do what I can to keep it stable and improve it with your contributions.

@normen said: How do you place textures when the triangles are "optimized"/missing?

Right now they aren’t placed correctly, so that’s one of the problems that needs dealing with, but I did just abstract the renderer (allows for cycling between test renderers easily). If people are interested I can also show a basic MC meshing algorithm that snaps to whole-int values.

As far as ‘how’ it’s done, texture wrapping.

Hm… texture wrapping means you can’t merge block faces that have different textures. I.e. best for mostly-uniform scenes.
Alternate approach 1: Build textures on the Java side when doing the block face merge. Downside: can be slow if blocks change frequently.
Alternate approach 2: Write a shader that picks the right texture to interpolate from. Should be fast for all scenarios but the shader is a bit complicated (extra complications at block face boundaries).

@sleaker said: Right now they aren't placed correctly, so that's one of the problems that needs dealing with, but I did just abstract the renderer (allows for cycling between test renderers easily). If people are interested I can also show a basic MC meshing algorithm that snaps to whole-int values.

As far as ‘how’ it’s done, texture wrapping.

Its not really a trivial issue, especially when using texture atlases. If you come up with a good generic solution I’d be interested, its also an issue for repeating textures on models you want to add to a texture atlas.

Generally the triangle count isn’t really a big issue nowadays but ofc you might get some added performance out of this if you manage to get around this issue somehow.

Hi everyone,

i’ve copied the code from the sample but i get this one, if iam looking downwards…and i cant see any block :frowning: :

-> java.lang.IllegalStateException: No material is set for Geometry:

this is the code:

[java]public void initTerrain(){
//You have to specify a valid application, the framework will use e.g. its assetManager
CubesSettings cubeSettings = new CubesSettings(app);

    //The stone texture is in the 10th column and 1st row in the texture atlas
    BlockManager.register(Block_Stone.class, new BlockSkin(new BlockSkin_TextureLocation(9, 0), false));
    
    BlockManager.register(Block_Wood.class, new BlockSkin(new BlockSkin_TextureLocation[]{
        new BlockSkin_TextureLocation(4, 0),
        new BlockSkin_TextureLocation(4, 0),
        new BlockSkin_TextureLocation(3, 0),
        new BlockSkin_TextureLocation(3, 0),
        new BlockSkin_TextureLocation(3, 0),
        new BlockSkin_TextureLocation(3, 0)
    }, false));
   
    //This is your terrain, it contains the whole
    //block world and offers methods to modify it
    BlockTerrainControl blockTerrain = new BlockTerrainControl(cubeSettings, new Vector3Int(1, 1, 1));

    //To set a block, just specify the location and the block object
    //(Existing blocks will be replaced)
    blockTerrain.setBlock(new Vector3Int(0, 0, 0), Block_Wood.class); 
    blockTerrain.setBlock(new Vector3Int(0, 0, 1), Block_Wood.class);
    blockTerrain.setBlock(new Vector3Int(1, 0, 0), Block_Wood.class);
    blockTerrain.setBlock(new Vector3Int(1, 0, 1), Block_Stone.class);
   // blockTerrain.setBlock(0, 0, 0, Block_Grass.class); //For the lazy users :P

    //You can place whole areas of blocks too: setBlockArea(location, size, block)
    //(The specified block will be cloned each time)
    //The following line will set 3 blocks on top of each other
    //({1,1,1}, {1,2,3} and {1,3,1})
    blockTerrain.setBlockArea(new Vector3Int(1, 1, 1), new Vector3Int(1, 3, 1), Block_Stone.class);

    //Removing a block works in a similar way
    blockTerrain.removeBlock(new Vector3Int(1, 2, 1));
    blockTerrain.removeBlock(new Vector3Int(1, 3, 1));

    //The terrain is a jME-Control, you can add it
    //to a node of the scenegraph to display it
    Node terrainNode = new Node();
    terrainNode.addControl(blockTerrain);
    rootNode.attachChild(terrainNode);
    
}

[/java]

i hope, you can help meee :slight_smile:

thanks a lot to you

You don’t set a default material in your CubeSettings:

[java]CubesSettings settings = new CubesSettings(application);
settings.setDefaultBlockMaterial(“Textures/cubes/terrain.png”);[/java]

nice thank you. in the meanwhile i got the solution myself but thank you very much, anyway :wink:

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?