Ok, here is your chance to vent! Just be civilized, don’t insult my mother or anything.
What is really annoying you about jME? What needs to be added/fixed/changed/removed. Just vent, let us know what you think is holding jME back? Don’t keep it in any longer. Here is your forum to let it all out. Try to be as specific as possible, give all the details you can.
I hope this will give us devs a better understanding of what is truely needed, and what we should be working on.
Have at it!
OK, you asked for it… 
First point is documentation. Or rather the lack of it. You knew this before, didn’t you.
Second point: my problems are as follows. I’ve got an idea, I try it out, it almost works, but for some reason somewhere eg. the lighting does not seem to be correct. Most of the time I then more or less blindly start altering RenderStates to finally find out, that I forgot to set something to the enabled state. And I am sure this is due to my lack of knowledge of the internal workings of jME. But if people want to use jME as a lib for game development one day, they should not have to look into the jME sources in order to find the solutions for their problems nor should they be OpenGL experts first. This should be hidden by the lib and covered by the documentation.
I know that jME is work under development but I’ve asked myself quite a lot during the last few weeks, whether it would be a good idea if the jME team would try to write a complete game using its own library (maybe as part of the distribution), because only by using it you have a look on the lib from a users point of view. I say this from my experience at work. I am working in a team which develops an application framework for J2EE, having a data and business logic abstraction layer, a Swing GUI framework and a web framework. The best ideas came to our team, when team members worked together with those teams, which actually used our framework, because they then saw, where the drawbacks were.
I droped using jME widgets and wrote my own UI elements for 3 reasons. 1. The widgets use a different set of rendering and input systems. 2. They use a hardware mouse instead of the standard AbsoluteMouse. 3. There is no good way of changing look-and-feel, my widgets ended up just being derrived from multiple textures on a Orthoized Quad. This allowed any look-and-feel I like.
Also, some functionality is hidden down a layer in the LWJGL specific code. There needs to be a way to access functionality at that level without loosing the future ability to use a different rendering/display/input system. 2 specific examples… VBO ability query (which renanse said he’d fix), and getting the mouse’s screen coordinates and deltas.
documentation
I just gotta comment on this one from the above two posts. Yes, documentation is very important, but functionality is even more so. I'll take a new ability over documentation any day, especially with the great developers that are helping out on this project. I also ask lot's of stupid questions. But I think that I've come to the place where I need to start putting the 'smart' answers to my 'stupid' questions into the wiki, thus allowing for others to learn from my mistakes. This may mitigate a lot of future stupid questions ;). I'm not trying to harsh the point, just trying to be part of the solution.
.ase is next on my list 
Ok, so far it’s overwhelmingly documentation. As guurk mentioned we do our best to help here, so perhaps I should go through the forums and move some of the posts into the wiki and make a more coherent tutorial out of it.
Widgets - I’m a bit disappointed to hear that they aren’t working out for you. I wish Gregg still came around to chime in on it. If widgets continue to recieve negative feedback, perhaps we’ll have to consider an alternative. There’s a lot of work in there, though, so it will have to be a big majority.
batman.ac - About your comment with RenderStates. Do you mean you often forget to set the RenderState to enabled? We can make the default be enabled is true. Whenever you run into something that almost works like you thought it should, but different enough to require you to dig, let us know. We’ll document that right away.
keep it coming. Documentation is now on the top of the list.
A lot of replies on the poll are for tutorials. Does anyone have suggestions on what things we want in a tutorial and the format?
I believe there may be quite a few people out there who like me do not have that much knowledge of 3d programming yet. The biggest obstacle currently IMHO is to get started with jME. There are tons of test applications included, but in the beginning a whole lot of questions arise, which a complete beginners tutorial could solve I guess. Once you get a feeling for it learning more is an automatic process since you get more and more experienced.
Maybe the users guide could solve many of the beginners problems, too.
About the render states: I think the problem is not the default settings for things, it is my lack of overview of the concepts, and I do have to fill this gap currently by looking into the sources of jME. That’s exactly what I mean. The more I discover of jME, the more I can sense the general idea behind the conception, but if you asked me for a specific solution right now, I would need several attempts before I have the correct solution.
If you look at my example in the tutorial, when I apply the disabled light state to hudNode instead of the quad, it does not work and I do not know why. That’s the sort of problem I mean.
First of all, I really like how jME works so far and I think this engine has a future. Api docs are very good (much better then Xith for example), however some more tutorial stuff would be great.
I started using Xith just because they have a tutorial there, now I am seriously considering switching to jME coz it looks like it works much better. So, tutorials and coding examples are always welcome.
On the features side, my wishes include…
- Real time vertex color based radiosity light mapping
- jMEs own very simple binary model/scene format
- SWT support so that it can compile efficiently to native code, just for the sake of proving that java is faster and better that c++ :)))
I started playing with jME just last night for the first time, so maybe some of these features are already there… however…
keep up the good work
Vlad
2. jMEs own very simple binary model/scene format:D :D :D
Ok, I am not going to touch another bit of code for awhile, while I work on the User’s Guide. Bear with me as I do not have the goodest writing stuff. I’ll get through it, especially with me moving, I can hit the wiki from anywhere and add a bit here and there. The User’s Guide is my number one priority now.
SWT - I haven’t really thought about things in that light, but that could definately add to the API.
Light Mapping - Yes, we need all forms of shadow volumes and light mapping, etc. Personally, I think that is the one killer feature that we need to be competitive. Unfortunately, I’ve tried just basic planar shadows recently and failed. ://
"LevelVBoss" wrote:
1. Real time vertex color based radiosity light mapping
Sounds like fun :), can you point to any good references?
Hi,
Some interesting ideas are discussed in following articles
http://www.gamedev.net/reference/articles/article918.asp
http://www.gamedev.net/reference/articles/article1075.asp
some other details and math related to Radiosity…
http://www.gamedev.net/reference/articles/article873.asp
Majority of 3d engines today are using baked lightmaps.
I was thinking that it would be more efficient to use vertex color mapping to control lighting situations. Above articles discuss the posibility to have radiosity solved in real time, this is very nice but I think it is still not feasible with todays 3d hardware, however, possibility to have the feature inside of the engine would be really exciting. For start there can be a radiosity solver, which will process geometry (imported ASE for example) and create vertex color info once at development stage, this can be some sort of a batch process, but it will allow developers to throw geometry to engine that will then create lightmaps (vertex colors in this case). Later this feature could be used in realtime and calculated for every frame which will allow for moving lights and shadows. The main points here are the memory efficiency and easier content creation.
Here is a link to the c++ based program that creates radiosity solution for geometry and creates the lightmaps they have source code available there. Calculations are a little bit slow, but the results are very good.
http://www.fluidstudios.com/fsrad.html
Vlad
Now that my motorsport season is coming to an end I can concentrate on jME again. So here are some more suggestions (or summaries rather, I think most points have already been mentioned somewhere).
- The getXYZState methods in the Renderer interface are in fact no getter methods, even if their name suggests this. They are factory methods, which create new instances of the diverse render states. By looking into the source one can easily find this out, but when there finally is a binary-only distribution of jME one day, people will probably not always get the source code. For clarification I think that you should add createXYZState methods to the renderer interface and mark the getXYZState methods as deprecated.
- Additionally, initially render states should be enabled, I think. How often do you create a new state that you initially want to be disabled?
- Maybe it is possible to check in a working .classpath eclipse file in the repository, too? That way people using eclipse can set up their eclipse project much faster after checking out.
- Same is true for .launch files. If you start applications in eclipse, you get an entry in the run dialog. In the tab "common" you can chose to have this run configuration shared. That way every eclipse user will automatically get all run entries in their run list.
- You already started cleaning up the repository a bit. I think, all resources like textures, models etc. which are needed at runtime (like the font used in SimpleGame and the monkey image in the PropertiesDialog) should finally be shifted into a resource folder, which should be added into jme.jar when creating a distribution and which should be added to the classpath, if one likes to start apps from the project itself.
I know that almost all these points have been mentioned already, I just wanted to bring them to memory again. It’s all about making jME easier to use - I am quite happy with the features provided (the only thing missing would be shadows, but that has been mentioned somewhere, too).
I totally agree with batman’s first two. I’ld also like to standardize the names of the math class functions. If one uses “set”, then they should all use “set” to set values. For example, the “copy” function of matrix should be set. Similarly along other lines.
- (createXYZState) - agree.
- (enable states) - agree.
- (.classpath and .launch) - I’ll have to find a good place for it.
- (resource folder) - looking into it. I need to renew my talks with Sun about getting CVS cleaned up (empy folders issue).
- (standard names) - agree
"mojomonk" wrote:
1
4) (resource folder) - looking into it. I need to renew my talks with Sun about getting CVS cleaned up (empy folders issue).
4) (resource folder) - looking into it. I need to renew my talks with Sun about getting CVS cleaned up (empy folders issue).
Sorry for me bugging around, but I still do not understand, what the empty folder issue is. Moving files from a folder into a different one does not work under CVS, so you add them to the target folder and delete them from the source folder. Now, if the source folder is empty after that, it is true that you cannot delete it from CVS (which is in some ways a good thing since you may want to check out older releases later on). But if you check out or update from CVS, there is the -P option in the command line, also known as "prune empty directories", which is available as a check box in WinCVS and Eclipse, too. If after updating a folder is empty, it gets locally deleted by the CVS client if that option is set. If you want an empty folder still to be created when checking out/updating, you can place an empty file or a readme into it. Isn't that sufficient?
-P is not sufficient for many, because they browse the CVS directory using the web interface provided by the CollabNet toolset. These directories show up and are a major source of confusion.
Never thought of that access method, I must admit.
There are already a few Attics around there. I see the problem now.
What’s the status on 1,4,5 for .7? I could do 1 and 5 myself.