The cool thing about this design that the whole tile management is done transparent.
Currently only Normals, and TexCoords are generated.
Whats is planned for future releases, including priority
-[High] Each Blocktype can implement it’s own TextureMapping/NormalMapping
-[Mid] Multithreaded background automatical update of the tiles
-[Low] Surface Nets for generating smoothed surfaces
-[ReallyLow] A Plugin to edit all this in the SceneEditor
If it’s wanted that i add this to the contribution plugin thing, i would need commitment rights. My googlecode username is “zzuegg at* gmail dot com”
@zzuegg said:
If it's wanted that i add this to the contribution plugin thing, i would need commitment rights. My googlecode username is "zzuegg *a*t* gmail *d*o*t* com"
By all means! You've been added, go ahead and submit :)
Hey, thats awesome news I guess many users that dare not dabble with jar files and external projects will love this I also like testing these things like this very much. Best of all the updates go right into the projects so you only need to run your project to see the update changes
When you have added the module folder please tell me so I can add it to the suite build script. Do you compile the library project via the plugin build.xml file? Or will you simply update the jar/javadoc/source files for the plugin?
Again thanks for adding this, if you have any issues or need help, tell me.
@normen said:
Hey, thats awesome news :) I guess many users that dare not dabble with jar files and external projects will love this :D I also like testing these things like this very much. Best of all the updates go right into the projects so you only need to run your project to see the update changes :)
When you have added the module folder please tell me so I can add it to the suite build script. Do you compile the library project via the plugin build.xml file? Or will you simply update the jar/javadoc/source files for the plugin?
Again thanks for adding this, if you have any issues or need help, tell me.
Cheers,
Normen
I have compiled the suite with the build xml.. running the build target.
I have another question. Basically i have created a Module Suite 'JMPContributions' in the suite i have created the Module 'SimpleBloxelWorld'
When i want to commit the changes, SVN wants to create the folder trunk/JMPContributions
Question Nr1: what name appreas in the plugin list? JMPContributions, or SimpleBloxelWorld?
Question Nr2: If i want create additional contributions, i have to make new Modules inside the Suite, or a new Suite for each Contribution?
@zzuegg said:
I have compiled the suite with the build xml.. running the build target.
I have another question. Basically i have created a Module Suite 'JMPContributions' in the suite i have created the Module 'SimpleBloxelWorld'
When i want to commit the changes, SVN wants to create the folder trunk/JMPContributions
Question Nr1: what name appreas in the plugin list? JMPContributions, or SimpleBloxelWorld?
Question Nr2: If i want create additional contributions, i have to make new Modules inside the Suite, or a new Suite for each Contribution?
Yeah, you should *not* commit your suite, as said in the manual: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:setup#jmonkeyengine_sdk_contributions_update_center
just move the two "z.." and "zz..." folders to the trunk directory, theres a main suite that builds all plugin modules, so it will also build the module you created. Then that just has to call the build script of the actual jar and copy it over to the plugin project. I see the plugin project doesn't have any jar library created yet? Heres a rundown on how to create a Library entry from a jar file (and source/javadoc if available): https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:extension_library
Btw, no offense, I know its not exactly easy. I want to streamline this a bit, maybe with a plugin in the SDK ;)
@normen said:
Yeah, you should *not* commit your suite, as said in the manual: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:setup#jmonkeyengine_sdk_contributions_update_center
just move the two "z.." and "zz..." folders to the trunk directory, theres a main suite that builds all plugin modules, so it will also build the module you created. Then that just has to call the build script of the actual jar and copy it over to the plugin project. I see the plugin project doesn't have any jar library created yet? Heres a rundown on how to create a Library entry from a jar file (and source/javadoc if available): https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:extension_library
Btw, no offense, I know its not exactly easy. I want to streamline this a bit, maybe with a plugin in the SDK ;)
/cry... I'm gonna need to learn to speak WTF and get a degree in Jebus help me to ever get this done >.<
Here is a video showing how a large island is generated from a heightmap. The final grid resolution is 2048x2048x100-. Consuming about 7GB ram, but still running at 50FPS
@normen , how do i now commit the changes? The Module itself does not show anything out of sync, and in the commitwindow no files to commit show up.
The extracting of the mesh should be quite fast, am i right? Which method of computing the voxel volumes are you using? It seems pretty slow to me for some reason…
I use perlin noise for generation of large Volumes. My initial setup builds 127 Chunks each 64x64x64 Voxel. Per Chunk i got ~0.3 seconds for generating the Voxelvolume and 0.035s for extracting the mesh.
That makes 38.1sec to generate the Chunks and 4.45s to extract all the meshes! ( Using PolyVox. The marching Cubes algorithm extracts dense meshes… Hell are they dense! )
So maybe we can optimise that stuff a bit?
( I assume you use multithreaded generating, as i do… Looks hilariously good. I could watch it all day… Got something… hypnotic somehow. )
Not having it in one Object will be for extraction reasons i guess: Its faster to rebuild a small mesh than a big mesh… Or a part of a small mesh and then update the huuuuge meshbuffer.
I guess one has to find the golden middle.
Since the meshes share the same material and use a texture atlas the Drawcalls are quite low in comparison which makes up for the multiple objects.
Thats at least my guess…
Looking forward to the next step… Do you plan a material system soon? I would be pretty interested in your approach.
@KuroSei said: @t0neg0d:
Not having it in one Object will be for extraction reasons i guess: Its faster to rebuild a small mesh than a big mesh... Or a part of a small mesh and then update the huuuuge meshbuffer.
I guess one has to find the golden middle. :)
Since the meshes share the same material and use a texture atlas the Drawcalls are quite low in comparison which makes up for the multiple objects.
Thats at least my guess...
The only reason I asked, is I've been told numerous times that JME handle large vertex counts much more efficiently than large object counts.
On the other hand... manipulating large mesh buffers would suck and more than likely be sloooooow.
I guess the question is more... why not batch the final? Or at least multiple chunks...
I have not much time since i have to go to work, but i will make some some benches as soon a i come home.
What i can say in this short time is:
-No multithreading is used currently
-No batchning up to now, each tile is a separate object because batching big meshed was not possible without massive lag
-My GPU can handle the current amount quite nicely. (Already over 3mio triangles)
-Currently the RAM is limiting…
No special algorithm is used for generating the mesh, up to now i would call it brute force Checking every box to see if it’s on the outside of the grid, if yes, emit vertices
@normen said:
SimpleBloxelWorld is now available in the update center :)
Edit: @zzueg, I changed the category of the plugin to "Library", I ordered the categories a bit in general.
Any advice regarding the updateing? I cannot commit the new changes i have made because SNV say's i am already in synch with the repo.. It seems it does simply not check if a library get's updated..
@zzuegg said:
Any advice regarding the updateing? I cannot commit the new changes i have made because SNV say's i am already in synch with the repo.. It seems it does simply not check if a library get's updated..
The updating? If you commit a new version of the jar your plugin version is automatically upped. If you cannot commit you messed up something with the svn (e.g. deleted a folder including the .svn subfolders). Easiest is to check it out again, or up your svn skills, it can be a bit unforgiving ;) Best manage the deleting etc. via NetBeans, it cares that the svn implications are met.
@normen said:
The updating? If you commit a new version of the jar your plugin version is automatically upped. If you cannot commit you messed up something with the svn (e.g. deleted a folder including the .svn subfolders). Easiest is to check it out again, or up your svn skills, it can be a bit unforgiving ;) Best manage the deleting etc. via NetBeans, it cares that the svn implications are met.
Well, after following all the instruction i now have this layout:
You have to update the jar file and commit that. I usually make a command in the library projects build file that copies it over. This way I can decide when I commit that to the update center so people get an update.