Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Quake3 Renderer progress  (Read 4225 times)
0 Members and 1 Guest are viewing this topic.
Offline DavidYazel

Junior Devvie




Java games rock!


« Posted 2004-01-06 09:52:56 »

I have finished writing a Quake3 map loader.  I was able to load and display several maps last night without issue.  I am working on a walkthrough demo with collision to be available hopefully this weekend for you to try.  I will be checking this code in to the xith-toolkit project.

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline DavidYazel

Junior Devvie




Java games rock!


« Reply #1 - Posted 2004-01-08 17:29:00 »

The first version of the Quake renderer ran at 0.5 FPS due to the fact that I was not using the cluster visibility provided with the BSP.  I integrated the VIS stuff now and brought the FPS up to 24 FPS.  After doing a bunch of profiling and found a few bottlenecks in Xith3D and removed them and now am running at 110-220 FPS depending on the location and view inside the level.  I don't know if you guys are familiar with the way FPS levels are stored, but the faces (which are really Shapes, a whole bezier patch is considered one face) in leaves are referenced if there is a non-zero intersection with the leaf bounds, which means one face can often be shared by multiple leaves.  So when you do your VIS by cluster you need to assemble a list of faces which are non duplicate in the potential visibility cluster information.  This list is then culled per frame and rendered.  So I created a huge switch with an entry for each face.  I created some optimized code in View so that it could handle large switches more quickly (using bitSet.nextSet() - very cool feature).  Now 99 percent of the time is spent texture switching and rendering all those itsy bitsy faces.  The really wierd thing is that by the time you do all this PVS and FOV culling you are leff with very little triangles... sometimes 300-500.  I would have expected the framerate to be much higher.  

There are a couple of current ineffiencies in the current Xith3D.  One is that multi-tetxure geometry is not getting sorted very well.  In the case of Quake you have large lightmaps which are shared for many faces, so you really want to sort first by the second texture unit and second by the main texture unit.  Discovering this automatically might be extremely difficult, so perhaps we should create a shape hint or sort policy which can guide the renderer on how to sort the shapes.  

The next problem is that currently multi-textured is not good about handling state changes as well as non-multitextured geometry is.   So for example when redering quake faces the geometry continues to enable unit 1, bind lightmap, render and then disable unit 1 which is incredibly expensive.  The same is also true of unit 0.  So I will have to improve that radically.  I think that we should also add some optimization into the state sorter so it can basically say "all other things being equal, render all these geometries with the same exact state."  Which is a bit like combining shapes into one shape dynamically, but at a lower level than the scenegraph.

any other ideas or thoughts would be welcome.

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #2 - Posted 2004-01-09 07:57:20 »

Quite important topic. I was waiting for proper time to bring this up, and looks like this is now.

I was also thinking about the possible efficiency and flexibility of rendering process in Xith3D, and have several suggestions.

1. Multipass rendering. You know this is needed for many different things. My idea was to allow to specify explicitly rendering pass (or even multiple passes) for every specific node in a scenegraph and let user define number of passes, their sequence and sorting type. Sometimes distance sorting for opaque geometry bringh benefit also, so I was thinking about completely flexible pass definition, which is rather simple: user defines number rendering passes for View (?) and then sets sorting policy for every pass (i.e. FrontToBack, BackToFront, None, State, custom, etc.), and then associates rendering pass bits with every shape in node. Such a way we will achieve good flexibility.

This can be also a very elegant hint for state sorder: you place shapes you want to render sequentially in the same pass and let sorter sort the rest.

2. State Sorting. As of state sorting, we definitely have to make it more intelligent, and sorter hints will be very useful. But before we need a king of benchmarking procedure or better set of procedures. In my game I get ~65-75fps on 1600x1200 32bpp GeF 440 Go, but scene is very specific.

Yuri

Yuri Vl. Gushchin
JProof Group
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline DavidYazel

Junior Devvie




Java games rock!


« Reply #3 - Posted 2004-01-11 02:18:22 »

Some screenshots of a quake3 level being rendered through xith3d.   I can walk through the level with full collision detection / sliding along surfaces with gravity.  All running very smoothly.

http://www.magicosm.net/xith3d/snapshot4.jpg

http://www.magicosm.net/xith3d/snapshot2.jpg

Dave

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #4 - Posted 2004-01-11 04:35:38 »

very impressive!

Offline Preston

Senior Devvie


Medals: 4



« Reply #5 - Posted 2004-01-11 06:39:00 »

Can't wait for the walkthrough-demo. :-)

