Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Porting Quake III to Java3D  (Read 19320 times)
0 Members and 1 Guest are viewing this topic.
Offline Niwak

Senior Member


Medals: 1
Projects: 1



« Reply #30 - Posted 2005-12-16 05:54:43 »

To drakprophet. Here are what I mean by redundant callls ;

the GLIntercept log for one primitive is in Xith3d :
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  
40  
41  
42  
43  
glGetFloatv(GL_CURRENT_COLOR,0x23049aec);
glClientActiveTextureARB(GL_TEXTURE0);
glActiveTextureARB(GL_TEXTURE0);
glBindBufferARB(GL_ARRAY_BUFFER,7037);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2,GL_FLOAT,0,0x0000);
glBindBufferARB(GL_ARRAY_BUFFER,0);
glDisable(GL_TEXTURE_GEN_S);
glDisable(GL_TEXTURE_GEN_T);
glDisable(GL_TEXTURE_GEN_R);
glDisable(GL_TEXTURE_GEN_Q);
glClientActiveTextureARB(GL_TEXTURE1);
glActiveTextureARB(GL_TEXTURE1);
glBindBufferARB(GL_ARRAY_BUFFER,7038);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glTexCoordPointer(2,GL_FLOAT,0,0x0000);
glBindBufferARB(GL_ARRAY_BUFFER,0);
glDisable(GL_TEXTURE_GEN_S);
glDisable(GL_TEXTURE_GEN_T);
glDisable(GL_TEXTURE_GEN_R);
glDisable(GL_TEXTURE_GEN_Q);
glBindBufferARB(GL_ARRAY_BUFFER,7039);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3,GL_FLOAT,0,0x0000);
glBindBufferARB(GL_ARRAY_BUFFER,0);
glDisableClientState(GL_NORMAL_ARRAY);
glDisableClientState(GL_COLOR_ARRAY);
glDrawElements(GL_TRIANGLES,6,GL_UNSIGNED_INT,0x649c000); Tex=(0,35) (1,16)
glClientActiveTextureARB(GL_TEXTURE1);
glActiveTextureARB(GL_TEXTURE1);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisable(GL_TEXTURE_GEN_S);
glDisable(GL_TEXTURE_GEN_T);
glDisable(GL_TEXTURE_GEN_R);
glDisable(GL_TEXTURE_GEN_Q);
glClientActiveTextureARB(GL_TEXTURE0);
glActiveTextureARB(GL_TEXTURE0);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisable(GL_TEXTURE_GEN_S);
glDisable(GL_TEXTURE_GEN_T);
glDisable(GL_TEXTURE_GEN_R);
glDisable(GL_TEXTURE_GEN_Q);
glColor4fv( [1.000000,1.000000,1.000000,1.000000] );


the GLIntercept log for one primitive is in Java3D :
1  
glCallList(2904(src2904)); Tex=(0,23) (1,17) 

with display list equal to :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
glEnableClientState(GL_VERTEX_ARRAY)
glDisableClientState(GL_NORMAL_ARRAY)
glDisableClientState(GL_COLOR_ARRAY)
glVertexPointer(3,GL_FLOAT,28,0x246437dc)
glClientActiveTextureARB(GL_TEXTURE0)
glEnableClientState(GL_TEXTURE_COORD_ARRAY)
glTexCoordPointer(2,GL_FLOAT,28,0x246437cc)
glClientActiveTextureARB(GL_TEXTURE1)
glEnableClientState(GL_TEXTURE_COORD_ARRAY)
glTexCoordPointer(2,GL_FLOAT,28,0x246437d4)
glLockArraysEXT(0,4)
glDrawElements(GL_TRIANGLES,6,GL_UNSIGNED_INT,0x2464390c)
glUnlockArraysEXT()
glClientActiveTextureARB(GL_TEXTURE0)
glDisableClientState(GL_TEXTURE_COORD_ARRAY)
glClientActiveTextureARB(GL_TEXTURE1)
glDisableClientState(GL_TEXTURE_COORD_ARRAY)
glClientActiveTextureARB(GL_TEXTURE0)


