Resolves #69 Added 2D transfer function support and updated Volume object type #75
Conversation
griffin28
changed the title
| @@ -53,6 +53,15 @@ Feature support information can be queried as properties on the `ANARIRenderer` | |||
| |=================================================================================================== | |||
|
|
|||
|
|
|||
| Feature: `KHR_RENDERER_VOLUME_METHOD` | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yes, that will work also.
| @@ -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 | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Working group decided (4/26/2023) to stick with the current design but change the subtype name to better reflect the type of volume and avoid confusion and perceived connection to Renderer subtypes. |
Resolves #69. Added 2D transfer function support and updated Volume object type by removing subtype as it really isn't needed similar to how subtype is not needed for the Surface object type.
Also added a feature to the Renderer for explicitly specifying the volume rendering method.