|
# Octree Requirements
|
|
The current design allows for multiple representations. The primary being a set of frames that represents a 3D point cloud using a collection of 2D arrays of points. This representation is maintained up to the point of virtual view rendering. Other plausible representations include mesh models or F-Rep, but it is only at the rendering stage that these are combined. Each kind of scene would have a different renderer and scenes would be merged by compositing the different renders.
|
|
|
|
|
|
|
|
# Old Designs
|
|
|
|
Previously we considered a common representation.
|
|
|
|
|
|
|
|
## Octree Requirements
|
|
* Fixed attributes or functionally computed attributes
|
|
* Fixed attributes or functionally computed attributes
|
|
* Any number of attributes but at least the following:
|
|
* Any number of attributes but at least the following:
|
|
* RGB Colour
|
|
* RGB Colour
|
... | @@ -12,7 +17,7 @@ Cache coherence must be considered for both GPU and CPU context. It must also be |
... | @@ -12,7 +17,7 @@ Cache coherence must be considered for both GPU and CPU context. It must also be |
|
|
|
|
|
The ability to limit the number of levels traversed to lower the level-of-detail and enable compression should also be possible. This means that approximations of attributes need to be stored at parent nodes or computed from the parents center point. Another option is to store the levels with occupancy information only and only keep attribute data in the parents.
|
|
The ability to limit the number of levels traversed to lower the level-of-detail and enable compression should also be possible. This means that approximations of attributes need to be stored at parent nodes or computed from the parents center point. Another option is to store the levels with occupancy information only and only keep attribute data in the parents.
|
|
|
|
|
|
# Octree Design Ideas
|
|
## Octree Design Ideas
|
|
* Store the attributes separately for each type of attribute, still attempting to maintain cache coherence during usual lookup operations. For example, baked RGB should be in one memory block, computed RGB equations in another, normals in another, object classifications in another. Any block can then be excluded from a data stream.
|
|
* Store the attributes separately for each type of attribute, still attempting to maintain cache coherence during usual lookup operations. For example, baked RGB should be in one memory block, computed RGB equations in another, normals in another, object classifications in another. Any block can then be excluded from a data stream.
|
|
|
|
|
|
* Not all attributes may be available for each octree node so a list of attributes is required. Could be a 64 or 128 bit set of flags to indicate existence of attributes. All zero would mean the node is empty.
|
|
* Not all attributes may be available for each octree node so a list of attributes is required. Could be a 64 or 128 bit set of flags to indicate existence of attributes. All zero would mean the node is empty.
|
... | @@ -29,10 +34,10 @@ The ability to limit the number of levels traversed to lower the level-of-detail |
... | @@ -29,10 +34,10 @@ The ability to limit the number of levels traversed to lower the level-of-detail |
|
|
|
|
|
* Support octree union, this can be done in f-rep style.
|
|
* Support octree union, this can be done in f-rep style.
|
|
|
|
|
|
# Non-Octree Options
|
|
## Non-Octree Options
|
|
Store points relative to some approximate geometric representation as a distortion map similar to bump mapping. This however requires a good geometric representation (or f-rep).
|
|
Store points relative to some approximate geometric representation as a distortion map similar to bump mapping. This however requires a good geometric representation (or f-rep).
|
|
|
|
|
|
# Scene Interface
|
|
## Scene Interface
|
|
What observations and actions need to be taken with a scene object?
|
|
What observations and actions need to be taken with a scene object?
|
|
|
|
|
|
* Set or replace voxel data and attribute maps
|
|
* Set or replace voxel data and attribute maps
|
... | | ... | |