This is an in-depth presentation for coders that covers the key concepts of Creation Core and Creation Platform. It starts with a couple of demonstrations, and then moves onto the actual workshop.

00:20 – Asset Browser demo

06:30 – rigging/animation tool demo

19:20 – Introducing the Core

44:20 – Registered Types

53:00 – Wrapping the core

58:40 – Introducing Creation Platform

The code samples can be found on github at: https://github.com/fabric-engine/UsergroupWorkshops

Accompanying articles:

Part 1

Part 2

You can get the software from here

*IMPORTANT NOTE FOR UPGRADING FROM 1.0.31*

• Due to some changes between versions, you must uninstall 1.0.31 before installing the new release.
• Creation Platform now requires OpenGL 3.2 or later.

Thanks,

Team Fabric

1.0.32 Release notes:

Supported Platforms

• Mac OS X is once again a fully-supported platform. The real-time renderer has been updated to use the OpenGL 3.2 profile, which is required for OS X support.
• We now officially support a Windows 7 64-bit Python 2.6 build.
• The other supported platforms have remained the same. The complete list is:
  • Windows 7 64-bit using Python 2.7
  • Windows 7 64-bit using Python 2.6
  • Windows 7 32-bit using Python 2.7
  • Ubuntu 12.04 (Python 2.7)
  • Ubuntu 10.04 (Python 2.6)
  • CentOS 6.3 (Python 2.6)
  • Mac OS X 10.7 “Lion” or later (Python 2.7)

Creation Platform Changes

 Real-time Renderer Framework

• Avoid recomputation of valid render targets (for example: don’t recompute a shadow map if we orbit the camera)
• Multiple fixes related to supporting dynamic pass changes (for example: from exposed pass options)
• Support for Boolean and flags as input arguments of render callbacks, and boolean as shader params
• Removed implicit construction of projection matrices (based on bounding volumes); now built explicitly by pass render function callbacks
• Support for cube map render targets (used for point light shadows), including new ‘refineTextureTarget’ render pass statement
• Octree queries for spheres and transformed bounding boxes
• Improvement of the RTR documentation
• All shaders are now updated to comply with OpenGL 3.2 profile.

 Real-time Renderer Passes and Shaders

• Support for orthographic cameras
• Shadows for all light types (directional, point and spot), including infinite lights, with various global controls exposed by the passes. Implementation of 3-level cascaded shadow maps for directional lights.
• Adjustment of the near/far planes of cameras and shadow maps based on the view frustum and scene bbox for more precision
• Integration of our SSAO and bloom in the standard passes. The effects themselves can be improved but provide a great example for the RTR
• Per-instance support for culling and double-sided shading, including an option to revert the culling if negative scaling (like in some DCCs)
• Reduction of deferred shading render target memory (Z (depth) instead of full positions + more optimal texture formats)

 Scene Graph

• Refactoring of the lights in 3 python classes with improved construction options (PointLight, SpotLight and DirectionalLight)
• The Image node class hierarchy was refactored to store pixels in a registered type. this makes querying of pixel values from within KL code easy. An example ‘Displacement Deformer’ was added that demonstrates deforming a mesh using pixel values.
• The Alembic exporter has been updated and now supports a wider range of scenarios.
• Refactored our reference interface system. Now each node maintains a list of InPorts and OutPorts. These can be used to navigate the graph and explicitly create connections between nodes.
• Fixes to Curve Editor Framing, and background grid drawing.
• A collection of minor bugs were fixed.

 DCC Integration

• Support for Maya 2013 integration on Linux

 Licensing

• RLM floating licenses are now per-host and not per-process. This is not a change in Creation Platform but rather in our license generation settings; any user who wants their previous floating license updated to be per-host instead of per-process can contact us.

 Creation Core Changes

• CAPI: Add support for calls into Creation Core from different threads in the client
• Fix optimized code cache on machines running in non-US locales
• A few small Python client fixes that could cause crashes on invalid input.

Problems with the old model:

• Customers find the $3k price point very high for simple tools like asset viewers and other widgets. It means that everyone wants to see significant value before they can justify purchasing Creation – yet we started the company so that we could cover both large and small problems.
• This in turn means that we have to keep adding functionality to create sufficient value to justify the purchase – this has meant that we are getting further away from offering a framework and heading towards to the monolithic DCC applications that we never intended to replicate.
• Bundling crowds, muscles, vegetation systems etc within the framework is not efficient – in many cases this functionality just gets ignored.
• Customers want to use Creation for non-interactive/headless scenarios, but cannot justify paying thousands for these licenses. It’s very difficult to do create a split between interactive and non-interactive licenses with Creation – the things that make the framework powerful, also make it difficult to create arbitrary separations like this.
• 3^rd party developers are unable to build and sell simple, useful tools with Creation because of the price point. Part of our plan has always been to support and develop a strong 3rd party developer ecosystem, but the business model has made that impossible.

Our solution:

• Release the core framework without all of the high-end application samples – so muscles, crowds, vegetation etc are removed.
• Release this functionality as standalone modules that are more complete products, and charge for them separately.

Benefits:

• Studios can start using Creation for simple tools with a low cost of entry – $250 per license, per year
• Development of the core Creation framework will be faster, with a focus on performance and flexibility
• We can put more work into various modules, as we can get a clear return on investment by selling them to customers that need the functionality
• 3^rd party developers can sell standalone applications and modules at a much lower cost

What is/isn’t in the basic Creation framework?

• Muscles, SSR, Crowds, Hair, Vegetation will all be removed from the Creation framework and offered as modules (over time)
• Generically useful functionality will always be in the core product – so real-time rendering, file extensions, DCC integration, UI functionality, Creation Core Execution Engine, debug tools etc etc. Everything you’d need if you decided you wanted to build your own modules

Creation:

Annual rental: $250 per year, per node – a node can run anywhere (artist machine, render node etc)

Purchase: $750 purchase + $100 annual subs

We will still offer the two free licenses of Creation!

Volume discounts/Site licensing: contact us

Modules: We will announce module pricing as we release them.

Hey folks,

just as a heads up: We did it. The Creation Platform workshop at Sehsucht was an overall success. The feedback was great, the attendees as well as myself enjoyed the presentation and the general vibe was very creative.

It was particularly interesting to see the ideas and prospective projects come to life once the inner workings of Creation Platform had been explained and layed out.

Providing Server Side Rendering without any friction, allowing tools to be used as well as standalone as inside of Softimage or Maya… all of these subjects kept people excited throughout the workshop. We are very proud to say that our vision is shared by our users!

A special thanks again to Sehsucht for hosting the event. Their location is quite amazing and helped the casual and family-like feeling for the event. The IT did an amazing job as well, providing everything requested.

Thanks to all of the attendees for coming. We hope to see you again soon!

The Fabric Engine team.

We will build a simple Core dependency graph with some trivial operators, and then build a simple abstraction using Python classes to aid in the construction of the graph.

The following post is based on a workshop presented at the Montreal Fabric Engine user group. All of the source code can be found online in the repository location:

https://github.com/fabric-engine/UsergroupWorkshops/tree/master/WorkshopNovember2012/IntroductionToTheCore

This is an article to accompany the workshop video – you can see it here. The first part of this tutorial is here.

1 . Building a Basic Dependency Graph

In the following example, we build a trivial dependency graph

import FabricEngine.Core

