@normen said:
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.
O, got it.
At least the build script in the module should replace the library automatically if the library could not be added by reference to the project. Everything else the straightforward this contribution management system. From what i got, even for you as a manager, since you have to manually add any project added to the contribution plugin..
@zzuegg said:
O, got it.
At least the build script in the module should replace the library automatically if the library could not be added by reference to the project. Everything else the straightforward this contribution management system. From what i got, even for you as a manager, since you have to manually add any project added to the contribution plugin..
Its not more complicated than maven ^^ Actually its exactly the same, it depends from where you come. I want to add them manually atm as its the easiest thing. I guess for the initial setup issues of NetBeans newbies a plugin to set up the base suite and module would be good, thats where most seem to fail as they ignore the step by step manual and go by intuition first.
You're putting together two things here, a descriptor for a jar and its javadoc/sources and a normal java library project. Maybe you don't even want to build/commit the actual library project.
@normen said:
Its not more complicated than maven ^^ Actually its exactly the same, it depends from where you come. I want to add them manually atm as its the easiest thing. I guess for the initial setup issues of NetBeans newbies a plugin to set up the base suite and module would be good, thats where most seem to fail as they ignore the step by step manual and go by intuition first.
Ok, i have added the versioning..
Well, i have followed the instructions step by step, but for example the is no mention of this Library Description File. I am going to edit that article today evening..
Well, i have followed the instructions step by step, but for example the is no mention of this Library Description File. I am going to edit that article today evening..
Its created by the wizard, which is mentioned in the recipe I linked: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:extension_library
Three docs in all you gotta follow:
Setting up Plugin Development: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:setup
Creating a Library Plugin: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:extension_library
Loading it to the Contrib Repo: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:development:setup#jmonkeyengine_sdk_contributions_update_center
@normen said:
You're putting together two things here, a descriptor for a jar and its javadoc/sources and a normal java library project. Maybe you don't even want to build/commit the actual library project.
Thats true, but simply because i think once i start a project which i want to contribute i want to contribute also the future changes. If at some point i think i need to add features which i don't like to get publish i simply start a new fork of the project.
In that way i can go on adding features to the contribution version without commiting the private features.
But all in all that might be a setup i personally am used to..
At least i think i got now how it works and for future contributions i hope i don't have to ask anymore such question ;)
@zzuegg said:
Thats true, but simply because i think once i start a project which i want to contribute i want to contribute also the future changes. If at some point i think i need to add features which i don't like to get publish i simply start a new fork of the project.
In that way i can go on adding features to the contribution version without commiting the private features.
But all in all that might be a setup i personally am used to..
At least i think i got now how it works and for future contributions i hope i don't have to ask anymore such question ;)
You can build everything together, as I explained. The version is upped each time theres a change in your *plugin project* folder. So simply store the library project inside the plugin folder and call its build script from the main plugin build script. This way any change you make will automatically translate to a new plugin with new version and newly build library each night. Just make sure the library project has all its libraries in its "lib" folder (go to the project settings and set "store libraries in project folder", else they cannot be built on the server. Yes, this means you commit all the jmonkey library with your project (this is due to plugins maybe wanting to support an earlier version of jme).
Thing is the plugins are not all library plugins as yours is.
@shirkit said:
7GB of ram? For how many boxes? Do you have an average comsuption, let's say, per 10,000 blocks?
10.1 Gb for exaclty 23.388.259 blocks.
The mesh itself contain 127.774.408 vertices. This alone take (1*32 + 2*32 + 3*32 + 3*32 * 127.774.408) ~4,2 GB
The remaining 6GB are probably used by the internal data management.
This comes down to 0.082kb/block, so on average 10k block should consume ~19mb
In a real game of course you can never allow such visible distances, simply because no gpu is able to render them in realtime.
Additionally you definately will need a disk based datasource, i might try to implement a TileHandler to add support for databases..
@t0neg0d , i have also tried batching them, however the gained speed from the culling mechanism outperforms the gained speed from batching. And by outperform i mean using batching results in a unplayable framerate as soon as 1 block is visible. However if using a top down camera (RTS for example) the cullingmechanism works that good that i have about 200fps is the above scene.-
@zzuegg said: @t0neg0d , i have also tried batching them, however the gained speed from the culling mechanism outperforms the gained speed from batching. And by outperform i mean using batching results in a unplayable framerate as soon as 1 block is visible. However if using a top down camera (RTS for example) the cullingmechanism works that good that i have about 200fps is the above scene.-
I had this same issue working on a weather system. I was hoping I was just doing something wrong with batching, but I'm guessing it is only useful when you are only adding/removing objects on a very infrequent basis. Thanks for explaining!
@t0neg0d said:
I had this same issue working on a weather system. I was hoping I was just doing something wrong with batching, but I'm guessing it is only useful when you are only adding/removing objects on a very infrequent basis. Thanks for explaining!
The batching itself is quite fast, but it works only good for a group of small/near objects. You will loose the power of frustum culling
@KuroSei said:
Nice progress!
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. :D )
@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...
Looking forward to the next step... Do you plan a material system soon? I would be pretty interested in your approach. :)
It's actually very unoptimized, since this is basically my second approach to bloxels. For a propper usage a better datamanagement is definatly required.
A basic material system is already included, currently the system allows you to put a Class parameter for each block, when generating the mesh you also have to specify the Class for which you want to generate the mesh.
I am not yet sure if i like the marching cube algorithm since i think for not high res data it will create a too uniform terrain, with the surface net algoritm i was able to add a bit of random noise very easily. I probably find out soon
I had never an issue with drawcalls, could be gpu vendor specific, or the performance gain kicks in when other stuff than simple triangle drawing happens on the gpu. Don't know.
This might be me just failing with using google code, but I canāt find a way to download your source zip file or documentation zip file. Opening it says google code canāt read zip files, save as attempts to save the webpage (i think).
Has the code changed since you posted the code in the OP? because getDebugMeshFromTile has 2 parameters not 3 and even removing the 1 im getting Error: cannot find symbol: method getDebugMeshFromTile(String,Class) location: variable blockManager of type BlockManager
using the code: [java]BlockManager blockManager = new BlockManager(10, 10, 10, 1);
@maxyme said:
Has the code changed since you posted the code in the OP? because getDebugMeshFromTile has 2 parameters not 3 and even removing the 1 im getting Error: cannot find symbol: method getDebugMeshFromTile(String,Class) location: variable blockManager of type BlockManager
using the code: [java]BlockManager blockManager = new BlockManager(10, 10, 10, 1);
String key = blockManager.addBlock(DefaultBlock.class,1,1,1);
Material mat1 = new Material(assetManager,"Common/MatDefs/Misc/Unshaded.j3md");
Node newTile;
newTile = blockManager.getDebugMeshFromTile(key, DefaultBlock.class); //error line
newTile.setMaterial(mat1);
Spatial oldTile= rootNode.getChild(newTile.getName());
if (oldTile!= null) {
oldTile.removeFromParent();
}
rootNode.attachChild(newTile);[/java]
the method it should be accessing is
[java]public Node getDebugMeshFromTile(String key, Class blockType) {[/java]
which returns that error in calling it, yet if I make a method with the same parameters it works.
Method:[java]public void testClass(String key, Class blockType){
System.out.println(blockType.getName());
}[/java]
Call: [java]test.testClass(key,DefaultBlock.class);[/java]
The test method I made is in my own object (test).
Am I missing something really obvious or what?
Hello, sorry for the confusion, updating from Beta to RC unfortunately deleted all my SVN stuff so i can't doublecheck that currently.
Yes, since the OP the api changed a bit, and probably will change again sometimes in the future.
I have removed the scale parameter from the getMesh() function and moved it to the constructor because the results look odd if different scales for different tiles get used. Using the new constructor this could not be done anymore.
Addiitonally i changed the name getDebugMeshFromTile to getMeshFromTile, simply because when i started this project i wanted to use the bloxel stuff only as control mesh. Of course if you want to generate a bloxel world this isn't the case so i tought using getMeshFromTile is more convencing. I should have left the old function and marked it deprecated..
Btw, it seems that the src and javadoc on the svn are still from the old implementation.
Add:: in your example above you won't see anything, since you are not adding any block...
Thanks anyway
http://i.imgur.com/YXeco.png