To tom.
To get GLIntercept to work, just install it, then copy the openGL32.ddl and gliconfig.ini in your application directory.
It will work. Note that most of the time, it is configured to log one single frame when you press Ctrl+Shift+f.

To swpalmer.
Your word is a very good conclusion to this.

Vincent
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #31 - Posted 2005-12-16 15:14:38 »

Quote
1   two different benchmarks produced two different results, one has to suspect the benchmarks.  They did not test the same thing.

2   lets not confuse FPS with performance.  It is one thing to rip screen updates at full speed it is a different thing to have a high performing game.  By this I mean how well can you allocate the resources, time, memory, etc. to have the optimum frames without sacrificing game play, quality of display, quatitiy of game activities.  With xith, because I have full control over what renders, how it renders. when I want to handles key strokes/mouse actions, I can get performance through control..  In my game I adjust the various allotments of time different subsystems have based on the FPS, because I control the render loop ...I AM THE GOD OF MY GAME.  Java3D offers substantialy less control because behaviors activate at sometime in the future...that is the level of control you have..you ask Java3D to do something "pretty please" and hope it happens soon.

3 Any refresh greater than 60 FPS is a waste

to n

1) They do produce the same image now, tom said he fixed his lightmap thingy so they both produce the same. Nothing is wrong with the benchmark

2) Errr....FPS is performance. Your confusing performance with how well the programmer controls the engine.

3) You have it backwards Smiley; because Java3D's performance is now higher, i can add more stuff into Java3D's scene and it will still be >= xith's (to an extent). So you can get more dense scenes and thus, more things to look at. Whats the point of an engine that only draws a very cool box at 100 fps, while another engine can draw an entire level in 100fps ?

Niwak:
Thats an awfull lot of calls to be making just for 1 primitive...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #32 - Posted 2005-12-16 15:49:38 »

maybe we should re run JavaCoolDude's Benchmarks with the newer versions of Xith3D and Java3D?

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #33 - Posted 2005-12-16 16:00:09 »

To tom.
To get GLIntercept to work, just install it, then copy the openGL32.ddl and gliconfig.ini in your application directory.
It will work. Note that most of the time, it is configured to log one single frame when you press Ctrl+Shift+f.

Thanks, got it working now. The problem was that application directory is set to the jre/bin directory when running from eclipse.

The log for one batched array in Undead Arena:
1  
2  
3  
4  
5  
6  
glActiveTextureARB(GL_TEXTURE0)
glClientActiveTextureARB(GL_TEXTURE0)
glBindTexture(GL_TEXTURE_2D,73)
glActiveTextureARB(GL_TEXTURE1)
glClientActiveTextureARB(GL_TEXTURE1)
glDrawElements(GL_TRIANGLES,42,GL_UNSIGNED_INT,0x1b3e1000)


Also the geometry is batched up so there is usually 10 times as many triangles being drawn for every draw call compared to Java3D and Xith3D.


Quote
maybe we should re run JavaCoolDude's Benchmarks with the newer versions of Xith3D and Java3D?

That might be a good idee to see if there has been a change in the performance of the two libs. But don't compare this benchmark with JavaCoolDude's. They test completely different things. Xith3D may still have a lower overhead and faster than Java3D on "simple" benchmraks as those of JavaCoolDude.

Btw, Java3D uses display lists and this causes some hickups when lists are created and destroyed.

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #34 - Posted 2005-12-16 16:30:51 »

What the hell !

That's not pleasing for actual Xith users like me...

But we cannot deny the facts, so here's a sum-up :
  - In the old times, when Java3D was abandoned, JCD did some Benchmarks that showed up Xith's superiority : 1980 FPS for Xith vs  920 FPS for Java3D.
  - David Yazel's left, Xith3D core development has gradually stopped
  - Java3D core development has been started again by the community (while abandoned by Sun)
  - Now somebody port the Quake 3 level viewer to Xith3D, and it shows that the situation has been inverted !

