Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
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 4664 times)
0 Members and 1 Guest are viewing this topic.
zahl2001
Guest
« Posted 2004-10-17 21:45:11 »

It's been several months since the post, and I've finally convinced myself to attempt to cobble together the beginings of a 3-D engine.  I've also purchased Practical Java Game Programming, and have been looking at that.  Both the book and Mithrandirs post have been helpful, but I still have plenty of questions about how to begin.

Anyway, it seems logical to have a Scene object containing Sector objects (which can be frustum culled), with the Sector objects containing lists of objects within those sectors.  I can see the use of this being that frustum culling the Sectors would automatically cull all of the objects in that sector if done correctly. It also seems logical to have Appearance objects associated with the Sector objects so that those Apperances can be shared.
So, if I were to rig this up, I can imagine a set of calls like:

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  
// Called from drawing loop
myScene.draw();

// Method of Scene
public void draw(GL gl)
{
   for(int i=0; i<sectorList.length; i++)
   {
       sectorList[i].draw(GL gl);
   }
}

// Method of Sector
public void draw(GL gl)
{
   for(int i=0; i<objectList.length; i++)
   {
       objectList[i].draw(GL gl);
   }
}

// Method of gameObject
public void draw(GL gl)
{
    // Use the vertex arrays and associated
   // Appearance object to render the objects
   // individual polygons
}


All of that sounds OK until I remember that there isn't any state sorting at all.  There clearly needs to be a list of some sort at the global level so that all of these things can BE state sorted, collision detected, etc.

My problems:

1) If I place references to the gameObjects in the global lists, how do the individual polygons making up those complex objects get sorted?

2) If there is a global list of objects, then I don't need to
call draw() down the hierarchy, I could just call draw() on the global list.  BUT, then how do I do the frustum culling of the objects in each sector?  I could imagine having a flag in each object to set it's drawable state, and then flipping them all on or off based on the results of the frustum cullilng, but that can't be right.

If someone has the patience to answer this and the myriad of other questions I'm going to have, my hat is off to you Smiley

I have no doubt that an answer to these 2 questions will cause me to have many more...

Thanks,

Keith

p.s. Thanks Mithrandir for writing those lengthy post.  I have them printed and saved Smiley
Offline cylab

JGO Ninja


Medals: 38



« Reply #1 - Posted 2004-10-17 23:29:14 »

One idea to that problem was to completely separate the scene from the rendering process. So you end up with bunch of 'Entities' like 'Person' or 'Animal' wich have several 'Primitives' connected to them. A Primitive can be a 3D-mesh, a sound origin or anything else, that generates "user experience" like e.g. a visual effect like heat haze.

Entities (Person,etc.) are placed inside a 'World' which is organized in a Quadtree or Octree of Sections (maybe partitioned and connected by Portals) and have their own coordinates and simple boundaries (spheres, boxes). A Entitiy can be modified by interaction, behaviour or physics threads (pathfinder; lifecycle: sleep, eat, work, eat,  f*, pee, sleep; wind)

To get an "insight" into this world you need a 'Camera' with its own coordinates and view frustum. You want to get a scene from this Camera by calling getScene(). This call analyses its World and sorts out all Sections in the tree, that are not at least partial inside the Cameras frustum. After that it takes a look at the Entities inside the partial visible Sections and sorts out all Entities that are not at least partial in the frustum based on their boundaries (spheres, boxes as stated above).

The getScene() method returns all Primitives that are contained in the remaining Entities as a flat Array, since that is all what is needed for rendering (or soundmixing, if the Primitive is a Sound origin). In your rendering thread you can now sort this Primitives according to your needs and iterate them for rendering at last.

You can design this Primitives as descriptive datastructures with no code at all, so that you can design your renderer replaceable or you can just implement a "render"-method on it, that uses JOGL for drawing (and JOAL for mixing).

cya
cylab

Mathias - I Know What [you] Did Last Summer!
zahl2001
Guest
« Reply #2 - Posted 2004-10-18 00:43:11 »

Thanks for the quick reply Smiley

I'm going to try to summarize your idea.  Please correct the errant parts.

1) Use frustum culling to get the visible Sections
2) Extract all primitives from the entities which exist
    inside of the visible Sections.
3) Sort the primitives and render.
4) Do this every frame.

