Field3D ImplicitField DSO for prman – motionblur

motionblur from Alan Warren on Vimeo.

This is a continuation from my previous posts regarding the rendering of volumes from Houdini in prman.

This is a short test with velocity driven motionblur, computed internally within my DSO.

The result should be more pronounced compared to previous test I posted on vimeo, which I removed. (you didn't miss much) I made a mistake in the way I handle scalar velocity fields, which led to incorrect data being presented to prman for the Y and Z axes. That's been solved, but I'm still not entirely happy with the result. It may be the resolution of my voxel grid, but I'm not pleased with the "streaky" look the blur has. It may also be alleviated with different shutter timing, and lower shading rate. More experimentation will follow.

Tags: ,

4 Responses to “Field3D ImplicitField DSO for prman – motionblur”

  1. David Hessel Says:

    Great stuff, I am planning on doing the same so I can render fumefx field3d data with prman. Any advice you might be able to offer would be great before I embark on my journey.

  2. admin Says:

    It's difficult to give off the cuff advice on this. Especially since it's been a little while since I was consumed by it.

    I can think of a few things though, but not sure how helpful they'll be.

    Build f3dinfo (included w/ field3d) and study the structure of the files you're going to be rendering. Look at how many fields you have, and what type of data they are, etc.

    Speaking of building stuff.. It wasn't a big deal for me on Gentoo Linux, but I think it would be difficult if you're building and configuring all of Field3D's deps yourself on another platform. (especially windows)

    For hdf5, I built static libs with -fortran and -cxx (disabled). For openmpi, I used the defaults, but enabled +romio and +cxx. I also built boost with +mpi and +static-libs, as well as ilmbase with +static-libs.

    If your going to be rendering both sparse and dense fields, then I recommend coding your DSO with the generic Field::Ptr type. It's much easier than using both of the specific data types.

    The general idea is to loop over your field3d files's structure in your constructor. You'll store a pointer to the buffer as member data. (I used Field::Ptr m_float_buffer ) Then, in Eval() you're going to use an interpolator to sample that buffer. You'll also need to convert the RiPoint coming into Eval() from worldToVoxel space.

    There's more to it, but that is the most general breakdown of the very core of how this is done. If you have extra fields, or want to do motionblur then there's more to it.


  3. David Hessel Says:

    Thanks for the advice that is useful information indeed, I will probably be building on Windows so it looks like I am going to have a few headaches in the near future :)

  4. admin Says:

    It looks like I forgot to encode open brackets, as they didn't show up (and might not still…). I intended to say, use the generic Field<T>::Ptr type. < ---- I hope that worked ;) Also, I should have clarified. In your constructor, you're going to store a pointer to the "density" field's buffer. You'll need to examine your file to be sure what the density field's name is. (most likely = density) Good luck doing this on Windows! I would be sure to monitor the google group for Field3D. Halfdan, a developer from Side Effects Software ported Field3D to windows. I'm pretty sure his changes were pushed to the tree, but not positive.

Leave a Reply