Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolves #69 Added 2D transfer function support and updated Volume object type #75

Closed
wants to merge 2 commits into from
Closed

Resolves #69 Added 2D transfer function support and updated Volume object type #75

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
97c5d6a
Resolves #69 add 2D transfer functions and update Volume object type
griffin28 Apr 25, 2023
0440476
Fixed incorrect array type for gradient
griffin28 Apr 25, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions chapters/object_types.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,15 @@ Feature support information can be queried as properties on the `ANARIRenderer`
|===================================================================================================


Feature: `KHR_RENDERER_VOLUME_METHOD`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this could be multiple extensions one per method all of which interact with this parameter? That way the availability of the method can be queried as a feature while introducing the ability to select it in case of multiple options.

KHR_RENDERER_VOLUME_METHOD_RAYCAST, KHR_RENDERER_VOLUME_METHOD_SPLAT etc.
All of which define new values for the method parameter but none specify a default. In case the parameter is not set the choice is up to the implementation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that will work also.


.Parameters understood by renderers with feature `KHR_RENDERER_VOLUME_METHOD`.
[cols="<,<,>,<3",options="header,unbreakable"]
|===================================================================================================
| Name | Type | Default | Description
| method |`STRING`| raycast | the volume rendering technique, possible values: raycast, splatting, shear-warp, texture
|===================================================================================================

Feature: `KHR_RENDERER_BACKGROUND_COLOR`

.Parameters understood by renderers with feature `KHR_RENDERER_BACKGROUND_COLOR`.
Expand Down
30 changes: 18 additions & 12 deletions chapters/object_types/volumes.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,23 +6,17 @@
=== Volume

Volumes in ANARI represent volumetric objects (complementing <<Surface,
surfaces>>), encapsulating spatial data as well as appearance information. To
create a new volume object of given subtype `subtype` use
surfaces>>) and take a <<object_types_spatial_field, SpatialField>> which defines the
spatial representation. The <<Renderer, renderer>> defines the volume rendering method used for
the volume (e.g., ray casting/marching, splatting, shear warp, texture/image-based).
Volumes are created with

[source,cpp]
....
ANARIVolume anariNewVolume(ANARIDevice, const char *subtype);
ANARIVolume anariNewVolume(ANARIDevice);
....

[[object_types_volume_scivis]]
==== Scivis

Feature: `KHR_VOLUME_SCIVIS`

The scivis volume is created by passing the subtype string `scivis` to
`anariNewVolume`. It supports the folowing parameter:

.Parameters understood by the scivis volume.
.Parameters understood by Volume.
[cols="<3,<3,>2,<9",options="header,unbreakable"]
|===================================================================================================
| Name | Type | Default | Description
Expand All @@ -34,6 +28,7 @@ The scivis volume is created by passing the subtype string `scivis` to
| opacity.position |`ARRAY1D` of `FLOAT32`| | optional array to position the elements of `opacity` values in `valueRange`
| densityScale |`FLOAT32` | 1 | makes volumes uniformly thinner or thicker
| id |`UINT32` | -1u | optional user Id, for <<object_types_frame>> channel `objectId`
| material |`MATERIAL` | | optional <<object_types_material>> to handle volumetric effects like scattering
Copy link
Collaborator

@progschj progschj Apr 26, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this interacts with the material system which implicitly interacts with the sampler concepts, it would make sense to treat the transfer functions as a sampler type. Current samplers can already express the transfer function functionality for the equally spaced case via image1D with a transforms encoding the range and density scale.

While materials (or a material-like volume equivalent) interact with volumes the transfer function parameters seem a bit out of place on the "anonymized" volume object.

The fully symmetric design to the surface API would be to have the volume as a "container" type that just pairs up spatial fields (or an array thereof representing different "attributes") with a material. The material would then encode shader types along the lines of "integratedDensity", "scatteringMedium", "emissiveMedium" etc.

The role of the transfer function would be taken up by samplers which could interact with volume attributes like attribute0 etc. for the regular channels from the structured field but also gradient0 etc. for derived quantities.

Copy link
Collaborator Author

@griffin28 griffin28 Apr 26, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. Your suggestion in my opinion gets us closer to a better design for volumes. Also, having it more symmetric with the surface API makes the spec more intuitive.

For Surfaces we have a Geometry for the spatial representation and Material to specify appearance. With Volumes we currently have SpatialField for the spatial representation but the parameters to specify appearance are exposed under a subtype. Your suggestion will basically take that exposed appearance information that we are currently putting under a subtype and encapsulating them in a volume Material object.

This design will have the top-level Volume object represented by a SpatialField for spatial representation and a volume Material that has all of the volume appearance information which includes transfer functions.

|===================================================================================================

The `color` and the `opacity` array map values sampled in `field`
Expand Down Expand Up @@ -61,3 +56,14 @@ representing the color/opacity of the lowest value in `valueRange`, and
the last element representing the color/opacity of the last element in
`valueRange`.

Feature: `KHR_VOLUME_TF2D`: The 2D transfer function look-up table defined by `tf2d` uses field
values for the columns and gradient magnitude for the rows.

.Additional parameters accepted by the volume with feature `KHR_VOLUME_TF2D`.
[cols="<3,<3,>2,<9",options="header,unbreakable"]
|===================================================================================================
| Name | Type | Default | Description
| gradient |`ARRAY1D` of `FLOAT32_VEC2` | | optional array to map gradient magnitude to an opacity multiplier
| tf2d |`Sampler` with subtype `image2D` | | optional 2D image sampler for defining the 2D transfer function look-up table
|===================================================================================================