Quake3 level loader - Benchmarks

[Marvin Fröhlich]

Looking at the numbers you were quoting compared to Renanse's I'm not convinced which version would be faster. It would seem Tom's was quicker.

However, I think it'd be a clearer comparison of scenegraph core performance if the code bases were essentially pretty similar. The webstarts and related resources were referenced in this thread:

http://www.java-gaming.org/forums/index.php?topic=11748.60

I've had a look at the source of Tom's one. The sources are dammn similar. There won't be a difference in the performance because of the loader code.

Marvin

[Marvin Fröhlich]

It would be very nice if the test could be redone when I've optimized the RenderBin thing. The two test results would be of a very high interest.

[kevglass]

Be even nicer to see ongoing performance tests as you do the optimizations. Would help us all understand which ones were the most useful.

Kev

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

Be even nicer to see ongoing performance tests as you do the optimizations. Would help us all understand which ones were the most useful.

Well, so far the only optimization visible in performance is the one concerning the display lists. This has done a 22% boost in MultiCubeBenchmark and 16% in BSPLoaderTest. The other "optimizations" were just to make the code better understandable and cleaner.

The next big boost is to expected from the RenderBin optimizations.

Marvin

[renanse]

I pulled down xith from cvs and paired it up with the code I have here...  I had to massage a lot of the texture stuff to get it to work, and the end result is that the performance is actually slightly worse than before.  Maybe you could edit the xith version of the joint test code and post that somewhere?

[Amos Wenger]

I pulled down xith from cvs and paired it up with the code I have here...  I had to massage a lot of the texture stuff to get it to work, and the end result is that the performance is actually slightly worse than before.  Maybe you could edit the xith version of the joint test code and post that somewhere?

sometimes I'm inclined to believe you're a lier paid by NCSoft to diffuse false infos about jME's concurrent engines..

but I *do* know it's not true at all.. so please don't flame again, FPS is FPS, OK ok I know.

[kevglass]

sometimes I'm inclined to believe you're a lier paid by NCSoft to diffuse false infos about jME's concurrent engines..

but I *do* know it's not true at all.. so please don't flame again, FPS is FPS, OK ok I know.

Wow, I assume thats the language barrier coming in there because otherwise thats fairly insulting. Also, there doesn't appear to be a flame anywhere?

Kev

[Marvin Fröhlich]

I pulled down xith from cvs and paired it up with the code I have here...  I had to massage a lot of the texture stuff to get it to work, and the end result is that the performance is actually slightly worse than before.  Maybe you could edit the xith version of the joint test code and post that somewhere?

What do you mean? The cluster-visibility test? This is the same as in David's original and in the version I found in the original benchmark thread (posted above).

And I can't believe the FPS are worse than before ,since we have display lists now and the rendering code is not less efficient than before.

Marvin

[Amos Wenger]

sometimes I'm inclined to believe you're a lier paid by NCSoft to diffuse false infos about jME's concurrent engines..

but I *do* know it's not true at all.. so please don't flame again, FPS is FPS, OK ok I know.

Wow, I assume thats the language barrier coming in there because otherwise thats fairly insulting. Also, there doesn't appear to be a flame anywhere?

Oh yeah I know shouldn't have posted that, it's just it seems the FPS of Xith3D in the Q3 bench really can't go up. Now it seems even that it has gone down since display lists implementation. Unbelievable.

@renanse : don't pay attention I said it wasn't true.. I just feel a bit sad

[kevglass]

Oh yeah I know shouldn't have posted that, it's just it seems the FPS of Xith3D in the Q3 bench really can't go up. Now it seems even that it has gone down since display lists implementation. Unbelievable.

Well there have been a lot of other changes going on with Xith aswell. Not to mention as Renanse pointed out, the code provided here isn't the same code base as he tested before - because this is based directly off David's initial code, rather than Tom's benchmark (of SquareHeads - the optimised Quake 3 level renderer - fame).

Either way, Renanse is nice enough to bother running the tests - no need to get defensive

Kev

Games published by our own members! Check 'em out!

[Amos Wenger]

Oh yeah I know shouldn't have posted that, it's just it seems the FPS of Xith3D in the Q3 bench really can't go up. Now it seems even that it has gone down since display lists implementation. Unbelievable.