fabricClient = FabricEngine.Core.createClient()
timerNode = fabricClient.DG.createNode('timer')
timerNode.addMember('time', 'Scalar', 0)
valuesDGNode = fabricClient.DG.createNode('data')
valuesDGNode.addMember('values', 'Scalar[]')
valuesDGNode.addMember('valueCount', 'Integer', 100)
valuesDGNode.setDependency(timerNode, 'timer')
# The operator that will create our particles
operator = fabricClient.DG.createOperator('ComputeDataOp')
operator.setEntryPoint('computeDataOp')
operator.setSourceCode(open('dataCalculator.kl').read())
# We instanciate a Binding object. It will glue the data with the operator.
binding = fabricClient.DG.createBinding()
binding.setOperator(operator)

binding.setParameterLayout([
  'timer.time',
  'self.index',
  'self.valueCount',
  'self.values'
])

valuesDGNode.bindings.append(binding)

print timerNode.getErrors()
print valuesDGNode.getErrors()

for i in range(0, 100):
  print 'At frame:', i
  timerNode.setData('time', float(i))
  valuesDGNode.evaluate()
print "======================"

What the code does above builds a trivial dependency graph. The timer node stores a value which is used to compute an array of values in the values node.

2. Data Parallel Nodes

import FabricEngine.Core

fabricClient = FabricEngine.Core.createClient()

timerNode = fabricClient.DG.createNode('timer')
timerNode.addMember('time', 'Scalar', 0)
valuesDGNode = fabricClient.DG.createNode('data')
valuesDGNode.addMember('values', 'Scalar[]')
valuesDGNode.addMember('valueCount', 'Integer', 100)
valuesDGNode.setDependency(timerNode, 'timer')
# The operator that will create our particles
operator = fabricClient.DG.createOperator('ComputeDataOp')
operator.setEntryPoint('computeDataOp')
operator.setSourceCode(open('dataCalculator.kl').read())

# We instanciate a Binding object. It will glue the data with the operator.
binding = fabricClient.DG.createBinding()
binding.setOperator(operator)

binding.setParameterLayout([
  'timer.time',
  'self.index',
  'self.valueCount',
  'self.values'
])

valuesDGNode.bindings.append(binding)

print timerNode.getErrors()
print valuesDGNode.getErrors()

#####################################
# 2. Data based parallelizm

# By setting the slice count of a node to 100, the node's data mambers are
# all duplicate by 100 times, and the bound operator will evaluate once for
# each slice. This gives us an easy method of 'instancing' a node many times.
valuesDGNode.setCount(10)

for i in range(0, 100):
  print 'At frame:', i
  timerNode.setData('time', float(i))
  valuesDGNode.evaluate()

print "======================"

The data node slice count has now been increased, effectively giving us 10 instances of the Data Node. The operator bound to the Data Node is now evaluated for each slice of the node. Each slice of the data node contains a unique set of data which can be computed independently.

3. Python Abstraction Classes

#####################################
# 3. Wrapping the Core DG elements in Python classes

import FabricEngine.Core

class TimerNode(object):

  def __init__(self, client):

    # The dependency graph node is a private member
    # that can only be accessed via accessor methods.
    self.__timerNode = client.DG.createNode('timer')
    self.__timerNode.addMember('time', 'Scalar', 0)
    self.__dependents = []

  def getDGNode(self):
    return self.__timerNode

  def addDependent(self, node):
    self.__dependents.append(node)

  def evaluateTimeRange(self):
    # To trigger evaluations of the Core graph, we modify
    # the values tored in the Timer node, and then trigger
    # evaluations in the dependent nodes.
    # Note: generally graph evaluations are triggered by rendering
    # or export processes. Manual evaluation of graphs is not usually required.
    for i in range(0, 100):
      print 'At frame:', i
      self.__timerNode.setData('time', float(i))
      for dep in self.__dependents:
        dep.evaluate()
class DataCalculator(object):

  __numDataCalculators = 0
  __operator = None

  def __init__(self, client, valueCount=1, sliceCount=1):
    # Core dependency graph nodes must have unique names.
    # Construct a Dependency Graph node, giving it a
    # unique name for each instance of DataCalculator.
    self.__class__.__numDataCalculators += 1
    self.__valuesDGNode = client.DG.createNode('data' + str(self.__class__.__numDataCalculators))
    self.__valuesDGNode.addMember('values', 'Scalar[]')
    self.__valuesDGNode.addMember('valueCount', 'Integer', valueCount)
    # By setting the slice count of a node to 100, the node's data mambers are all duplicated
    # by 100 times, and the bound operator will evaluate once for each slice.
    # This gives us an easy method of 'instancing' a node many times.
    self.__valuesDGNode.setCount(sliceCount)

    # Compile the shared operator.
    # The operator is a class variable as it can be shared
    # amongst all instances of DataCalculator, meaning the KL code
    # is only compiled once.
    if self.__class__.__operator is None:
      self.__class__.__operator = client.DG.createOperator('ComputeDataOp')
      self.__class__.__operator.setEntryPoint('computeDataOp')
      self.__class__.__operator.setSourceCode(open('dataCalculator.kl').read())

    # We instantiate a Binding object. It will glue the data with the operator.
    binding = client.DG.createBinding()
    binding.setOperator(self.__class__.__operator)

    binding.setParameterLayout([
      'timer.time',
      'self.index',
      'self.valueCount',
      'self.values'
    ])

    self.__valuesDGNode.bindings.append(binding)

  def setTimerNode(self, timerNode):
    # Create a relatonship between the TimerNode and the DataCalculator,
    # so the timeer can update the calculator when the time value changes.
    self.__valuesDGNode.setDependency(timerNode.getDGNode(), 'timer')
    timerNode.addDependent(self)

  def evaluate(self):
    self.__valuesDGNode.evaluate()
fabricClient = FabricEngine.Core.createClient()

timerNode = TimerNode(fabricClient)
myDataCalculator1 = DataCalculator(fabricClient, valueCount=200, sliceCount=5)
myDataCalculator2 = DataCalculator(fabricClient, valueCount=500, sliceCount=7)
myDataCalculator1.setTimerNode(timerNode)
myDataCalculator2.setTimerNode(timerNode)

timerNode.evaluateTimeRange()

print "======================"

Rather than building the dependency graph nodes directly, we can use Python classes to construct the dependency graph. The Python classes defined in the graph above are used to generate the dependency graph nodes, making it easy to build graphs quickly. The Python classes can create small parts of a bigger dependency graph. The Python classes define  re-usable sub-graphs which can be shared across projects.

The dependency graph nodes constructed by the Python classes are kept as private members. Python can then be used to provide a level of abstraction, facilitating the construction of larger dependency graphs. This simple example is analogous to Creation Platform. Creation Platform is a collection of Python classes which are used to build Creation Core dependency graphs.

4. Registering Custom Data Types

One of the key features of the Creation Core is the ability to define custom data types that can then be used in the dependency graph. All complex data types used in Creation Platform are custom types registered at runtime. This means that our Vectors, Quaternions, and Matrices are all defined as custom types at runtime, and can therefore be modified, and extended according to your requirements.

The way type registration works, is a Python class is defined with a collection of methods for working with that class in the Python environment. This Python class is then registered with the Core, and equivalent KL methods are specified for working with the same type in KL.

fabricClient = FabricEngine.Core.createClient()

