<div dir="ltr">Only reading / import of OpenVDB files would be required for Cycles, no export.<div><br></div><div>We don't need a volume texture node, OpenVDB grids can be available as voxel grids as they are now. What we could have is a Volume Attribute node that is easier to use than the Attribute node, with a position or displacement input, and a menu for picking available volume grids. Keeping them as attributes is a better fit for an eventual volume object, and for optimizations like empty space skipping.</div><div><br></div><div>Regards,</div><div>Brecht.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 23, 2018 at 1:04 PM, Geraldine Chua <span dir="ltr"><<a href="mailto:gsc97531@gmail.com" target="_blank">gsc97531@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"><div><div><div><div><div><div>Hi Kévin and Brecht,<br><br></div>Thanks a lot for your feedback! I am in the process of drafting the proposal and reseraching the Cycles architecture, previous work with Volumes, and related literature. I will have to lower my naive ambitions quite a bit. I have structured my GSoC task list as something similiar to the below list:<br></div><br></div><div>Required:<br></div>- Tiling support for Volumes in Cycles kernel (so Cycles can better support volumes in general)<br></div><div>- Import/export of OpenVDB files to/from Cycles 3D image<br><br></div><div>Optional (most likely only do 1 of these):<br></div>- Textures for volumes (basically Jehuty's main project)<br></div>- Volume motion blur<br></div><div><br></div><div>(so it has now almost returned to the proposed idea list :P)<br></div><div><br></div><div>On your advice, I do not think I should pursue Volume Primitives since, as has been said, volume rendering is itself not fully developed yet, and perhaps other rendering tasks would be better use of any remaining time e.g. motion blur. I will try to post the draft of my proposal by tomorrow or Sunday.<br><br></div><div>Best regards,<br></div><div>Geraldine<br></div><div><div><div><div><div><br></div></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 23, 2018 at 12:42 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</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 <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Geraldine</span>,<br><div class="gmail_extra"><br></div><div class="gmail_extra">Blender indeed supports OpenVDB as a file format for baking smoke simulations, but nothing else.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We indeed want to have an OpenVDB backed volume object in Blender. But it's a big project that touches a lot of areas, and we prefer projects that are well defined and can be finished within the GSoC timeframe. We shouldn't have a Blender version that supports volume objects but has no way to render them. So I think it makes most sense to add Cycles rendering support first, because it's pretty much a required step in adding a volume object.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cycles tiled 3D image storage is important to support VDB files properly, since being able to store sparse volumes is a big feature of OpenVDB. Basic reading of OpenVDB files into 3D images is a relatively small project. These projects can potentially be finished much faster than the GSoC timeframe, it depends on the experience of the student. Starting a Blender volume object as an optional third step in the remaining time makes sense to me.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Brecht.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_3891311580115301603h5">On Thu, Mar 22, 2018 at 3:05 PM, Gg Cc <span dir="ltr"><<a href="mailto:gsc97531@gmail.com" target="_blank">gsc97531@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_3891311580115301603h5"><div dir="ltr">Hello everyone!<br><br>I am Geraldine Chua, a prospective GSoC candidate, and although I am a little late to the game, I would really love to be able to help work on Cycles over the course of this summer :).<br>In regards to my project, I would like to enquire about the feasibility of fully integrating OpenVDB into Cycles. One of the tasks mentioned under the Volume Rendering potential ideas list is the "Direct reading of OpenVDB files as a Cycles 3D image, to render volumes generated by other software."<br><br>Right now, it seems like Blender can already read and write (but not edit?) smoke volumes (but not other volumes?) as OpenVDB files (<a href="https://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport" target="_blank">https://wiki.blender.org/inde<wbr>x.php/User:Kevindietrich/OpenV<wbr>DBSmokeExport</a>). There are also various other integrations done over the years such as one attempted back in GSoC 2013 (although I cannot tell how far Jehuty managed to finish) and the rest of Kevin Dietrich's work.<br><br>However, from this forum post (<a href="https://blenderartists.org/forum/showthread.php?433900" target="_blank">https://blenderartists.org/fo<wbr>rum/showthread.php?433900</a>), as well as a few others, it seems like a quite a few people want much greater support for OpenVDB. Perhaps instead of doing these 3 unrelated (although all interesting!) tasks for Volume Rendering, I could focus on extending or even finishing the OpenVDB integration started by Kevin Dietrich. This would be a much more focused project, and I think one fully-fledged project, as opposed to a few spread out tasks, might be better for the community who will get a fully-fledged new tool.<br><br>Some ideas of tasks that can be done:<br><br> - Revisit and complete Kevin Dietrich's unfinished projects such as the implementation of a Volume Object Primitive or the Particle Mesher Modifier (<a href="https://wiki.blender.org/index.php/User:Kevindietrich" target="_blank">https://wiki.blender.org/inde<wbr>x.php/User:Kevindietrich</a>)<br><br> - Integration of other features of OpenVDB such as conversion tools, transforms, etc. (<a href="http://www.openvdb.org/about/" target="_blank">http://www.openvdb.org/about/</a><wbr>)<br><br> - Refactoring of current Volumes functions in Cycles to work with the OpenVDB format<br><br>I would like to ask from those who are much more experienced than me in volumes development:<br><br>1. Does this project contradict any current plans or goals set for the Blender architecture? Is OpenVDB integration a goal of Blender's?<br><br>2. Is this a project that is of actual benefit to the Blender community? Or is the original requirement of only OpenVDB import/export what is actually needed and  would you rather I focus on trying to also accomplish the other 2 volume rendering tasks?<br><br>3. Would you estimate that this project is feasible, i.e. the most useful features can be implemented in 12 weeks?<br><br>Thank you for taking the time to read my questions and I hope you can provide some of your insights and feedback on this proposal :). I know that the Blender development community is a quite busy right now with the upcoming Code Quest, so thank you for taking the time to help me on this.<br><br>Best regards,<br>Geraldine Chua<br><br></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-cycles</a><br>
<br></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mail<wbr>man/listinfo/bf-cycles</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br></div>