@@ -230,7 +230,7 @@ counting for lifetime determination. Objects are created with particular type's
230
230
231
231
In general, modifiable parameters to objects are modified using ` vklSet... `
232
232
functions based on the type of the parameter being set. The parameter name is
233
- passed as a string. Below are all variants of ` vklSet... ` .
233
+ passed as a string. Below are variants of ` vklSet... ` .
234
234
235
235
void vklSetBool(VKLObject object, const char *name, int b);
236
236
void vklSetFloat(VKLObject object, const char *name, float x);
@@ -241,6 +241,19 @@ passed as a string. Below are all variants of `vklSet...`.
241
241
void vklSetString(VKLObject object, const char *name, const char *s);
242
242
void vklSetVoidPtr(VKLObject object, const char *name, void *v);
243
243
244
+ A more generic parameter setter is also available, which allows setting
245
+ parameters beyond the explicit types above:
246
+
247
+ void vklSetParam(VKLObject object,
248
+ const char *name,
249
+ VKLDataType dataType,
250
+ const void *mem);
251
+
252
+ Note that ` mem ` must always be a pointer _ to_ the object, otherwise accidental
253
+ type casting can occur. This is especially true for pointer types
254
+ (` VKL_VOID_PTR ` and ` VKLObject ` handles), as they will implicitly cast to `void\
255
+ * `, but be incorrectly interpreted.
256
+
244
257
After parameters have been set, ` vklCommit ` must be called on the object to make
245
258
them take effect.
246
259
@@ -427,11 +440,12 @@ Finally, the value range of the volume for a given attribute can be queried:
427
440
### Structured Volumes
428
441
429
442
Structured volumes only need to store the values of the samples, because their
430
- addresses in memory can be easily computed from a 3D position. The dimensions
431
- for all structured volume types are in units of vertices, not cells. For
432
- example, a volume with dimensions $(x, y, z)$ will have $(x-1, y-1, z-1)$ cells
433
- in each dimension. Voxel data provided is assumed vertex-centered, so $x* y* z$
434
- values must be provided.
443
+ addresses in memory can be easily computed from a 3D position. Data can be
444
+ provided either per cell or per vertex (the default), selectable via the
445
+ ` cellCentered ` parameter. This parameter also affects the interpretation of
446
+ the volume's dimensions, which will be in units of cells or vertices,
447
+ respectively. A volume with $(x, y, z)$ vertices will have $(x-1, y-1, z-1)$
448
+ cells.
435
449
436
450
#### Structured Regular Volumes
437
451
@@ -443,10 +457,10 @@ table below.
443
457
--------- -------------------------------- ----------------------------- ---------------------------------------
444
458
Type Name Default Description
445
459
--------- -------------------------------- ----------------------------- ---------------------------------------
446
- vec3i dimensions number of voxels in each
460
+ vec3i dimensions number of values in each
447
461
dimension $(x, y, z)$
448
462
449
- VKLData data VKLData object(s) of voxel data,
463
+ VKLData data VKLData object(s) of volume data,
450
464
VKLData[ ] supported types are:
451
465
452
466
`VKL_UCHAR`
@@ -465,10 +479,27 @@ table below.
465
479
through passing an array of VKLData
466
480
objects.
467
481
482
+ bool cellCentered false indicates if data is provided per cell
483
+ (true) or per vertex (false)
484
+
468
485
vec3f gridOrigin $(0, 0, 0)$ origin of the grid in object space
469
486
470
487
vec3f gridSpacing $(1, 1, 1)$ size of the grid cells in object space
471
488
489
+ affine3f indexToObject 1, 0, 0, Defines the transformation from index
490
+ 0, 1, 0, space to object space. In index space,
491
+ 0, 0, 1, the grid is an axis-aligned regular
492
+ 0, 0, 0 grid, and grid cells have size (1,1,1).
493
+ This parameter takes precedence over
494
+ ` gridOrigin ` and ` gridSpacing ` , if
495
+ provided.
496
+
497
+ vec3i indexOrigin $(0, 0, 0)$ Defines the index space origin of the
498
+ volume. This translation is applied
499
+ before any (` gridOrigin ` ,
500
+ ` gridSpacing ` ) or ` indexToObject `
501
+ transformation.
502
+
472
503
uint32 temporalFormat ` VKL_TEMPORAL_FORMAT_CONSTANT ` The temporal format for this volume.
473
504
Use ` VKLTemporalFormat ` for named
474
505
constants.
@@ -537,7 +568,8 @@ Structured spherical volumes are also supported, which are created by passing a
537
568
type string of ` "structuredSpherical" ` to ` vklNewVolume ` . The grid dimensions
538
569
and parameters are defined in terms of radial distance ($r$), inclination angle
539
570
($\theta$), and azimuthal angle ($\phi$), conforming with the ISO convention for
540
- spherical coordinate systems. The coordinate system and parameters understood by
571
+ spherical coordinate systems. Structured spherical volumes currently only
572
+ support vertex-centered data. The coordinate system and parameters understood by
541
573
structured spherical volumes are summarized below.
542
574
543
575
![ Structured spherical volume coordinate system: radial distance ($r$), inclination angle ($\theta$), and azimuthal angle ($\phi$).] [ imgStructuredSphericalCoords ]
@@ -807,9 +839,9 @@ VDB leaf nodes are implicit in Open VKL: they are stored as pointers to user-pro
807
839
808
840
![ Structure of ` "vdb" ` volumes in the default configuration] [ imgVdbStructure ]
809
841
810
- VDB volumes interpret input data as constant cells (which are then potentially filtered).
811
- This is in contrast to ` structuredRegular ` volumes, which have a vertex-centered
812
- interpretation.
842
+ VDB volumes interpret input data as constant cells (which are then potentially
843
+ filtered). This is in contrast to ` structuredRegular ` volumes, which can have
844
+ either a vertex-centered or cell-centered interpretation.
813
845
814
846
The VDB implementation in Open VKL follows the following goals:
815
847
@@ -826,15 +858,16 @@ following parameters:
826
858
------------ ------------------------------------- ------------------------------ ---------------------------------------
827
859
Type Name Default Description
828
860
------------ ------------------------------------- ------------------------------ ---------------------------------------
829
- float[ ] indexToObject 1, 0, 0, An array of 12 values of type ` float `
830
- 0, 1, 0, that define the transformation from
831
- 0, 0, 1, index space to object space.
832
- 0, 0, 0 In index space, the grid is an
833
- axis-aligned regular grid, and leaf
834
- voxels have size (1,1,1).
835
- The first 9 values are interpreted
836
- as a row-major linear transformation
837
- matrix. The last 3 values are the
861
+ affine3f indexToObject 1, 0, 0, Defines the transformation from index
862
+ float[ ] 0, 1, 0, space to object space. In index space,
863
+ 0, 0, 1, the grid is an axis-aligned regular
864
+ 0, 0, 0 grid, and leaf voxels have size (1,1,1).
865
+ A ` vkl_affine3f ` can be provided;
866
+ alternatively an array of 12 values of
867
+ type ` float ` can be used, where the
868
+ first 9 values are interpreted as a
869
+ row-major linear transformation matrix,
870
+ and the last 3 values are the
838
871
translation of the grid origin.
839
872
840
873
uint32[ ] node.format For each input node, the data format.
@@ -898,6 +931,14 @@ following parameters:
898
931
float[ ] background ` VKL_BACKGROUND_UNDEFINED ` For each attribute, the value that is
899
932
returned when sampling an undefined
900
933
region outside the volume domain.
934
+
935
+ box3i indexClippingBounds Clips the volume to the specified
936
+ index-space bounding box. This is
937
+ useful for volumes with dimensions that
938
+ are not even multiples of the leaf node
939
+ dimensions, or .vdb files with
940
+ restrictive active voxel bounding
941
+ boxes.
901
942
------------ ------------------------------------- ------------------------------ ---------------------------------------
902
943
: Configuration parameters for VDB (` "vdb" ` ) volumes.
903
944
@@ -1033,6 +1074,9 @@ radial basis function phi, for each particle that overlaps it. Gradients are
1033
1074
similarly computed, based on the summed analytical contributions of each
1034
1075
contributing particle.
1035
1076
1077
+ Particles with a radius less than or equal to zero are ignored. At least one
1078
+ valid particle (radius greater than zero) must be provided.
1079
+
1036
1080
The Open VKL implementation is similar to direct evaluation of samples in Reda
1037
1081
et al.[ 2] . It uses an Embree-built BVH with a custom traversal, similar to the
1038
1082
method in [ 1] .
0 commit comments