I’ve been searching for alternatives for SpeedTree and found that Arbaro thingy(in java, open source). And have been thinking.
Is it viable to incorporate it’s code(i need to check the licenses, but i supose it’s legal) into a game, and have it generate trees in real time, giving two parameters, a seed and a code? (All the "Jason Weber & Joseph Penn: ‘Creation and Rendering of Realistic Trees’ " algoritm parameters will have already been saved somewhere into presets, the code just links to which preset to use and use the seed to make it diferent).
Im asking becaue:
(a) might have been done already and i don’t know.
(b) someone might have already tryied and concluded that it is too slow or something.
I willing to have something like this because i want my world to be generated in a way similar to Infinity’s Universe, you give a seed and then the seed makes more seeds, that makes more seeds, that makes a planet and more seeds, that makes continents and more seeds, or at least that’s how i think it works, then only saving diferences(might as well give up on voxels and use heightmaps + holes on the heightmaps + objects that fit perfectly on the holes or something).
Thx in advance
a) havent seen any tree generation code for jme.
b) no its 1000% faster than loading a file from disk. Because it is done by cpu, instead of waiting hours for disk. Plus you can do it in init(), since the tree doesnt change appearance on runtime (except if you make them “age”).
You don’t usually generate a unique tree mesh for every tree you have in your scene, that would be way too slow to render, I think.
Probably better way is to just generate 20-30 variations of trees and then just place them randomly in a scene. In that case you generate the tree geometry during loading.
Also it isn’t necessarily faster to generate trees … Tree models are fairly small and their loading is just read the mesh data and display. Tree generation on the other hand requires generating complex geometry based on various algorithms.
So…
Probably no one tryied it yet and there is no way to be sure if it’s faster or slower?
Guess that i will try it on the incoming months, once i get the rest of the terrain done
A java implementation exist http://sourceforge.net/projects/arbaro/files/. They use the Jason Weber & Joseph Penn Algorithm. 
@momokoFan :
- mesh rendering :
Using the same mesh will offer no performance boost. Since jme doesnt support mesh instancing, so it will just duplicate all mesh data.
- creation speed: compare that to loading 30 files from disk with 1-5 mb file size. Obviously its slower. In my mind i think it like generating a primitive sphere, its obviously faster when you do it programmatically than loading a file from a disk. Also note that lower distribution file size of your game means that users can play it instantly instead.
- mesh creation : you do it in init() or when application has excess fps in a seperate thread. Thus speed is not a problem.
You can reuse the same tree mesh (from a pool of tree meshes), when u don’t want to generate new ones.
@stomrage
- The problem with arbaro is that is gpl, so your code will have to be gpl as well. You can use :
Treal or opentree.
Yes jme does support mesh instances, the mesh isn’t copied twice to the card if two geometries use it.
Heh, thats by no means a complete feature list, more of an overview. And you can believe what @Momoko_Fan says about his own engine ^^
No jME3 doesn’t support mesh instancing. It supports sharing mesh data. Those are two different things.
Also a tree model doesn’t take 1-5 MB. Assuming textures are shared, the tree model in jME3 takes 88 KB when zip compressed.
tralala said:
1) The problem with arbaro is that is gpl, so your code will have to be gpl as well.
Yeah.. my best chances are to either request the source without glp (as the copywright owner can distribute/release multiple times with or without a licence) or write it myself D:
Momoko_Fan said:
No jME3 doesn't support mesh instancing. It supports sharing mesh data. Those are two different things.
Also a tree model doesn't take 1-5 MB. Assuming textures are shared, the tree model in jME3 takes 88 KB when zip compressed.
I understand very little about this 'shared mesh' or 'mesh instancing', but that means that i can use the same mesh and draw it in diferent places while using the same ammount of memory, regardless of how many trees i draw?
Shared mesh isn’t hard to understand, I believe I’m doing this myself (assuming I didn’t skim through this thread too quickly and misunderstand):
[java]
nonblendedGeometry = new Geometry(“nonblendedGeometry”, interfaceMesh);
…
wireframeGeometry = new Geometry(“wireframeGeometry”, interfaceMesh);
…
[/java]
I’m using the same mesh object in two different Geometry objects, shading them differently but otherwise they’re using the same backing data.
There’s no way any reasonable model of a tree (unless maybe we’re talking about ray-tracing quality, which we aren’t) is 1-5mb. I have simple tree models here that are more in the 88kb range Momoko specified. Even so, you don’t load this same file thousands of times for each tree that gets created, you load it once into memory and use that. So hard disk speed just isn’t a factor.
It obviously “depends” on specifics, but I’d be surprised to see automatic-random generated trees improve performance (in most situations), assuming you’re utilizing your static models correctly. Not to mention any other optimizations that are going on behind the scenes when you have the same x# of tree models rendered over and over, vs many more completely unique generated models with entirely different mesh data. Depending on how ambitious the tree generation code is, the memory usage alone could make a huge difference.
Anyway I think this is a digression from the OP’s original question. It would appear that jME doesn’t have anything like this available yet, but it’d definitely be cool to see (random-generated trees).
Guedez said:
I understand very little about this 'shared mesh' or 'mesh instancing', but that means that i can use the same mesh and draw it in diferent places while using the same ammount of memory, regardless of how many trees i draw?
To attempt to answer your question - I'm going to go out on a limb here and guess that mesh 'instancing' is just creating copies of the same mesh in memory. i.e.
[java]
String originalString = "original";
String newString = new String(originalString);
[/java]
(Well, never mind that I think in the case of a String like this I don't think the JVM copies the object at all, but just imagine it's a different class with a copy constructor... :p )
And yes, "instancing" would use quite a bit more memory as you create many more copies of the same mesh, but mesh "sharing" (as we can do in jME) would be a single copy of the data in memory. Using the same mesh multiple times seems quite efficient in my experience so far.
@tebriel
Thanks for showing a exemple, i guess i understand it now.
About the performance, it was never about getting improviments, but being able to give a seed to the game, and have millions of diferent tree ‘especies’ avaliable for the game to place where the world generating algorithm pleases, instead of making 30-50 in blender and then math.random betwen them.
The performance question was because im worried that it would take 30 minutes or so to generate a florest of 1500~ trees. Of course having the tree generation algorithm making 15 especies and 5 variations of each and then spread those betwen the 1500 don’t seem so slow, it “don’t seem” since i don’t have any experience on the issue and wanted to make sure.
As far as i read untill now, it’s is viable and not so hard to implement, as long as i either manage to get a ‘not-under-glp-arboro-source’ or implement Jason Weber & Joseph Penn’s algorithm myself which both seem hard to get done D:
Guedez said:
having the tree generation algorithm making 15 especies and 5 variations of each and then spread those betwen the 1500 don't seem so slow,
I would agree with your guess here, since we're talking about the same meshes being used and not 1500 entirely random looking trees. :)