class Vec2():
  def __init__( self, x = None, y = None ):
    if type( x ) is float and type( y ) is float:
      self.x = x
      self.y = y
    elif x is None and y is None:
      self.x = 0
      self.y = 0
    else:
      raise Exception( 'Vec2: invalid arguments' )

  def sum( self ):
    return self.x + self.y

  def add(self, other):
    return Vec2(x = self.x + other.x, \
    y = self.y + other.y)

  def __str__(self):
    return "Vec2(x = " + str(self.x) + ", y = " + str(self.y) + ")"

desc = {
  'members': [ { 'x':'Scalar' }, { 'y':'Scalar' } ],
  'constructor': Vec2,
  'klBindings': {
  'filename': "(inline)",
  'sourceCode': "\
function Vec2(Scalar x, Scalar y)\n\
{\n\
 this.x = x;\n\
 this.y = y;\n\
}\n\
\n\
function Vec2 + (Vec2 a, Vec2 b) {\n\
 return Vec2(a.x + b.x, a.y + b.y);\n\
}\n\
function Scalar Vec2.sum() {\n\
 return this.x + this.y;\n\
}\n\
"
 }
}

fabricClient.RegisteredTypesManager.registerType( 'Vec2', desc )

newVec2_1 = Vec2(3.4, 7.2)
newVec3_2 = Vec2(2.6, 17.5)

print newVec2_1.add(newVec3_2)
print (newVec2_1.add(newVec3_2)).sum()
node = fabricClient.DependencyGraph.createNode("foo")
node.addMember( 'vec2_1', 'Vec2' )
node.addMember( 'vec2_2', 'Vec2' )
node.setData( 'vec2_1', 0, newVec2_1 )
node.setData( 'vec2_2', 0, newVec3_2 )
# The operator that will create our particles
operator = fabricClient.DG.createOperator('addVec2')
operator.setEntryPoint('addVec2')
operator.setSourceCode(open('vec2Add.kl').read())

# We instanciate a Binding object. It will glue the data with the operator.
binding = fabricClient.DG.createBinding()
binding.setOperator(operator)

binding.setParameterLayout([
  'self.vec2_1',
  'self.vec2_2'
])
node.bindings.append(binding)
print node.getErrors()
node.evaluate()
print "======================"

The code sample above defines a type called Vec2, and some basic methods on that type for manipulating the data. The type is then registered with the Core, along with a collection of kl methods for operating on the Vec2 in KL. The same math can then be computed in KL, or in Python giving the same results.

Note: Often data structures are defined where the methods defined in Python and KL are completely different. The Animation system is made up of a collection of registered types where the methods in Python are used to manipulate the animation tracks, generate, or remove keys, and the methods in KL are performance critical, such as evaluation of the tracks. This enables Python to be used for user interfaces and data manipulation, and KL for data evaluation.

https://github.com/fabric-engine/UsergroupWorkshops/tree/master/WorkshopNovember2012/IntroductionToTheCore

You can watch a video presentation of the complete workshop here.

Defining a Custom Creation Platform Application

import math, random
from PySide import QtGui, QtCore

from MandelbrotImage import MandelbrotImage

from FabricEngine.CreationPlatform.PySide import *
class MandelBrotViewerApp(Basic3DDemoApplication):

  def __init__(self):
      super(MandelBrotViewerApp, self).__init__(
      setupGlobalTimeNode = True,
      setupSelection = False,
      setupUndoRedo = True,
      setupPersistence = True,
      enableRaycasting = True,
      setupImport = True
    )

   self.setWindowTitle("MandelBrot Viewer App")
   self.constructionCompleted()

MandelBrotViewerApp().exec_()

Defining a Custom Scene Graph Node

Scene Graph Nodes are python classes that define the structure of the Creation Platform's scene graph. There is a wide range of scene graph nodes defined in Creation Platform, making it easy to take one of the base nodes types and extend it according to your own requirements.
In this example, we define a new custom Image node that display a generated mandelbrot set. The MandelbrotImage node exposes a time port enabling it to be connected to time nodes so it can be driven by the time value.
from FabricEngine.CreationPlatform.Nodes.Images.Image2DImpl import Image2D
from FabricEngine.CreationPlatform.Nodes.Animation.TimeImpl import Time

class MandelbrotImage(Image2D):

  def __init__(self, scene, **options):

    ###########################################
    # 1.0 Setup the base image

    options.setdefault('width', 640)
    options.setdefault('height', 480)
    options.setdefault('format', 'RGB')
    options.setdefault('createSlicedDGNode', True)
    options.setdefault('forceRefresh', True)

    super(MandelbrotImage, self).__init__(scene, **options)

    ###########################################
    # 2.0 Setup the parameters for the madelbrot set.
    imageAttributesDGNode = self.getAttributesDGNode()

    imageAttributesDGNode.addMember("center", "Complex64", Complex64(0.0, 0.0))
    imageAttributesDGNode.addMember("zoom", "Float64", 1.0)
    imageAttributesDGNode.addMember("maxIterations", "Size", 1536)

    self._addMemberInterface(imageAttributesDGNode, 'center', True)
    self._addMemberInterface(imageAttributesDGNode, 'zoom', True)
    self._addMemberInterface(imageAttributesDGNode, 'maxIterations', True)

    ###########################################
    # 3.0 Setup the pixels node.
    pixelsDGNode = self.getPixelsDGNode()
    pixelsDGNode.setDependency(imageAttributesDGNode, 'parameters')

    self.bindDGOperator(pixelsDGNode.bindings,
      name = 'resizeNode',
      fileName = FabricEngine.CreationPlatform.buildAbsolutePath('Mandelbrot.kl'),
      layout = [
        'self',
        'attributes.width',
        'attributes.height',
      ]
    )
    self.bindDGOperator(pixelsDGNode.bindings,
      name = 'generateMandelbrot',
      fileName = FabricEngine.CreationPlatform.buildAbsolutePath('Mandelbrot.kl'),
      layout = [
        'self.pixels',
        'attributes.center',
        'attributes.zoom',
        'attributes.maxIterations',
        'self.index',
        'attributes.width',
        'attributes.height',
      ]
    )

    ###########################################
    # 4.0 Setup time reference

    self.__timeOpBindings = None
    def __changeTimeNode(data):
      if data['prevNode'] is not None and data['node'] is None:
        if self.__timeOpBindings is not None:
          self.removeDGOperatorBinding(imageAttributesDGNode.bindings, self.__timeOpBindings)

        imageAttributesDGNode.removeDependency('time')
      if data['node'] is not None:
        imageAttributesDGNode.setDependency(data['node'].getDGNode(), 'time')
        self.__timeOpBindings = self.bindDGOperator(imageAttributesDGNode.bindings,
          name = 'setTime',
          sourceCode = 'operator setTime(Scalar time, io Float64 zoom){ zoom = 1.0 + time; }',
          layout = [
            'time.time',
            'self.zoom'
          ]
        )

    self.addReferenceInterface('Time', Time, False, __changeTimeNode)
###########################################
# 5.0 Register the new custom node so that it will show up in the
# user interfaces, and be saved and loaded with the scene files.

MandelbrotImage.registerNodeClass('MandelbrotImage')



The base class constructor can be invoked with parameters to setup an empty image node.
New members can be added to the dependency graph node defined in the base class. The 'AddMemberInterface' methods expose the specified values on the user interface of the node.
Operators are bound to the dependency graph node that will compute the pixel values of the mandelbrot set.
A 'reference interface is added to the node, enabling the node to be connected to Time nodes, to drive the zoom value of the mandelbrot set.

