Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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]
  ignore  |  Print  
  Mithrandir's state sorting post  (Read 4639 times)
0 Members and 1 Guest are viewing this topic.
Offline Spasi
« Reply #30 - Posted 2004-10-21 12:06:21 »

Packing states in ints should not be necessary in a general case. You can take advantage of the radix sort properties and call it successively, sth like:

1  
2  
3  
4  
5  
6  
7  
radixReset(); // Reset the indices
radixSortFloat(objects, distanceKey);
radixSortInt(objects, state0);
radixSortInt(objects, state1);
...
radixSortInt(objects, stateN);
radixApplyIndices(object); // Apply the final indices


It looks a little ugly though, because you need to modify the algorithm to accept "Sortable" objects that can be sorted upon a certain "sort key" (distanceKey, state0, etc, in the above pseudo-example).

We use sth like this in Marathon, it's faster than anything else we've tried and avoids the need for packing states.
Offline shawnkendall

Senior Member





« Reply #31 - Posted 2004-10-21 12:11:59 »

Quote

In practise there is no general case, there is a specific case to solve. For any given instance of a major scene graph node I decide on how many kinds of state there are to worry about ahead of time.


I guess is depends on what your _practice_ is.  Java3D is a general case graph and renderer, and does "unlimited" (not limited to palettes) state sorting, just like Open Scene Graph, Performer, OpenInventor, RenderWare, etc.


[mod]
Additionally, I can say within one execution session, our apps have switched quite drastically the number and arrangement of Appearance states, and therefore needed a _general_ solution.  Our 3D worlds are heavily data driven, giving as much control as possible to the content creation people, emulating that trend in professional game dev.  

Already our artists are making the actual shader code in Maya with shader authoring tools.  Very soon the "general" case will be the only case for pro dev, game middleware, etc, etc. (It's already there for companies like E.A. - they bought Renderware are using it across there new line of games)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #32 - Posted 2004-10-21 14:55:18 »

Quote
Many GL state changes are actually much less expensive than you might think.


Right... and when did you last benchmark your code. In order to determine the best orders for sorting within each object, we took every class that we had in the scene graph and individually benchmarked each state change. Compared to setting it once and never changing again, versus setting every object, you get a minium of a 20% performance penalty - not including the differences of method call overhead into the basic object itself. A lot of this cost is the OpenGL call cost - that is, the pure fact that you're even making the function call in the first place, when there was no need to (not to mention the JNI overheads for JOGL).  If you're only rendering under 100 objects per frame, then you probably won't notice this, but for us, we're typically rendering 5-10K objects every frame, even after culling and state sorting. Any state change is bade because that means extra objects on the render queue, so extra iterations of the render loop, more data to copy across every frame, more method/function calls to be made etc. There is far more to state sorting than just the simple opengl function call cost that you make it out to be.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 342
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2004-10-21 15:02:09 »

Unfortunately that benchmark is invalidated under many conditions Sad One version of a driver to the next, or one vendor to the next, or one OS to the next... the number of permutations is horrendous. So instead I have to apply a little "lowest common denominator" logic to it (eg. what's the worst case? Uploading 12mb of textures? etc.) You can also wrap your states up clientside with a boolean guard and attempt to track them and ignore dud state changesthough this can be fraught with difficulty if you don't have very thorough control of what's going on and I suspect many of the later drivers might already optimize this case.

So you're dead right but in practise you can get away with some leeway as the variations to be found in the field can invalidate carefully benchmarked conclusions.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #34 - Posted 2004-10-21 18:15:16 »

We have about 10 different video cards here from 3 different manufacturers - ATI, nVidia and 3DLabs. There's 3 different desktop boxes, including 2 multiple CPU machines (one is a dual Xeon, running hyperthreading, so the appearance of 4 CPUs) and 3 different laptops (obviously these are fixed video cards so the combo can't be tested). We got a darn good sampling of what the differences are and there isn't much between them. The relative costs are still about the same between states.  The absolute values are going to be different, but it's the items that are more expensive on one card/cpu combo is stil the same "more expensive" on a different CPU/card combo. When state sorting, it's the relative factors that matter most, not absolute.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Online Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #35 - Posted 2004-10-21 19:35:48 »

Quote
The relative costs are still about the same between states.  The absolute values are going to be different, but it's the items that are more expensive on one card/cpu combo is stil the same "more expensive" on a different CPU/card combo. When state sorting, it's the relative factors that matter most, not absolute.

Gonna tell us what they are then?

I only tend to sort on shaders then textures, but then again I'm generally using the same setup for all objects and don't tinker with things like material colour much. I'd guess thats generally true for most games.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline cylab

JGO Ninja


Medals: 38



« Reply #36 - Posted 2004-10-21 23:01:18 »

Both can be true. If you hava some specialized application (game) where you are able to make some assumtions prior to rendering you can get away with state-ids and there might even be circumstances where the performance gain from using a faster sort algorithm based on such assumtions can outrun the performance gain from "proper" state sorting. Thats of course an opinion and cannot be proven with numbers right now. But it seems logical, since there a two interdepent variables in this equation...

I also tend to the position, that one should enforce "shortcuts" in rendering where ever applicable. I doubt shawnkendalls predication that "the general case will be the only case for pro dev", or at least my definition of "pro dev" may differ Wink But taken into account what seems to be the very nature of computer graphics - faking images with a lot of tricks, so that you have the illusion of real physics - it is... well... _natural_ to tailor your application to the one special case so that you can get the best out of it.

See, i've got a job in J2EE development and if you know EJBs, you know that there are lots of "right" things to do that are a f**** pain in the ass, just to be prepared for an eventual requirement in the unforseen future...

I am not saying that EJBs are crap, they have their usage, but simpler approches have them, too. In my opinion this can be projected to software development in all areas, including computer graphics.

cya
cylab

Mathias - I Know What [you] Did Last Summer!
Pages: 1 [2]
  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.

pw (22 views)
2014-07-24 01:59:36

Riven (20 views)
2014-07-23 21:16:32

Riven (17 views)
2014-07-23 21:07:15

Riven (20 views)
2014-07-23 20:56:16

ctomni231 (48 views)
2014-07-18 06:55:21

Zero Volt (44 views)
2014-07-17 23:47:54

danieldean (35 views)
2014-07-17 23:41:23

MustardPeter (38 views)
2014-07-16 23:30:00

Cero (53 views)
2014-07-16 00:42:17

Riven (52 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!