Houdini 15 Wishlist

[Mason]

 

[jkunz07]

I think it is dops in general that cannot operate on vdbs.

 

the flip solver could benefit quite a bit if vdbs were implemented.

 

 

On the topic of doing a smoke solve on a sparse grid - DreamWorks has a proprietary solver that does this, so it is possible.

[Guest tar]

I must study up on vdb then! - can't see how it helps solvers.. is it the way it accesses the tree nodes and leaves or the multi-threaded goodness?

 

There is a dreamworks Sony Imageworks smoke paper from 2010 where the MAC velocity grid is at lower res vis-a-vis the density- which is held sparsely.  

Edited March 9, 2015 by tar

[fathom]

i think the benefit people are hoping for with vdb is not having to worry as much about the resolution of the containers.  theoretically, the vdb would only put data where you needed it.  but there are many steps in solvers that put data everywhere in the domain, so i'm not sure how much it would really help.  unless maybe there were known thresholds of influences that could help create sparse volumes for secondary fields....

[Guest tar]

Yup - sounds a bit more like FLIP for the gas motion, as in Imageworks paper:

 

Capturing Thin Features in Smoke Simulations 

http://library.imageworks.com/pdfs/imageworks-library-capturing-thin-features-in-smoke-simulation.pdf

[vi_rus]

 but there are many steps in solvers that put data everywhere in the domain, so i'm not sure how much it would really help

 

I'm not sure that understood your point. Obviously, it needs to create new microsolvers which will work specially on sparse volumes

[edward]

I'm not sure that understood your point. Obviously, it needs to create new microsolvers which will work specially on sparse volumes

Which may (or may not) make the solvers slower. The best data structure to use depends on the data requirements and access patterns required by the algorithms. It's not clear cut because the performance is tightly coupled between both the algorithms and data structure. So while the existing code in some cases is faster with native volumes, that's not to say that an algorithm designed with VDBs in mind cannot be faster overall. Or vice versa, one can also have algorithm+data combos that are faster using native volumes over VDB. To further muddy up the numbers, different performance/memory trade offs depend on the size of the voxel tiles as well. VDBs in Houdini use 8^3 voxel tiles but native volumes use 16^3 voxel tiles. In theory, one can vary the sizes of these voxel tiles to improve performance depending on the algorithm as well.

[Guest tar]

Nah for the nodes themselves, not the parameter option. Yeah something like that at least for the box. The swatch selection should not be mathematical arrayed. This is a fundamental problem with coloring crowds, too. 

PastelColors.jpg

 

Check it: very nice swatch tool.

https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=37994

[LaidlawFX]

Check it: very nice swatch tool.

https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=37994

 

Thanks Marty,

Hoping this work in h13 tomorrow... first thing on the agenda for sure.

 

YEAH!!! my sanity is restored... now if this was only default, lol.

Edited March 23, 2015 by LaidlawFX

[Diego A Grimaldi]

I'd love to see this integrated in Houdini!

 

Edited March 24, 2015 by Diego A Grimaldi

[sanostol]

- better handling of orientated voxelboxes, right now You have to correct all forces end emission velocities to work correctly with orientated voxel boxes

- a more robust resizing node on dopsmokesims

- max mode for vectors in volume operation do not make sense (rasterize, sourcefluid)

- vdb support for smoke simulations

- eliminate the ghost object bug in viewport

- extend animation curves automaticly without chops

 

- some tools to reorder the multiparm block folder contents

 

- support for OpenColorIO

 

- more love to the opengl rop, ( background plate, motionblur, animated textures) , it should really behave like the viewport flipbook, automatic flipbook conversion

 

- support opengl rop as cop render input driver (why not?)

 

- take menu list entries could be in indented to reflect their hierarchical position

 

- opengl viewport comment could be more advanced in layout an position, right now most of the time it is cutted away during flipbook capture

 

- vex like stuff to operator in objectlevel, chops is cool but to limited to vectormath and stuff like that

 

- packedfulltransform could be more easily acessible (writeable)  to play nice with bullet

Edited May 16, 2015 by sanostol

[Solitude]

I'd love to see this integrated in Houdini!

 

 