Question: You stated that your primitives can be something complex like a mesh. If the mesh is made up
of geometry with different textures, materials, etc. how can the individual polygons be sorted in the 'big picture' that contains all of the polygons in the other primitives?
For instance, what if your world was made up of 100 cubes with a different texture and material on each side of each cube (each cube is identical to every other).  In this case it seems you would extract all 100 cubes (if they passed the frustum cull) and then do what with them?  As you can see, I'm still stuck on how to minimize state changes when you've got all those cubes in an array.  It seems when you render each cube you would have 6 texture binds and 6 changes in material, which would of course give no advantages at all.

Thanks,

Keith
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2004-10-18 07:31:35 »

You introduce something like Shape3D (see Java3D/Xith3D) which prevent the API user from specifing more than one texture per mesh (and hence makes them split it up into smaller meshes), this allows for efficient state sorting.

Kev

Offline cylab

JGO Ninja


Medals: 38



« Reply #4 - Posted 2004-10-18 08:31:34 »

Yes, thats basically the idea: make your Primitives as primitive as possible, so that you have "scene-atoms" that could be sorted. In your example, the cube would be an Entity with 6 Primitives, one for each side.

You can define your Entity as a Composite- pattern, so you can aggregate your Entities out of smaller parts, e.g. 'Person' would consist of 2 instances of 'Arm', one 'Torso', two 'Legs', etc. wich all are made of Primitives for rendering.

Mathias - I Know What [you] Did Last Summer!
Offline kaffiene
« Reply #5 - Posted 2004-10-18 11:34:02 »

Quote
You introduce something like Shape3D (see Java3D/Xith3D) which prevent the API user from specifing more than one texture per mesh (and hence makes them split it up into smaller meshes), this allows for efficient state sorting.

Kev

And what do you do if your object is rendered using texture splatting?
zahl2001
Guest
« Reply #6 - Posted 2004-10-18 13:28:30 »

OK, the idea of 'world-atoms' and 'Shape3D' seems clear at this point.

Let's say this happens:
1) Create model
2) Send model's shapes to the collection, wherever it is
3) model's shapes are scattered in collection due to
sorting
4) model needs to be removed from world
5) How do you find it's shapes to remove them from the list?
Offline cylab

JGO Ninja


Medals: 38



« Reply #7 - Posted 2004-10-18 13:34:50 »

Well, there are limits to everything. It depends how you implement your Primitives.

You could implement a sorting mechanism, which groups all interdependent Primitives, so that you can call a prepareState()-method on the first Primitive in that group before calling render() on every Primitive in this particular chunk. At the beginning of the next chunk of similar Primitives you again call the prepareState()-method on it's first entry followed by iterative render() calls on the Primitives in that group and so on.

Sorting a scene graph for realtime rendering is one of the trickier parts in game development... Wink

Mathias - I Know What [you] Did Last Summer!
Offline cylab

JGO Ninja


Medals: 38



« Reply #8 - Posted 2004-10-18 13:44:36 »

zahl2001:

In a simple implementation you just provide a method named 'getPrimitives()' in the Entity (Model). For each frame you recreate the Primitive list for rendering, so if the Model vanishes, it's primitives are not collected by the getScene()-call.  Thats it Wink

You might want to create a more complex implementation, that minimizes the need to change the sorted primitive list, e.g. just delete unused and add new primitives. You could install some sort of central event bus to notify the different parts of your engine about such changes. Don't try to use the EventListener scheme from Java Swing here, because you will get myriads of Objects and interdependencies.

Mathias - I Know What [you] Did Last Summer!
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


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

ooow... my ears are burning!

Grin

I think most of the above posts have covered the basics.  The biggest gain that you'll get is by not changing state at all. All those primitives that may have multiple textures per primitive are going to have to be broken down. They need it for two reasons: Firstly, OpenGL does not handle more than one texture per primitive, and secondly because you need to minimise state changes and sending anything down the pipe that has not changed. If you have two sets of primitives both sharing the same textures, you're going to need to pull those apart and send bits of each primitive down to OpenGL at the same time.

This is how the speedup occurs. If all you did was sort the higher-level primitives you'd still be getting larges amount of state change per primitive, and you'll barely get any performance boost. The major boost comes when you strip everything back to absolutely bare minimum and sort based on those small chunks.  Even resetting the same texture twice in a row with glBindTexture() can still dramatically kill performance on some video cards.

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 kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #10 - Posted 2004-10-18 15:32:57 »

