Houdini 14 Wishlist

[LaidlawFX]

what it does?

In a not so eloquent manner... It doesn't look $%!#, and it's easily update-able. For the intro peops, I can't point people there and not be embarrassed.

Silly I know, but it's nice. 

[kev2]

A "Community" pane for Odforce like the Community / forums tab in Mari.

[willow wafflebeard]

One thing I noticed with the wrangle sops is that vex functions are not equally supported in all the wrangles. It would be great if that was added to the documentation for each vex function, stating which nodes are compatible/incompatible.

i think most of the reasons are the difference between attrib wrangle ang point wrangle, there are few functions that only works with attrib vops and vise versa. but i agree unto giving more documentation on it

[Alexey Vanzhula]

1. Drag by Screen X handle - simple change value by dragging, like Peak handle, but with screen X normal

2. Drag by Screen Y handle

Edited September 20, 2014 by Alexey Vanzhula

[sanostol]

Improvements to the oglRop

 

-support for backgroundimage

-motionblur like in flipbook

-animated textures (right now $F is not evaluated )

-cameraviewmask to display additional infos

-full support in cops (right now cops cannot pull oglROPS)

 

Martin

 

the normal flipbook is just not very pipeline friendly, oglRop could streamline a lot here

Edited October 4, 2014 by sanostol

[sebkaine]

Orient Pivot along :

- primitive normal

- edges normal

- point normal

 

With the

- translate

- rotate

- scale

Manipulators.

 

It is simply impossible to do some modeling without those TRIVIAL operation.

 

 

Ability to use the ALT key in all hotkeys options, especially the volatile select.

Edited October 14, 2014 by sebkaine

[sebkaine]

- Pre and Post infinity cycle animation accessible directly from the channel editor menu to simlify the life of animators.

- addition of the oscillate() function

Edited October 16, 2014 by sebkaine

[Pazuzu]

- Ability to "select all" keys in the channel editor.

- Faster visualization of huge number of channels-curves in channel editor.

- Ability to mute/unmute curves ala Maya in channel editor.

- Full VDB support in DOPs (sometimes one need to convert to native volume primitive).

- Native Python wranglers in all context.

- COP, CHOP wranglers.

- SHOP wrangler at material level.

[edward]

- Ability to "select all" keys in the channel editor.

- Faster visualization of huge number of channels-curves in channel editor.

- Ability to mute/unmute curves ala Maya in channel editor.

- Full VDB support in DOPs (sometimes one need to convert to native volume primitive).

- Native Python wranglers in all context.

- COP, CHOP wranglers.

- SHOP wrangler at material level.

 

You can mute/unmute curves in the Dopesheet.

 

I'm not sure about what you mean by "select all" keys in the channel editor ... Ctrl+A ?

 

As for speed, are you still getting a lot of channel editor slowdowns in H13.0.384 and later? You should submit examples if you still do.

[Pazuzu]

You can mute/unmute curves in the Dopesheet.

 

I'm not sure about what you mean by "select all" keys in the channel editor ... Ctrl+A ?

 

As for speed, are you still getting a lot of channel editor slowdowns in H13.0.384 and later? You should submit examples if you still do.

 

Thanks for the info Edward!

About the select all keys, yes! Ctrl+A like in viewport with objects.

About speed, I have some scenes that read some tracking data with very dense curves (H13.0.509), I'll upload the hips then!

[up4]

My turn:

• UDIM support, transparently, everywhere, especially the viewport (there is this thread here for a little background), have the UV display appropriate background maps in UV view.
• Universal interoperability of dynamics solvers, especially between FEM and RBD. I expect my dop networks to be as sophisticated and complete as The Matrix (eventually).
• OpenCL everywhere, support for heterogenous computing environment (abstraction of network distributed, gpu vs cpu), especially for simulations/dynamics. I won't mention rendering because it's soooooo controversial.
• Radicalization of the procedural, non-destructive philosophy: it's better to have a Houdini Engine inside Z-Brush than to have a Z-Brush cheap copy inside Houdini. To me, even the paint tool is a heresy. MARI does it waaaaay better.

Thanks.

[malexander]

OpenCL everywhere.... I won't mention rendering because it's soooooo controversial.

 

OpenCL support in general is pretty controversial. Many have been wooed by its promises, only to end up getting burned. If you happen to have one of those tasks that is ideally suited to it, OpenCL generally produces good performance results. Tasks that don't quite fit into its ideal structure require much more effort for less gain. The trick is picking which tasks are good candidates for conversion to OpenCL to avoid wasting a lot of development time.

[up4]

The trick is picking which tasks are good candidates for conversion to OpenCL to avoid wasting a lot of development time.

 

 

As per Houdini and Bullet's own SIGGRAPH 13 papers, a pretty much all dynamics are perfect candidates. Any SIMD or (properly) multithreaded code is perfect candidate (e.g.: VEX). SESI is indeed experimenting with OpenCL. With Bullet alone you typically get 10-20x performance increases. OpenCL DOPs (at the very least) seem like a no-brainer to me.