The resulting MandelbrotImage node can then be constructed in the node graph and connected to the background texture port on the Viewport node.

The next part of this tutorial can be found here.
]]>
			http://fabricengine.com/2012/11/creation-platform-102-building-custom-tools-using-creation-platform/feed/
		0
		
		
		
		http://fabricengine.com/2012/11/workshop-event-hamburg-8th-of-dec/
		http://fabricengine.com/2012/11/workshop-event-hamburg-8th-of-dec/#comments
		Mon, 19 Nov 2012 10:50:55 +0000
		Helge Mathee
				

		http://fabricengine.com/?p=3637
		
				Hey gang!

I am happy to announce the first official Creation Platform workshop in Germany.
Date: 8th of December 2012

Location: Sehsucht, Laeiszstrasse 13–15, Hamburg. 
In this workshop we will go through the details of:

What’s the Creation Core?
Multithreading approaches
The core’s language KL


Creation Platform
Implementation of a custom node
Integration into a DCC (such as Maya or Softimage)

Please bring linux (ubuntu 64), windows (win7 64) or OSX based laptops.
We’re sorry, this event is now fully booked.
]]>
			http://fabricengine.com/2012/11/workshop-event-hamburg-8th-of-dec/feed/
		0
		
		
		
		http://fabricengine.com/2012/10/creation-platform-101/
		http://fabricengine.com/2012/10/creation-platform-101/#comments
		Wed, 17 Oct 2012 17:58:40 +0000
		Paul Doyle
				

		http://fabricengine.com/?p=3253
		
				Introduction
Click here to view the embedded video.
In this series of articles we would like to explain basic but extremely important concepts used by Creation Platform to build a 3D application.
In the first part, we will only use the Fabric Core from its python module, to build the dependency graph (without using Creation Platform). This will give you the picture on the low level subjects first. Taking this path will help you to quickly understand some key concepts that are abstracted in Creation Platform. We will build a super simple particle system and will visualize it from a command line interface.
In the second part you will learn how to take advantage of such high performance systems for an interactive particle simulation application. Creation Platform will helps us in various areas, as it will provide all of the tools to build a user interface, but it will also help us to build a more complex dependency graph (and more easily), as well as providing a much better debugging environment.
Part1  The Core Dependency Graph
Part2  Building a Particle System with Creation Platform
]]>
			http://fabricengine.com/2012/10/creation-platform-101/feed/
		0
		
		
		
		http://fabricengine.com/2012/10/creation-platform-101-building-a-particle-system-with-creation/
		http://fabricengine.com/2012/10/creation-platform-101-building-a-particle-system-with-creation/#comments
		Wed, 17 Oct 2012 17:58:13 +0000
		Paul Doyle
				
		

		http://fabricengine.com/?p=3338
		
				Note: This tutorial comes with full source code that can be found here: https://github.com/frenchdog/CreationPlatform101.git


Now that you know how to build a dependency graph, we will build on what you learned and create a more interactive particle system. We will design a simple system that will allow us to move an emitter and play with some of the parameters using a graphical user interface. We will use the Euler method to solve the motion of our particles. This system will use an openGL viewport to visualize the particles and widgets to edit various parameters like the emission rate and the randomization of the velocity.
Here is a list of the objects we need to design:

Emitters: Generate initial particle attributes like velocity or position. The emitters can be of various shape e.g a disc, sphere etc
Forces: Will modify particle velocity. Can be as simple as a directional force, or something more complex, such as a field.
Simulator: Generates particles and computes their positions for each time step.

These three types of objects will give us the opportunity to take a look at Creation Platform classes like the SceneGraphNode, the Component, and the PointCloud (which is more specialized). We will also discuss the Creation Platform Application classes that handle services like the timeline, persistence, and undo-redo.
The SceneGraphNode class:
This is the main building block in Creation. This node lets you package various DG nodes needed for one specific task. You can connect SceneGraphNodes together using the reference system. Referencing a node is not the same thing as connecting two DGNodes together – which is what we covered in the first tutorial using setDependency() – referencing a SceneGraphNode gives you access to all the DGNodes of the referenced node. You can access every DGNode of a referenced SceneGraphNode, but some dependencies may not make sense. For example, connecting the rotation of a Transform Node to the point positions of a Geometry node would return an error. The node referencing system ensures that only valid connections between SceneGraphNodes are established. Using this system, you can build very complex graphs yet keep things nicely organised – as you can see by opening the SceneGraph Debugger:

Compared to the true Dependency Graph that you can visualize using the Dependency Graph Debugger :

The SceneGraph is an abstraction of the Core dependency graph that lets you construct your scene much more easily. The SceneGraph only exists within Creation Platform, it is not represented in the Core (since it is an abstraction of the `true`dependency graph).
To create a new node you can either derive it from the SceneGraphNode class or use a subclass of SceneGraphNode (like PolygonMesh or PointCloud). These classes create the DGNodes and data members needed for these primitives. You can also augment an existing class by applying a Component. A Component can add additional DGNodes, Operators and References to an existing SceneGraphNode (we will build our particle system node using this approach).
Choosing to subclass a SceneGraphNode or to apply a new Component is a matter of choice that can vary per project. In the particle system that we are building we will create a new SceneGraphNode type for the emitter. You will see that this approach means that we will only be able to connect this type of node to the emitter input of our particle system.
Now that you understand the difference between the Core Dependency Graph and the Creation SceneGraph lets build our particle system!
The Force class:
We will define a simple force here. This shows us how to create a single DGNode in Creation Platform.
class Force(SceneGraphNode):
""" A simple Directional Force Class """
  def __init__(self, scene, **options):
    super(Force, self).__init__(scene, **options)
    self.constructDGNode()
    self.getDGNode().addMember( 'direction', 'Vec3', options.setdefault('direction',Vec3(1, 0, 0)) )
    self._addMemberInterface(self.getDGNode(), 'direction', True)
    self.getDGNode().addMember('intensity', 'Scalar', options.setdefault('intensity',10))
    self._addMemberInterface(self.getDGNode(), 'intensity', defineSetter = True)

“constructDGNode(‘myName’)” build a … DGNode inside our SceneGraphNode. But this method doesn’t just call FabricCoreClient.DG.createNode() like we saw in the first article, it is also adding a “getMyNameDGNode” instance method to any instances of the class. Since we didn’t provide a name, the instance method is just called “getDGNode”. But when a SceneGraphNode uses more than one DGNode, it makes sense to use more explicit names for every constructed DGNode.
After we add a member to a DGNode, we can expose data contained in it on our class using “_addMemberInterface”. An Interface is a system that lets you get and (optionally set) a DGNode member from your python code AND from the graphical user interface of the Creation application. This reflection between your python code the running application is very useful as you can inspect any exposed DG members from the UI.
You maybe already noticed that every SceneGraphNode’s “__init__” method uses **options as one of its argument. This let you pass any number of arguments to your subclass using keyword arguments (like kwarg=value). For example, if I use “options['direction']“ in the class object, it will return a value only if I create my class instance like this : force = Force( direction=Vec3(0,5,0) ). If ‘direction’ is not passed in the instance, its construction will fail. This is why we use options.setdefault( ‘direction’, Vec3(10,0,0) ). It will return Vec3(0,5,0) if it is passed as an argument, else it will use the default value Vec3(10,0,0).
The Emitter class:
An emitter will generate some points. Those points will be added to our simulated point cloud each time an emitter create new ones. Creation provides a class called Points, and it provides all the services we need to display our points in the viewport. By inheriting from this class, the Emitter class will just need to define the ‘shape’ of those points positions.
First, we are going to create an ‘abstract’ base class for our emitter. The idea is to be able to connect various type of emitters to our particle system. So if we tell this system to reference any SceneGraphNode of type “BaseParticleEmitter”, it should validate the connection for and only for every BaseParticleEmitter subclasses.

