zarti
here is another tiny dot :

- wd be great to have an Image Manager .
.. which manages all the images ( and sequences ) loaded within a scene .

ive been using LightWave for a decade and this little but useful feature is one that i miss ( esp when the project has a lot of references and textures to jump from and to ) .

i hope the attached pic could look pretty self-explanatory about its usefulness .

oc , other additional / alternated options wd make it fit perfectly into houdini's enviro .. IMHO .



.cheers

+1

Plus one for keeping Houdini exactly as it is. I've been a 3ds Max user for 17 years, Softimage XSI since version 4, Maya since version 2. I own Zbrush and use Mudbox, and have a deep love for 3dCoat.
That having been said, I respect Houdini's interface, and have learned how to use it. It simply is the best for getting so much complex work done, much of it beyond the capacity of “out of the box” software. You'd need to know loads of Python or Mel to get it to work in Maya. ICE in Soft is great, but I find it limited compared to Houdini. Probably it needs to be around more, and it might develop into the robust tool that Houdini is. Anyway, just wanted to add my two cents. Fix a few irritating things around the edges and make it run faster. Everything else is just fine. It's a high powered rocket engine, just hang on tight and figure out how to control it by grabbing inside and tweaking the knobs and rearranging the pipes. Without exception, all my students prefer Houdini's interface and workflow to Maya's. Maybe that will all change this upcoming semester, when I really test them.

I think the documentation could be better. When I go to the help menu, show me some more examples of how to use the tools. The “launch/load” links are pretty good, though.

Great to see you here ctedin. Maybe some tutorials about Houdini and rigging/animation in near future? Same as these great ones you did for Softimage.

One of the things I am feeling at work right now is VERY long pre-bake times for rendering volumes with motion blur. I have quite a few shots that have 30-40 min renders but were sitting doing something(nothing printing out) for upwards of 3-4 hours. Motion blurring volumes in general could use some kind of speed boost(if possible). There are times when I am rendering locally and the render will appear to hang, going from full cpu usage to a core or a core and a half.

Working with volumes in vops could use some loving as well. It isn't immediately obvious if I have multiple density primitives(or multiple primitives of the same name) which if any the vop is working on. There is a lot more “magic” happening for the volumes vops than any other vop context, bindings especially. Even if you compare the global import/export of volumes to every other context volume vops feels much more duct taped together than anything else(including pc operations in vops). I am not saying volume vops need to change in how they work; I love working with volume vops, but it needs to be brought in step workflow wise with the other vop contexts.

Thanks SreckoM. Yes, I would love to do some animation based videos once I get the complete hang of the character rigging system. From what I've seen worked on so far, it kicks serious arse. The system is very well built to do some very amazing metaball based deformations right out of the box using the AutoRig system. Tricky to add more muscles to the system once you've already started, but I'm digging into it a bit further. I would hate to suggest further improvements in this area until I'm fully familiar with the toolset. I'm pretty stoked with the fact that I could just build myself a tool that would work using the existing operators. But again, better documentation and some step-by-step documentation in a few areas would be fantastic.

Overall, I love the tabs for the rigging setups, but to get to the real power of this tool, you really need to dig down pretty far and do some hand building.

a few more primitive nodes, would be nice to match 3dsmax on this one


and to have some that they havnt thought of would be better


extend the level of detail on the help for the main node reference would help decrease the learning curve, especially listing common uses of each of the nodes with more working examples


implement the ZBrush GoZ function so that an seamless workflow between the zbrush/houdini can be used without needing to utilize max/maya


some updates to the edit modelling side of houdini, topogun style


include a base rigged demo anatomically correct character mesh, including
- male/female
- default correctly animated walk
- full working bones/muscle/face
- deformed skin from the muscle/bone
- controls to alter the bones/muscles dimensions
able to generate a fully working rigged base of any proportion, sending the deformed skin to zbrush ready for sculpting, then when done import straight back to houdini (via the GoZ function) for immediate animation of the skin on the muscle/bone rig.


include default animated demo scene's, utilising instances of the demo character to visually demonstrate efficiently rigged scenes styles/fx for the apprentice program

1. more speed (Mantra & COPs javascript:emoticon(':x') )

2. COPs improvement (Why need to learn nuke ?)

3. Crowd solution (like Massive)

4. Realtime animation development solution (like `Unity3d 4.0 Mecanim`)

5. Camera tracking solution (like PFTrack)

6. Some More Video Tutorials

7. Most people aren't developers.

-PyQt (PySide) or equiv shipped with Houdini. Then things like the Image Manager from Lightwave would be easy to write and share.

-Maintain good balance between new features and optimization. Sales can't sell optimizations and bug fixes and selling more is a Good Thing for all of us!