(I need to impress some sceptical friends who still think a 3d Java engine wouldn't be as fast as a C++ one... ;-)
Offline whome

Junior Devvie




Carte Noir Java


« Reply #6 - Posted 2004-01-11 12:52:42 »

Quote
I integrated the VIS stuff now and brought the FPS up to 24 FPS.  After doing a bunch of profiling and found a few bottlenecks in Xith3D and removed them and now am running at 110-220 FPS depending on the location and view inside the level.

I really want testdrive this demo on my Cel500Mhz machine. None will use such machine for a real gaming but is very good fps benchmarking platform.
Offline StefanD2

Senior Newbie




Java games rock!


« Reply #7 - Posted 2004-01-15 19:41:38 »

Quote
I have finished writing a Quake3 map loader.  I was able to load and display several maps last night without issue.  I am working on a walkthrough demo with collision to be available hopefully this weekend for you to try.  I will be checking this code in to the xith-toolkit project.


Hi
I have currently found this impressive xith project and am  playing with its features. Due to the fact that I checked out another quake level viewer being based upon gl4java around christmas it would be very interesting for me to compare both. Especially since I have been thinking of a port to jogl before that could be obsolete by now.
But I have not been able to find your code in the xith-toolkit project. Could you please give a hint when to expect it? Thanks.
Offline Amos Wenger

Senior Devvie




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


« Reply #8 - Posted 2006-10-20 16:46:28 »

The first version of the Quake renderer ran at 0.5 FPS due to the fact that I was not using the cluster visibility provided with the BSP.  I integrated the VIS stuff now and brought the FPS up to 24 FPS.  After doing a bunch of profiling and found a few bottlenecks in Xith3D and removed them and now am running at 110-220 FPS depending on the location and view inside the level.  I don't know if you guys are familiar with the way FPS levels are stored, but the faces (which are really Shapes, a whole bezier patch is considered one face) in leaves are referenced if there is a non-zero intersection with the leaf bounds, which means one face can often be shared by multiple leaves.  So when you do your VIS by cluster you need to assemble a list of faces which are non duplicate in the potential visibility cluster information.  This list is then culled per frame and rendered.  So I created a huge switch with an entry for each face.  I created some optimized code in View so that it could handle large switches more quickly (using bitSet.nextSet() - very cool feature).  Now 99 percent of the time is spent texture switching and rendering all those itsy bitsy faces.  The really wierd thing is that by the time you do all this PVS and FOV culling you are leff with very little triangles... sometimes 300-500.  I would have expected the framerate to be much higher. 

There are a couple of current ineffiencies in the current Xith3D.  One is that multi-tetxure geometry is not getting sorted very well.  In the case of Quake you have large lightmaps which are shared for many faces, so you really want to sort first by the second texture unit and second by the main texture unit.  Discovering this automatically might be extremely difficult, so perhaps we should create a shape hint or sort policy which can guide the renderer on how to sort the shapes. 

The next problem is that currently multi-textured is not good about handling state changes as well as non-multitextured geometry is.   So for example when redering quake faces the geometry continues to enable unit 1, bind lightmap, render and then disable unit 1 which is incredibly expensive.  The same is also true of unit 0.  So I will have to improve that radically.  I think that we should also add some optimization into the state sorter so it can basically say "all other things being equal, render all these geometries with the same exact state."  Which is a bit like combining shapes into one shape dynamically, but at a lower level than the scenegraph.

any other ideas or thoughts would be welcome.
@Qudus : interesting points here, have you worked yet on multi-texturing issues ? (Note : I've not read yet the "Shader order" topic).

"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 Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #9 - Posted 2006-10-20 16:59:50 »

Hi,

Note that this topic dated back to 2004 - it's a time ago...

Yes, I was working on multitexturing performance issues also and especially on state sorting.

Unfortunately, state sorting in respect of multitexturing is still not perfect, and even far from perfect. But on the other hand as I mentioned before in that post - we still need a benchmark or example that will show that state sorting will help: a year ago I was surprized that in newer drivers when textures are already in VRAM changes in state sorting do not give so much performance boost... but I assume it is due to too simple example.

State sorting is VERY important on low-end graphic cards (which were high-end that time), or when textures have to swap out of VRAM.

Yuri

P.S. If you have some specific questions on Xith3D State Sorting let me know - I was partially developing it...

Yuri Vl. Gushchin
JProof Group
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Devvie




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


« Reply #10 - Posted 2006-10-20 17:03:47 »

P.S. If you have some specific questions on Xith3D State Sorting let me know - I was partially developing it...
Myeah, do you plan to take it to the next level ? That would be more than appreciable  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"
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #11 - Posted 2006-10-20 17:07:30 »

In short words, first we should prove that proper (better, other) state sorting will give performance boost.

After we locate the bttleneck I believe we can invent the more intelligent sorting algorithm. So if you can help in locating the bottleneck it will be of even more help than, say, me making some changes Smiley

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




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


« Reply #12 - Posted 2006-10-20 17:22:07 »

In short words, first we should prove that proper (better, other) state sorting will give performance boost.

After we locate the bttleneck I believe we can invent the more intelligent sorting algorithm. So if you can help in locating the bottleneck it will be of even more help than, say, me making some changes Smiley

Yuri
So I could e.g. profile the Q3 test with YourKit and see where most of the CPU time goes ?  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"
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #13 - Posted 2006-10-20 17:25:11 »

For Quake3 test I've disabled render atom sorting completely. It boosts the performance a lot (or decreases it when enabled).
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #14 - Posted 2006-10-21 11:34:15 »

Hi,

To make correct test you have to disable also state change optimization - it is active even when state sorting is off.

As I already mentioned, on modern cards and drivers state sorting has no such a big effect like in order cards/drivers, so turning it off may casue performance boost, but all of this is really scene-dependent.

I suggest the following test: imagine screen filled with non-intersecting shapes textured with two or three different textures (so neither depth buffer nor culling will affect the test). We make many small simple shapes (rectangles or even triangles). In this case, the rendering result will not depend on the shape rendering order. Next we try to profile timing (FPS) when 1) all A-textured shapes added first, then B-textured, then C-textured; 2) Shapes added interleaved way (one A-textured, one B-textured, one C-textured, then again one A-textured, one B-textured, one C-textured, etc.). All other appearance attributes are the same (after we can experiment also with other shaders, but this example is for texture shader only). I also assume state sortung turned off, so we do manual state sorting. All shapes go to the same group. We should speak of thousands of shapes of approx. 2x2 screen pixels size, so lets make screen context fixed size (say, 1000x1000 screen pixels).