- Note that we didn’t create a Base class for the Force node, but you should also create one if you want to use more than one type of Force in your simulation -
class BaseParticleEmitter(Points):

""" A simple emitter system to define initial values for a particle system"""

def __init__(self, scene, **options):

# ensure that base class is never instantiated
 if self.__class__.__name__ == 'BaseParticleEmitter':
   raise FabricEngine.CreationPlatform.SceneGraphException('You cannot instantiate the BaseParticleEmitter node directly.')

# call the baseclass constructor
 super(BaseParticleEmitter, self).__init__(scene, **options)

self.addValue('points_count', 'Size', options.setdefault('pointCount', 100), addGetterSetterInterface=True)
 self.addValue('initial_velocity', 'Vec3', Vec3(0,10,0), addGetterSetterInterface=True)
 self.addValue('initial_velocity_variance', 'Vec3', Vec3(1.0, 0.0, 1.0), addGetterSetterInterface=True)

def __setTimeNode(data):
 timeController = data['node']
 self.getGeometryDGNode().setDependency( timeController.getDGNode(), 'time')
 self.addReferenceInterface(name='Time', cls=BaseTime, isList=False, changeCallback=__setTimeNode)

if options.setdefault('time', None) is not None:
 self.setTimeNode(options['time'])

# the Time class doesn't store the fps in its DG node. It is a standard python attribute that we set into the emitter node
 fps = self.getTimeNode().getFPS()
 self.addValue('fps', 'Scalar', fps)

As we are inheriting from the Points class, we can use some handy methods like “addValue()” and “addAttribute()”. The “addValue()” method lets you add a uniform data member to the node (a single value of any supported type) and ”addAttribute()” lets you add some geometry attributes for each point. Currently attributes only support the type Scalar, so to define a Vec3 per point, you just specify the number of components you want in the “addAttribute()” method – note that this is a temporary limitation as more complex types will be handled by the GeometryAttributes in the future.
Using the “addReferenceInterface()” method, we can set a reference to another node, in this case the scene Global Time Node, that is created by the Creation Platform application (as we will see later on). Setting the reference creates a connection between the Particle Emitter and the Time node. But it doesn’t create any dependency with Time’s DGNode(s). You must pass a callback function to addReferenceInterface() that will set the dependency on one or more DGNode. This callback will be called when you “set the reference”. Here, we named this reference “Time”  so we can set it using the instance method named ‘setTimeNode’. The ‘setTimeNode’ argument can only by of type ‘Time’, trying to connect another class will raise an error like this :
“FabricEngine.CreationPlatform.SceneGraphException: Reference ‘Time’ only supports nodes of type ‘BaseTime’”
Next we will implement a concrete class for one of our particle emitters. We will create a disc emitter, and it will include its own manipulator to be placed interactively in a 3D view.
class DiscEmitter(BaseParticleEmitter):

""" A specialized Particle Emitter using a circle primitive for interactive manipulation """

def __init__(self, scene, **options):

# call the baseclass constructor
 super(DiscEmitter, self).__init__(scene, **options)

self.addValue('seed', 'Integer', 123, addGetterSetterInterface = True)

# add a manipulator
 self.circle = LinesCircle(scene, radius=1.0)
 self.circleXform = Transform(scene, globalXfo=Xfo(Vec3(0.0,0.0,0.0)))
 self.circleMaterial = Material(scene, xmlFile='FlatLinesMaterial')
 self.circleMaterial.addPreset(name='blueLines', color=Color(0.35,0.75,0.95), lineWidth = 1.0)
 self.circleInstance = GeometryInstance(scene,
 geometry=self.circle,
 transform=self.circleXform,
 material=self.circleMaterial
 )

 def onConnectCircleXform(data):
   circleXform = data['node']
   self.getGeometryDGNode().setDependency( circleXform.getDGNode(), 'transform')

 self.addReferenceInterface('Transform', Transform, False, onConnectCircleXform)
 self.setTransformNode(options.setdefault('emitterXform', self.circleXform))

 self.bindDGOperator(self.getGeometryDGNode().bindings,
 name = 'DiscEmitterGenerator',
 fileName = FabricEngine.CreationPlatform.buildAbsolutePath('ParticleEmitters.kl'),
 layout = [
 'self.attributes',
 'time.time',
 'self.fps',
 'self.points_count',
 'self.seed',
 'self.initial_velocity',
 'self.initial_velocity_variance',
 'transform.localXfo'
 ],
 )

The disc emitter will emit some points randomly into a unit circle, so we define a “seed” value that will be exposed in the UI to let the user edit the random distribution. Then we add a Circle that is a built in primitive in Creation. The circle will help visualize the emitter limits. As we want to interactively move this circle, we add it to an Instance node. The Instance node combines a Transform and a Geometry node to represent a single Instance of a shape at a given position in space. We set a reference with the Transform node as we will need it to move the created particles. Then we can create our first KL operator. If you remember correctly, in the first part we learned that we need to instantiate a DGNode, a Binding and an Operator to then glue those objects together. In Creation Platform it is simpler as you can use the “bindDGOperator()” method instead. You just need to define the DGNode you want to attach the operator to, the name of the KL operator you want to use, the path to the KL file and the Parameter Layout.
In this layout, ‘self’ always refer to the node used in the first argument. ‘transform’ can be also used as we set a reference to this node.
And now the KL code for our emitter :
operator DiscEmitterGenerator(
 io GeometryAttributes attributes,
 in Scalar time,
 in Scalar fps,
 in Size pointCount,
 in Integer seed,
 in Vec3 initialVelocity,
 in Vec3 initialVelocityVariance,
 in Xfo emitterLocalXfo
) {
 attributes.addStandardAttributes( true, true );
 attributes.resize(pointCount);

AttributeKey velocityAttrKey = attributes.getKey("velocities");
 if(velocityAttrKey.type == AttributeType_Invalid)
 velocityAttrKey = attributes.addScalarAttribute("velocities", 3);

Integer offset = fps*time + seed;
 executeParallel(
 setParticleOnDisc_perPoints,
 pointCount, offset,
 attributes.scalarAttributes[Attribute_Pos],
 attributes.scalarAttributes[velocityAttrKey.index],
 initialVelocity,
 initialVelocityVariance,
 emitterLocalXfo
 );
}

