Houdini 14 Wishlist

[jonp]

As far as takes go...

 

Why not convert them from a unique hierarchy list to a dependency graph?  Each take 'node' could have parent / child connections.  You could then create an object-specific take and wire it into the parent render takes that need the specified changes, instead of having to duplicate changes across takes.

 

I think this would go a little way towards making render-specific changes much easier to manage across multiple ROPs, etc.

 

In general though there should be a way to have more wildcard-based methods of applying render time changes (shader assignments, etc.).

Edited January 24, 2014 by jonp

[Alexey Vanzhula]

Align viewport camera to closest plane (XY,XZ,YZ)

[Alexey Vanzhula]

To use PySide instead of PyQt:

change:

from PyQt4 import QtCore
from PyQt4 import QtGui

to something like:

try: from PyQt4 import QtCore
     from PyQt4 import QtGui
except:
     from PySide import QtCore
     from PySide import QtGui

in pyqt_houdini.py file (http://www.sidefx.com/docs/houdini13.0/hom/cookbook/pyqt/part1/)

Edited January 27, 2014 by Alexey Vanzhula

[Alexey Vanzhula]

Move pyqt_houdini.py file (http://www.sidefx.co...ook/pyqt/part1/) to standard python modules location

[MarkBru]

new retime tools with spline interpolation based on id attribute would be great. and sourceinterpolation based on velocity attributes in the new popsource (this can be done easely by replacing the timeshift nodes inside the sourcenode with a pointwrangle with the code @P+=@v and @P-=@v, but it would be a lot easier with a checkbox).

 

Vexpressions in all parameter fields would be awsome....

[Alexey Vanzhula]

"ctrl + enter" for "Apply" button in all windows would be cool

[Guest mantragora]

"ctrl + enter" for "Apply" button in all windows would be cool

Any additional info on why this would be a good idea?

Edited February 1, 2014 by mantragora

[jordibares]

I would love Houdini to have DEM manipulation tools to generate geometry, stitch maps, etc… seems this is a constant source of nightmares every time I have to work on this field with crazy tools that are designed for GIS technicians.

Edited February 1, 2014 by jordibares

[Alexey Vanzhula]

Any additional info on why this would be a good idea?

 

There are some situations where it promotes acceleration, for example, of asset creation.

If you need to edit (and rename also) many parameters (in "Type Properties" window) - you can view result earlier, because you fingers near the keys.

Edit of string parameter also use ctrl+enter for update state.

imho

Edited February 1, 2014 by Alexey Vanzhula

[sebkaine]

Some extra effort on the Houdini doc would be great for the VEX and HOU section.

- Sort the VEX function by type / by context / by first alphabetical letter.

- put 1 or 2 coded exemple in every VEX function same for HOU module

- a good library of coded exemple in VEX and HOU

 

I find that the ROP part of houdini is extremely powerfull and interesting , it is not a feature request, but

the ability to lunch an application that would be compose of the ROP tree + OpenGL viewer only as a standalone app would be cool.

the ability to execute agnostic code in this app in a cleaner way than the "shell" node would be interesting.

this tool could be use a a scene builder , a render manager , a luncher for external app

well an enhance ROP externalise as a standalone utilities could be great to build a pipeline without R&D effort.

 

so you will have

- houdini

- image viewer

- geometry viewer

- houdini builder (ROP nodal tree that execute any code for scene assembling/render lunching etc...)

 

with a tool like this we could store pymel code to build maya rig or lunch nuke rendering without having to open houdini and use a license ...

 

this tool could also respect some sort of scene description convention beetween Maya/Houdini , for exemple take inspiration of pixar USD or use it.

http://graphics.pixar.com/usd/

 

something in the mood of image engine gaffer, not only ligthing centric like katana.

 

Cheers

 

E

Edited February 13, 2014 by sebkaine

[altbighead]

zbrush style high poly in opengl viewport combine with vop sop for landscape and procedural modeling in real time.

[mawi]

Vex geometry procedural that allows us to create any geometry at rendertime using a cvex shader.

[Alexey Vanzhula]

It is queryPrimAtPixel func in hou.GeometryViewport.

SESI, please, give us queryPointAtPixel and queryEdgeAtPixel

[freaq]

It is queryPrimAtPixel func in hou.GeometryViewport.

SESI, please, give us queryPointAtPixel and queryEdgeAtPixel

I agree I want to be able to sample the 3D location of my mouseclick with a simple command.

also preferable not constantly casting rays untill the moment of the click or while not pressed use the depth buffer or something (if that is available) as an approximate value

[bandini]

I badly want a cloth solver that works and is stable and FAST! I am not liking the FEM implementation at all for cloth.  Let me have ngons and bad topology and all that without killing the solver.  Maya ncloth isn't so picky about the incoming geo, and works pretty damn well for most things I need. I feel like every major release has a revision to cloth, and it seems to only get marginally better, or sometimes moves backwards (as is the case in R13).  FEM for sims and softbodies... seems ok, but the simulation speed makes it unusable for the typical projects I work on.  I wonder why they haven't implemented bullet cloth or some other open source cloth library...

[freaq]

basically GPU computing: gpu's are incredibly fast if utilized for the proper functions:

GPU particles (plenty of demo's)

GPU cloth (like marvellous designer has shown)

GPU PBR (brigade/arion/octane)

GPU bullet (already available to be used)

 

option to execute Vex to GPU??? it's already an SIMD language...

 

also please fix the join sop, it is incredibly buggy at times :/

 

[Guest tar]

basically GPU computing: gpu's are incredibly fast if utilized for the proper functions:

GPU particles (plenty of demo's)

GPU cloth (like marvellous designer has shown)

GPU PBR (brigade/arion/octane)

GPU bullet (already available to be used)

 

option to execute Vex to GPU??? it's already an SIMD language...

 

also please fix the join sop, it is incredibly buggy at times :/

 

 

 

GPU rendering? checkout this from the Octane forums:

 

We are delighted to share the unveiling of the “The Boy and His Robot”, allegedly the first live-action movie with visual effects that are entirely rendered by GPUs.

 

 

Trailer

https://www.youtube.com/user/tbahrmovie

 

https://render.otoy.com/forum/viewforum.php?f=7&sid=76d085ea3a3e37f27025c88c4c2015ad

Edited February 28, 2014 by tar

[Stalkerx777]

I badly want a cloth solver that works and is stable and FAST! I am not liking the FEM implementation at all for cloth.  Let me have ngons and bad topology and all that without killing the solver.  Maya ncloth isn't so picky about the incoming geo, and works pretty damn well for most things I need. I feel like every major release has a revision to cloth, and it seems to only get marginally better, or sometimes moves backwards (as is the case in R13).  FEM for sims and softbodies... seems ok, but the simulation speed makes it unusable for the typical projects I work on.  I wonder why they haven't implemented bullet cloth or some other open source cloth library...

Totally agree!! FEM for cloth is not an option! Its slow comparing to H12 cloth solver and MUCH slower than nCloth.

[edward]

it seems to only get marginally better, or sometimes moves backwards (as is the case in R13).

 

If you have a performance regression, please submit your file to SideFX. Performance improvements are continuously worked on but the developers don't necessarily know the exact situations that you're using it in.

[bandini]

If you have a performance regression, please submit your file to SideFX. Performance improvements are continuously worked on but the developers don't necessarily know the exact situations that you're using it in.

 

Thanks Edward.  I will in the future. I don't have access to old files anymore, but I will start submitting bugs or errors when I find them.  It's one of those things I always mean to do, but never get around to doing it.  I recently submitted one about missing tearable cloth, which has been logged.

 

In general, though, I have found self-collision to be the biggest slow-down and error causing variable in the FEM cloth solver.  Very easy to make the cloth explode with lots of irregular geo.  Not even talking about ngons here, but sometimes long, skinny tri's, which are not always avoidable.  Unfortunately, without self collision, cloth isn't good for much for me except waving flags and very basic cloth-like deformations.  I may have time this week to submit a file.  Will have to see how my week goes.