Cool, was pretty easy to port the CameraFlight class to work with jME and run your pre-recorded flight. I've also ported the class to my copy of the Q3 Java3D test and for kicks I've also ported it to the old version of the Xith3D test as a means of measuring any difference between old and new xith tests.
One thing I noticed is the texture filtering and the torch transparencies are much much nicer on the older version of the xith q3 test. The first thing I was able to correct in BSPConverter.convertTextures(String[]) like so:
1
2
3
4
5
6
7
| if ((textures[i] == TextureLoader.getInstance().getDefectTexture()))
{
System.err.println( "texture not found: " + textureNames[i] + " (.jpg / .tga)" );
} else {
textures[i].setMagFilter(Texture.BASE_LEVEL_LINEAR);
textures[i].setMinFilter(Texture.MULTI_LEVEL_LINEAR);
} |
For the transparency issue, I could not find anything different between how the old xith and new xith tests set up transparency, so I'm guessing it's due to a change in the engine itself. Have you changed how render bins and sorting work by any chance?
FYI: One other thing I noticed is that playback of the camera flight has several of intermittent flashes on xith... I saw something similar in jME and switched from Quats to Matrix3f and that fixed it.
Btw, my machine at home is spec'd as follows: P4 3.2 GHz with 2.75 GB of RAM and a Radeon X850 XT Platinum running WinXP and Java 1.5.0_07
In any case, without further ado, the flight numbers and memory usage. I've let it run through 6 fly throughs and taken the readings at the end of the each (memory reading were done on a seperate run using yourkit and they were taken after the 3rd lap had finished and printed out the average time.) Note also that no command line args were passed to the java process, so default memory caps, etc.
Xith3D old version:
flight average times: 112.6, 113.8, 114.2, 113.4, 111.4, 113.1
heap (allocated/used): 52.4 MB / 35MB (used more memory than the newer version, but used memory stays nice and flat.)
non-heap (allocated/used): 11.2 MB / 11.1 MB
Xith3D new version (HUD off):
flight average times: 163.2, 163.5, 143.3, 121.2, 112.0, 98.9
heap (allocated/used): 27.4 MB / btwn. 17MB and full usage (used memory was all over the place causing lots of small gcs, as it progressed, gc caused the framerate to drop as you can see.)
non-heap (allocated/used): 12.1 MB / 12MB
jMonkeyEngine:
flight average times: 224.4, 226.8, 226.3, 226.5, 226.4, 224.4
heap (allocated/used): 30.1MB / 17.5MB
non-heap (allocated/used): 9.4MB / 8MB
Java3d:
flight average times: 198.8, 199.1, 195.5, 194.8, 194.7, 194.3
heap (allocated/used): 44.8 MB / 36 MB
non-heap (allocated/used): 11MB / 10.8MB
So, on one hand, kudos on getting initial frame rates up and memory usage down. On the flip side, object creation is so bad it really eats frame rate as time progresses and the flight plays, especially around the 3rd flight and beyond. Also, it would be nice if the transparency was working on the new version so we could definitely be comparing apples to apples.
I'll wait to do webstarts and all of that until you do whatever optimizations you were talking about. (Man I am so sick of seeing that same quake level!
)
edit: fyi, in case it wasn't apparent above, "flight average times" is the average FPS following a prerecorded flight plan.
edit: as requested, I've attached the flight path used (it's just what I found in CVS) I had to rename it from .cflt to .txt
