Instancing

To conserve memory and minimize processor cache misses and GPU state changes, we need reasonable ways of "instancing" scene graph elements, meaning reusing the same objects in cases where the same element conceptually appears multiple times in the same scene.

It's possible to implement a transform and bounding volume hierarchy which supports instancing, however the overhead is significant, both in terms of its impact on processing costs and memory-use, as well as on ease-of-use for many use cases. If you introduce instancing at this level, every node potentially has many parents (and further ancestors) - which implies a node also has as many world space transforms and world space bounding volumes as the product of all its ancestors.

To avoid these costs but still retain some of the benefits of instancing, one approach is to make the instancing purely visual. In this case, a Node which appears multiple times in the same scene still may have at most one actual parent, and thus only a single world transform and bounding volume. A special auxiliary node type is provided which itself is part of the transform hierarchy and bounding volume hierarchy of the scene, however any nodes it contains remain disconnected from that, i.e it is not their parent. When this auxiliary node is rendered, it cancels the world transform of the actual parent (if any) of its child nodes and substitutes its own in place of that. In addition, it arranges for its children to derive their render states from its own rather than those of their parents.

In our system, this auxiliary node is called a "Lens" and has the following partial definition:

public class Lens extends Node {

    public var view: Node;
   
     ...

}

Example - Bubblemark

It's not a very interesting example, but it is (hopefully) somewhat familiar. In "Bubblemark" the same vector "bubble" graphic appears N times, each with a different translation. It would be extraordinarily wasteful to actually create N duplicate Bubble objects (which are quite heavyweight). Instead, we can use N Lens objects (which are lightweight by comparison) each viewing a single Bubble, and translate the lenses instead of the bubble. Here's the relevant code:

Stage {
    scene: Scene {
       def bubble = Bubble {}
       content:
       Group {
            content: bind lazy
                for (ball in model.balls)
                    Lens {
                        x: bind lazy ball.x;
                        y: bind lazy ball.y;
                        view: bubble;
                    }
	}
    }
}

With this formulation of instancing I no longer have transform and bounding volume information about the "instanced" bubbles, however in this case I didn't need that since it's already present in the Bubblemark application's "model".

Performance of "Bubblemark" in our system seems good compared to others:

By comparison, the vector Flex example on bubblemark.com has roughly half the frame-rate, and more than double the CPU usage, even while rendering far fewer pixels. Of course, these discrepancies aren't just about instancing, but more so about using the GPU rather than the CPU for rasterization.

As a second example, here's a quickly thrown together example of a 3D chart, which was produced using one cylinder instance and one rectangle instance:

Comments:

In my opinion, the same approach can be used for enterprise software tools integrated with Web Services as in Sun Java CAPS. Note that as above nobody is going to say "Hey, here you go, why don't you test your enterprise tools on my enterprise". Instead in each case we need to simulate the enterprise software problem that our tool is supposed to solve. http://www.aygulum.net
http://sohbetcide.com

Posted by Chat on June 17, 2010 at 09:07 AM PDT #

In my opinion, the same approach can be used for enterprise software tools integrated with Web Services as in Sun Java CAPS. Note that as above nobody is going to say http://www.evdenevenakliyatsec.com
http://www.cagdasnakliye.com
http://www.evdenevenakliye.us

Posted by nakliyat on July 11, 2010 at 08:38 PM PDT #

You may want to have a look at a new RIA Benchmark called RIABench:
http://www.timo-ernst.net/riabench-start

It supports JavaFX, Flash, Silverlight and HTML5/JavaScript.

Compared to Bubblemark or GUIMark, it is based on a more scientific approach from the University of Ulm.
It also goes into deeper analysis for potential bottlenecks on RIA technology performance.

Posted by Timo on September 22, 2010 at 12:45 AM PDT #

In my opinion, the same approach can be used for enterprise software tools integrated with Web Services as in Sun Java CAPS. Note that as above nobody is going to say http://www.parcatlkontor.com

Posted by parça kontör on October 20, 2010 at 01:36 AM PDT #

güzel bir link kaynağı olmuş bizlere teşekkürler arkadaş/nice comments is liked editors thnks

Posted by Chat on November 01, 2010 at 12:15 PM PDT #

sizlerin bu konudaki düşüncelerini bilmem ama bu site güzelmiş arkadaşlar sizlerde katılın kazanın değilmi ( very good nice admin tnks)

Posted by chat siteleri on November 01, 2010 at 12:16 PM PDT #

n my opinion, the same approach can be used for enterprise software tools integrated with Web Services as in Sun Java CAPS. Note that as above nobody is going to say "Hey, here you go, why don't you test your enterprise tools on my enterprise". Instead in each case we need to simulate the enterprise software problem that our tool is supposed to solve

Posted by konyachat on November 01, 2010 at 05:30 PM PDT #

danke chat deyince 1 numara

Posted by chat on November 13, 2010 at 10:35 PM PST #

ezgichat deyince bie numara

Posted by ezgichat on November 13, 2010 at 10:37 PM PST #

Simple and Nice example !

Posted by شات on December 15, 2010 at 03:39 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

user12610627

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
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
  
       
Today