On Wed, May 17, 2017 at 5:29 AM Matej Tyc <matej.tyc@gmail.com> wrote:

On 15.5.2017 21:26, Nathan Goldbaum wrote:

On Mon, May 15, 2017 at 2:12 PM, Matěj Týč <matej.tyc@gmail.com> wrote:

...

Hello guys,

we're not all guys :)

Actually, guys includes everybody: https://en.wiktionary.org/wiki/guys

I've had several women tell me that using gendered language like that makes them feel uncomfortable participating in discussions. That's why I pointed it out, I want to make sure everyone feels comfortable.

our research group would like to visualize volume data, where the

...

transfer function is bivariate (see

http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2017-April/00855... ). We have been struggling with this task, so I would like you to help me understand some of the basic concepts I have come across and that I find confusing.

1. I think that I somehow understand the concept of transfer functions with multiple fields, but I have difficulties of creating a volume source with multiple fields. I have somehow examined the source code, and it seems to me that only the first field is used (judging by

https://github.com/yt-project/yt/blob/master/yt/visualization/volume_renderi... ).

The class you linked to here is for rendering unstructured mesh data. Is that what you're trying to do? If so then the advice for how to proceed is very different than if you are rendering gridded data.

It is great that you have pointed this out. I think that we have gridded data (i.e. a numpy array that corresponds to sampled data). What does it mean that render_source is not involved?

You will be using a VolumeSource in that case, not a MeshSource. There will still be a source to be rendered though. Would be the following snippet OK if I implement the MyCustomTF correctly?

import scipy as sp import yt import yt.visualization.volume_rendering.api as vr_api

trans = sp.rand(20, 40, 40) color = sp.rand(20, 40, 40)

ds = yt.load_uniform_grid(dict(color=color, trans=trans), color.shape)

scene = vr_api.Scene()

source = vr_api.VolumeSource(ds.all_data(), ["color", "trans"]) source.log_field = False source.transfer_function = MyCustomTF(...) scene.add_source(source)

scene.add_camera() scene.save('render.png')

In principle yes.

You are right that each source only renders a single field. If you want to render more than one field you will need to create multiple sources.

...

If I am wrong and it is meaningful and possible to construct a source with multiple fields, could you please provide an example?

Here's an example:

https://github.com/yt-project/yt/blob/master/doc/source/cookbook/render_two_...

That said, this is simply compositing two separate volume renderings together. A bivariate transfer function is a bit more complex than this.

Transfer function is a property of a volume source, isn't it? So if one source means one field, then how can a transfer function access multiple fields? At least PlanckTransferFunction uses multiple fields.

Good point. You may need to relax that assumption.

2. I have no doubts that transfer functions work, but I was unable to

...

find out how are they involved in the integration process. What I came across were the integration routines and they have mentioned that the transfer function is not used:

https://github.com/yt-project/yt/blob/master/yt/utilities/lib/ray_integrator... . This is really interesting, how is it in reality?

I believe the low-level routine you want to look at in is yt/utlities/lib/image_samplers.pyx, in particular the VolumeRenderSampler. The PlaneVoxelIntegration class you linked to here is experimental code that is not used elsewhere in yt.

okay, I am happy about this as the code was extremely hard to read. This one is somehow easier, although the code still doesn't reveal much intent and names of variables are difficult to understand for an outsider. Anyway, I will proceed and if I manage to understand it, I may be able to come up with some proposals.

Feel free to ask questions as you have them.

3. You have mentioned the PlanckTransferFunction as a good example of

...

multivariate transfer function. However, doing a Google search, hoping that we will find a code snippet featuring a non-trivial example did not yield any results. Would you be so kind and provide one?

There is no easy example I'm aware of. Making it easier to do the sorts of bivariate volume renderings you're trying to do is a longstanding issue. I'm not aware of anyone successfully using the machinery in yt for doing volume renderings with transfer functions that depend on multiple fields since John Wise added the code for the PlanckTransferFunction several years ago. That code was not added with any documentation or tests so unfortunately it may have bitrot since it was added. Also, in the meantime the volume rendering machinery in yt has undergone substantial reworking so it's possible that things are just simply broken right now.

We would welcome contributions that make it easier to do the sorts of volume renderings you are trying to do. I'm sorry that it's not straightforward to do that right now.

As soon as I get this working, I will be happy to submit a PR.

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

On Tue, May 30, 2017 at 8:48 AM, Matej Tyc <matej.tyc@gmail.com> wrote:

Hello again, I have took another iteration and we still need your help to proceed:

On 17.5.2017 14:37, Nathan Goldbaum wrote:

...

You will be using a VolumeSource in that case, not a MeshSource. There will still be a source to be rendered though.

Would be the following snippet OK if I implement the MyCustomTF correctly?

...

import scipy as sp import yt import yt.visualization.volume_rendering.api as vr_api

trans = sp.rand(20, 40, 40) color = sp.rand(20, 40, 40)

ds = yt.load_uniform_grid(dict(color=color, trans=trans), color.shape)

scene = vr_api.Scene()

source = vr_api.VolumeSource(ds.all_data(), ["color", "trans"]) source.log_field = False source.transfer_function = MyCustomTF(...) scene.add_source(source)

scene.add_camera() scene.save('render.png')

In principle yes.

...

You are right that each source only renders a single field. If you want to render more than one field you will need to create multiple sources.

...

If I am wrong and it is meaningful and possible to construct a source with multiple fields, could you please provide an example?

Here's an example:

https://github.com/yt-project/yt/blob/master/doc/source/ cookbook/render_two_fields.py

That said, this is simply compositing two separate volume renderings together. A bivariate transfer function is a bit more complex than this.

Transfer function is a property of a volume source, isn't it? So if one source means one field, then how can a transfer function access multiple fields? At least PlanckTransferFunction uses multiple fields.

Good point. You may need to relax that assumption.

What do you mean by "relaxing that assumption"? Am I wrong when I think that the transfer function needs to use multiple fields? Regarding the volume source, I have examined the source code https://github.com/yt-project/yt/blob/master/yt/visualization/volume_ rendering/render_source.py#L160 and although I can pass a dataset with a list of fields, the __init__ method completely forgets that there is more than one fields involved.

I mean that code modifications will need to happen. The behaviors you are describing will need to be changed to get the multivariate transfer function working once again with the current volume rendering interface. It might even make sense to leave VolumeSource alone and instead create a new MultiVariateVolumeSource to handle multivariate volume renderings.

I have tried to fiddle with the ColorTransferFunction by making my own CTF and changing all the field IDs in the code from 0 to 1 (see https://github.com/yt-project/yt/blob/master/yt/visualization/volume_ rendering/transfer_functions.py#L393), but although I have assigned the CTF to a supposedly two-field source, nothing came out (as opposed to the case when field IDs were flipped back to 0).

Unfortunately I don't know the details of how the color transfer function is implemented to give you educated advice here. I think you're going to need to poke at it with a debugger.

2. I have no doubts that transfer functions work, but I was unable to

...

find out how are they involved in the integration process. What I came across were the integration routines and they have mentioned that the transfer function is not used: https://github.com/yt-project/yt/blob/master/yt/utilities/ lib/ray_integrators.pyx#L235 . This is really interesting, how is it in reality?

I believe the low-level routine you want to look at in is yt/utlities/lib/image_samplers.pyx, in particular the VolumeRenderSampler. The PlaneVoxelIntegration class you linked to here is experimental code that is not used elsewhere in yt.

okay, I am happy about this as the code was extremely hard to read. This

...

one is somehow easier, although the code still doesn't reveal much intent and names of variables are difficult to understand for an outsider. Anyway, I will proceed and if I manage to understand it, I may be able to come up with some proposals.

Feel free to ask questions as you have them.

I see, it is VolumeRenderSampler.sample and ImageSampler.__call__, walk_volume etc. There is some very impressive functionality in there, but I would have to study that for weeks just to get to some level of understanding, which I can't do. So I hope that we will be able to achieve this multimodal visualization without understanding those masterful, but also quite sophisticated low-level routines.

To get this to work you might need to come back to these low-level routines, in particular to figure out how the transfer function is expressed at this level.

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org