Minor improvements to chapter 3 about anari-docs HOT 4 CLOSED

Addressing some of your points:

• We considered supporting double precision data everywhere (vertex positions, transformation matrices, ...), currently only the structuredRegular spatial field supports double data). Broader support will very likely come as an extension. The issue right now is that we are not aware of a renderer supporting this and thus did not want to require double precision support in the core specification. If you are aware of an potential implementation, please contact us that we can specify and verify such an extension together.
• attributes:
  • the reference to volumes is a remnant of an intermediate version of the spec, please disregard
  • Sec 3.12 lists which attributes are known to ANARI, e.g. the allowed names for inAttribute of samplers
  • Specification of attributes by the user happens via geometries (Sec 6.1), in whatever format the geometry supports. For example, vertex.color can get set as UFIXED8_VEC4.
  • Similar to a vertex shader, the attributes of Sec 3.12 are then implicitly (e.g. for worldPosition) or explicitly (for e.g. color if set) forwarded to the "fragment shader", which implements materials and samplers; the internal format of those temporary "variables" is listed in the table. (I'm using shading language terms here, how this actually happens is up to the implementation, the specific ANARI backend)
• library initialization: right, this is the interface towards the backend (see ANARI-SDK), not to the user / application using ANARI.
• Thanks for the hint on broken Table 7 and on commit, will be fixed soon.

from anari-docs.

Thanks!

• double precision data - I very agree with making it only an extension. No need to support it in every library or device. Me, personally, never had time to implement double precision rendering. I went only as far as gathering knowledge about it, unfortunately.
• attributes - thanks for your sentence "the allowed names for inAttribute of samplers" - at the moment of reading of this I started to understand the meaning of Anari attributes! So it is not truly the attribute in the sense of OpenGL or Vulkan (input of vertex shaders). It is rather input of samplers, so it is rather value passed from vertex shader to fragment shader - if we use the terminology of mentioned APIs. Surely, I understand that Anari is general enough and might use raytracing, radiosity,... so spec should not use OpenGL or Vulkan language or terminology. So, thanks for explaining - now I understand the meaning of Anari attributes.

So, with your answer, we can close 5 points. Three points remains, all related to arrays. Let me append one more point to this question of nulls in arrays of handles that was actually preparation for this question:

• effective handling of children - we often need to quickly append or remove nodes from the scene graph: during the construction, during appending new parts of the model, during visibility changes, LOD detail switches, during delete operations and close model operations, for instance. Once again, we are often dealing with thousands or even millions of objects. Especially this LOD operations over large models might be troublesome - for instance, to remove one object and insert four others that together represent bigger detail. When we consider the scene of 10 million boxes, the current design would result in allocating new Array1D of 10'000'003 items (e.g. ~80MB), mapping of old and new array, copying the whole content, updating four new values and unmapping the whole array. All this would probably include the whole process of updating reference counters, that would probably be the biggest overhead. In summary, all this seems quite expensive on big arrays. To append single Anari::Instance into such a large scene would involve not only copying of megabytes of data, but incrementing and decrementing of millions of reference counters. For a kind of performance extension, I would very like to use a kind of more effective approach, such as something like appendChildren() and removeChildren() interface. The exact interface can be discussed to best fit all needs, but I would be a big friend of such an extension. It is true that your current design really brings the simplicity. However, having such performance extension would remove possibly big overhead on already middle sized dynamically changing scenes.

from anari-docs.

The only place where a NULL handle is allowed is for anariRelease, not in handle arrays. I see your point with millions of objects/instances in the world (also raised in #1). ANARI can deal with huge amounts of data, but millions of objects are a weak point. We considered something similar to your idea with appendChildren() and removeChildren(), but put that on hold until we have a better understanding about the consequences. Also note that only few implementations will be able to handle millions of changing individual objects in real time; for example, ray tracing based renderers need to build an acceleration structure, which will take a second or so for million objects.

Maybe there is still a misunderstanding about the concepts and nature of ANARI. ANARI is a high-level API, it's object hierarchy with World, Instance, Geometries/Volumes is almost that of a scenegraph. The World should only change if the scene changes, e.g., due to animation, but not for different camera positions; i.e. LOD should be transparently handled within the ANARI implementation, not by the application using ANARI.

One way to deal with many objects is (hierarchical) aggregation, which is (partly) supported by ANARI: primitives (triangles, spheres, ..., but as potential extension also boxes, see for example OSPRay's box geometry) are gathered in geometry objects, which in turn can be instanced many times. Right now, ANARI only allows for single-level instancing, but a potential extension could be multi-level instancing – a proven technique used by the VFX industry to efficiently handle scenes with billions of objects. BTW: In the example case you describe the application scenegraph also needs to deal with millions of objects, which I think is only efficiently possible in a hierarchical manner, too.

Another avenue could be adding an enable flag to objects to be able to quickly toggle visibility of them.

For the shared and managed arrays we want to include flowcharts to better describe the object life cycles, but your understanding and interpretation is correct.

from anari-docs.

Thanks! I am very happy that your team is aware of this appendChildren() and removeChildren() problem. I am aware that this so simple looking problem is actually quite complicated and far from trivial. The effective implementation is quite a piece of work. One tends to use std::find to find handles in the array that we are going to remove, but this might be painfully slow already on middle sized scenes. Effective removal needs to introduce parent list in the internal implementation and, once again, the temptation to use std::find is big. But full parent-child implementation with constant append+remove complexity is reachable.

Anyway, I see your point that raytracing implementations might not benefit from these fast changes to the scene graph structure because of these acceleration structures that need to be rebuilt. So, this will be of benefit just of some implementations.

Thanks for pointing out this LOD - you are very right. I was too long among traditional scene graphs and your comment emphasized me once again that Anari is a little different. LOD is really something of internal implementation. Anyway, it served just as an example that the user might have reasons to append and remove scene objects through the life time of the application. I am happy that you consider effective means of changing the scene structure.

With this aggregation, you are right. This could be one solution. I understand it in a way that there would not be millions of Anari::instances but millions of triangles baked in one Geometry::Triangles. One of limitations here is that it is limited just to the objects sharing the same material. Another disadvantage is that appending new instances of particular object that is baked in Geometry::Triangles would probably result in multiple copies of all its indices inside Geometry::Triangles::primitive.index . Surely, you can build sophisticated algorithms that would decide if we create new Anari::Instance or if we append new indices into Geometry::Triangles, but is it not the task for particular Anari implementation to decide if it would bake or aggregate objects together or keep them as multiple instances of the same geometry? Particular implementation knows its performance characteristics, so the implementation should decide, in my opinion. Now, how to embody this principle into Anari API?

In my opinion, Geometry shall be allowed to carry anything from the simplest object (f.ex. one triangle) to something as large as the whole scene. It should be the user's decision how he wants to organize his scene. Any recommendations here, although it might exist for serious reasons, should be limited to minimum IMHO, because each implementation has different preferences, different "optimal" object size, etc. Implementation should optimize the data and build optimal acceleration or rendering structures on its own and not try to put restrictions on Anari API, if possible. My opinion, but I might not see everything.

My point was that particular Anari implementation should be implemented to handle with decent efficiency many (or most of) applications. It is not an application that shall adjust to the particular Anari implementation, but rather Anari implementation that should be adjusted to most of the applications that might use it. Or is the idea of your team different? Surely, I do not mean it as a strict rule, but rather as an idea that is pursued.

Concerning single and multiple level instancing - I was intending to open this as separate issue. So, we can leave it for now.

Thanks for this shared and managed arrays - I am sure that any of my remaining doubts will be answered in the updated spec in the future, so no need to waste time with it any more.

from anari-docs.