Hi guys,

I'm Hristo, Bottleship founder. Context - we are a team of 20, 5 of which are FX. We are using Houdini with V-Ray, for all our 3D on some projects, mixed with Katana/Blender/Vray on some too. We do lots of simulation work. We're trying out 18.5 after checking out most of the info in the documentation, webinars etc. Here's our first impressions - basically notes from the meeting with the artists:

- burst and trail sources are cool, quick and easy to set up, thanks for these!
- pyro bake - the quick setups not using HDAs, the subnets it adds don't feel like part of the same toolset. You can only invoke them from the quick setups menu, not from the tab menu as parts of a bigger toolset like for example the groom tools. That's fragmenting things in a way that's a bit unpleasant
- pyro bake is writing out many volumes. That might be ok for a mantra workflow where all these are used in the shader, though we like to optimize our VDBs so we can handle higher resolutions with the same footprint, so we end up with density, color ramp (float, remapped to color in the shader, so decisions are made by the lighting artist), emissive and velocity. Writing out more volumes very quickly baloons the VDB size
- The scatter volume is color vector - we feel like that's a shader decision that's being made in the volume bake step, which is limiting what the lighting guy can do downstream.
- We learned a lot from the Axiom examples, like multiplying emissive by remapped flame and density, blending in sharpened emissive locally where it's higher values, etc - feels like much more of these could have gone in the pyro bake

These are our thoughts, from our perspective, hopefully it's useful. We're implementing our own pyro post process tools that are more like granular HDAs that do all that steps, so the FX artist can do a preliminary look design using the OpenGL shader, and pass data in an optimized form downstream to lighting.

Thanks!

Hello Hristo!

Thank you so much for the feedback, very much appreciated!

- burst and trail sources: That is great to know, is there anything additional to that you would think could be improved?

- quick setups: There are two reasons for seeing subnets generated:
In case of Pyro Scatter From Burst -> Simulated Trails, the Ballistic_Path_from_Simulation contains too much nodes that could overwhelm users seeing them right away, therefore it ended up in a subnet. It has a very specific task and it is an open question whenever it is worth to generalise and what else could it be used for?

The other case, the Pyro Bake Volume -> Sharpen Volume, that generates a subnet simply because we do not have a generic easy-to-use Volume Sharpen tool, but I still wanted to provide a basic ‘sharpening’ setup for those not familiar with setting one up. And because I wanted the users to only see the two needed parameters and again, not to overwhelm them with all the kernel values.

- pyro bake is writing out many volumes: I am not sure I understand correctly what you mean by ‘many’. Ideally it should be generating one additional volume ‘scatter’ if you decide to enable Scatter. ( + ‘Ce’ if you enable it on the last tab, but that is for a different workflow in which case you do not need ‘scatter’).

May I ask what is ‘color ramp (float)’ and ‘emissive’ volume exactly as you have described above? If we are talking about generic (but still sexy) explosion workflow, ideally you need is ‘density’, ‘scatter’ and ‘vel’, and when it comes to render the Absorption Color and Density Control Volume are essentials parms on the shader for good look.

- scatter volume is color vector: This is indeed one drawback of this shading technique. The blurriness of the scatter needs to be controlled in SOPs as this is a volume blur operation.

So you can do it two ways:

1. Remap temperature to color vector -> sop blur it -> give this to the shader.
2. Sop blur temperature -> give this float volume to shader, where you remap it to color vector.

Unfortunately the two methods do not provide the same look, we decided on the first one as this provides the nicer looking results. This brings up the possibility to support both methods, but currently this would have caused a lot more complications in the workflow. This also brings up the question whenever to add hue-shift and other color correction parameters on the shader which would help coloring, but some more into color pipeline might find this as an ‘evil’ control.

- Axiom examples: Matt made rather custom shaders for each of his example files for purely artistic controls. While it is possible to introduce secondary masks for each emission component, it will certainly introduce more complexity to the workflow and that is the reason why such additional controls were not included, unless it turns out very essential.