I am very exciting for the 2.0 release, and I would really like to know when there would be a 2.0 beta, I need to change some architecture in my game so it is important to know if I am doing the right thing before starting.
Teaster
"When" probably mostly depends on when we get svn setup. You can read a little bit about 2.0 changes in my blog.
renanse said:I already read in your blog :)
"When" probably mostly depends on when we get svn setup. You can read a little bit about 2.0 changes in my blog.
I wish you luck with the svn, it sounds too retarded they want $500, maybe just a too late aprill joke I hope :S
I don't know if its too much to ask for, but could you zip a copy one and pump it up somewhere on the web?
Teaster.
No, sorry, you'll have to wait for svn. Changes get made on such a frequent basis it would not really be worth trying to keep things up to date. 
Okay, I will be waiting without patience 
Teaster
By the way, is the version number bump to 2.0 immediately? It took you 4 (or more ?) years to get to 1.0, and then in simply month you are going to go to 2.0? (Not that I am complaining… specially if the version name is justified)
duenez said:
By the way, is the version number bump to 2.0 immediately? It took you 4 (or more ?) years to get to 1.0, and then in simply month you are going to go to 2.0? (Not that I am complaining... specially if the version name is justified)
when changing from one (e.g 1.0) version to another (2.0), it might not be that compatible with the other version, which have its disadvantages, but there is also a reason for that since it will make it lot better designed, making it easier to work with.
There are many things which I find quite odd in jME, but was created for a reason.
Teaster
duenez said:
By the way, is the version number bump to 2.0 immediately? It took you 4 (or more ?) years to get to 1.0, and then in simply month you are going to go to 2.0? (Not that I am complaining... specially if the version name is justified)
2.0 is kind of the "next generation". 1.0 will still be maintained.. or that was the idea anyway :)
This is about 2.0, so if i may hijack this thread with some of my ideas:
I've read Renanse's blog, and it struck me that you want to remove batches. I agree that they are overcomplicated and are just the same as Geometry was before batches. But they are still useful, they are the "atoms" of the scene. I would go and made only batches "renderable". Going wrong with batches started with adding "isEnabled()" to batch, being able to switch on/off presumes that batches can behave dynamically. Then this widened to include other scenegraph functionality, as opposed to only rendering functionality. When SharedBatch was added as is, it became apparent that its gone wrong.
Why are batches needed? One is multithreading. There must be something in the bottom of the scenegraph where the update and cull stops. So, one or more threads are updating and culling the scene, while another thread renders batches. This requires that every information needed to render is contained in the batch, and is not randomly changed by the update thread. This also means that there must be two sets of batches, one that is updated with current state and the other that is currently rendered. Or one set of batches, with two sets of member variables. It also means, that batches should not define any properties on they own. They should not be "Geometry defining elements" of the scene, but "reusable atomic rendering tasks". The most close to what i have in mind is the current SharedBatch, but not as a reference to another batch.
There is more to batches. Interleaved arrays and large VBO-s, compiling unchanging geometry into a single buffer, and storing the pointers in the batches.
I hope its clear and makes sense what i wrote.
One thing to consider is that Renanse never said what will take the place of Batches… I am positive the alternative will be all you say, only cleaner and more useful… I also though like you did when I first read that, but realized I know too little to be critic. 
1.x will be used for fixes to the 1.0 version. i think we will go for a "jME 2.0 somekindofversionnameandnumberingthingy" for 2.0, with a 2.0 final or just 2.0 in the end, but we'll see…
i promise you that interleaved arrays, separated render/game/cull threads and lots more will be solved in the upcoming design, even without batches 8)
I assumed 2.0 will be some kind of modified 1.0 and not a total redesign.
We really needed some redesign for quite a while now. It was postponed often. Finally we decided to wait for 1.0 with major API changes and redesign… so now's the time
llama said:
duenez said:
By the way, is the version number bump to 2.0 immediately? It took you 4 (or more ?) years to get to 1.0, and then in simply month you are going to go to 2.0? (Not that I am complaining... specially if the version name is justified)
2.0 is kind of the "next generation". 1.0 will still be maintained.. or that was the idea anyway :)
Lol that was what I tried to explain :)
I hope it will be redesigned so you wont need to think of thread safety, that really suck you have to think of that. I got lot of troubles my program runs, hundres of times and then suddenly I get error because of threading.
Anyways except for that exception, I think the jME design is really great, I think you could make a book about how to design a 3d engine - and I would buy it :)
Teaster.
Thread issues really shouldnt be a problem, LLama introduced a simple process to add tasks per the continuos terrain.
I WILL, WILL WILL when I have time, implement the continous terrain and get developing on the code again, along with a simplified, simple and efficient task simple to take carer of multi threading woes…
theprism said:
Thread issues really shouldnt be a problem, LLama introduced a simple process to add tasks per the continuos terrain.
I WILL, WILL WILL when I have time, implement the continous terrain and get developing on the code again, along with a simplified, simple and efficient task simple to take carer of multi threading woes...
So threading will be totally automatized? :D :D
To realise that it shouldnt be totally automised requires a greater understanding than thinking its best to automise it all.
Sure it can be dumbed down, but performance will suffer at the cost of ignorance
theprism said:
To realise that it shouldnt be totally automised requires a greater understanding than thinking its best to automise it all.
Sure it can be dumbed down, but performance will suffer at the cost of ignorance
I wouldn't call it ignorance, since it will help both new users to jME, and those which are unfamiliar with opengl.
I had hope for thread safety, but it is working more than fine with jME 1.0 so can't really complain, too much :)
I will hope you will document with a warnings in the javadocs whenever it needs to be inside the opengl or not, this is very hard and troubled worked but would be so nice.
Teaster.
There are beginner helper classes to make it easier for beginners and there is core code which needs to run fast, as long as the core isnt comprimised it should be ok.
Maybe a tutorial should be written to highlight the threading issues.
? is there anything in particular with respect to multithreading that you want to do
Also I wouldn't advise OpenGL newbies to start off multithreaded. Combining multithreading and OpenGL is definitely a rather advanced topic in game development, and IMO multithreading in general is something you should not do if you haven't spent a good amount of time learning about possible side effects. If you don't want to have to think about side effects, don't do multithreading. It's as simple as that.
Of course some more learning material for multithreading and jME would be awesome to have, but to make the engine fool-proof in regard to multithreading sounds like an awful waste of both manpower and processor cycles to me.