Future

I just posted to the blog about Renanse and I’s major decisions (we are still talking things through), but here’s the post for those who don’t read the blog:




After a few hours of serious discussion with Renanse, we think we have a viable solution or at least a viable plan for the future of jME. A plan that will move jME out of the murky waters of indecision and into the realm of a professional well written and most importantly focused graphics library. We have a lot to discuss still but have the basis of a plan down.

First, take the current jME source and freeze the code, releasing 0.8. I know that there are not nearly as many features as desired in 0.8, but there are still quite a few great additions that are worth releasing as a full release. Most importantly this will free Renanse and I to start 0.9.

0.9

With luck 0.9 will have a relatively quick turnaround. The major caveat for this is no new features will be added. This will free us up to focus purely on bug fixes, clean up and memory optimizations. While no new features will be added to 0.9 this does not mean development of features should stop as they will still be added as seen fit. The main goals of 0.9 will be:

1. Bug fixing
2. Code optimization (memory usage)
3. Visually describing the current system (UML)
4. Visually describing the desired system (UML)
5. Creating a road map to get from 3 to 4.
6. Creating a road map for feature additions.
7. Code clean up, documentation.
8. Implementation of new tools (Issue Tracker, etc) and policy on using them.
9. Organization of the development structure to keep the development on track.

A word we keep throwing out is Professional API. This is important, for jME to reach that next level of software we need firmer hand and tighter structure. This includes a firm road map for the future and leadership from the developers. While I hope to continue with the open atmosphere that we currently enjoy, final decisions are going to have to be made by the development team and these decisions may not always be popular.

Please, bare with us, and while this may be a slow process (getting through 0.9), we feel jME will be stronger afterwards and have a bright future.

Well, when you said you wanted jme to "fall back on the standard pipeline" do you mean fall back on non-shader code written by the coder or some kind of non-shader code generated by jME? if you mean the first one, then I agree.

"renanse" wrote:
Do you mean that jme should provide a hook for developers so that the developer can provide both paths? If so, I agree. If not, and you expect the system to provide the alternate pipeline to shaders, then no.


I do not understand what you are saying.

The fallback mechanism can be part of jme, but it will be the coder’s responsibility to code what that fallback is.

The format change would be optional and would not have any down side. The main fall back would be using light states instead of the shader

oh right, i see…



so what your saying is that if applying the shader fails due to some problem (ie. fragment programs are unsupported by their card), jme should automatically fall back onto something that can emulate this desired effect?



In this cause, i sort of agree. But i strongly believe the fall back should be user based and jme should not do this automatically.



DP

"renanse" wrote:
Well, when you said you wanted jme to "fall back on the standard pipeline" do you mean fall back on non-shader code written by the coder or some kind of non-shader code generated by jME? if you mean the first one, then I agree.

I mean fall back on standard states and on the users code. I also think that the .jme format should have something that lets you specify back up states if the one you want is not supported. I do NOT think that jme should supply a software renderer for shader code.



<shadersupported>

<--shader states-->

</shadersupported>

<shadernotsupported>

<--non shader states-->

</shadernotsupported>

Do you mean that jme should provide a hook for developers so that the developer can provide both paths? If so, I agree. If not, and you expect the system to provide the alternate pipeline to shaders, then no.

"renanse" wrote:
Or perhaps you mean we should handle the shader program arguments for the user? Such as passing the position of a light and so forth... Something like that could be possible, basically a standardization of argument names and such, but sounds more useful as an external addon pack to me.

That and more. If the shader is disabled and unsupported jme will have to fall back on the standard pipe line. I think that this should be part of the core because I predict that this will become the most important part of a 3d engine very soon.

Yeah, if you mean "adding a shader should be as easy as adding a texture" then it already is… If you have your shader files, you simply create a GLSLShaderObjectsState, ask it to load your files and add the state to the scene object in question. Very similar to textures… you have your graphic, you create a TextureState and you have the system load your graphic and then add the state to the scene object.



Or perhaps you mean we should handle the shader program arguments for the user? Such as passing the position of a light and so forth… Something like that could be possible, basically a standardization of argument names and such, but sounds more useful as an external addon pack to me.

