Well, we've made some progress, but I for one would still very much like to see some design docs for the future plans of your code 
v2 sounds very exciting, please tell me more in the form of a wiki page on googlecode! ;D
Also I'm wondering, will you intend for v2 to be integrated with JME3, or just be usable with it the way the current mapspinner is with JME2? It seems Momoko_Fan agrees with blaine's original points and more, so you'd probably have to fulfill those in order to make v2 part of JME3. That, or convince Momoko_Fan otherwise 
Sorry that I dont really have time to read everything right now guys, new source is up, but it doesnt seem to be under trunk its just /mapspinner.
for v2 I'm looking at a jme3 implementation, I want to move to jme3 before jme3 is complete that so that I dont have so many people using my code before its semi-complete. I also plan on making the structure integrated in a way that it follows the jme3 structuring and naming convensions. However whether it becomes the official jme3 terrain or even becomes part of the official source is up to you and momoko_fan I guess
lanmower said:Sounds good! Default or not, Mapspinner will certainly be a most welcome addition to the JME3 toolbase :)
for v2 I'm looking at a jme3 implementation, I want to move to jme3 before jme3 is complete that so that I dont have so many people using my code before its semi-complete. I also plan on making the structure integrated in a way that it follows the jme3 structuring and naming convensions. However whether it becomes the official jme3 terrain or even becomes part of the official source is up to you and momoko_fan I guess :)
Blaine would you look at the new source?
I seperated texturing into a seperate class, and made it linked to the pass class instead of the terrain block class, that should enable you to replace the pass system together with the texturing/painting mechanism that goes with it, tell me what you think about it and what more needs to be done for your system to exist in mapspinners world
Please ignore the autotexture method for now, I will move that into the editor class when that becomes more modular.
Advice is good, and I will appreciate pointers on the new modularity in mapspinner further than whats been done so far.
Thank you for your patience.
Once you have your 'infinate texture' system integrated, perhaps it could be committed to the main codebase if you'd be willing to waver any harsh licences for those specific classes.
When I get time to, I'll review the mapspinner code, but due to business exigencies I have to make my own terrain system now, and I must concentrate on that for now. There won't be much opportunity to share code, as my new system is from-scratch and borrows nothing from mapspinner. (WRT sharing to help with my suggestions below-- my implementation doesn't use the jME Perlin class, and in fact uses a different, but similar, noise algorithm).
I'll make two new suggestions here related to your use of the Perlin noise function, because they're easy to explain and will probably not lead to a debate that I won't have time to continue. In the unlikely case that you have just improved either of these items, please ignore.
-
The permutation table in the Perlin noise class that you use is fixed. As you know, an advantage to procedural noise is that you can regenerate large sets of output data based on a very small set of input parameters. One critical parameter is a randomization seed for the same frequency and scaling parameters to allow for distinctive, reproducible output data sets. One use case for this, especially for use with low frequencies, is for the game designer to make lots of runs with different seeds and programmatically or manually choose the seed that generates output most to his/her liking. Another is when you want the game to purposefully make a new game world map with the same exact scale and frequency settings (say when the user completes a game level). This won't work until you enhance the Perlin class to utilize a seed. - The parameters that you pass to the noise function seem to be emipirical adjustments to hammer the output to the desired output scale and frequency. Those static factors just obfuscate the purpose of the only parameters which really matter: frequency and amplitude (besides the input coords of course), and those are the values that a game designer (of the type who would be adjusting those values) should be dealing with. This simplification will be a practical necessity if you ever plan to accommodate summation of multiple Perlin functions (which usage is both basic to noise functions and extremely appropriate for terrain generation).
Both of these items would be straight-forward to satisfy, but do require pretty good understanding of noise functions (specific details of which can be very difficult to find). You're welcome to PM me if you want references or have short questions. Postnote: I just learned about noise functions adequately myself a couple months back.
very good point, the noise generator is very old code and needs an update, of course your message could have been reduced to 'adjustable, seedable noise would be nice'
dont be silly, your post was neccesary and helpful, thanks.
I was just being misguidedly comedic