GeometryAttributes is a type that let you access a specific attribute using its name (the attribute key). You can resize it and all of its attributes will be resized accordingly. For example, if we want 100 particles then we set attributes.resize( 100 ) and it will set the size for the velocities array to 300 (we set the number of components for the velocities attribute to three).
As we are executing the ”setParticleOnDisc_perPoints()” function in parallel, this function is using an integer as its first argument. In the implementation of the function, it will be the current index in the array of data we want to evaluate. When we call the function, this integer define the size of the array.
The KL code for the ”setParticleOnDisc_perPoints” :
function setParticleOnDisc_perPoints(
 in Size index,
 in Integer offset,
 io ScalarAttribute positionsAttr,
 io ScalarAttribute velocitiesAttr,
 in Vec3 initialVelocity,
 in Vec3 initialVelocityVariance,
 in Xfo emitterLocalXfo
){
 Index i = 0;
 Vec3 position;
 do {
 position = Vec3( mathRandomScalar(index, offset + i) - 0.5, 0.0, mathRandomScalar(index, offset + i + 500) - 0.5 );
 i+=1;
 } while (position.lengthSquared() > 0.25 & i < 1000);

 Index voff = index * 3;
 position *= 2;

position = emitterLocalXfo.transformVector( Vec3(position) );
 positionsAttr.setVec3Value(voff, Vec3(position.x, position.y, position.z));

Vec3 rndInitVelocity = initialVelocity;
 rndInitVelocity.x += (mathRandomScalar(index, 123) - 0.5) * initialVelocityVariance.x;
 rndInitVelocity.y += (mathRandomScalar(index, 345) - 0.5) * initialVelocityVariance.y;
 rndInitVelocity.z += (mathRandomScalar(index, 456) - 0.5) * initialVelocityVariance.z;
 rndInitVelocity = emitterLocalXfo.ori.rotateVector( Vec3(rndInitVelocity) );
 velocitiesAttr.setVec3Value(index * 3, rndInitVelocity);
}

This function generates a random position in a circle. This position is then transformed in the space of the Circle (used by the manipulator). Next, the attribute position is set using this Vec3 value and finally the velocity is set.
The SimulatedParticleComponent class:
This is the central station of our particle simulation. We will use a SimulatedPoints type as this class provide various attributes used in simulation like the velocity. However, in this case we won’t create a new type as it will be used as a standard simulated points node by any SceneGraphNode referencing it. For this scenario, adding a Component is the best option.
You can apply a Component to a SceneGraphNode like that : mySceneGraphNode.addComponent( myComponent( someOptions ) )

The “addComponent()” method of a SceneGraphNode will add a reference to this SceneGraphNode in the instantiated Component. This way the component can take the control of the node and can add any needed feature. To access the node from the component class, you can use self._node.
Let’s take a look at the added feature applied by the “SimulatedParticleComponent” to build our particle system:
class SimulatedParticleComponent(Component):

""" A component to add a simple euler integration solver on a SimulatedPoints node"""

def __init__(self, **options):
 super(SimulatedParticleComponent, self).__init__(**options)

@staticmethod
 def canApplyTo(node):
 return isinstance(node, SimulatedPoints)

def apply(self, points):
 super(SimulatedParticleComponent, self).apply(points)

self._node.addValue('gravity', 'Vec3', Vec3(0.0, -9.81, 0.0), True)
 self._node.addValue('ageLimit', 'Scalar', 3.0, True)
 self._node.addValue('randomizeAgeLimit', 'Scalar', 0.25, True)
 self._node.setValueInterfaceOption('randomizeAgeLimit', 'uiRange', Vec2(0, 1))
 self._node.addValue('startColor', 'Color', Color(0.0, 0.2, 0.8), True)
 self._node.addValue('endColor', 'Color', Color(0.0, 0.0, 0.0), True)
 self._node.addValue('randomizeColor', 'Scalar', 0.25, True)
 self._node.setValueInterfaceOption('randomizeColor', 'uiRange', Vec2(0, 1))

self._node.addReferenceInterface(name='Emitter', cls=BaseParticleEmitter, isList=False, changeCallback=self.__onChangeEmitterCallback)
 self._node.setEmitterNode(self._getOption('emitter'))

self._node.addReferenceInterface(name='Force', cls=Force, isList=False, changeCallback=self.__onChangeForceCallback)
 self._node.setForceNode(self._getOption('force'))

# Operators bindings
 self._node.bindDGOperator(self._node.getGeometryDGNode().bindings,
 name = 'SimulatedParticleOp',
 fileName = FabricEngine.CreationPlatform.buildAbsolutePath('SimulatedParticleComponent.kl'),
 layout = [
 'self.attributes',
 'time.time',
 'time.timeStep',
 'emitter.attributes',
 'self.gravity',
 'force.direction',
 'force.intensity'
 ])

self._node.bindDGOperator(self._node.getGeometryDGNode().bindings,
 name = 'SetParticleColorOp',
 fileName = FabricEngine.CreationPlatform.buildAbsolutePath('SimulatedParticleComponent.kl'),
 layout = [
 'self.attributes',
 'self.ageLimit',
 'self.randomizeAgeLimit',
 'self.randomizeColor',
 'self.startColor',
 'self.endColor'
 ])

def __onChangeEmitterCallback(self, data):
 emitter = data['node']
 self._node.getGeometryDGNode().setDependency( emitter.getGeometryDGNode(), 'emitter')

def __onChangeForceCallback(self, data):
 force = data['node']
 self._node.getGeometryDGNode().setDependency( force.getDGNode(), 'force')

As you can see, velocities and gravity data is added to our PointCloud. References to the Time, Emitter and Force nodes are set and a “SimulatedParticleOp” operator is added.
Here is the KL code for this operator:
function addPoints(
 in Scalar time,
 io GeometryAttributes attributes,
 in GeometryAttributes emitterAttributes,
 in AttributeKey velocityAttrKey,
 in AttributeKey emitterVelocityAttrKey
) {
 if(time==0) {
 attributes.resize(emitterAttributes.size());
 attributes.scalarAttributes[Attribute_Pos].data = emitterAttributes.scalarAttributes[Attribute_Pos].data.clone();
 attributes.scalarAttributes[velocityAttrKey.index].data = emitterAttributes.scalarAttributes[emitterVelocityAttrKey.index].data.clone();
 }
 else {

Size previousSize = attributes.size();
 Size newSize = attributes.size() + emitterAttributes.size();
 attributes.resize(newSize);
 attributes.scalarAttributes[velocityAttrKey.index].incrementVersion();

for(Index i=0; i< emitterAttributes.size(); i++)
 {
 Index emitterIndex = i * 3;
 Index particlesIndex = (i + previousSize) * 3;

attributes.scalarAttributes[Attribute_Pos].data[particlesIndex+0] = emitterAttributes.scalarAttributes[Attribute_Pos].data[emitterIndex+0];
 attributes.scalarAttributes[Attribute_Pos].data[particlesIndex+1] = emitterAttributes.scalarAttributes[Attribute_Pos].data[emitterIndex+1];
 attributes.scalarAttributes[Attribute_Pos].data[particlesIndex+2] = emitterAttributes.scalarAttributes[Attribute_Pos].data[emitterIndex+2];

attributes.scalarAttributes[velocityAttrKey.index].data[particlesIndex+0] = emitterAttributes.scalarAttributes[emitterVelocityAttrKey.index].data[emitterIndex];
 attributes.scalarAttributes[velocityAttrKey.index].data[particlesIndex+1] = emitterAttributes.scalarAttributes[emitterVelocityAttrKey.index].data[emitterIndex+1];
 attributes.scalarAttributes[velocityAttrKey.index].data[particlesIndex+2] = emitterAttributes.scalarAttributes[emitterVelocityAttrKey.index].data[emitterIndex+2];
 }
 }
}