This has been bothering me a lot lately. While I appreciate that development is trying to help lower the learning curve for new users, can we please go back to a naming convention that makes sense? Or a naming convention that is at least standard to itself?

Example: Parts of the new sourcing workflow is great. Fluid collisions without build collision mask slowing the sim to a crawl, awesome. What isn't awesome is within the entire workflow are confusing names of paramaters that do the same thing but are named completely differently(I'm looking at you block size and swirl size). Can we please use a standard USED EVERYWHERE naming convention? Noise is noise and even if it is turbulant/anti-aliased/curl/etc it would be nice to have names standard between them. Roughness is roughness(grain? really?), octaves make perfect sense, and what the heck is pulse length? I know what it's doing in the vop but what is with that name? I have to constantly hunt down the docs or dive into the node to see what it is doing because the name makes no logical sense(not just pulse length). Also why are the fluid source workflow nodes not named the same? They are used so heavily in conjunction why is one called “Fluid source” and the other called “Source volume”?

This “appealing to new users” has started to show itself in updated workflows as well. It seems like more parts of houdini are going away from being procedural and going to one size fits all uberflows. The fluid source node is a perfect example of this. You have one node that does 10 different things, but the amount of python updating things when you change the presets(which should be above ALL the tabs always visible and not hidden in the second to last tab), makes me feel like houdini is trying less to teach and more to do it for the user under a black cloth.

I would really love to see quick ghosting and editable (or at least non-editable) motion trails in the viewport for animation polishing.
While I'm at it, when middle mouse dragging a copy of the keys (foot planting for example) it would be nice if the splines were flat (plateau) in between the keys. That's irritating to fix every time. One can almost always assume that a middle mouse drag is a held key.

1) VEX 2.0 with classes —> coshaders
2) Faster DeepShadow generation (like in prman)
3) Area shadow maps.
4) More advanced rendering documentation.
5) More PBR enhancements . Radiosity caching?
6) Please!!! fix a viewport !!! It has A LOT of problems with shading, clipping, displaying pt/ptim numbers, interactivity.
7) Handles behavior sometimes are nightmare! Hard to pick! Either to big or to small. Handles size options in preferences?
8.) Ability to undo camera movement in viewport.
9) Switch back to perspective mode when you done looking from distant light. Now it's stays in orthographic….
10) Please! Disable Middle Mouse Button moving/resizing/closing network boxes!!! It's annoying!
11) Introduce concept of Heads Up Displays (like in Maya). Give us a python access to it. We want to display a lot of custom info in viewport.
12) UNICODE support!!!!

Stalkerx777
1) VEX 2.0 with classes —> coshaders

+1 Also, SESI, please make source code generated documentation for VEX. VEX documentation is hardly ever up to date with current state of VEX. Optional parameters, new functions, depreciated functionality. Specially that VEX is entirely omitted in learning materials (which I may understand as it's more a general programming knowledge, than Houdini's specific), but at least give us a chance by providing complete and up-to-date VEX reference.

2) Faster DeepShadow generation (like in prman)
3) Area shadow maps.

+1 for ray traced deep shadows allowing area shadow mapping.

5) More PBR enhancements . Radiosity caching?

+1

6) Please!!! fix a viewport !!! It has A LOT of problems with shading, clipping, displaying pt/ptim numbers, interactivity

I've already forgotten what is like to see all the objects all the time in a viewport in every display mode.

7) Handles behavior sometimes are nightmare! Hard to pick! Either to big or to small. Handles size options in preferences?

+1, also shouldn't be handles shaded 2D? One of the main reason why some animators hate to animate in Houdini is how hard is to grab handles in viewport.

It would be awesome if provided OGL shaders be documented and prepared for user customization. There are many custom stuff to be achieved with OGL shaders Houdini uses in viewport, but they apparently weren't meant to be customized.

Also:

GUI:
1) Search/filter in Edit Shelf->Tools window
2) Expressions in Smart Bundles
3) Categories everywhere by default
4) Colors and annotations for takes
5) Python panel (with built-in PySide)
6) Houdini style® flexibility frame selector in Rops: 1,2,3,4-12:3 etc
7) More scripting/customization in GUI (xml) in pair with *.ui scripts.
8) Extend tree view with things can't be done in network view (like selections across networks)
9) Smart actions in VOPs ie: if I select tree nodes with vectors output and float to matrix node it's not really hard to guess what I want to do. Now, even three vector_to_float and float_to_matrix nodes don't cooperate. 18 clicks!

HDK:
1) Allow third parties to use license server
2) Viewport hooks, and IPR hooks for custom renderers
3) More documentation for DOPS
4) Variable parameters in custom VEX
5) VRAY library in HDK
6) Allow custom backend to Mantra (or extensible current backend)
7) Read-access to objects (geo cache etc) from within custom VEX.