Well there have been a lot of other changes going on with Xith aswell. Not to mention as Renanse pointed out, the code provided here isn't the same code base as he tested before - because this is based directly off David's initial code, rather than Tom's benchmark (of SquareHeads - the optimised Quake 3 level renderer - fame).

Ahm I see. Anyway, is it possible that display lists are slower than immediate mode/vertex arrays

Either way, Renanse is nice enough to bother running the tests - no need to get defensive

Yeah sure, not is fault for sure. "Say Thanks -Thanks -Thanks who ? -Thanks renanse".
Anyway, would be interesting to be able to run the test on others computers, just to see if the difference is so great (not pretending anything here).

[renanse]

I can understand the frustration, but honestly, NCsoft doesn't care if Xith or jME looks better to the community, they just wanted, and got, a Java game base to build from.

Anyhow, as has been pointed out, the code I am using to run Xith/Q3 is the same code I was using on the last benchmark, just tweaked (very quickly) by me to run with the changes in the latest cvs...  things like how you guys split TextureLoader up into utility classes and locator classes, etc.  Unless display lists "just happen" under the covers, I'm sure they aren't turned on, and who knows what other things might need to be turned on in the test to make most optimal use of the engine.  So, if someone could take the original joint test code from the beginning of this year and tune it to work with your latest xith changes, I'll be happy to redo the stats as before (plus post web starts and source code if that's desired.)

[kevglass]

Ahm I see. Anyway, is it possible that display lists are slower than immediate mode/vertex arrays

I suppose it depends how they're being used. If the display lists get built incorrectly it could be rendering more of the scene that it used - i.e. preventing culling or something?

Or I suppose it's possible there might have been some error in the display list code making it recreate every frame, or possibly killing a wierd driver implementation.

Or possibly, it's just not Qudus' latest cut of code - which turns out to be ultra fast! 

Never know until you benchmark and profile

Kev

[Amos Wenger]

I can understand the frustration, but honestly, NCsoft doesn't care if Xith or jME looks better to the community, they just wanted, and got, a Java game base to build from.

Yeah, and that's the worth of it : it's nobody's fault  ........................  Anyway, thanks not bugging as easily as me.

Anyhow, as has been pointed out, the code I am using to run Xith/Q3 is the same code I was using on the last benchmark, just tweaked (very quickly) by me to run with the changes in the latest cvs...  things like how you guys split TextureLoader up into utility classes and locator classes, etc.  Unless display lists "just happen" under the covers, I'm sure they aren't turned on, and who knows what other things might need to be turned on in the test to make most optimal use of the engine.  So, if someone could take the original joint test code from the beginning of this year and tune it to work with your latest xith changes, I'll be happy to redo the stats as before (plus post web starts and source code if that's desired.)

Ah ok display lists aren't turned on. Maybe FPS will go up then.

[Amos Wenger]

I suppose it depends how they're being used. If the display lists get built incorrectly it could be rendering more of the scene that it used - i.e. preventing culling or something?
...

Well surely display lists implementation as now aren't the most efficient solution, I bet. But it do work for now.

[renanse]

Cool.... so, can any volunteers for updating the xith q3 test?

[Amos Wenger]

Cool.... so, can any volunteers for updating the xith q3 test?

Sure, I'm giving it a try.

[Amos Wenger]

This image sum it up pretty well.

- Tom's version loader *works*
- Performance is acceptable (~20-40 FPS) with my crappy card when staying *in* the level. From outside I get a plain 7FPS
- There is a transparency problem with the flames (maybe RGBA loading is not enabled, I'm gonna check that).
- Some texture files are missing

[Amos Wenger]

I had the display lists enabled, noticeable perf boost.

[renanse]

Great!  Source?

[Amos Wenger]

Great!  Source?

On CVS, why ? 
com.xithtk packages and trb.timer ones.

[renanse]

You put the joint quake test in your main cvs?  Sorry if I didn't expect that. 

[renanse]

Ah, didn't see xith-tk before.

[renanse]

Hey, nice job, definitely much faster, just a couple texture issues you noted before.  Runs at about 242 FPS now.

edit: Let me know when you finish working on it and I'll redo the full set of tests and put together web starts.

[Marvin Fröhlich]

I've now updated the loader (in org.xith3d.loaders.bsp) to use renase's texture code. The textures are fine now (apart from the missing ones) and lighting is better, since I took renase's lightmap code.

I also took the setVisibility() code, which was slightly different (espeacially concerning usePVS parameter). Now I don't see any reason, why my port should be slower than the other one. The only thing could be input or timer. Please have a look and tell me, if you see any differences in FPS (I don't).

