Hi speed, does your world consist of cubes or of quads, looking at your code you createdQuads and put sun and light on them. You dont create single cube out of the quads? Do you just merge these quads based on their material to larger chunks of quads so that you can optimize the scene better? And If you are building cubes out of quads how did you solve putting different texture on the each side of cube and keeping them when you merge the quads into cube?
A common (core) part of such a engine could be the necessary data structures/services/factories, i.e
- dynamic chunk-grid (for Open World Stuff, caching of chunks, thread bases loading/storing/…)
- chunk loader (for filling chunks)
- voxel-factories for creating real geometries
- manager for entities,
- manager for liquid voxels (water, lavel, …)
- all these with best practices for jme3 (appstate, shader etc.)
This all would be very independent … doesn’t matter what a game you are developing … only the core parts for a bloxel engine
Or something as simple as being able to pick a spatial that is culled/hidden (not sure if this is possible now), then you could batch all your meshes based on material. When you wanted to pick specific cube you would be picking on original source meshes which all are culled but pickable. If they are not sent to graphical card you get huge fps improvment cos you only will be showing few really big meshes with lots of faces.
Are culled meshes pickable in jme3? If not what would be reason not to have them pickable? Is it techical problem or is it more a question of “why would anyone want to pick culled geometry” and thats why it was not added.
Another idea which I am not sure if its supported right now by jme3 is ability for mesh to use atlast textures.
Add just those two features to the engine and you’ve come a long way. Imagine now how easy would be to implement cube world.
1. Create Source geometry (millions of cubes) that will be culled but still pickable.
2. Create batch meshes based on (source geometry) that will be sent to card for the rendering.
3. if JME3 supports atlas textures, now put atlast texture on the batch meshes.
Now it would be damn easy for anyone to get an easy start withouth heavy heading and having great math knowledge to be able to do what speed or andreas are doing.
I have other ideas as well that would involve compressing data(vertices, etc) that is sent to graphical card and then using shaders to uncompress, this stuff is to complicated for me I am programer that is best at using frameworks not building them, but talented guys like guys that make jme could perhaps be able to handle stuff like that and implement it for everyones benefit.
I found JME engine when I was looking for an easy and great engine to start experimenting with cube worlds like minecraft has. And JME is fucking great engine, very easy to use, and if guys that create it could perhaps think about adding support for first 2 ideas I suggested it would be an even greater engine. I think many would welcome offical support for atlast textures.
It could be very funny and exciting to solve such problems by ourself 
And at the end there will be some distributions for the community (maybe) …
Try to find a opensource project (like http://code.google.com/p/bloxel) and hack something!
Andreas I looked at the bloxel I love what you did there and though I am really interested to join it, I still find the design of application complex, lots of classes there mate 
And documentation is what is missing, or perhaps document that gives the overview of the classes and describes why they are needed and their relations to eachother.
I want to simplify everything, keep classes to absolutly necessary minimum, you want to be able to easily maintain the application years after you have started it and have jme3 do the heavy lifting if possible.
I think bloxel’s architecture design could be simplified a bit for sure, but since I have not built it I would not know where to start to hack to simplify it and I am sure you guys would not have liked that
Btw what do you think about those two ideas I suggested, would they not make your life easier as well and progress faster?
I like this thinking:
TerraMonkey
– When someone says “terrain system” it can mean many things. Flat terrain, run-time generated terrain, spherical worlds, infinite terrain, terrain editor, textures… All of these have many similarities but also have significant differences that can drastically affect the architecture. So how do we cope with all of the requirements out there for a “Terrain System”? We built a solid foundation that is extensible and pluggable, and try to solve many of the difficult problems up front so you don’t have to.
Few years ago you’d have to build your own terrain system but now many engines support it. Lets have also a simple foundation for being able to handle millions of simple geometries/entities on the screen.
moonkey said:
Hi speed, does your world consist of cubes or of quads, looking at your code you createdQuads and put sun and light on them. You dont create single cube out of the quads? Do you just merge these quads based on their material to larger chunks of quads so that you can optimize the scene better? And If you are building cubes out of quads how did you solve putting different texture on the each side of cube and keeping them when you merge the quads into cube?
I hesitate to get too deeply into this...
The data structures are arrays of cubes partitioned into smaller sections so they can be cached and uncached (allowing the user to walk endlessly in all directions). The geometry (for at least the straight-up cubes) is batches of quads batched by material type. Only the quads between an empty block and a filled block are drawn. Geometry is generated as needed when you walk off the edge of what has currently been generated.
Picking, collision detection, and in some cases the geometry generation are greatly complicated by the non-cube block types that Mythruna supports. This maybe increased the related code by half (150%). (A straight block world is pretty simple but wasn't going to work for my plans.)
All that being said, there's really not that much code in Mythruna. There is some duplication of a handful of classes at the moment since I refactored recently and haven't retired the old classes yet but in general things are as tight as they need to be. And given all of the other stuff in the pipeline, this is easily less than 1/4 of the code that I'll end up with. If I'm lucky.
Also, I think the majority of the code was pretty specific to my own needs. You could argue that things like the geometry generation and maybe some of the caching and geometry management strategies are reusable but even those are heavily tailored to where I'm going. To try to package them into a reusable engine nearly forces everyone down the same path where the only real difference between one game and the next are the textures and the name. :P It's not clear how it could be easily split into customizable and reusable chunks.
Since Mythruna is not open source, I start to feel uncomfortable going into too much detail about why that's true.
To try to package them into a reusable engine nearly forces everyone down the same path where the only real difference between one game and the next are the textures and the name.
Well thats not what I'm asking them to do anyways :)
moonkey said:
Are culled meshes pickable in jme3?
Yes
1. Create Source geometry (millions of cubes) that will be culled but still pickable.
Millions is a lot to have in memory. This is where setting your own requirements on the system completely changes the architecture of your engine. A generic "voxel" engine is not sufficient in that case.
2. Create batch meshes based on (source geometry) that will be sent to card for the rendering.
GeometryBatchFactory
I have other ideas as well that would involve compressing data(vertices, etc) that is sent to graphical card and then using shaders to uncompress, this stuff is to complicated for me I am programer that is best at using frameworks not building them, but talented guys like guys that make jme could perhaps be able to handle stuff like that and implement it for everyones benefit.
You will need a geometry shader to do this. However geometry shaders are not supported in jme3 yet nor on most slightly older video cards.
Videocards can process lots of triangles really fast. So compressing the data will only save you some memory. The performance hit is sending many, many, objects to the video card. That is where the geometry batch factory comes in.
As an example… the opening shot of the latest version of Mythruna has over 600,000 vertexes just in the view. 200,000+ triangles. My card renders these at 70 FPS or so. That’s pretty good.
…and because of batching, that’s only about 500 actual objects.
if culled meshes are pickable, then thats great, that can sure save alot cycles from having to batch to many times. if only atlas textures were easy to implement, batching based on same materials would not even be necessary longer
Atlas textures may not help you as much as you’d think and there’s nothing preventing manual usage of atlas textures in JME3 today. I only use them for grass and clouds.
Everything else is batched by texture and that works out pretty darn well. While it’s nice to batch as much as possible, you also end up regenerating it every time the user modifies the world. So some balance is required. I played with a lot of different numbers before I ended up with the sizes Mythruna uses and even that’s sort of related to my other structures and requirements. If I went too big, I started to burn through direct memory faster than the GC could keep up… and the pauses when I user deleted or added a block were very noticeable. Too small and it starts to kill frame for having too many objects in the scene.