Technical aspects

Round 1

Scene graph design

The system mentioned in my previous post utilizes JavaFX script language features to construct a lazy dependency graph, part of which is the scene graph that provides the infrastructure for rendering, picking, and collision detection. This scene graph does not use the trigger feature of JavaFX script, but rather relies on its lazy binding feature.

Thus, when you modify the scene, nothing happens other than that things that depend on your modifications are (implicitly) marked invalid. Only when you subsequently access the scene does (minimal) reevaluation occur. In addition, due to the nature of binding, results are implicitly "memo-ized" and you get fast cached access to them if their dependencies haven't changed. Ultimately when the render pass occurs, it touches everything, bringing it up to date if necessary as a side effect.

Linear Math

Animation of 2d or 3d geometry consists of animating the components of 2d or 3d affine transformations that are applied to such geometry or of deforming the geometry itself. Linear algebra provides truly elegant mechanisms to express such, however, that elegance is severely diminished in programming languages that cannot provide the expected arithmetic operators. Therefore one of the language and compiler modifications I made is to provide overloaded arithmetic operators for vector and matrix operations. For our purposes (vector graphics) we only require 2d, 3d, and 4d vectors and 2x2, 3x3, and 4x4 matrices. These types are provided in a new package called javafx.math, namely Vec2, Vec3, Vec4, Mat2, Mat3, Mat4. Since rotations may be represented as a pair of angle/axis, or quaternion form, in addition to matrix form, we also provide the types AngleAxis, and Quat. All of the types mentioned are conceptually immutable value types, like Java/JavaFX primitive types. Ideally, they should be implemented with VM level value types.

Transform and bounding volume hierarchies

With these prerequisites, implementation of the transform hierarchy is trivial (simplified, with some details omitted - local transform consists of a number of sub-components):

import javafx.math.Mat4;

public abstract class Node {

    public var parentNode: Node;
    public var transform: Mat4 = IDENTITY;
 
    public def worldTransform: Mat4 =
        bind lazy
        if (parentNode == null)
        then localTransform
        else parentNode.worldTransform \* localTransform;

    public def localTransform = bind lazy transform \* ...
    ...

The above simply states that a Node has an optional parent, which is also a Node, and that its local to world space transformation is that of its parent multiplied by its own local to parent transform or just its own transform if it's the root of the hierarchy.

Implementing the bounding volume hierarchy is equally trivial:

   
public class Bounds {

    public-init var center: Vec3 = Vec3.ZERO;
    public-init var extent: Vec3 = Vec3.ZERO;

    public def width = bind lazy extent.x \* 2;
    public def height = bind lazy extent.y \* 2;
    public def depth = bind lazy extent.z \* 2;
    public def min = bind lazy center - extent;
    public def max = bind lazy center + extent;
    ...
}

public function transformBounds(b:Bounds, transform:Mat4):Bounds { ... }


public abstract class Node {
    ...
    public def worldBounds:Bounds = bind lazy Bounds.transformBounds(contentBounds,
                                                                     worldTransform);
    public def bounds:Bounds = bind lazy Bounds.transformBounds(contentBounds,
                                                                localTransform);

    public-read protected var contentBounds:Bounds;
    ...
}

The above states that the world space bounding box of a Node is the bounding box of whatever it contains multiplied by its local to world transform, and similarly for its local bounds in its parent's coordinate system.

This approach has a worst case cost which is the same as one which used eager bindings, for example if I modify a node's transform and then immediately read the root node's bounds, then modify another node's transform, then read the root node's bounds, etc. However, for real programs the average case cost is fantastically less, since reading all the dependents during a sequence of modifications rarely happens in practice. With eager bindings as in javafx 1.x and in prism, you pay this price all of the time regardless. I believe the "boundsInScene" variable of the javafx 1.1 Node class was actually removed in 1.2 due to this type of overhead.

A similar lazy binding strategy is used throughout, for the shading network, 2d shape creation and composition, for complex compositions of weighted transformations such as aim, point, and orient constraints, etc, all in contrast to what we have in javafx 1.x.

I had to make some compiler modifications to make lazy binding operate correctly. In particular ensuring that it truly is lazy - for example, in the above bounding volumes are not created at all until they're used.

Comments:

Is there any chance this project will ever be released? If not, it seems kind of mean to tell us about all these wonderful features we'll never see...

Posted by guest on July 09, 2009 at 02:11 PM PDT #

I for one thank Chris for making this information publicly available. The concept of using lazy binding to implement a correct and rich dependency graph with minimal code is very powerful and could inform the design of future scene graphs, even if this one is never released.

Posted by Kenneth Russell on July 09, 2009 at 05:16 PM PDT #

I second that. Thanks for the info Chris!

Posted by Pär Dahlberg on July 09, 2009 at 06:36 PM PDT #

Are there any plans for (re-)introducing lazy binding into JavaFX?

Posted by pron on July 09, 2009 at 07:45 PM PDT #

Actually, we do use lazy binding in the production scenegraph. We also do not recompute bounds or transforms on every change. There is certainly more to tighten up.

Posted by Richard bair on July 10, 2009 at 12:20 AM PDT #

This seems more like a real production scenegraph then the present one Richard. Or are you referring to yet another project?

Posted by Tim West on July 11, 2009 at 08:38 PM 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 "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:00 AM PDT #

Actually, we do use lazy binding in the production scenegraph. We also do not recompute bounds or transforms on every change. There is certainly more to tighten up
http://www.evdenevenakliyatsec.com
http://www.cagdasnakliye.com
http://www.evdenevenakliye.us

Posted by nakliyat on July 11, 2010 at 09:19 PM 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 "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.zurnacet.net

Posted by zurna on September 28, 2010 at 06:43 PM PDT #

In my opinion, the same approach can be used for enterprise software tools integrated with Web Services as in Sun Java CAPS.. devam ediyoruz değilmi?

Posted by konyachat on November 01, 2010 at 04:54 PM PDT #

nstead in each case we need to simulate the enterprise software problem that our tool is supposed to solve.. aynen devam

Posted by chat siteleri on November 01, 2010 at 04:55 PM PDT #

This seems more like a real production scenegraph then the present one Richard. Or are you referring to yet another project. http://www.memleketchat.com

Posted by Chat on November 01, 2010 at 04:55 PM PDT #

nstead in each case we need to simulate the enterprise software problem that our tool is supposed to solve.. aynen devam

Posted by شات مصري on December 04, 2010 at 07:26 PM PST #

nstead in each case we need to simulate the enterprise software problem that our tool is supposed to solve.. aynen devam

Posted by دردشة on December 04, 2010 at 07:27 PM PST #

Thaaaaaaaaaaaanks

Posted by شات on December 04, 2010 at 07:27 PM PST #

Thaaaaaaaaaaaanks

Posted by دردشة مصرية on December 04, 2010 at 07:28 PM PST #

Okey Oyunu İndirme merkezine hoş geldiniz. Türkiye’deki okey severlerin ortak buluşma noktası olan bu site, okey oyunu hakkında merak ettiğiniz ve bilmek istediğiniz her şeye rahatlıkla erişebilmeniz için dizayn edilmiştir.
link: http://www.okeyoyunuindir.com

Posted by okey oyunu indir on April 25, 2011 at 07:20 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

user12610627

Search

Archives
« April 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
   
       
Today