Marvin

EDIT: btw. These wyred key settings in Quake3Renderer are driving me mad .

[Marvin Fröhlich]

View does not work very well here : i get a
dX = -1
dY = -3
when I don't even move my mouse.. HIAL problem I guess..

Solved the problem.

In non-fullscreen (decorated) mode the method getLocationOnScreen() of the Component class returns other values than it will do after the first rendered frame, which are the correct ones. So the method updateCenters() of the AWTMouse class needs to be called once more after the first frame. Another option is to call mouse.setExclusive(true) after the first frame.

Well, anyway, I've added a fix to the RenderLoop class, which calls updateCenters() for all registered, exclusive AWTMouse devices once exactly after the first frame. Now the mouse should work properly. Please tell me if it does for you, too.

Marvin

[Marvin Fröhlich]

I have written a new utility called CameraFlight. It loads a camera flight previously recorded using the class CameraFlightRecorder (both in org.xith3d.util.view) and moves/rotates the View according to the loaded matrices and times.

I think this would be a good test to compare engines or optimizations. Since it is very important to have the exact same view positions to take FPS test, this is the best solution to be sure.

Take a look at BSPLoaderTest and find these lines (117 - 155):

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39

switch (key)         {             case 120: // F9                if (flightRecorder == null)                 {                     flightRecorder = new CameraFlightRecorder(view, 100L);                     this.addInterval( flightRecorder );                     this.addIntervalListener( flightRecorder );                                         flightRecorder.startRecord(getGameTime(), "camflight.cflt");                 }                 else                 {                     flightRecorder.stopRecord();                                         this.removeIntervalListener( flightRecorder );                     flightRecorder.kill();                     flightRecorder = null;                 }                 break;                             case 121: // F10                if (camFlight == null)                 {                     try                     {                         camFlight = new CameraFlight( "demo/levels/quake3/bdmq3duel5/camflight.cflt" );                         camFlight.start( getGameTime() );                     }                     catch (IOException e)                     {                         e.printStackTrace();                     }                 }                 else                 {                     camFlight = null;                 }                 break;

By pressing F9 you can record a new camera flight (press F9 again to finish). By pressing F10 you can replay a recorded one (in this case the one saved to demo/levels/quake3/bdmq3duel5/camflight.cflt) (press F10 again to get back mouse control).

It should be very straight forward to port the CameraFlight class to other engines to replay a flight recorded in xith.

On my machine this camera flight makes an average FPS of 96, which is printed to the console, when the flight is finished (and restarts from the beginning). This flight takes about a minute or so.

Unfortunately I currently have problems with the interpolation of the matrices (recorded one at 100ms), so I'm currently using uninterpolated flight. But this shouldn't address the FPS too much, but just looks a bit ugly .

Maybe someone could help me with the interpolation. This is the code to be found in org.xith3d.util.CameraFlight:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

// ip1 is the last interpolation point (matrix) and ip2 is the next one        float dt = (float)t0t - (float)t0i; // this is the time from the last interpolation point to the current time (between 0 and 100 ms)                 float d;         for (int i = 0; i < 4; i++)         {             for (int j = 0; j < 4; j++)             {                 d = ((ip2.matrix.getElement(i, j) - ip1.matrix.getElement(i, j)) * dt); // interpolated value for this element of the matrix                viewMatrix.setElement( i, j, ip1.matrix.getElement(i, j) + d );             }         }                 view.getTransform().set( viewMatrix );

Thanks in advance.

Marvin

[Amos Wenger]

Average FPS : 22.

[Amos Wenger]

I deleted the com.xithtk packages. Your version now rules, Marvin.

[renanse]

Um, so then we'd have to report your new stuff to J3D and jME to be able to do a valid cross test?