<div dir="ltr">I agree that this is an issue.  I think the easiest way forward is just to provide an example or two where we don't use auto=True, and show what needs to be done in the instance where it isn't done automatically.  I don't think it necessitates an overhaul, but perhaps others disagree.  Since 3.3 will be the first release with the new VR interface, I think this would be appropriate to include before the release.<div><br></div><div>Cameron</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 1:57 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>tl;dr:</div><div><br></div><div>I have a high-level issue with the volume rendering API. I think there are some simple things that can be done to make it simpler to use, but I'm not sure how much work it will take to get us there.</div><div><br></div><div>----------------------------------------------------</div><div><br></div><div>Today I was looking at issue #1234: <a href="https://bitbucket.org/yt_analysis/yt/issues/1234/volume-rendering-example-in-loading" target="_blank">https://bitbucket.org/yt_analysis/yt/issues/1234/volume-rendering-example-in-loading</a></div><div><br></div><div>This refers to an example in our documentation that uses the old volume rendering API to make a very pretty image. I wanted to retain that image, which led me to try to make a fully customized volume rendering using the new interface for the first time, and it left me very confused. If I was completely unfamiliar with yt internals and not comfortable looking at the yt source code, I don't think I would have been able to successfully recreate the image using the new API.</div><div><br></div><div>To make that concrete, here's how you would construct the volume rendering using the old interface:</div><div><br></div><div><a href="https://bpaste.net/show/58194a5a1352" target="_blank">https://bpaste.net/show/58194a5a1352</a><br></div><div><br></div><div>And here's what I did to make the same image using the new volume rendering interface:</div><div><br></div><div><a href="https://bpaste.net/show/9fba5872e532" target="_blank">https://bpaste.net/show/9fba5872e532</a><br></div><div><br></div><div>Three lines of code in the old interface expand into 26 lines of code in the new interface. I also need to do scary-looking undocumented things like manually creating an AMRKDTree to be able to get the field logging setting I wanted. I also need to know about what's going on under the hood in the VolumeSource class since I wanted to avoid setting auto=True, which does a lot of basic setup, but also does some unnecessary computation.</div><div><br></div><div>That said, some of the additional boilerplate constitutes an improvement in clarity. For example, I like how I'm setting camera attributes now instead of setting keyword arguments in the Camera initializer. </div><div><br></div><div>The main problem I see is that the VR interface attempts to do too much "magic" by default. If auto=True is set when the VolumeSource is created, an AMRKDTree is constructed, fields to render are set, whether or not the rendering happens in log space is determined by looking at the take_log setting in the FieldInfo, and a transfer function is created based on a TransferFunctionHelper instance. If auto=False, it's not clear about how one sets this stuff up without looking carefully at what happens inside the VolumeSource code when auto=True.</div><div><br></div><div>It would be nice if there were a better story in the auto=False universe. For example, the VolumeSource object could grow a way to *automatically* create AMRKDtree instances when needed, after a user sets the field to render and sets which fields should be rendered in log space. This is almost possible in the current API, but the VolumeSource object would need to grow an API that allows the user to control the field logging behavior - right now this is only controllable at the level of the AMRKDTree object.</div><div><br></div><div>I'm curious whether anyone has suggestions or ideas for ways forward on this. Is this a documentation problem (i.e. do we just need to add a ton of examples where we do customized volume renderings in a somewhat baroque but very explicitt style) or indicative of deeper issues with the new VR interface? Should the issues I'm raising be dealt with before we release yt 3.3 or could we patch it afterwards?</div><div><br></div><div>All that said, I don't particularly want to embark on a several weeks-long yak-shaving expedition in the volume rendering code and I can't volunteer to lead any kind of overhaul. I am willing to make small usability improvements, though, if that's what we decide we should do.</div><div><br></div><div>Hope that wasn't too much of a novel, I'd love to hear comments about this.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nathan</div></font></span></div>
<br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Cameron Hummels<div><span style="font-size:12.8000001907349px">NSF Postdoctoral Fellow</span></div><div><span style="font-size:12.8000001907349px">Department of Astronomy</span></div><div><span style="font-size:12.8000001907349px">California Institute of Technology</span><br></div><div><a href="http://chummels.org" style="font-size:12.8000001907349px" target="_blank">http://chummels.org</a><br></div></div></div></div>
</div>