I’m attempting to create a solid floor with unit boxes as the title of this topic suggests; only I’m fairly new to jME3 and 3D programming in general. Using the beginner tutorials I’ve attempted to create a function to create a floor and give each segment (Box) physical properties. This compiles, runs and works properly - only the fps drops to almost zero for a 20x20 floor. I have a HD4670 1GB gpu and 4GB of RAM so evidently it’s my programming and not my hardware causing the problem!
The function making this floor is:
Code:
private void initFloor(int x, int z) {
Box[][] boxArray = new Box[x][z];
Geometry geom;
Material mat;
boolean colourTicker = true;
for (int i=0; i<x; i++) {
for (int j=0; j<z; j++) {
Vector3f translationVector = new Vector3f((float)i, -2, (float)j);
boxArray[i][j] = new Box(translationVector, 0.5f, 0.5f, 0.5f);
geom = new Geometry("Box", boxArray[i][j]);
mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
if (colourTicker) {
mat.setColor("Color", ColorRGBA.DarkGray);
colourTicker = false;
}
else {
mat.setColor("Color", ColorRGBA.Red);
colourTicker = true;
}
geom.setMaterial(mat);
geom.addControl(new RigidBodyControl(0));
bulletAppState.getPhysicsSpace().add(geom);
rootNode.attachChild(geom);
}
}
}</div>
Yes it is your hardware, it cannot do what you tell it to do so fast. But your approach is about the worst way you could attempt this, the beginner tutorials actually warn you about this. Are you planning on doing a box world or whats it about the boxes? A box world does not consist of boxes. Read the many posts on box world and voxel engines here in the forum if you plan to do something like this.
Box worlds do not use boxes. Having many, many, boxes is a lot of geometries and that slows down the rendering because each geometry has to be sent to the videocard. Instead use fewer geometries comprised of many polygons to build up areas of the world.
Search the forums for “Voxel”. There are lots of threads on it and that is how Minecraft and Mythruna work.
Having searched the forums for voxel related stuff, it seems a shame there’s no user guide or form of tutorial to ease people into it. Even the source code is hidden and not simple to get to!
You’re welcome to start a guide on the wiki with your search findings. People would definitely read it.
A lot of the voxel worlds people are building are for their own proprietary use that they plan to sell later on. So the code won’t be available for them. There are several “starter kits” that are open source however, google search comes up with a few.
Is there a likelihood of voxel-based programming perhaps being integrated into jME3 or at least as a plugin? It seems potentially important enough to warrant it.
If someone paid for the time to put it in, sure that would get it started sooner rather than later. We all work for free on jme in our spare time, and there are lots of game types to consider, besides voxel. Right now we are trying to stabilize the engine, fix bugs, and make it more extensible by others.
Having read up some on voxels, I must admit I don’t see how it gets around the problem of multi-geom landscapes? It just seems like a method of representing what boxes should be there - in order for each box to be independently ‘interactive’ it still seems like you’d need a geometry and physics control for each one.
Like I said I’m fairly new to the 3D side of programming so apologies if this is completely wrong, just trying to get my head around it.
My understanding is that since the landscape is mostly static, you render it as quads because you only work with one box at a time anyway. So in a way, the interaction with the scene is really a special case. 99.9% of the time, you are just rendering a mesh of quads and not boxes.
@ancalagon said:
My understanding is that since the landscape is mostly static, you render it as quads because you only work with one box at a time anyway. So in a way, the interaction with the scene is really a special case. 99.9% of the time, you are just rendering a mesh of quads and not boxes.
Yeah, that's right. You break the world up into larger meshes based on size or whatever... trying to balance performance versus the speed of regenerating sections when a block changes. Physics is a separate issue.
I think people try to make block worlds because they think that it is somehow easy. The truth is that it is only easy if you already know 3D graphics pretty well. A lot of things that an engine like JME provides, you won't get to use and will have to write yourself. Your own meshes, your own paging, your own collision code, your own physics, etc.. And for JME to support these things it will basically have to write second versions of many things because the optimization of a large block world is very different from the optimization of a game that loads predefined levels, geometry, etc..
So basically you’d create a custom mesh out of the Quads (or perhaps Boxes since Box = 6 Quads?) in particular size ‘chunks’? 64x64x64 for example from Minecraft and then separate any particular Box from the mesh upon interaction and/or change? In the case of my floor it would be a 2-dimensional equivalent. Am I hanging off the right tree here? (monkey joke ;))
I think Minecraft does it in 16x16x128 meshes… but I’ve never bothered to look. That’s just what I guess from playing and watching terrain load in.
In my case, in Mythruna I just regenerate my local mesh whenever a block is added or removed. Moving blocks would be detached and handled differently but I don’t have that case yet.
No you dont use boxes at all, the reason being is that boxes have quads in places where they will never be seen. The only time you would use a box is if there was a block that was floating in mid air by itself. Because then it could have 6 quads and all 6 could be visible.
Since that will happen so seldom, most likely you will build up your mesh of quads from another representation of your terrain. My uneducated guess would be that you could store a virtual representation of your terrain in some kind of data structure, and use that to generate your quads. You would do this only once - when you first load the level. Once the level is loaded, you just modify and/or remove individual quads or groups of quads as needs be, referring back to the virtual representation if you must.
Like you could have a 3 dimensional array of Blocks, where each block has a material, for instance. When you create your mesh of quads, you would use that array to work out where to create a quad. Basically you would only create a quad if their was no adjacent block.
This is all purely guess work, so as has already been mentioned I suggest you take a look at some of the examples mentioned above.
@ancalagon said:
Why does everyone want to make Minecraft clones?
Because they think it will be easy.
In my case, it was easier than the alternative I'd been poking at for 6 years... but I also have 3D graphics experience. ;) If I can ever swing back and resurrect my real terrain code, I totally will.
As mentioned earlier in the thread, it’s (mistakenly) seen as an ‘easier’ place to start. I’m not building this for any commercial or proprietary purpose, just wanting to explore 3D capabilities and learn as I go along.
That’s my reason anyway, can’t speak for others of course
