Jump to content

Houdini 15 Wishlist


LaidlawFX

Recommended Posts

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.

Link to comment
Share on other sites

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 by tar
Link to comment
Share on other sites

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....

Link to comment
Share on other sites

 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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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. 

attachicon.gifPastelColors.jpg

 

Check it: very nice swatch tool.

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

Link to comment
Share on other sites

 

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 by LaidlawFX
Link to comment
Share on other sites

- 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 by sanostol
  • Like 1
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

attachicon.gifUntitled-1.jpg

Even this crappy one has better dominant colors

colour_picker.jpg

 

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]))

post-2857-0-33108000-1427999181_thumb.jp

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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 by sebkaine
Link to comment
Share on other sites

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 by Netvudu
  • Like 1
Link to comment
Share on other sites

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.

 

 

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...