But all's not lost ! Why everybody would be moving back to Java3D ? Xith3D's not dead (slowly dying maybe, but not dead yet). William ! Arne ! Yuri ! Where are you ? I'm sure we can correct that.. Studying Java3D pipeline and improve Xith3D's one wouldn't be so difficult, isn't it ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #35 - Posted 2005-12-16 19:30:01 »

FWIW, glLockArraysEXT shows up in a web search on a page devoted to optimizing gl drivers for Quake3...  Considering only the J3D side is using that, I wonder how much of a difference (if any) this makes in this test.

Renanse  (ruh-NON-say)
Offline tom
« Reply #36 - Posted 2005-12-16 21:37:09 »

Not much I think. Xith3D is using static VBOs as far as I can tell and it is something similar. By the way, that is not good when rendering Q3 levels. It has a high overhead and not much are gained when you are only rendering 2-8 triangles. Imidiate mode would be better. But it does make sense in most other cases.

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #37 - Posted 2005-12-17 21:39:20 »

I compared the outputs of xith3d and java3d versions of the quakeIII demos and it says, that it converts the textures in the java3d version to 2^a * 2^b size. It doesn't say that in the xith-version.

could that be a reason?

:: JOODE :: Xith3d :: OdeJava ::
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #38 - Posted 2005-12-17 22:55:30 »

Not much I think. Xith3D is using static VBOs as far as I can tell and it is something similar. By the way, that is not good when rendering Q3 levels. It has a high overhead and not much are gained when you are only rendering 2-8 triangles. Imidiate mode would be better. But it does make sense in most other cases.

To turn them off:

There is a USE_VERTEX_BUFFER_CACHING RenderOption, tutorial here.

-DXITH3D_USE_VERTEX_BUFFER_CACHING=false  should do the trick.

Cheers,

Will.

Offline tom
« Reply #39 - Posted 2005-12-18 02:49:03 »

I'm also porting the viewer to jMonkeyEngine. First results show that it is slower than Xith3D. About the same speed when looking at whole level from above, but much slower inside. It almost seems like it don't do view frustum culling. Also I'm trying to find a better way to implement the PVS enable and disableing. I will upload the code tomorrow.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #40 - Posted 2005-12-18 16:31:00 »

I've uploaded the source to the jMonkeyEngine port.

Got frustum culling working but it is still much slower than Xith3D and Java3D.

Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #41 - Posted 2005-12-18 17:52:42 »

Got this running in jME...  Wow.  Considering we haven't even begun optimizing for such a scene (by coincidence, BSP/Portals is next on our list - see our v.10 feature list)  I'm surprised it runs as smoothly as it does...  I get 70-150FPS inside and 17FPS from the top. 

I'll have to setup all of the source and libs to see the xith version next to get an idea of how much slower we run, but I'm thrilled you ported the demo to jME because now we have a nice demo to test with while we optimize.  Thanks!

Renanse  (ruh-NON-say)
Offline EgonOlsen
« Reply #42 - Posted 2005-12-20 00:35:38 »

What do i need to get the jME version compiling correctly? I managed to run the xith as well as the Java3D version, but i couldn't get jME to run without commenting keyboard and mouse related stuff out...so i couldn't move. I tried the official 0.9 and the "latest" release but to no avail.

So i benchmarked the starting position only (P4HT@3.2 Ghz, Ati X800XT-PE, latest drivers, WinXP, Java 1.5):

jme: 85 fps
xith: 132 fps
java3d: 210 fps

I've also loaded the level into jPCT but without BSP stuff (used jPCT's build in octree support instead) and with full collision detection enabled and i got around 300fps for this particular view. And that's with jPCT "special" T&L pipeline, which is not 100% hardware based due to support for software rendering... Wink

Edit: 25fps for software rendering using that view (without multi texturing in that case).

