ANARI 1.0 Provisional Specification typos and missing info about anari-docs HOT 2 CLOSED

Thanks for the feedback! Some of the issues have already been reported (and #6) and fixed (plus #12), but we indeed need to update the documents in https://github.com/KhronosGroup/ANARI-Registry/blob/main/specs/1.0-provisional/ to reflect those changes.

I'll add ANARI_SPATIAL_FIELD.

Is it expected or useful to use anariGetObjectParameters for objects without subtype – their parameters are known per spec? Then using NULL for objectSubtype could be an option, otherwise we could disallow the call for those object types (similarly as for anariGetObjectSubtypes).

The parameter introspection indeed has gaps: for non-trivial (nested) types like you describe and also for type aliases (when different types with the same name are allowed). We have some ideas for the latter, but generically supporting the first is hard.

from anari-docs.

Oh, I missed this repository so I didn't know about the ones that have already been fixed. Oops.

In my opinion/use case, I think it's useful to have anariGetObjectParameters work for objects without subtypes. I specifically want to be able to enumerate the entire API so I can do some code generation on my side. My reasoning is that there are already some parts of the spec that aren't fully implemented in the example library/device (for example, lights) so going through the introspection methods means that I'll always get the most up-to-date information for the current library.

from anari-docs.