Quote

And what do you do if your object is rendered using texture splatting?


Depends on how you're implementing your splatting now doesn't it? If you're using multitexturing (which aims you at more modern hardware) then you have a new state (the one in which you load multiple textures in) see (TextureUnitState in Java3D). If you're using multiple coplanar alphaed polys (preferred for my stuff) then you have no problem.

Kev

zahl2001
Guest
« Reply #11 - Posted 2004-10-18 16:57:51 »

Since my knowledge of Computer Science is limited, I'd like to make a proposed case that I feel is going to be a giant waste of memory, or inefficient, and have someone offer a better proposal.  

I realize this isn't going along with some of the information posted above, I'm just curious to learn some reasons whay not to do certain types of operations.

1) Lanscape is composed of 100 acres (Sections).
2) Each Section contains 100 trees.
3) Each tree contains a certain number of Primitives, each of which conatains a flag called isDrawable.
4) On startup a referencee to every Primitive in the world is placed in a global collection.
5) The collection is sorted.
6) At runtime frustum culling checks each Section for
visibility. If invisible, each Primitive in that Section is set to not drawable. If visible, the opposite happens.
7) Visible items are rendered.

Thanks for all the input so far,

Keith
Offline cylab

JGO Ninja


Medals: 38



« Reply #12 - Posted 2004-10-18 20:25:10 »

I assume, that step 7 "Visible items are rendered" means, you iterate through your global collection and only draw those primitives that have "isDrawable" = true.  One drawback of this approach is, that you can't reuse primitives this way by referencing them, since it might be drawable in one context and not drawable in another.

Also you have to iterate over all your primitives in your world every frame, at least to call "isDrawable()". If so, you have to set all invisible primitives to "isDrawable" = false. Only setting the primitives in the visible section does not suffice, despite you are just drawing the visible section alone, but than what is the use of the global collection at all?

Since you are analysing your world to gather visibility information anyway, you could just add the visible primitive to your rendering collection and sort this every frame. This way you are also not bound to static environments, since you can add, move or modify entities in your world as time goes by. Some of those changes (e.g. changing the texture of a primitive or adding an effect to your scene/world) affect the rendering order, since they add or alter state changes.

For reducing the cost of visibility analysis, I would recommend using quad or octrees. An introduction to octrees and their applications can be found here: http://www.gametutorials.com/Tutorials/OpenGL/Octree.htm

cya
cylab

Mathias - I Know What [you] Did Last Summer!
zahl2001
Guest
« Reply #13 - Posted 2004-10-18 21:11:22 »

Ok, I think I have enough info to get started except for one thing: what type of collection to hold all of the Primitive objects.  A previous suggestion was to use a wrapper class that implemented Comparable, but at school we have never done such a thing, so I am unsure on how to proceed.  I looked at Comparable, and none of the implementing classes seem to support objects.  I was hoping to see something like ArrayList, or LinkedList.  I realize that a class (or subclass of something else) is going to have to be created, and then compareTo() defined, but that's about it.

Thanks,

Keith

p.s. After this I'll give you a rest for a while Smiley
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #14 - Posted 2004-10-18 21:53:44 »

Just use whatever collection is suitable (Set, ArrayList, whatever) and use Collections.sort(). Then either write a Comparator class to sort your rendering objects or build it in to the primatives themselves.

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

JGO Ninja


Medals: 38



« Reply #15 - Posted 2004-10-18 22:13:59 »

