google code.
http://code.google.com/p/mapspinner/
lanmower said:
Omg, I turn my back for one minute and all of a sudden everyone is posting on my thread! :D
Trussel: can you hold on just a teeny bit, and I'll give you very basic code to start things off :). I've decided to start off without a real editor, I just used some of the sandbox code to get a window up to start testing so that I can start to understand wich parts of mapspinner needs modifications. If you think that modifying an existing world editor would do the job better then we could either work closely on that or I could develop a tiny one that gets bundled with mapspinner, and you can develop a port of worldeditor... what do you think?
I think it would be a good idea for us to port World Editor and expand it's functionality a lot. I think it would be best for mapspinner to be directly integrated into jME and for jME to ship with the editor we build, much like it ships with Renanse's Particle Editor (except hopefully we'd have a better installation approach).
thats a shader error…
i had a similar issue with the vertex shader…
it's an easy fix…
lanmower said:
The 'supposedly' GNU radakan game doesnt allow me to checkout their code without a username/pass
;)
http://code.google.com/p/radakan/source/checkout
I believe he has looked into jmeterra and is partly working off that… Here is a related thread where he asks interesting questions.
It would be nice if we could get some comparison between this solution and jmeterra…
Am interested in your rendering technique, bit puzzled though why you want to rewrite the terrain block management system when the terra does it all.
Have you tried adapting the terra system ??
Last official release is http://www.virginbreed.com/terrademo/src.rar
Have got a lot more functionality in my local copy - reducing splats based on distance, entity management, terrain editing brushes etc, standard java tasking rather than the confusing task system.
Happy to add comments if it wil help you reach your objectives, just sooo short of time atm, so cant release all the new features that I have locally…
Have you tried jmeterra? While it would be nice to have an alternative, a lot if not all of what you want to achieve here is done there already, so you might save a lot of time by checking it out and have a look at it.
My post is now updated, and I have new changes to submit soon (reducing all the queues to one queue)
Mark my words, I will have a better looking example picture than yours based on my system in 4 weeks.
Positive competition is what makes OS great 
Oh and by the way, I like your copy of terra much more than the 0.3 that I had.
lanmower did you update your code? I don't see that BooleanKeyTable thingy anymore…
Anyway I think you have even more competition 
The Radakan RPG game also uses dynamic loading, but it's not threaded…
You can see the code here: http://code.google.com/p/radakan/source/browse/trunk#trunk/radakan/src/com/radakan/game/tile
It would be nice if there was a generic implementation of "infinite terrain" in jME, where you would implement the tile "load" and "unload" methods and the rest would be taken care of by the system.
I dislike the Terra system because it is a bit too big… There are many classes for managing threads and tasks, also I find it hard to understand what I have to do in order to write my own tile loading and unloading methods. I think lanmower's clean and slim system is much better in that aspect. A complex system is okay but it also requires documentation as complex as itself otherwise other people wouldn't be able to use it.
Maybe when both are a bit more ready the two teams could have a (public) chat and see to which point they could/should be collapsed. Maybe that would be a nice way of comparing features and strengths.
I plan/wish to be using one of these. I hope they are ready soon ;).
Lets all try and make one … See if we can agree on what it should have.
I too dislike the tasking, its functionally brilliant, but very clumsy for on going development and is closely coupled to instanced queues. This whole tasking can be moved to standard threading of java 1.5 containing latches and queue polling.
Another consideration is what is the cost of the terrain on CPU, memory,loading speed, GPU etc is. Likewise, what else is to be rendered with the terrain, will the consumption of resources be so high with the terrain that there is nothing left to render veggies.
The terrain splatting as per above can be replaced with straight textures - one in alpha channel one in opaque and only consuming two texture units, the scale can be modified as can the number of tiles in view… How it looks is one thing, how it performs is another
Also, bare in mind that each terrain block should be identifiable, this will allow changes to the block to be replicated to each client in a multiuser environment.
Another factor is to be able to have an actor move over the terrain and at each intersection of blocks be placed in the correct quad/oct tree area efficiently.
When adding new blocks, the normals should join up so that any lighting is seamless, other wise there will be normals duplicated at the seams that point in slightly different directions ( normal is calculated via an average of adjacent points) .
I do like competetion, but think we can all use our energies more wisely if we join up…
Anyone who wants to join forces and write a CLEAR, CONCISE and SHORT terrain loading system, feel free to message me, anyone who wants to complain about me not using a bloated existing codebase, bug off.
No progress that works, I'm working on putting the right things in the main opengl thread and the right things in my thread, wich means slowdowns but working code.
If anyone has advice on sharing the opengl context of jme with other threads please comment.
sorry about that line, I actually removed it prior and it didnt update (slow internet)
Please contribute!
Busy with some major refactoring and adding normal stitching, will post soon when finished with the debug.
Most queues are removed now.
I have now completed all functionality that the public jmeterra has, i'm sitting with 27kb of code and all thats left to do is debug the index generation for lodutil (similar to llamas one) that I cant seem to fix, I will upload my code soon and if anyone is willing to help me fix it (my math really sucks) I would be much obliged.
I will post the new code to google within the next few days, dont have it with me now.
LLAMA!!! can you maybe help me fix my lodutil code?
Great ! Do you reckon your code is easier to use than JmeTerra ?
NEW SOURCE EVERYONE!!!
Here is the second latest version of mapspinner.
Unfortunately, I borrowed someone my pc, leaving me unable to upload the latest, and unable to work on it till later this week.
This version contains all the functionality of the latest one, wich contains all (as far as I can tell) of the functionality of jmeterra.
What is however different in my latest version is I shortened the code in mapstremer (it no longer uses a visitor pattern) and I modified the code in lodutils to be less jmeterra and more my own bitwise style code, this will be available and uploaded soon. Likely with some texturing support.
This code is small (I think roughly 28k) and understandable beyond comparison with jmeterra. Also the latest code (wich will likely only get committed with additions, being larger then) is 25k flat.
No comments in code, I dont think its neccesary.
Check out the editing test, a simple example of how things can get generated-if-never-been-saved, saved-if-modified and loaded-if-ever-been-saved. Wich is what I think is the best approach with streaming data terrain for mmorpgs.
I changed CompressedMapData to store shorts instead of bytes cause bytes looked a bit rough.
I had a changelog since my last upload, but it was longer than the code itself so just have a look at it.
and yes I reckon is a damn lot simpler, I'm getting my pc that I borrowed to a friend since cristmas back today and I will resume development.
COMMENTS!!!
Post contributions and I will add neccesary updates as well, this can also score you a project membership.
I looked at the code and it's indeed very simple! I like it so far, but I haven't tested it yet. Unfortunately I am no longer working on Radakan so I don't have much need in using those streamed map systems.