jme mouse input

The mouse input system in jME has long suffered from some issues of smoothness. This is especially noticeable when moving the camera frustum from a high fps view to a very low fps view and back again. The issue looks like a bug in how the mouse camera rotation is generated. It uses the displacement of the mouse X the difference in time since the last input system update X an input speed. (actually, I think the speed is actually done twice.) Throwing out the speed since it is a constant, we are left with a mouse displacement (or in other words, how far the mouse moved since the last update on a given axis) and the time.

The bug is that there is no need for time since we really only need to account for displacement amount. All the time variable is doing is magnifying the result when the fps is low (thus raising the amount of time since the last update) or diminishing the result when the fps is high. The time variable was really just a carry-over from the key input system where the action (such as moving forward) is a boolean on/off deal and time is used to account for how long the button is in the on state.

What does this mean? I will be doing a small rework of the mouse input internals (classes like MouseLook and MouseNodeLook which are used by classes like FirstPersonHandler, etc.) to fix the bug. Unfortunately though, this *may* mean that if you are using jME, your mouse input speed may need readjusting. If you were just using default values though, you should be ok as I will attempt to keep things as close to the same as possible. I will also be removing the speed*speed affect of having speed in the MouseLook classes and in the actions (it will just stay in the action.)

Stay tuned.

Particles

The last several days have seen several changes and upgrades in jME's particle system. Much of that was prompted by work done by Andrzej over at Three Rings who gave the so called "RenParticleEditor" I wrote a couple years ago a nice face-lift.

What was done? Well, for starters, you can now use the editor to layer multiple particle emitters. You can also load/save particle effects to file using jME's new efficient binary format. You can now access more of jME's particle system properties, such as being able to emit from a line, rectangle, etc. (he added a Ring origin type, ironically enough... :) The camera controls are now orbit based and things just look, well, nicer. Since you can save your particle effect to .jME format, the code panel has been removed. The editor has an added amount of sleep between frames (2ms) to allow the swing panels to be more responsive to input.

As he did these things, I got the itch to go back and start looking at the particle system itself. In the previous releases, you could set a gravity influence on your particle system, but that's it; And it was a hard-coded property of the particle system. Now you can create your own particle influences and apply as many as you like. A few basic influence types are there for you already including gravity, wind, drag and a cool vortex (the last donated by Andrzej who also was very patient as I constantly made changes.)

The texture on particles is now correctly oriented. The old code had it flipped horizontally which made words hard to read without a mirror. You can test that out with the texture image below (right click - save as):


In addition, particles are now faster and cheaper, largely due to a change I made regarding the geometry of particles. The previous system used a textured quad, so 2 triangles, 4 verts and 6 indices. Now I am using a single triangle, 3 verts and 3 indices. It still looks the same because the triangle is created such that it can just fit the old quad with side (s) nicely inside it (see the diagram below) and is centered in the same position (P) so rotating the particle has the same effect.



The results? I can render the same number of particles and use half the triangles and 25% less verts. I can also render 10,000 software calculated particles in the editor at 80fps whereas the webstart version gives me 25fps or so.

What's to come next? I'm thinking of working on an extension that takes the particles from software calculated to hardware. And perhaps more from Three Rings on making the editor easier to use and more functional. (Thanks again to those guys!!) If you have ideas for cool features, give me a shout.

You can try out the old version here (until jME .11 is released...) [old version] Be careful, I noticed that version does not exit cleanly... sigh. If you'd like to try the new one, you'll need to pull it down from cvs.

More from Sun

Came across this online:

more from yesterday

The doubters have bad memories (see comments on last post), so here is a posting of their words to remind them:

[00:40:26] <Gustav_Trede> im amazed i can draw 1 mill
triangles shaded at 30 fps and java app cpu load is 0 or
 sometimes 1%. total cpu load is 1-2%.
[00:40:47] <Gustav_Trede> so i love  LWJGL =).  and jme that
 makes it easy
[00:41:12] <DarkProphet> you can draw 1 million triangles per 
second ?
[00:41:20] <DarkProphet> or 1 million triangles per frame ?
[00:41:31] <Gustav_Trede> yes and it takes 1-2% total cpu load.
[00:41:39] <Gustav_Trede> its 30 mill per second
[00:41:49] <DarkProphet> which one? per frame or per second ?
[00:42:11] <Gustav_Trede> 30 fps a  1 mill triangles = 30M
 triangles / sec
[00:42:21] <DarkProphet> ah ok, so 1million triangles

And then later on...

[00:46:30] <DarkProphet> if you can render 1 million
 triangles @ 30 fps...you'll be my god :)

No worries, I won't be claiming my deity status yet...

34,078,720

There was a few doubters out there, so I thought I'd just put this out there for the record. That's how many triangles per second I got in jME in a sample run through one of our simple test demos (unoptimized, lots of extra key checks and debug code, etc.)

Not bad for Java, huh?

Here's the screen shot for the curious. Click for the original 800x600... It's a bit big due to it being straight from the renderer with no resizing or touching:



Here's another view... I've cranked up the heightmap from 128x128 to 1024x1024 to show off having a couple million tris in a scene at once:

71,303,168 triangles per second. :) Keep in mind that this is using opengl lighting as well as multitexturing with blending on each triangle. Also consider that there is scene overhead of boundings, transforms, etc (which can be locked in jME to reduce overhead, but weren't in this case.)



In wireframe mode (a bit slower) you can see how dense the triangles are packed...



If you'd like to run it yourself, here ya go (you'll need Java 1.4 or higher, I used java 1.5.0_07 on a p4 3.2 machine with a Radeon X850 powering dual monitors - running lots in the background and no optimization... hmm, maybe next time I should do another test and crank things to their best settings.):
Test Here