Offline tom
« Reply #43 - Posted 2005-12-20 13:13:18 »

I used the nightly build with JME.

Offline EgonOlsen
« Reply #44 - Posted 2005-12-20 17:24:33 »

I used the nightly build with JME.
Thanks. I've downloaded it again and now it works. Only god knows, where i've unzipped it to yesterday... Embarrassed

Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #45 - Posted 2005-12-20 21:57:13 »

This was a great exercise, and really let us find out a couple weaknesses in our (jME) rendering pipeline. Specifically, we found two issues, that we can now fix.

1. Static geometry should not update (transform/merge) boundings up the tree, as it's not changing. Wink
2. Sending small trimesh data to the card without batching is very wasteful (sending 3700 individual data objects to the card one at a time).

After playing with the demo some, and doing some hacks to force these improvements into the renderer for this case, I went from ~85 FPS to ~250 FPS (for initial starting position). And ~15 FPS to ~60 FPS on full level view.

So, this was a fantastic demo to point out a couple areas that we can gain the most improvement. Thanks for the effort, Tom.

Don't send a man to do a monkey's work.
Offline EgonOlsen
« Reply #46 - Posted 2005-12-20 23:08:38 »

Does anybody have the chance to run these tests on a dual core cpu (or dual cpu)? Because Java3D seems to use multiple threads for rendering, which you can notice when running it on a hyperthreading cpu. Xith and jME are using 50% of the two virtual cpus while Java3D uses around 85%. It would be interesting to see, if Java3D scales better when run on two (or more) real cpus/cores.

Offline tom
« Reply #47 - Posted 2005-12-22 01:54:43 »

I have compared the 3 scene graphs with my custom level renderer and will post some numbers.

Test 1 - Spawn position looking at windows. 2206 out of 3704 nodes are enabled by PVS but most are outside frustum.
JME: 55
Xith3D: 117
Java3D: 135
Custom: 375

Test 2 - Spawn position but rotated 180 degrees, looking down hall. 2206 out of 3704 nodes are enabled by PVS and most are inside frustum.
JME: 20
Xith3D: 24
Java3D: 44
Custom: 185

Test 3 - Looking at level from above. Everything is enabled and visible.
JME: 9
Xith3D: 9
Java3D: 34
Custom: 103

Test 4 - Camera is in one of the corners looking at the spawn position. 1230 out of 3704 nodes are enabled by PVS.
JME: 37
Xith3D: 54
Java3D: 74
Custom: 328

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #48 - Posted 2005-12-27 11:08:36 »

Who says Xith3D development was dying ? http://www.java-gaming.org/forums/index.php?topic=11811.0
It would be interesting to re-run the bench with these optimizations (although it may not gain a thousand FPS)

Note : I don't want to make a war between the different scenegraphs, yet my ego would want to Smiley I think we should all work to remain humble and recognize that sometimes others make better than us. But that shouldn't prevent us from working on our projects. (On this point I agree totally with swpalmer).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #49 - Posted 2005-12-28 17:49:49 »

FYI, We've made several upgrades to jME in the last two days or so that affect these tests.  I've also had the opportunity to benchmark all three libs and have come up with the following results.

Note: Latest xith-cvs tar available from their site.  Latest jME-cvs (a few things will be checked in around New Years eve/day).  Latest stable Java3D (1.3.2).  My only significant to the demo code was to enable scene locking in the jME version so that repeated calculation of bounds for things that do not change does not occur.  Other changes include porting to our vecmath objects, reducing object creation when moving between areas and enabling the renderqueue. (all things that probably should have been done when porting to jME)

From Top looking at entire scene:
Xith: 15 FPS
jME: 24 FPS
j3d: 81 FPS


From Initial Position: (after waiting for any JIT, etc.)
Xith: 205 FPS
jME: 260 FPS
j3D: 365 FPS


From Max Load Position: (lowest FPS from real player position seems to be secondfloor, over one of the star blocks, looking through the big room to the other side - where another start block awaits)
Xith: 50 FPS
jME: 75 FPS
j3d: 145 FPS