Take a look at the "Comparing Objects" section (http://java.sun.com/developer/technicalArticles/Collections/Using/#co) of the "Using Collections" article at sun.com (http://java.sun.com/developer/technicalArticles/Collections/Using/)

Mathias - I Know What [you] Did Last Summer!
zahl2001
Guest
« Reply #16 - Posted 2004-10-18 22:19:10 »

Ok, thanks for the suggestions.  I'll see if I can 't get this figured out soon.

Keith
zahl2001
Guest
« Reply #17 - Posted 2004-10-20 13:18:16 »

I was doodling some ideas on paper yesterday, and I'm getting a scenario with very little vertex data sharing due to the fact that the primitives are small and  encapsulated.  Do you geniuses have some arcane method of getting around this?  Or maybe I don't want to know... Smiley

Seriously, though, if it's normal for there to be little vertex data sharing, I suppose that's the lesser of the evils? (The other being a ton of state changes).

I'm looking at some tutorials for building software renderers, and the basic unit of geometry for each of those I'm reading is a single polygon containing information about it's texture, location in 3D space, etc.  The state-sorting approach in JOGL seems to be heading in that direction if I understand what's been said so far.  Although a Polygon3D class would be very easy for me to understand and deal with, I suppose it would be a giant memory waste with no data sharing.  

Well, if anyone has any thoughts they want to share on these topics I would be interested to hear your opinions.

Keith
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #18 - Posted 2004-10-20 14:15:57 »

Lots of little primitives is fine. Makes it easy to visibility cull them. In addition, if you set up your scene graph correctly, you can share the individual primitive through mulitple branches of the scene graph, thus saving a lot of memory usage. This is particularly relevant if you're doing outdoor scenes where you have lots of the same object (eg trees, benchs etc).

Software renderers do take a slightly different tack to those that are hardware based. Or at least they used to. These days, the same tactics that make hardware renderers fast will also make software renderers fast. Due to the huge speed differentials between the various memory levels from CPU to main memory, the more that you can make use of cache coherency, the better. Keeping small tight loops, reusing as much data as possible, not rendering anything that you don't see. All of these approaches are the same both for software and hardware. Some of the costs for state changing may be be different between the two, for example texture contexts, but in the end, it's not going to make that much difference.  If you're reading a book on software rendering, make sure it's not much older than a year or two.  Anything older than that just doesn't have concepts that can be applied to the modern computer architecture setup.  

A classic example of this that we found yesterday - a two line change in code gave us a 50% better framerate on heavily transparent worlds.  We'd taken an older-style approach to dealing with the transparent geometry, but we found that by applying a different technique that was already in another piece of code, gave us a massive performance boost. Our code was correct according to anything you read from the last couple of years, but this simple change made far, far better use of the internal CPU and driver resources than the "correct" way of doing it.

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.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2004-10-20 14:29:52 »

That sounds like a neat optimisation... care to go into details in another post?

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #20 - Posted 2004-10-20 15:41:41 »

After doing your transparency sorting, when dropping in the objects for transparency rendering, continue to apply the basic state sorting to it. Large outdoor scenes that have hundreds of the same object (eg tree) don't need to go into texture state changes most of the time.  We'd turned state sorting off completely for the transparent objects (as is recommended by every text that you read about it).  Using a partial sort test after the depth sorting made a huge difference.

Edit: Doh... button, wanted preview not send....

Anyway, what I was saying...     We run a lot of the Planet9 data on our applications for various things. In the Elumens dome mode (which does 3 or 4 render passes per final output pass) we jumped from averaging 20 FPS to 33FPS just through this simple change. In non-dome mode we've jumped from 65FPS to 100+FPS. These are the really big outdoor scenes like Washington DC with the 2Kx2K textures etc. Smaller stuff like the various downtown locations (San Diego, San Fran etc) got less of a speed boost because there's less transparent objects. In the D.C test, about 50% of the objects have some form of transparency.

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.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2004-10-20 16:36:19 »

Interesting insight.

Cas Smiley

Offline shawnkendall

Senior Member





« Reply #22 - Posted 2004-10-20 17:25:07 »

Quote
Just use whatever collection is suitable (Set, ArrayList, whatever) and use Collections.sort(). Then either write a Comparator class to sort your rendering objects or build it in to the primatives themselves.


BTW, we did this in  the engine in the book, and used a ZDepthComparator class for comparing - you guessed it - Z-depth (this is for transparency sorting).  It worked famously and was very fast in our all alpha and mixed alpha scene tests.

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

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2004-10-20 19:43:46 »

I've got a triangle sorter buried in SPGL somewhere. I tried using Collections.sort() and comparators and it was basically dog slow. I instead went for radix sort and it was an order of magnitude faster, especially as the number of triangles increased.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #24 - Posted 2004-10-20 21:42:52 »

Well, you need to compare like algorithms. The collections built in sort() is just qsort, which is the fastest implementaiton of a comparsion sorter (O(nlogn)). Radix sort is not comparison based, and thus can be a linear-time sort (O(n)). It's not an order of magnitude faster, but there's a non-linear difference in speed as the number of objects increases.

Depth sorting, because of the single variable, is easy to turn into a linear sort using any of the counting-based sorting algorithms. However, state sorting is another thing entirely. I've not yet come across any way of generating a meaningful hashing strategy that would allow the use of a counting-sort for state sorting.

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.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #25 - Posted 2004-10-20 22:11:11 »

Quote
However, state sorting is another thing entirely. I've not yet come across any way of generating a meaningful hashing strategy that would allow the use of a counting-sort for state sorting.

I always get my sorting algos confused, but I don't see why you can't crowbar rendering state into a format suitable for radix sort? Just packing various state ids into one larger 32bit value, something like:
SSSS PPPP SSSS RRRR
where S is your bits for shader id, then primary texture, secondary texture, then specific rendering state (alpha test etc.). I think a single 32 bit value would be enough (unless you've got silly amounts of textures?).

Feel free to point out the great big gaping hole in my idea now.  Smiley

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

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2004-10-20 22:23:04 »

No need, that's exactly how I've done it, and it works well.

Cas Smiley

Offline shawnkendall

Senior Member





« Reply #27 - Posted 2004-10-21 02:43:42 »

If you limit the number of possible render state combinations to something like a palette system, then you can bin objects by your palette id in something like bit wise blocks but...

In practice,  that is just too limiting for the general case.  Evetually you'll want to do it with "shader" objects (shader code, support texture and vertex data etc) then 32-bit index palette should work pretty good BUT...

You still want to minimize the state changes between shader changes and often trying to get that to happen too can make the original bulk shader objects look like they should be split into render state chunks that can be mixed and matched.

Again in the truly general case, it's pretty ugly to get near optimal state sorting.  If you have a domain specific engine (i.e. terrain, characters etc) you can force some short cuts, which is why you still see things like terrain rendering engines as a seperate part of render engines.

[mod spelling]

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

Senior Member




Cut from being on the bleeding edge too long


« Reply #28 - Posted 2004-10-21 03:02:33 »

OrangyTang, it's close to impossible to do it meaningfully as far as I can tell. For example, let's look at material state itself.
Firstly you have say at least 4 different colour values - emissive, ambient, difffuse, specular, two sided and a few others. So you need a minimum of 4 bits for say 4 colour values that can be set. Each of those colour values is a floating point number, and has 4 of them. Now you can hash a single floating point number into an in (between 0 and 1) bot now you have 4 per colour that you need to hash.  Why? Well, you want to state sort for any material state change. Just changing the emissiveColor and leaving the other 4 alone is a costly state change, let alone change all 4.

One of the primary goals of state sorting it is minimise the amount of change that you need to make when you sort. Thus, ifyou have three material objects where two have the same emissive and a different two have the same diffuse, then the most efficient state traversal is to start with one pair, put the middle that has the common emissive and diffuse, and then final object is the one that didn't have the first state.  Trying to encapsulate 4 different state values for two different floats as hashed values already blows you past the 32 available bits - even if you decided to cheat and quantise float colours to 8bit int (that's still a single 32bit int for a single colour).  Now, you've got hundreds of other states to start considering for state sorting - you can't just compare texture objects, for example. A lot of stuff ends up actually using the same texture bytes, just with different filtering states or blend or wrap etc etc. So you end up needing to, potentially compare thousands of different things every frame. In the end, it just doesn't work out into anything sane, so comparison-sorts are the only way to do this.  Luckily, using good culling strategies, you can minimise the amount of stuff that you have to sort, so the O(nlogn) timing doesn't really hit that hard for reasonably culled scenes.

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.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2004-10-21 08:53:06 »

Quote
In practice,  that is just too limiting for the general case.

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.

Quote
Trying to encapsulate 4 different state values for two different floats as hashed values already blows you past the 32 available bits

My radix sorting is already based on 128 bits in little ol' Alien Flux! The radix sort algorithm is very cunningly adaptable.

I know it's not a perfect solution but the sort speed vastly outweighs occasional overlap in GL state changes. Many GL state changes are actually much less expensive than you might think. The only truly expensive ones are texture binds as they may incur a texture upload and otherwise zap any hardware memory cacheing.

I realise my fixed-known-problem approach may not cut it for a truly general purpose scenegraph but it would work well for a situation such as, say, Doom3.

Cas Smiley

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.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

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

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

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

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

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

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

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