articulation of policy on channel 0

If channel 0 is not configured using AddChannel() upon startup, GVDB crashes. So, channel 0 must exist for GVDB to run properly; however, I cannot write data to channel 0. Yet when a transfer function is used, the rendering shows variation in channel 0 (assuming that is the only channel used as input to the transfer function…this is an open question in another thread).

  1. So, where is the data for channel 0 coming from, if I am not able to write to it? The answer has to be that channel 0 is being used by GVDB and GVDB only.

  2. If that is the case, why does GVDB not own this channel completely and AddChannel() itself? Why do I have to call AddChannel() on a channel I cannot access?

  3. And, I do not understand what kind of density is in channel 0. Is this the number of sample points that fall within a given voxel? Is it some kind of density accumulation? What is GVDB’s definition of density?

Basically, GVDB gets mad at me if I don’t declare channel 0. When I do declare that channel, GVDB becomes a ball hog. So much so that I never get to play. Instead, I have to play with a different ball (channel 1)…a ball that GVDB couldn’t care less about. GVDB is a very spoiled kid. Maybe, because he’s 1 version old. His parents need to hug him more or something.


Hi Notzeus,

  1. Where is the data for channel 0 coming from, if I am not able to write to it?

You should be able to write to it. It depends on how you would like to do this. When using functions such as SurfaceVoxelizeGL, that will create both a topology and populate data. When using modify operations with gvdb.Compute, that assumes you already have data there. When using ScatterPointDensity, that assumes the topology is already activated, and will write data into the channel #0. If you use a custom ComputeKernel, then you should be able to read and write whatever you want.

  1. Why do I have to call AddChannel() on a channel I cannot access?

As per #1, you should be able to access it. Note that requiring that channel #0 is T_FLOAT is only a current limitation with GVDB 1.0. The reason for AddChannel is that the API has the flexibility to define the any type for any channel, to leave room for multiple channels and types in the future.

  1. The concept of ‘density’ here refers to the notion of a volume as a “semi-transparent medium” through which light can be absorbed or scattered. In other words, with a perfectly linear transfer function (0,1)->(0,1), the channel value is directly the opacity of the medium (0=transparent, 1=opaque). However, for flexibility the channel value passes through the transfer function to give the transparency.
    channel #0 value -> transfer function -> color & alpha

Yes, you need to declare channel #0 (T_FLOAT). Once created, you prepare it properly depending on the technique you’d like to use to write. When attempt to write values directly, be sure to activate topology first, FinishTopology, UpdateAtlas, and then launch your kernel to write data. A good example of this can be found in the newly posted gResample example, which shows how to write data to channel #0 by reading RAW data from disk and making it sparse.

Regarding your analogy, kids need to socialize with others, they need teachers, mentors and classmates, not only their parents. You’re welcome to give this kid some love too, as the code is all there.