Howitzer99

For transferring the @Cd info into the shader, use one of Redshift's RSUserDataColor nodes, and give it Cd as the attribute name. Then plug that into the color input (diffuse_color, emission_color, etc) of the material.

The short version is: from inside Houdini, choose File->Run Script... and point to the generated .cmd files. Here's a longer version, if anyone needs help with the steps involved. There's an option to open a windows shell from inside of Houdini that will have systems variables set to be able to run Houdini's included command-line tools, like the mcbiovision converter. Another good one is abcinfo for sanity-checking any alembic caches you might be working with, either way, there are a lot of useful tools that ship with Houdini that run from the command-line. From Houdini's top menu, choose Windows->Shell This will pop-up a Windows cmd shell. To test that it's working, type in mcbiovision, and you should see the help information displayed in the window. Run the mcbiovision tools to create the .cmd files, and then from houdini, File->Run Script... and point to the resulting .cmd file, then carry on with Atom's #4 item above. Hope this helps, and thanks for sharing Atom, I was looking into converting some mocap animations a few months ago before being sidetracked by Vellum. Dave

I would be great if Houdini had a nice interface for ACES similar to Maya, but you can still setup your own config.ocio file to control studio-specific file handing. See the roles section in the config file. Here is and article from 3D Artist that gives an intro into setting up Houdini for ACES. Also briefly discusses converting your existing textures into ACES via COPs. Nice to have in-line solutions in Houdini for ocio transforms, instead of needing to pre-convert textures, but I have yet to implement this myself in my personal setup. In an Attribute VOP node, the ocio_transform node can be used with the predefined roles from the config.ocio file, or manually set for other non-defined colorspace transforms. https://www.pressreader.com/uk/3d-artist/20181023/281732680454331 Hope this helps, Dave

Looks like my HDA was also missing the Tools/Scripts, so adding back the objecttoolutils worked. Thanks for sharing!

Sounds strange, I'd suggest rolling-back to a previous version. I'm still on 2.6.38 and have never seen this error when disk rendering.

Thanks for sharing, will definitely be useful to know.

If you're ok with running from the command-line, this looks a simple solution:

I haven't tried this in Houdini yet, but in other packages, you'd use something along the lines of a rayswitch node to change which shader is being evaluated for the different calculations (direct, reflection, refraction, etc). I've seen these mentioned for Redshift and V-Ray in Houdini, so I'd suggest looking into your renderer to see how this function is supported. Here is the Redshift docs: https://docs.redshift3d.com/display/RSDOCS/Ray+Switch Hope this helps.

I've been building-up my personal lighting pipeline around Houdini, and I'm really impressed with the speed and ability to customize so many of the features in Houdini. While I'm relatively new to Houdini, I've used Katana for many years, and it really hasn't gotten any faster for geometry loading (scrub the timeline, what?!). At the end of the day, it all comes down to speed and how comfortable the artists are with the software package to turn-around shots in a tight schedule. With Houdini, you also get the power of a DCC package, and direct integration with FX elements, since they're mostly being generated from within Houdini already. One less headache it always nice! As Peter mentioned, Mantra is definitely not fast, but with all the major render packaged supported in Houdini, at least you're not locked-down to using it if you don't want.

Great stuff!

Cool, glad it's working!

For converting paths, I used to have a pretty handy standalone app a few years ago, but can't find it anywhere. I did find this Chrome extension though, that looks like it'll work: https://chrome.google.com/webstore/detail/path-converter/egbgfaldpekjcbmfhbjmcafbfcdjgboe?hl=en Sorry, can't help on the python side.

I'm not familiar with importing FumeFX into Houdini, but internally for Houdini, it's expecting to have velocity as a vector parameter named "vel" for it to pickup and use motion vectors during rendering. Check which parameters are coming in from the FumeFX VDBs, you may need to just rename the velocity attribute. Here's a link from SideFX's site with some more info: https://www.sidefx.com/forum/topic/43574/

Maybe try using FBX to transfer from Houdini to 3ds Max, might give cleaner results. Select your geo, then go to File->Export->Filmbox FBX... In the options, there is a choice for 3ds Max format. For the obj options above, since the model doesn't look smoothed, nor have materials, turn off the Smoothing Groups and Import Materials options, should give a cleaner result in the viewport. It's mostly cosmetic if your final export is to dxf/dwg, but might solve why the model looks so different when imported.

For anyone following this topic, Simon has a breakdown of the process in the 3D World 2018 Christmas issue. Enjoy!