function eulerIntegration_perPoints(
 in Index index,
 in Scalar time,
 in Scalar timestep,
 io ScalarAttribute positionsAttr,
 io ScalarAttribute velocitiesAttr,
 io ScalarAttribute ageAttr,
 in Vec3 force ) {

if(time == 0) {
 ageAttr.setScalarValue(index, 0, 0.0);
 }
 else {
 Vec3 newVelocity = velocitiesAttr.getVec3Value(index * 3) + force * timestep;

Vec3 newPosition = positionsAttr.getVec3Value(index * 3);
 newPosition += newVelocity * timestep;

positionsAttr.setVec3Value(index * 3, newPosition);
 velocitiesAttr.setVec3Value(index * 3, newVelocity);
 Scalar age = ageAttr.getScalarValue(index, 0);
 age+=timestep;
 ageAttr.setScalarValue(index, 0, age);
 }
}

operator SimulatedParticleOp(
 io GeometryAttributes attributes,
 in Scalar time,
 in Scalar timestep,
 in GeometryAttributes emitterAttributes,
 in Vec3 gravity,
 in Vec3 force,
 in Scalar intensity
) {

AttributeKey velocityAttrKey = attributes.getKey("velocities");
 AttributeKey emitterVelocityAttrKey = emitterAttributes.getKey("velocities");

AttributeKey ageAttrKey = attributes.getKey( "age" );
 if( ageAttrKey.type == AttributeType_Invalid )
 ageAttrKey = attributes.addScalarAttribute( "age", 1);

// Scalar initAges[];
 // initAges.resize(attributes.size());
 // attributes.scalarAttributes[ageAttrKey.index].data = initAges;

addPoints( time, attributes, emitterAttributes, velocityAttrKey, emitterVelocityAttrKey);

executeParallel(
 eulerIntegration_perPoints,
 attributes.size,
 time,
 timestep,
 attributes.scalarAttributes[Attribute_Pos],
 attributes.scalarAttributes[velocityAttrKey.index],
 attributes.scalarAttributes[ageAttrKey.index],
 gravity+force.unit()*intensity
 );

}

We finished the description for all the objects needed to created our particle system. Lets build a demo application to test it now !
The CreationPlatformApplication class:
Here is a drawing showing the general structure of a Creation Platform Application:

Those applications let you enable some common services very easily. For our particle simulation demo, we would like an undo-redo system, a timeline, being able to save the scene and to export the particles (using the Alembic exporter). All those feature are enable using keyword arguments in the __init__ function :
class ParticleSystemDemo(CreationPlatformApplication):
 def __init__(self):

 super(ParticleSystemDemo, self).__init__(
 setupGlobalTimeNode=True,
 setupSelection=True,
 cameraPosition=Vec3(19.0,13.0,-4.0),
 cameraTarget=Vec3(0.0,2.0,0.0),
 setupUndoRedo=True,
 timeRange=Vec2(0.0,10.0),
 timeAsSeconds=False,
 setupPersistence=True,
 setupExport=True
 )

Then we can setup the simple particle system:
# build the Particle System
 particles = SimulatedPoints(scene, name='Particles', time=time)
 emitter = DiscEmitter(scene, pointCount=200, time=time)
 force = Force(scene, direction=Vec3(1,0,0), intensity=0)
 particles.addComponent(SimulatedParticleComponent(emitter=emitter, force=force))

To be able to access easily any SceneGraphNodes, another Python object called Scene is used.

It is always required when you instantiate a SceneGraphNode. The scene let you access a node like this : camera = scene.getNode(‘Camera’)
Conclusion
As you can see, we built a Particle Simulation system with just one type of emitter and one type of force – the purpose of this tutorial was to understand key principles first – but it could be a good exercise for the reader to add some other types. Also, we did not deal with multiple emitters/forces referencing. It is not very complex but it was too much to cover in 101 course. We will see how to deal with this problem in a future tutorial.
We hope you enjoy being able to create you own particle system from scratch using Creation Platform. Comments are welcome !
If you’re signed up to our beta, you can get all of the source code for this application on github
]]>
			http://fabricengine.com/2012/10/creation-platform-101-building-a-particle-system-with-creation/feed/
		0
		
		
		
		http://fabricengine.com/2012/10/test/
		http://fabricengine.com/2012/10/test/#comments
		Wed, 17 Oct 2012 17:57:47 +0000
		Paul Doyle
				

		http://fabricengine.com/?p=3259
		
				This series of articles will introduce you to the key concepts behind Creation Platform and step you through the process of building a particle system so that you can see how everything fits together.

Note: This tutorial comes with full source code that can be found here: https://github.com/frenchdog/CreationPlatform101.git
Why use a Dependency Graph ?
The Fabric Core can build a dependency graph (more precisely, a Directed Acyclic Graph). This graph is used to describe the relationships between data and functions (called operators) – Creation maintains a separation between data and the operators on those data, which is an important first concept to understand. The operators are written using Fabric’s high performance Kernel Language (KL), which we will get to later in the article.
Using our example scenario, we will discuss using the dependency graph for working with particles. If you want to move particles using a force, you would define a graph composed of three nodes: a particle node storing the point positions, a time node to store the time step, and a force node. Then you need to specify the dependencies between these nodes. In this example, the particle node is dependent on the time and force nodes.
You may wonder why you should define those dependencies. After all, you could write a python program to move particles, as in this pseudo python code:
force = getClosestNeighborPosition()
particlePosition += force * timeStep

The problem with this code is that it cannot easily be executed in parallel! The force is dependent upon the previous particle neighbour’s position, but we cannot guarantee that this previous position is valid, because another thread may have already updated it. This dependency prevents us from executing in parallel, which results in poor performance – defining dependencies before computing the data is a very important step, since it allows us to execute in parallel. In the Fabric Core, the dependency graph is analyzed at construction-time, and the data is evaluated at run-time. The good news is that a scripting language – like Python – is sufficient for describing the dependency graph, as we are not processing heavy data. In contrast, the function implementations are exclusively written using KL. KL is a simple, high-level language used to write high-performance operators. KL allows developers to keep working with Python, using KL only for the performance critical parts of their application. KL uses a similar syntax to JavaScript, but is optimized for performance.
To glue together the data and the operators, a Python class called Binding is used. The Binding class stores the parameter layout of the operator and is accessible from the node that is storing the required data. You can visualize this binding process as follows:

To build a dependency graph, you always instantiate the following Python classes:  the Dependency Graph Node (DGNode), the Operator, and the Binding.

You will use DGNode methods to add a data member or set a dependency with another node. As a DGNode has a list of all its bindings,  you can add a Binding instance to this list. You can imagine this list as a little operator stack for your DGNode, Binding at index 0 of the list being your first operator and so on.
You use Operator methods to get the KL source code you want to use.
You use Binding methods to get the Operator instance object and define the Parameter Layout. The Parameter Layout describes what data member you want to bind to an operator parameter.

Building a basic particle system:
To be able to access Fabric Core we instantiate a client. This client can create Python instance objects like the DGNode, the Operator and the Binding.
import FabricEngine.Core
FabricCoreClient = FabricEngine.Core.createClient()

We instantiate three DGNodes and define their data members.
particlesNode = FabricCoreClient.DG.createNode('particles')
particlesNode.addMember(name='pointsCount', typeName='Size', defaultValue=100)
particlesNode.addMember(name='positions', typeName='Vec3[]')

timerNode = FabricCoreClient.DG.createNode('timer')
timerNode.addMember(name='frame', typeName='Integer')
timerNode.addMember(name='rate', typeName='Scalar', defaultValue=60.0)