I was just thinking about this the other day --  using the new grooming tools as a base one should be able to modify it pretty easily to be able to sculpt any set of points, however getting all the same functionality is another story. 

[Diego A Grimaldi]

Well, my idea behind it, Ian, would be to have a sculpting tools with all the functionality that Sparta Project or Zbrush has for post meshing or post simming fixing...I think it would greatly benefit small/medium scale FLIP (or even particle) sims in order to achieve more tendril-like looking sims (think of Smorganic in Realflow).

[hkspowers]

Node Color Picker

A non math mathematically picked color range of strong colors. Honestly I hate pastels in user interface, there are so many wonderful colors to pick from... Whose uses 1,1,.8 color next to a 1,.8,1 on nodes.

My god they even have blue on the sliders!

I love the new color picker so maybe a baby version of it for the node picker.

Untitled-1.jpg

Even this crappy one has better dominant colors

 

Just cross posting for those who don't frequent sidefx forum. 

 

After working at a few studios that had their own versions of custom swatches, I decided I needed this feature as well. I can't take credit as I had help in figuring it out from several people and basically mimicked a much larger and more robust script but I find this to be the most simplified method out there.

Simply add the code as a shelf tool and assign the c shortcut to it to completely take over node color behavior.

you should get something like the attached image.

from PySide import QtGui, QtCore

selectedNodes = hou.selectedNodes()
if selectedNodes:
    nodeColor = selectedNodes[0].color()
    initialColor = QtGui.QColor()
    initialColor.setRgbF(*nodeColor.rgb())
    c = QtGui.QColorDialog.getColor(initialColor)
else:
    c = QtGui.QColorDialog.getColor()

if c.isValid():
    for n in selectedNodes:
        n.setColor(hou.Color(c.getRgbF()[:3]))

[sebkaine]

I like the idea of the POP grain node that you plug before POP solver where you define specific properties.

Extend this idea with 2 similar nodes :

- POP collide => that allow to setup self collide particle behavior for pop solver

- POP cloth => that allow to do particle / spring base cloth sim with the pop solver

 

While POP cloth could be kinda redundant with FEM cloth. Having a very fast POP cloth could be interesting imo.

 

In FLIP sims a sheeter / surface tension node plug in post solve like the pavel tricks could be very cool

http://forums.odforce.net/topic/18111-flip-smorganicsheeter-effect/

 

I also agree with Martin on the vdb support for smoke simulations

Edited April 14, 2015 by sebkaine

[Netvudu]

Some very good suggestions. I like the seether thing.

 

As a development of tools that we already have I would also suggest some ready-made ocean blending tool in order to easily blend dynamic wave tank simulations with non-dynamic ocean.

I know it´s doable already, and in fact I´m acceptably good at it. It´s still cumbersome and not elegant.

The same way we got a nice whitewater tool, we should have something like this. it would save a huge amount of time.

 

And also the eternal rfe for simple and quick layered materials, of course. Quick as in "easily tweakable", not as in "cheap looking".

Edited April 15, 2015 by Netvudu

[lisux]

And also the eternal rfe for simple and quick layered materials, of course. Quick as in "easily tweakable", not as in "cheap looking".

I think, hope, you will have this in 15

[LaidlawFX]

When Hotkeys are changed in the future make a preference menu option to pick the hokeys from H12, H13, H14, H15. 

 

 

Also I know this is extreme, but between major versions I wish there was a pipeline change list cheat sheet.

Example: How in H12 $CEX, $CEZ,$CEY used to evaluate but in H13  it doesn't.

Example: Then in H13 $HIPNAME used to evaluate to untitled.hip now in H14 it's untitled.

I'm ok with change except for when tools all break, and I need to hunt down each new thing as it's impossible to read the logs on a new major version that you aren't on beta for.

 

 

[malexander]

Also I know this is extreme, but between major versions I wish there was a pipeline change list cheat sheet.

 

The Compatibility file exists for this purpose (it's similar to the Version file). It contains all the little backwards-incompatible changes made in Houdini. You can also see the compatibility file online in the sidefx journal. This contains an entry for the HIPNAME change, for example.

[Alexey Vanzhula]

Move to python 3.x