I would like see some movement towards getting 2.0 tagged so that we can get on with it already. I know many of you have really great ideas and plans for jME. This is an outline of what I am ready to do in order to get the ball rolling again.
I have added milestones to the issue system at google and organized the issues that are already there. I acknowledge that the current state of the API is not what every one had dreamed 2.0 would be. But it is what it is, and I think some great changes have been made to it. I also feel that because it has been somewhat stagnant and widely used, I am confident in it’s stability and quality to be a release candidate.
I would like to see one thing done before we release. I think we need to finish the conversion to enumerations in the few places that have not yet been done (like render states). This will of course ‘break’ your code, but this is the right time to make these kind of changes. If there is anything else you think is an absolute must for 2.0 then create an issue ticket and let us discuss it here.
When this is done, and the API is consistent we release 2.0 and then branch for bug fixes. At that point, we can come together as a community for jME 3.0 and begin work on the many large enhancements and changes we all want to happen. You have already put forth some great plans and outlines and we should begin now discussing these topics and adding the agreed upon tasks for milestone 3.
I will work on issues this weekend, and I ask that you also check the issue list and grab one that has not already been claimed for milestone 2.0. There are only a couple and they are not difficult.
We have an awesome framework and an awesome group of people all willing to carry this project forward. Now is the time, let’s get on with it.
nymon said:
II will work on issues this weekend, and I ask that you also check the issue list and grab one that has not already been claimed for milestone 2.0. There are only a couple and they are not difficult.
Fully agree
Where is the issue list ?
Looks like we need a JOGL volunteer for the last task. Then we can draw that line under JME2.0
theprism said:
Looks like we need a JOGL volunteer for the last task. Then we can draw that line under JME2.0
Well, I think we want to remove any direct GL calls if possible. Momoko_Fan mentioned this, so maybe he can knock it out fairly easily when he gets a chance.
I took a look at that, and I really don't think there is a way to completely remove the calls directly to the current openGL implementation; jME doesn't really have an abstraction layer against any particular renderer (hence the need to have a JOGL and LWJGL camera class). However, performance wise I wonder if that isn't a thought out decision…
The other projected tests seem run beautifully under JOGL, and I really am starting to wonder if its not a shader issue.
If I reload the shader (by pressing 'G') I get this:
Jan 12, 2009 2:30:13 PM com.jmex.effects.water.WaterRenderPass reloadShader
WARNING: Error loading shader
com.jme.system.JmeException: Error in opengl: invalid value
at com.jme.renderer.jogl.JOGLRenderer.checkCardError(JOGLRenderer.java:1883)
at com.jmex.effects.water.WaterRenderPass.reloadShader(WaterRenderPass.java:398)
at com.jmex.effects.water.WaterRenderPass.setUseReflection(WaterRenderPass.java:818)
at jmetest.effects.water.TestProjectedWater.simpleUpdate(TestProjectedWater.java:101)
at com.jme.app.SimplePassGame.update(SimplePassGame.java:62)
at com.jme.app.BaseGame.start(BaseGame.java:84)
at jmetest.effects.water.TestProjectedWater.main(TestProjectedWater.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at jmetest.TestChooser.start(TestChooser.java:465)
at jmetest.TestChooser.main(TestChooser.java:444)
Caused by: javax.media.opengl.GLException: invalid value
at com.jme.renderer.jogl.JOGLRenderer.checkCardError(JOGLRenderer.java:1880)
... 12 more
Under LWJGL no exceptions....
I was working on this but didn't get it to work quite right. The trick is to use the AbstractCamera class.
Just to clarify here, what are all the features that jME 2.0 includes that were not in 1.0?
darkfrog said:
Just to clarify here, what are all the features that jME 2.0 includes that were not in 1.0?
That is something we really need to figure out and put together. I was thinking about running through the revision history. We should be able to list the additions, changes, and fixes.
Could the issue 24 be fixed in the release 2.0 instead of 2.1? I'm really sorry, I investigated some days but I didn't succeed in finding a fix.
gouessej said:
Could the issue 24 be fixed in the release 2.0 instead of 2.1? I'm really sorry, I investigated some days but I didn't succeed in finding a fix.
I will take a stab at it this week.
I am not sure we can really use the abstractCamera classes (which I did think about at the very first…)
The problem is that while the current camera implementations will store the correct matrices for us (I think…) it is using algebra to obtain/save the matrices, not (super fast) openGL calls and nio buffers direct to the video card. Furthermore, the derived camera classes that actually do make use of the buffers only use a single instance as a temp buffer; therefore I think the camera classes would need to be looked at before switching ProjectedTextureUtil to all non-openGL calls.
I could be all wrong here but I do (and always did) see how the camera classes would fit into this puzzle, when I try making the changes I quickly run into needing to change the camera classes; which I don't know about (although just having them store an extra buffer or 2 might not be much of a change).
The problem is that while the current camera implementations will store the correct matrices for us (I think...) it is using algebra to obtain/save the matrices, not (super fast) openGL calls and nio buffers direct to the video card. Furthermore, the derived camera classes that actually do make use of the buffers only use a single instance as a temp buffer; therefore I think the camera classes would need to be looked at before switching ProjectedTextureUtil to all non-openGL calls.
Guess what.. OpenGL uses algebra to obtain the matrices as well. Using those OGL calls means sending and reading from the video card (to change the modelview matrix), which uses the GPU bus. In addition to that, the call to get the matrix is an extremely costly one as GPUs don't like sending back info. There's a reason why the camera classes were switched from using OGL calls for perspective/projection calculation into algebra on the CPU.
I could be all wrong here but I do (and always did) see how the camera classes would fit into this puzzle, when I try making the changes I quickly run into needing to change the camera classes; which I don't know about (although just having them store an extra buffer or 2 might not be much of a change).
I didn't have to do any changes to them. The AbstractCamera class has all the neccessary calculations and methods built-in.
GPUs don't like sending back info
lol, I have never been told that (so didn't know) but it makes a lot of sense.
okies, I took my 'lunch break' a wiped up a quick 'camera' only implementation. however I must be doing something wrong with the lookat because the projected textures are not in the right spot. Maybe someone could take a look and see if anything pops out at them (probably the lookat vector just needs to be adjusted, but I have already used up my 'free time')...
import com.jme.image.Texture;
import com.jme.math.Matrix4f;
import com.jme.math.Vector3f;
import com.jme.renderer.Camera;
import com.jme.renderer.Renderer;
import com.jme.renderer.jogl.JOGLCamera;
import com.jme.renderer.jogl.JOGLRenderer;
import com.jme.renderer.lwjgl.LWJGLCamera;
import com.jme.renderer.lwjgl.LWJGLRenderer;
import com.jme.system.DisplaySystem;
/**
* <code>ProjectedTextureUtil</code>
*
* @author Rikard Herlitz (MrCoder)
*
* Dual implementation framework:
* @author Joshua Ellen (basixs)
*/
public class ProjectedTextureUtil {
private static final Vector3f[] savedCamera = new Vector3f[ 4 ];
static {
for( int i = 0; i < savedCamera.length; ++i ){
savedCamera[i] = new Vector3f();
}
}
//
private static Camera camera = null;
private static Matrix4f lightProjectionMatrix = new Matrix4f();
private static Matrix4f lightViewMatrix = new Matrix4f();
private static Matrix4f biasMatrix = new Matrix4f( 0.5f, 0.0f, 0.0f, 0.0f,
0.0f, 0.5f, 0.0f, 0.0f, 0.0f, 0.0f, 0.5f, 0.0f, 0.5f, 0.5f, 0.5f,
1.0f ); // bias from [-1, 1] to [0, 1]
/**
* Updated texture matrix on the provided texture
*
* @param texture
* Texture to update texturematrix on
* @param fov
* Projector field of view, in angles
* @param aspect
* Projector frustum aspect ratio
* @param near
* Projector frustum near plane
* @param far
* Projector frustum far plane
* @param pos
* Projector position
* @param aim
* Projector look at position
*/
public static void updateProjectedTexture( Texture texture, float fov,
float aspect, float near, float far, Vector3f pos, Vector3f aim,
Vector3f up ) {
if( camera == null ){
// We have to use the derived implementation constructor because there is no
// renderer.createCamera( width, height, dataOnly ); method...
final Renderer renderer = DisplaySystem.getDisplaySystem().getRenderer();
if ( renderer instanceof LWJGLRenderer ) {
camera = new LWJGLCamera( renderer.getWidth(), renderer.getHeight(), true );
} else if ( renderer instanceof JOGLRenderer ) {
camera = new JOGLCamera( renderer.getWidth(), renderer.getHeight(), true );
}
}
matrixPerspective( fov, aspect, near, far, lightProjectionMatrix );
matrixLookAt( pos, aim, up, lightViewMatrix );
texture.getMatrix().set(
lightViewMatrix.multLocal( lightProjectionMatrix ).multLocal(
biasMatrix ) ).transposeLocal();
}
private static void matrixLookAt( Vector3f location, Vector3f at,
Vector3f up, Matrix4f result ) {
// saveCameraFrame();
camera.setLocation( location );
camera.lookAt( at, up );
// camera.update();
// camera.apply();
setModelViewMatrix( result );
// result.invertLocal();
// restoreCameraFrame();
}
private static void matrixPerspective( float fovY, float aspect,
float near, float far, Matrix4f result ) {
// saveCameraFrame();
camera.setFrustumPerspective( fovY, aspect, near, far );
// camera.update();
// camera.apply();
setModelViewMatrix( result );
// result.invertLocal();
// restoreCameraFrame();
}
private static void setModelViewMatrix( final Matrix4f result ) {
result.set( ( (AbstractCamera) camera ).getModelViewMatrix() );
}
private static void saveCameraFrame() {
savedCamera[0].set( camera.getLocation() );
savedCamera[1].set( camera.getDirection() );
savedCamera[2].set( camera.getUp() );
savedCamera[3].set( camera.getLeft() );
}
private static void restoreCameraFrame() {
camera.setLocation( savedCamera[0] );
camera.setDirection( savedCamera[1] );
camera.setUp( savedCamera[2] );
camera.setLeft( savedCamera[3] );
camera.apply();
}
}
(The commented lines are where I was testing to see what was wrong...)
(Not sure its how Momoko_Fan would have done it, but it seems to work except for the above mentioned problem...)
The point I was trying to make was…are there enough "major features" in 2.0 to justify it's "completion" to move towards a 2.1 or 3.0?
darkfrog said:
The point I was trying to make was....are there enough "major features" in 2.0 to justify it's "completion" to move towards a 2.1 or 3.0?
What qualifies as enough? I certainly have no problem with waiting so we can include more changes. It just seems to me that not many people are very excited about working on jME, or are holding off for some reason. I was hoping that moving away from the 2.0 mark that seems to be haunting us would stimulate the community. I haven't received much feedback though, so I appreciate your questions darkfrog. What do you think?
nymon said:
gouessej said:
Could the issue 24 be fixed in the release 2.0 instead of 2.1? I'm really sorry, I investigated some days but I didn't succeed in finding a fix.
I will take a stab at it this week.
Thanks
The point I was trying to make was....are there enough "major features" in 2.0 to justify it's "completion" to move towards a 2.1 or 3.0?
In this case I kinda think that its not the major features, but the major changes than are requiring a solid (final) 2.0. More than one person has requested this and I for one tend to agree...
Just think we should draw a line under it now and move on.
I don't have a problem with releasing 2.0 presuming that additional development is going towards 2.1 and not a 3.0. I think it's a very bad idea to push out a version just to try to get people excited about something. I say, get more features and functionality and people are more likely to be excited than an arbitrary statement of "hey, this is stable and we assigned a pretty number to it". :-p