[Guest tar]

If you're running Windows, can you let us know if you can get the OpenCL CPU working please.  It seems getting it to work on Linux is far easier. Thanks!

 

 SESI is indeed experimenting with OpenCL. 

[up4]

Yes I should try it in the next couple of days and report back here.

[Alexey Vanzhula]

If polycomponents preselection highlight exists in version 14, SESI, please give us simple way to get it from python. It would be cool for python tools

[symek]

As per Houdini and Bullet's own SIGGRAPH 13 papers, a pretty much all dynamics are perfect candidates. Any SIMD or (properly) multithreaded code is perfect candidate (e.g.: VEX). SESI is indeed experimenting with OpenCL. With Bullet alone you typically get 10-20x performance increases. OpenCL DOPs (at the very least) seem like a no-brainer to me.

You know that you're discussing SESI developer at the moment, right? Probably co-author of OpenCL implementation in Houdini? 

 

Mulithreading doesn't translate trivially into OpenCL'ness. There are plenty of perfectly mutithreaded code which would be unbearable for OpenCL, like web servers for example. SIMD does match better here, but it's typically involved only in a small part of your algorithm, leaving plenty of room for other problems.

 

OpenCL needs coherent memory access and algebraically involved kernels, that is lots' of data with predicted order type and size, which can be split and pass through your math. Anything that doesn't fit into that scenario costs development time which doesn't pay off with performance. You make your development expensive, hard to maintain, you're lowering an users' experience by making your program drivers' dependent and you end up with 15% increase of performance in favorable case and -15% in most of them.  

 

 

ps I'm not discussing the need of GPU computing in Houdini, only justifying others skepticism (which I should no longer do, as 'others' can speak for them self much better.... me dismissing here    ).

Edited November 1, 2014 by symek

[up4]

You know that you're discussing SESI developer at the moment, right? Probably co-author of OpenCL implementation in Houdini? 

 

Errrrr right. Bullying much? I talk about Bullet and FEM and you counter argument with network I/O architecture?????

1. LOLZ
2. QED

Plus, Matrox and Windows 95 are cool, but maybe if you only see 15% average performance increases (seriously??) where I say I experience 10-20x performance increases, maybe you should upgrade your GPU and time travel to 2014.

 

Justify skepticism all you want. People (read: clients) will go where efficiency is. They don't care (I don't care) how hard it is for you to migrate from CVS to Mercurial. NUKE 9 is all about performance increase. And a lot has to do with OpenCL (no, I'm not talking about the IO part, or how they did HA and load-balancing on their web servers in the cloud).

 

Finally, if you are not discussing the need of GPGPU in Houdini, then let me wish for more GPGPU in H14 and start your own OpenCL skepticism thread and I won't even go troll it, I promise.

 

I'm signing off this topic as well, because I said what I wanted to say. But seriously bro, Y U MAD???? This is ridiculous.

 

I wish for more GPGPU (OpenCL or otherwise) in H14.

[paxsonsa]

Hello,

 

I figured I would toss in my options as well.

 

UV Improvments

- I would love to see some more tools in the UV Viewport like beable to spawn a UVTransform node by selecting points in the UV View and move them. 

- Ability to split by selected edge more freely. 

 

Overall, for UVing, Houdini has some good tools in place but the efficiency of using it for a high level model is difficult and slow. Maybe I am doing it wrong but for me it just didn't feel intuitive it felt clunky and I was fighting with the 3D Viewport when it would place edit nodes and I would want to control my selections a bit more. 

 

 

I would really love to see impact data improved.

 

Currently I know of Three Methods 

- Impact Analysis

- Impact Records (Using DOP Records Node)

- Debris Source (Cheat)

 

Impact Analysis is nice but it requires me to re-sim every time I make adjustments so I default to the DOP Records and grab the Impact Records.

Its a headache though to setup impact data when using pack primitives and you want to isolate the by the object, name, and primitive.

Occasionally I like to transfer attributes from the now transformed piece onto the impact data but there is no attribute shared between this data (I mean 's@name') so it becomes chaos to transfer this data.

 

What i want is for the impact records to contain a name attr from the bullet solver and pack primitive.

[symek]

Errrrr right. Bullying much?(...). But seriously bro, Y U MAD???? This is ridiculous.

 

I wish for more GPGPU (OpenCL or otherwise) in H14.

 

You simple made an over-simplified statement, that "Any SIMD or (properly) multithreaded code is perfect candidate" (for OpenCL implementation). This isn't the case in my opinion, what I tried to explain using arguments (after malexander trying to explain similar thing: the need of balancing GPGPU development and practical advantages of such in production environment). I don't understand your aggressive tone nor accusing me of trolling, so I won't comment it.

 

Cheers!

skk.