CHOPs:
1) Make it ready for today's amount of data.
2) Multidimensional customizable viewer, so users assign channels to axes (and per axis scales: lin, exp, inv). If I have a signal like particles animation, I should be able to see acceleration in respect to orientation in time, so we could easily have 3+ axes. Also channels don't have to be represented with curves, points, voxels will also do. It should be optimized for displaying massive amount of data without decorators, shading etc.


DOPs:
1) Microsolvers in RBD/Cloth/wire, like handling collisions or inertia/momentum or drag separably.
2) Hair solver.

Stalkerx777
1) VEX 2.0 with classes…

+1 for 1, 6, 8, and 10.

Here is the rest of my humble list:


VEX:
Find, Contains methods for arrays
Array support for pcfilter and pcimport VEX functions
Operator overloading for structs and classes
Closest point on a surface (not an actual physical point in the geometry)
List data type with common methods
Ability to define functions for structs
Ability to create arrays of structs
Ability to define vector3 literals when using variables (without the set function)


VOPs:
Array support
Shortcut to break input/outputs into floats (i.e. breaking P into a Vector to Float node, ready to be used)


SOPs:
Edge Loop and Ring SOPs
Ability to edit multiple points for the Curve SOP
Size detail attributes for bounding generator SOPs (width, height, radius, length, etc)
Ability to use any attribute as normals for Peak and Soft Peak SOP
Edge support for Foreach SOP
Fuse Ends option for the Revolve SOP


Expressions:
Signed random function
Expression to get the number of points in a primitive
Expression to calculate point to point distance
Expression to return the group type similar to what Guess from Group does
rgb and hsv expressions to accept integers for component type


HDAs:
Ability to secure HDAs (i.e. protecting all types of code within the asset)
More composable handle system, handles 2.0
Ability to setup multiple ramp parameters the same way as any other referenced parameters (Copy and Paste references)
Delete attributes in Python HOM


General:
Using float attributes everywhere instead of vectors, matrices
Copy pasting nodes should update channel references when nesting occurs
Ability to retarget dependencies without editing channel references by hand.


UI:
Ability to retain default desktop on file open
Ability to restore 100% zoom level in the network editor
Group parameters that only support a single type to explicitly show it in their labels (i.e. Primitive Group, etc)
Highlighting problem lines in code, or generated code in VOPs
Shift click to select multiple nodes in the Operator Tree
Viewport shortcut keys should cycle between their opposing views (Top to Bottom, Left to Right, etc)
Separate size setting for points and particles
Ability to jump to dependencies using the View Dependencies dialog
Ability to add new operator to selected operator using hotkeys without right clicking node output arrow (i.e. Shift+TAB instead of TAB)
Ability to up/down arrow keys in the Select File dialogs.
Ability to use value ladder for menu parameters to cycle between options
Ability to swap parameters by dragging one over another
Ability to toggle grid in the network editor via hotkey instead of cycling
Pasting literal values shouldn't toggle expression mode for parameters
Foreground highlight for last item used for open menu parameters
Disable When condition for Label parameters for visual cue
Floating parameters windows to automatically fit height to parameters
Unpinned Details View panes to automatically show the output of a VOP node currently being worked on (inside VEX Builder mode)
Normalized access option for vector parameters


Much love to everyone involved in making our dreams come true (:

my wish would be a mac osx version !

older houdini needs 20 sec to render a black frame and newer build crashes on installtion…

so my wish for houdini 13 is a “mac version”

I wish Sidefx could buy or cooperate with Cebas, and integrate THINKING PARTICLE in Houdini 13. Node based architecture of thinking particle will perfectly fit into Houdini, and will bring Houdini's particle system to a new level

Murciallogo
I wish Sidefx could buy or cooperate with Cebas, and integrate THINKING PARTICLE in Houdini 13. Node based architecture of thinking particle will perfectly fit into Houdini, and will bring Houdini's particle system to a new level

I wish that it would never happen.

qbick

Murciallogo
I wish Sidefx could buy or cooperate with Cebas, and integrate THINKING PARTICLE in Houdini 13. Node based architecture of thinking particle will perfectly fit into Houdini, and will bring Houdini's particle system to a new level

I wish that it would never happen.

Why not?

Murciallogo
I wish Sidefx could buy or cooperate with Cebas, and integrate THINKING PARTICLE in Houdini 13. Node based architecture of thinking particle will perfectly fit into Houdini, and will bring Houdini's particle system to a new level

Could you name any features of TP that Houdini doesn't support now?

It'll be nice to have an option to echo the python commands that runs behind to perform an operation similar to the one in Maya

Stalkerx777
12) UNICODE support!!!!

There's already support for Unicode in 12.1, unless you mean in the user interface.