As I mentioned, rendering result will be the same because of shape projections do not internsect in screen coordinate space, i.e. we have no overpaint. Case 1) gives perfect state sorting results (in respect of pipeline state changes); 2) gives absolutely wrong result (contra-productive) - we have state change for every shape.

Let's somebody code the test and we all can compare results - no changes in core are neccessary for this.

I have a guess with the results and also explanations for it, but will keep it until we get the test and numbers.

Even more interesting will be the test when we use more complicated shader (say, VP, FP, or GLSL shader) instead of simple texturing - the cost of context setup for it sounds much higher, but maybe I am also wrong.

I strongly believe that we should find out what is the best for hardware and the driver, and optimize Xith3D core for this alone with providing Xith3D users with scenegraph creation guidelines, because of as you can probably feel from the test example above, the OpenGL command output can be quite different for the scenegraphs providing the same visual result.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




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


« Reply #15 - Posted 2006-10-21 14:25:59 »

For Quake3 test I've disabled render atom sorting completely. It boosts the performance a lot (or decreases it when enabled).
How do you do that, man ? In the ColorCube example that would be ideal (lots of Shape3D so disabling render atom sorting boosts a lot and furthermore it would remove the artifacts when they get re-ordered the transparency doesn't look the same).

"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 Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #16 - Posted 2006-10-21 15:20:08 »

Hi,

Search in sources for TRANSPARENCY_SORT_NONE and OPAQUE_SORT_NONE.

Set using Renderer.setOpaqueSortingPolicy(...) and Renderer.setTransparencySortingPolicy(...) - this will make it. This feature already existing for a long time, I even remember I documented it while was adding TRANSPARENCY_SORT_BOUNDING_SPHERE_AND_EYE_RAY_INTERSECTION sorting policy (OK, was fighting a tricky intersecting shape transparency rendering that time).

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #17 - Posted 2006-10-21 15:49:25 »

How do you do that, man ? In the ColorCube example that would be ideal (lots of Shape3D so disabling render atom sorting boosts a lot and furthermore it would remove the artifacts when they get re-ordered the transparency doesn't look the same).

1  
env.getRenderer().setOpaqueSortingPolicy( Renderer.OPAQUE_SORT_NONE );


or without Xith3DEnvironment:
1  
myUniverse.getRenderer().setOpaqueSortingPolicy( Renderer.OPAQUE_SORT_NONE );


Marvin
Offline Amos Wenger

Senior Devvie




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


« Reply #18 - Posted 2006-10-21 16:43:24 »

OK, thanks.

"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]
  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.

rwatson462 (36 views)
2014-12-15 09:26:44

Mr.CodeIt (29 views)
2014-12-14 19:50:38

BurntPizza (61 views)
2014-12-09 22:41:13

BurntPizza (98 views)
2014-12-08 04:46:31

JscottyBieshaar (58 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (76 views)
2014-11-29 21:32:03

toopeicgaming1999 (137 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (37 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!