Hmm… I think I’ve understood what Badmi’s said, but it’s technically very difficult to do… I’ve never seen an engine doing that for the user. It would mean that the engine generate the shader’s code…



Could you point me to an engine that can do that ?



Chman

I still misunderstand then. Adding a shader is just as easy as adding a texture, you load the shader program into a shader state and set the state to the node.

You misunderstood me. Many modern engines have the ability to allow you to add shaders as easily as you would add a texture handling all the work of applying the lights and so on. Now that jme is being redesigned I am suggesting that this is a good time to look into how shaders fit in.



I was in a rush when I posted the last post and must have misused the spelling program.

://

"Badmi" wrote:
One thing I was wondering was how shatters will fit into JME. For example if I want some of my motels to have shatters and some not to. Will I be able to put shaders into the .jme format? And how will this work with lighting?
(If "shatters" equal "shaders") The lighting depends from your shader's code. There are keywords in ARB, GLSL, Cg or HLSL that return you each light that apply on the wanted vertex/fragment (you can retrieve the location of the light, diffuse, etc). Shaders are used to recreate your graphic card's rendering pipeline. Lighting is not automatic on objects that use shaders. You have to handle it manually.

Although shaders become more friendly to use, it's an advanced feature. You should read some books (for GLSL, the Orange Book is the best one).

Good luck.

Chman
"Badmi" wrote:
For example if I want some of my motels to have shatters and some not to. And how will this work with lighting?

Shutters on your motel windows will no doubt affect the lighting inside. Very handy if you live hurricane or tornado country (like miami city) to stop the glass shattering.

but I suspect you are asking about something else, no?

I think mojo mentioned it once before, Badmi, but can you please check your post for correct spelling and meaning before submitting. That's why there is a preview button.
http://dictionary.reference.com/ is a handy learning and reference resource.

I look forward to your posts (and code) but it really helps if you make clear and concise posts. We all make mistakes, but it helps if we take the time to check before sending (I've learnt by painful experience).
This is even more important if english is a second language, in the case of acquiring correct grammer.

ie:
motel: An establishment that provides lodging for motorists in rooms usually having direct access to an open parking area. Also called motor court, motor lodge

shatters: To cause to break or burst suddenly into pieces, as with a violent blow.

pc

ps: I'm not bagging anyone because they can't speak english properly. I'm learning Japanese (yet again) and I know the problems caused by mispronunciation. At least it's not chinese, with all those tones...

One thing I was wondering was how shatters will fit into JME. For example if I want some of my motels to have shatters and some not to. Will I be able to put shaders into the .jme format? And how will this work with lighting?

Thanks for making it clear for me what is going on.

Sounds like a good plan.



I think "professional API" is an achievable target to aim for, and your "stop, take deep breath, tune up, focus" approach is a good milestone.



If I could add a couple more that I think fit under your general categories.


  • full support for all OpenGL features needed, such as sampler3d for GLSL.


  • I sent cep21 some test files as requested so he may be looking at it it, but I’d like to suggest that the jME internal file format is an advanced format that has only one vertex that may support multiple uv’s (like .obj/.x as suggested by snaga). However, I’m no expert in this area (just had to do a quick crash course in indices/vertex structures) so any other comments would be welcome. Reason? I’m researching auto generating spring models for physical simulations (eg: soft bodies) and if the jME file has duplicate vertices it makes it extremely difficult to map the simulation back to the model. CompositeMesh (sphere) tristrips also appears to generate vertex duplicates (different vertices with same physical position) as well.





    Merry new year,

    pc

I think, Mojo’s and Renanse’s statements are the best thing that could possibly happen to jME and I have a very good feeling about this!



Thanks guys for this clear statement and vision. If desired, I am willing to take part in this future development, trying to ask the right questions, learning things, making suggestions and follow the general direction once it is decided.



If we are going to have a refactoring/bug hunting release, in which form would you like to receive input for that?

If we are going to have a refactoring/bug hunting release, in which form would you like to receive input for that?


Most likely start using the Issue Tracker on jme.dev.java.net, but Renanse and I will discuss the details to confirm if this is the case and the process by which to do it.