Just curious, what is the difference in the memory footprint between the two?
How do you mean by “redundant”. Those calls affect the pipeline of Xith3D, hence they aren’t redundant. They are needed, its just that Java3D has a different pipeline…
DP
There may indeed be redundant calls if for example it’s translating multiple things to the same space but pushing and popping for each of them. The whole thing could be done with one push/translate/pop. Other redudant things could be setting the same blend functions, texture etc, then unsetting and reseting to the same values for the next set of calls. when you haven’t actually changed them - the whole thing could be done as one set.
NOTE: I haven’t run the test myself, just giving some possibilities of redundant calls.
Java3D 70MB
Xith3D 140MB
That is the Mem Usage reported in task manager.
How do you get GLIntercept to work? I’ve copied the gliConfig.ini and opengl32.dll into the application directory. But I get no output. I’m guessing it uses the dll in system32 instead. Do I have to rename the one in system32? (I did try that but it came back. If that is what I need to do I’ll have to find out how to turn off the outo recovery on windows xp).
A copy of another post, please don’t let raw FPS be your primary concern…
Surprising numbers, a direct contradiction of the work javacooldude did. Makes me consider a few things
1 two different benchmarks produced two different results, one has to suspect the benchmarks. Thet 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. 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 ak Java3D to do something “pretty please” and hope it happens soon.
3 Any refresh greater than 60 FPS is a waste
4 What refresh rate do you really need
Well, when JavaCoolDude did his benchmarks, it was with a much older version of Java3D - there may have been substantial improvements. Also, JavaCoolDudes benchmarks were very limited, not as close to a real world rendering scenario as rendering a Quake 3 level. It’s easy to batch a simple scene correctly, but much more difficult to batch a complex scene. Doing the level test forces lots of data to the card, state switches, and opportunities for batching. Though this to is still limited as a benchmark. It could be that with simple scenes, Xith is faster, but with more complex scenes, J3D wins. That is what the FPS numbers and GLIntercept results suggest.
You can set J3D behaviours to execute each frame as far as I know, and act upon key strokes, etc when you like, which should give you the level of granularity needed for any game. You can also implement your own I believe. My J3D knowledge is out of date though - someone correct me if I am wrong here. As far as controlling what’s rendered, you can’t control if it goes as an array or a VBO with J3D, but you can say if it should be rendered or not, which again, should be what you need in most cases as long as J3D is picking the best way to do it (which is decided based on the flags you assigned your nodes), by the numbers it does seem to be.
Not if you want to run your monitor at > 60hz - in which case 60 FPS will show tearing. Also 60 FPS on a good machine != 60 FPS on a slow one. The more performance you can push from a renderer the better in most cases (I can’t think of any where it’s not).
72hz is a good target for monitor refresh. 60hz gives many people headaches with 3D environments.
Just a note: I am not for or against either J3D or Xith - Like Tom who created this benchmark, I use my own game engine developed with LWJGL - I am just commenting on the results posted.
[quote=“hawkwind,post:26,topic:25522”]
Any refresh rate faster than what you need means you still have breathing room to improve other things - level detail, visual effects… maybe free up more CPU time for better AI etc. Or you can lower the specs on the required hardware to increase the size of your target market.
Better performace is better performance, plain and simple. As long as the control issues you brought up are not a problem with implementing the game, then the RAW numbers do make a difference.
The real point of these findings and how they contradict JavaCoolDude’s is that you have to profile your own code and what you want to do, and not rely on some unrelated benchmark in the first place 
At any rate it shows we should keep an open mind.
I haven’t heard truer words in a long time 
To drakprophet. Here are what I mean by redundant callls ;
the GLIntercept log for one primitive is in Xith3d :
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 :
glCallList(2904(src2904)); Tex=(0,23) (1,17)
with display list equal to :
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
to n
-
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
-
Errr…FPS is performance. Your confusing performance with how well the programmer controls the engine.
-
You have it backwards :); 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
maybe we should re run JavaCoolDude’s Benchmarks with the newer versions of Xith3D and Java3D?
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:
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.
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.
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 ?
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.
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.
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?
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.
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.