Memory usage: snapshot after 90 seconds of running at initial position (for heap used, I show the range over the last 10 secs)

HEAP:
jME: 23MB allocated  20-22MB used
Xith: 52.4MB allocated  34-37MB used
J3D: 46MB allocated  31-34MB used


NON-HEAP:
jME: allocated 9MB  used 8MB
Xith: allocated 11MB  used 11MB
J3D: allocated 11MB  used 11MB


Also, as an FYI, I ran a profiler (YourKit) over all three... Interestingly, almost all of the time for the J3D version was spent in javax.media.j3d.J3dThread.run() with less than 1% of time spent in methods called from there.  Also, I did notice there are two threads at work there as thought by another poster.  Any idea why my profiler does not pick up any java3d methods other than the run on the threads?

(please excuse the cross post to here and the jME official forum... i figure two different audiences.)

Renanse  (ruh-NON-say)
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #50 - Posted 2005-12-28 18:49:27 »

Oops, as irrisor of the other forums pointed out, YourKit filters out javax.* by default.  Much better now and I might see why we are still slower than J3D... more later should anyone care. Wink

Renanse  (ruh-NON-say)
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #51 - Posted 2005-12-29 23:21:12 »

Interesting stuff, please keep posting Smiley

Will.

Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #52 - Posted 2005-12-30 21:20:25 »

FYI, we enabled display lists similar to what J3D is doing and our frame rates are much closer to J3D (although our top down view is still only 50 compared to 80 with J3D, not sure what that is about...)  After some polishing and javadoc, all these changes should be in jme-cvs (perhaps 3-4 days given my current tired state and NY eve... Undecided )

Renanse  (ruh-NON-say)
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #53 - Posted 2005-12-31 14:26:08 »

Thats interesting, so you moved to display lists from VBOs or Vertex Arrays or something entirely different? Ties in with some results I've been getting recently

Kev

Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #54 - Posted 2005-12-31 18:41:22 »

Well the demo was not using our VBO code, and just turning on VBO made things slower!  Huh  (perhaps because the size of the individual VBO was very small)  It was simply using VertexPointer (et al) and DrawElements.  Batching that up in a display list made it all much much faster.  EDIT: fixed spelling error.

Renanse  (ruh-NON-say)
Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #55 - Posted 2006-01-01 19:05:05 »

For anyone still watching this space, I've uploaded screenshots from all three to my blog (www.renanse.com)

Renanse  (ruh-NON-say)
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #56 - Posted 2006-01-01 19:39:49 »

Nice, most of the stuff I've been doing recently points towards current consumer cards implementations of VBOs actually being slower than display lists for static geometry.

Kev

Offline Vorax

Senior Member


Projects: 1


System shutting down in 5..4..3...


« Reply #57 - Posted 2006-01-01 22:03:31 »

Nice, most of the stuff I've been doing recently points towards current consumer cards implementations of VBOs actually being slower than display lists for static geometry.

Kev

VBO's are slower then display lists for static objects.  VBO's are intended to be the best way to do dynamic geometry with lots of vertices, but display lists can be optimized by the video card once compiled and stored entirely on the video card without parts living in main memory (VBO's don't guarantee data resides entirely on the video card).

Offline renanse

Junior Member




Intelligence is light to a dark world.


« Reply #58 - Posted 2006-01-03 22:48:25 »

jME cvs is updated with the changes mentioned plus more.  An updated version of the jME q3 demo source is here: http://www.renanse.com/jme/jme_q3_src.zip 

Renanse  (ruh-NON-say)
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #59 - Posted 2006-01-05 15:06:17 »

Will, arne, should w modify Xith pipeline to use display lists for static geoemetries ?
What other changes would bring performances to a higher level ?
@jME team : any trick to give ? I think rather than to be in competition we should help us mutually.  Smiley

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (15 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (33 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (29 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (42 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!