-
Notifications
You must be signed in to change notification settings - Fork 7
Asset trees
The set of objects (shapes) and the transformations applied to those objects are stored in a tree. The @tree methods are part of the ISET3d distribution.
The tree representing a scene has four types of nodes (see piAssetCreate). The two most important are
- object - Represents the data in a shape, such as a car
- branch - Represents the transforms that will be applied to everything below this node
We also include two special types of nodes
- light - Yes, it represents information about a light source
- marker - A world coordinate we want to remember; usually to store a useful camera position
We use the methods in @tree to modify and search through the assets.
Asset trees all start with a root node that is just a reliable placeholder.
The object nodes are the leafs of the tree - there are no nodes below an object. The parent node of an object node is a 'branch node' that describes the geometric transform that will be applied to the object. (See the asset transform page.)
The tree structure in the assets slot is simple, consisting of two cell arrays. Here is a very simple asset tree.
>> thisR.assets
ans =
tree with properties:
Node: {3×1 cell}
Parent: [3×1 double]
The @tree class assigns each Node an ID, which is simply the index of the node in the tree. This tree has three nodes; each has a Parent. The Parent is an integer that is the ID of its parent node.
We illustrate examples of asset trees in this page.
Nodes in the tree have names. ISET3d uses a naming convention for the nodes.
A branch node that contains the transforms will have a name like this
XXXXID_nodeName_B
The name has four digits (e.g., 0031) followed by the string 'ID'. The four digits are the node number in the @tree.
Following the underscore, the nodeName tells us something about the object that is the target of the transforms. The '_B' at the end indicates that this is a branch node, not a leaf of the tree (object node). The redundancy encoded in the naming makes our lives as programmers simpler, though it is not something we are proud of.
Object nodes represent the shapes and materials. They are the leafs of the tree. They have this format
XXXXID_YYY_nodeName_O
The four digits and 'ID' are the same as for branches. The object nodes have an extra three-digit number (YYY) that describes how this shape might be part of a bigger object. For example, a branch might contain several objects that are all part of a car (tire, windshield, trunk ...). The YYY_nodeName part of the name might look like this
001_fordCar, 002_fordCar, 003_fordCar ...
A branch node that transforms all of these parts might have the name 0012ID_fordCar_B. This convention arises because of the way we are working with Blender.
Once you read assets into an ISET3d @recipe, it is possible to rename the object nodes. You must preserve the ID, but you can change the (YYY_nodeName) part to be anything.
Lights and marker nodes are also leaves of the three.
You can see the slots in a node struct by running piAssetCreate. For example
>> piAssetCreate('type','branch')
ans =
struct with fields:
type: 'branch'
name: 'branch'
size: [1×1 struct]
scale: [1 1 1]
translation: [0 0 0]
rotation: [4×3 double]
concattransform: []
motion: []
>>
Or
>> piAssetCreate('type','object')
ans =
struct with fields:
type: 'object'
name: 'object'
mediumInterface: []
material: []
shape: []
index: []
>>
This is a special construct that we use in combination with Blender.
When we are designing a scene in Blender, we place a Blender marker (hence the name) at positions we want to remember, say for later viewing the scene. Blender exports these markers, and we read the marker positions and put them in the asset tree using piRead(). We can later find these positions and place the PBRT camera there to render.
>> piAssetCreate('type','marker')
ans =
struct with fields:
type: 'marker'
name: 'marker'
size: [1×1 struct]
scale: [1 1 1]
translation: [0 0 0]
rotation: [4×3 double]
concattransform: []
motion: []
>>
On to Asset transforms.
ISET3d development is led by Brian Wandell's Vistalab group at Stanford University and supported by contributors from other research institutions and industry.
- Introduction
- Installation
- Workflow
- Camera
- Assets
- Materials Overview
- Textures
- Lights
- Rendering
- Scene data
- Programming overview
- [General Notes on moving to v4]
- Dockerized pbrt-v4 on the GPU