forcesNode = FabricCoreClient.DG.createNode('forces')
forcesNode.addMember(name='gravity', typeName='Vec3', defaultValue=Vec3(0.0, -9.81, 0.0))

In this example we choose to define the particles positions as an array of Vec3. We could instead define a single Vec3 and set the node ‘slice count’ to a number greater than one to enable the core to compute over an array of data (“SIMD – Single Instruction Multiple Data – parallelization”). Using this feature, the parallelism would be implicit and the KL code simplified. However, using arrays instead of slices gives some advantages: you can define the data set you want to execute in parallel in your KL code. I will explain in more detail these two ways to handle parallelism at the end of this article. For the purposes of the example we will use the explicit parallelization using an array of Vec3, as the python code is shorter and more obvious.
Now we connect the timerNode and the forcesNode to the particlesNode. The dependencyName will be used by the Parameter Layout of the Binding object.
particlesNode.setDependency('timer', timerNode)
particlesNode.setDependency('forces', forcesNode)

Next, we instantiate the operator that will generate and simulate our positions. This operator gets the KL code that defines the operator function as a string. Here we are using a python File object and its read() method to access an external KL file. The opened file includes the definition of an operator called ‘ParticleSystem’.
operator = FabricCoreClient.DG.createOperator(name='ParticleSystem')
operator.setEntryPoint('ParticleSystem')
operator.setSourceCode(open('particlesOperators.kl').read())

Now we need to define the relationship between our operator and our data members.

The operator signature in the KL file looks like this :

operator ParticlesGenerator(in Integer frame, in Scalar rate, in Size count, io Vec3 positions[], in Vec3 gravity).

Its first parameter – called ‘frame’ – will use the eponymous data member of the timerNode and so on.
binding = FabricCoreClient.DG.createBinding()
binding.setOperator(operator)
binding.setParameterLayout([
  'timer.frame',
  'timer.rate',
  'self.pointsCount',
  'self.positions',
  'forces.gravity'
])

In the Parameter Layout we can use ‘self’ to refer to the node that references the Binding object, that is, the particleNode.

We can use ‘timer’ or ‘forces’ to refer to the timerNode or forcesNode because they are connected to the particleNode.

If you create a dependency called ‘forces2′, then the binding can bind using that binding name, plus the member names. E.g. ‘forces2.gravity’.

To reference the binding we add it to the node bindings list:
particlesNode.bindings.append(binding)
Our dependency graph is finished! We could run the python code and it would compile the graph, but it wouldn`t evaluate it. This is because we didn’t tell the Core which node we would like to evaluate. We need to add a final part that will run our particle simulation:
# Simulate 100 frames
for i in range(0, 100):
 timerNode.setData('frame', i)
 particlesNode.evaluate()
 print 'At frame: {0}, first particle position is: {1}'.format(i, particlesNode.getData('positions')[0])

The dependency graph is used to define how dirtiness propagates through the graph. We can make a change to a single node, and make many nodes dirty.

if you didn’t change the time value, the subsequent calls to ‘evaluate’ would not do anything, because once the node is ‘clean’ it will not re-evaluate. This the a key concept to the ‘lazy’ evaluation system. Only nodes that are dirty will be evaluated and cleaned.
Here is the KL code that is run each frame:
use Vec3, FabricMath;
const Scalar TIMESTEP = 0.01;

function setRandomPosition_perParticle(Size index, Integer offset, io Vec3 positions[])
{
    positions[index].x = mathRandomScalar(index, offset);
    positions[index].y = 10;
    positions[index].z = mathRandomScalar(index, offset + 20);
}

function applyForces_perParticle(Size index, Vec3 gravity, io Vec3 positions[])
{
  positions[index] += gravity * TIMESTEP;
}

operator ParticleSystem(Integer frame, Scalar rate, Size count, io Vec3 positions[], Vec3 gravity)
{
  if(frame == 0)
  {
    positions.resize(count);
    executeParallel( setRandomPosition_perParticle, positions.size, frame, positions );
  }
  executeParallel( applyForces_perParticle, positions.size, gravity, positions );
}

We use ‘executeParallel()’ to call the same function on every element of our positions array.
Running the python code gives this output:
At frame: 0 [MT:particles:ParticleSystem] First particle position: {x:+0.465661e-9,y:+9.901900,z:+0.255708}

At frame: 1 [MT:particles:ParticleSystem] First particle position: {x:+0.465661e-9,y:+9.803800,z:+0.255708}

…

…

 At frame: 98 [MT:particles:ParticleSystem] First particle position: {x:+0.465661e-9,y:+0.288099,z:+0.255708}

At frame: 99 [MT:particles:ParticleSystem] First particle position: {x:+0.465661e-9,y:+0.189999,z:+0.255708} 
Particles are falling down! It is not the most impressive particle simulation :), but we hope it helps you to understand the Core Dependency Graph. Here are the links to the full source code:
Python code for array version
KL code for array version (using executeParallel)
Slicing nodes or executeParallel ?
When we instantiated our first DGNodes, we explained that we could use two different approaches for parallel execution. An implicit one called ‘slicing’, and an explicit one using the function ‘executeParallel’. The slicing idea gives the same parallel execution for all the data members of a single DGNode. You specify a number of slices for the node and all of its members share a common array structure. In this KL example, every element in the sliced array (defined using “<>”) will be evaluated in parallel.
operator SlicedOp(Index index, Vec3 positions<>, in Vec3 gravity)
{
  positions[index] += gravity;
}

From this code snippet, it might seem that slicing is more elegant than explicit parallelism. However, there are many cases where we would like to use a more explicit system. One reason could be to simplify the dependency graph. Here is a comparison on our simple particle simulation. Using explicit parallel the dependency graph is as follows:

And using slicing:

As you can see, we need one more node for the sliced version. The reason, is by slicing a node, we say that the dimension(slice count) of the node defines the dimension of the data. The size of the positions array becomes implicit in the slice count of the node. The ‘pointsCount’ is a value of a different dimension, and so can’t be stored in the sliced node along with the positions. Often we want to combine together data sets of different dimensions, and so slicing becomes too restrictive.

Another advantage of the explicit parallelism is that we can use several executeParallel functions on different arrays of data. Imagine that we want to emit our particles every frame. In this case we must set the initial positions only on the created one, and apply the forces on every one. It can be tricky to do using sliced arrays! Using parallelExecute it is very easy:
Vec3 newPositions[];
newPositions.resize(count);
executeParallel( setInitialPosition_perPoint, newPositions.size, newPositions );

for(Index i=0; i< newPositions.size; i++)
{
 positions.push(newPositions[i]);
}

executeParallel( applyForces_perPoint, positions.size, positions );

But slicing can also be combined with executeParallel ! In this case it can be very useful as you can use it to define instancing. You can easily take your particle system defined using execute parallel and Vec3[] positions, and create 30 different particles systems, by simply increasing the count of the node. Imagine for example, you were building chimney smoke simulation, and then you wanted 100 different chimneys in a village to emit smoke. You can do this easily using a single node, that contains a particle system on each slice, and 100 different slices! You can find more explanation on slicing in this article.
To complete this first part, here is the source code for the sliced version of our particle simualtion: Python code for sliced node version and  KL code for sliced node
Part2 Building a Particle System with Creation Platform
]]>
			http://fabricengine.com/2012/10/test/feed/
		0