I do not know if we can just cut and paste text from another site here, so I am not going to do it. But here is the link:
http://www.devmaster.net/engines/engine_details.php?id=78
If you check the review posted at Feb 29, 2008 (last one atm) you will find some pretty criticizing points. I am not good enough to comment (nor even understand everything) on the technical stuff he said. However I would really like to hear your opinions and ideas concerning these statements.
About the community I would like to say though that I do not think we lack the ability to criticize. Nor that we always cheer, whatever the result. I think faults in people’s code are often pointed out with advice, just that it is done in such a friendly manner that a more harsh person might see it as ‘pat on the back’.
Anyways… your views?
There are a few valid critiques in this guy's rant, but it seems rather obvious he's got something else against jME. He's probably one of those people that have left the forums in a huff or just has a bad attitude. I definitely think there's quite a few items he mentions that we could improve on. One of the main ones I agree with is the model handling in jME.
Nobody here I think would say jME is perfect as it is. If it were, jME 2.0 wouldn't be in the works. 
Also, looking at the guy's details it would seem he created the account for the sole purpose of giving a negative review of jME. I think that says a lot.
i have to agree that the art pipeline of jme is the weakest point which is y i wrote the md5 importer but it still doesnt strictly tie into the jme native classes.
Hmm. All of the points are valid to some degree, but they all have been pointed out on the forum already (mostly by jwatte, if I recall correctly). So the learning value is rather limited IRT improving jME. On the other hand, there is much to be learned about the poster's social skills, but then, who cares… Doesn't seem to be the type I'd like to have around anyway.
There are two kind of people using jME:
- Those who learn game programming, or do things for school
- Those who want to make a complete game in Java
People nr 1. will do small projects, and dont realy care about the robustness of the engine, they just want to achieve something fast.
People nr 2. better get to rewrite/refactor the engine to their specific needs rather that use the stock CVS version of jME. Its better to have an engine that does only what is needed, but do it efficiently, than have an engine that does many things, but not optimally. Its quite easy to refactor jME as its clean Java code, you would not attempt such a thing with a C monster like the Ogre3D engine.
llama, you are going to post that on DevMaster right, thats a very good retort 
I don't think at devmaster you're meant to discuss other people's reviews. I've still not written a review myself though… so I could do that some time.
However, I think most of what I said is already well represented by the other reviews there.
True, it is. I just think it might be good if there was a post following that guys. So that other people evaluating engines won't be immediately biased against jME. Some of those top posts are VERY old, so it kinda looks like jME has stopped development…
Also, you make some VERY good points as far as datatype efficiency goes, I bet he is one of those guys that still uses a sin/cos lookup table 
Also, I don't mean discuss; I mean a new review right after his review.
The author spent part of his words to say something useful but part is to say how the jME comunity is "too polite" and do not push to have useful changes.
Unfortunately I am not expert enough to understand if jME is well designed or not. I am doing little experience with OpenGL and 3D now with MD5 Reader. MD5 Reader maintenace and refactoring, lead me to learn some aspects of OpenGL (also native code) that I did not ever known before. But I am still quite noob.
It is probably true that jME could be improved a lot. For example, talking about loaders, the goal of MD5 Reader project is exactly to fill the lackness of a solid animation system/importer. And, in the near future, when the core part will be finished, I would like to implement collateral projects to fill several aspects related to animation part.
Though I did MD5 Reader maintenance for a personal project: A FULL GAME! Maybe the review author can find it unbelievable but is true. I will probably change some parts of my local copy of jME if I will ever need to do it. But this not means that I consider jME crappy.
I would, also, like to remind him that Galun (another jME forum user) was working on his MMORPG, World of Mystery about a 1 or 2 years ago. I was in contact with him in that period and I was subscribed to the project I saw the code, and I can assure that it were in at a good point. He decided to abbandon it because they were only 2 developers and then they joined a greater project based on a C++ engine.
I do not like the attitude of the review author. I think that if he has anything really useful for jME he should contribute. I would be happy to test his "fixed matrix/quaternion" implementation, if he did any.
Contribute a project does not means to place there some words or code totally unrelated to the project itself. Contribute means join a project and do everything necessary to make the project growing.
So, if he has this matrix/quaternion implemetation, then he should share it an produce some tests to demonstrate its better performances.
This is the worst aspect of Open Source. There are a lot of project suffering of "false" contributors. Take for example Xorg. I read an article of a old contributor, who explained why he failed to actually help Xorg. Explaining the lack of organization of Xorg project and the fact that most of the contributors have not any leader in the core team, and they did only what they need without actualy help to improve Xorg engine.
jME has the luck to have a good community wich mostly understood this problem.
P.S. I would like to lear what are those interleaved data. Can anyone point me what they are?
http://www.cs.rit.edu/~ncs/Courses/570/UserGuide/OpenGLonWin-15.html#MARKER-9-61
http://lists.apple.com/archives/Mac-opengl/2006/Nov/msg00066.html
Probably tons more, just not using the right search terms.
Ender said:
P.S. I would like to lear what are those interleaved data. Can anyone point me what they are? :D
Interleaving data means storing your vertex, texture coordinates, color, normals, etc in the same buffer. That means less buffers which could be a good thing (of course it doesn't make your life easier when manipulating the data).
Aside from that the benifit is that often (escp older) GPUs will need those different data about one "point" at the same time. Of course that only works if you give the data to the GPU in the right order (there's OpenGL commands that will "hint" you which order the GPU prefers, if I remember correctly). Often you also have to align the data (leave empty gaps so the next point starts at the beginning of another block), in most examples you'll find 32 bit is used here.
Of course, this is all desgined for the times that GPUs had little internal buffering, shaders did not exist yet (which greatly changed GPU architecture). Basically GPUs were little more than stream proccesors with a local blit buffer and texture memory that were fed by the CPU. So if you gave stuff in the right order, the CPU would not have to reorder it, you'd have better caching locality for the CPU itself, etc.
Times have changed since then.. it might still give you a little boost (espcially if you have loads of small object, since you'll have less buffers total then) but there are also other disavantages.
Consider:
- Number of texture units has increased and diversified (try interleaving texture coordinates now), and color data is hardly used anymore.. so you're only interleaving normals and vertices now. Even normals are less used these days.
- Geometry has become a lot less static. Doing a bulk update of all vertex coordinates in an interleaved buffer is a lot WORSE for your CPU cache, since you're working in a much larger buffer
- Display list, or Locking as it's called for jME, already interleave your data in the most efficient way for your static object.
That said, if someone desperatly wants it, it's not terribly complicated to implement. Just some extra commands when you set the buffer, and some changes to when jME checks the size of buffers, or retrieving a specific coordinate. To it it cleanly we'd probably have to create a wrap around ByteBuffer.
It could also be useful for loading some model formats that store their data interleaved (of course if that happens to be a bad interleave for your GPU you're screwed), but I'd recommend everyone to use the jME binary format as an intermediate storage format anyway.
Wow… how many replies… so nice to see that people care
And I also think that llama should use this reply he wrote as a basis for a new review after that guy's post.
Thats what I'm saying too …
the fact that he used the words jme, model loading and crap in the same sentence then proceeded to big up torque should hilight that he's actually insane…
if he really believes this then i've got a couple of 3d artists who'd set him straight on that account
llama said:
... but I'd recommend everyone to use the jME binary format as an intermediate storage format anyway.
Thanks a lot for the explanation. It is really clear and understandable.
I can understand the drawbacks of this approach. In my opinion the better choiche is testing, always. Maybe there are cases where one solution is better then the other.
Though I continue to thing that if he has the "Answer to all our problems" he should come here a share it.
dhdd said:
now i am confused by what i said :|
:D Do not worry, we understand you. ;)
Seriously, I am totally agree with you.
is this jwatte being on the warpath again?
i think we're not afraid to admit what our flaws are, and we are working hard on addressing them. 1.0 was a big step for us, in that we can break backwards compatibility somewhat in 2.0 to take a step up in architecture and features.
people are free to choose whatever engine they wish, so i don't really understand the reason to bash on a particular one. we don't claim to be something were not…
but at the end of the day, just seeing the amount of attention and people using jME (both commercial, free, professional and noobs) tells me we are doing something right
MrCoder said:
is this jwatte being on the warpath again? :D
Not to say that wasn't the first thing that I thought as well, but we do not know for sure who it is and it is unfair to jump to such conclusions. :P
Let me just chime in to say that I hope that jME development will stay focused on usability and flexibility (I don't know if that is the official focus, it just feels like that to me), and not on getting out that last 10 (or even 20 or whatever) percent of performance.
I am interested in efficiently developing games, not developing efficient games.
Wouldn't it be great if you could have both?
Sure, but I can't. Improve performance and you loose flexibility, in general.