Jump to content

od[force] Houdini 11 Wishlist


Recommended Posts

XSI-style node wires. Houdini's wires often overlap and obstruct each other, making it hard to see where a wire is coming from or going to.

post-37-125437090495_thumb.jpg

I like XSI wires but I always use straigth lines as wires in Houdini, like Nuke wires, simple, they never overlap and easier to visualize for me.

Link to comment
Share on other sites

Complete overhaul of the handles handling ( :) ) in DA's interface.

Dragos

I am agree in part with you, I dont think they need an overhaul, just polish them and maje them usable. The idea of creating gizmos for your tool without any line of code is just amazing.

Link to comment
Share on other sites

just a comment about multithreading and speed...

this is the only area that I think deserves a major effort...DOP sim times are a different matter.

I don't know anything about anything except character work...rigging, weighting, controls and adding all the other crap (muscles, dynamics etc) so 95% of the time all I see all day is a single character in a viewport without animation...

so most of the time I don't have any issues with speed

but then I wander over to an animator's desk and see the poor bastards fighting with 3 animated characters, 40minute ~250 frame flipbooks etc

then I'll see a vid of 10 characters happily animated and doing so at 30+ FPS in XSI

beyond the meat and potatoes of production rigging a lot of my time is spent trying to figure out how to get things faster (AdamJ and I cooked up a few good ideas) but have never reached the levels that other apps can achieve - especially in the viewport.

(if I'm alone in this and there are people out there getting better results than I have I'd love to hear from you)

so I don't know the internal reasons for the difference between how Houdini deals with geometry, deformations and drawing the viewport and how, for example, XSI does - and frankly I don't really care, what I do know is that Houdini will never be the character animation tool it could very easily be unless this is addressed, and please note I'm not talking about simple toon characters with 15 bones or whatever, I'm talking about 100+ bones, IK/FK + facial controls etc...none of the the rigs for SuperWhy ( http://www.youtube.com/watch?v=E6cbU09doxc ) performed better than ~18FPS, alone, on the best box in the studio.

Link to comment
Share on other sites

so I don't know the internal reasons for the difference between how Houdini deals with geometry, deformations and drawing the viewport and how, for example, XSI does - and frankly I don't really care, what I do know is that Houdini will never be the character animation tool it could very easily be unless this is addressed, and please note I'm not talking about simple toon characters with 15 bones or whatever, I'm talking about 100+ bones, IK/FK + facial controls etc...none of the the rigs for SuperWhy ( http://www.youtube.c...h?v=E6cbU09doxc ) performed better than ~18FPS, alone, on the best box in the studio.

Me neither, SESI is working actively in the viewport side, so far is still faaaar away from the XSI performance which for me is the reference in this field.

Basically my opinion is that the design of the tool is really succesfull something that basically haven´t changed in more than 10 years is a success.

The implementation is a different thing and here Houdini is old, and the problem now is that Houdini is trying to add new features over and old architecture that obviously doesn´t scale.

So like two years ago the conclusion is that the implementation needs a change. At least for me.

Link to comment
Share on other sites

but then I wander over to an animator's desk and see the poor bastards fighting with 3 animated characters, 40minute ~250 frame flipbooks etc

then I'll see a vid of 10 characters happily animated and doing so at 30+ FPS in XSI

beyond the meat and potatoes of production rigging a lot of my time is spent trying to figure out how to get things faster (AdamJ and I cooked up a few good ideas) but have never reached the levels that other apps can achieve - especially in the viewport.

(if I'm alone in this and there are people out there getting better results than I have I'd love to hear from you)

Where is the speed going? Is it viewport draws? Is it SOP cooking? Is Object Level XForm caching turned on?

Link to comment
Share on other sites

Where is the speed going? Is it viewport draws? Is it SOP cooking? Is Object Level XForm caching turned on?

Definitely the most important is Viewport Draw.

Just try to move the same amount of polygons using cached geometry in XSI and Houdini ou will see the difference.

Link to comment
Share on other sites

I have to agree with michael. Nevertheless speed is not the only thing in viewport area to consider. I watch everyday animators working both in Houdini and xsi. Unfortunately the way how Houdini deals with handles, tiny objects, semi-transparent surfaces in viewport makes animating really painful in it. I'm not even sure how to describe it precisely, but once your character has lots of handles, helper objects etc, some with transparency and/or your scene is in a big scale (units), grabbing things in viewport becomes nightmare. You constantly loose a focus of handles or deal with clipping plane. Things like locking axies, orienting handles always are far for quick disposal. The whole viewport interactivity side of Houdini needs real attention. Are we intended to use a mouse in viewport or not? The more manual precision our work needs, the less Houdini support us. Some discrete look toward modern interactive application would be helpful here. I don't care if nodes and wires in Houdini will look like those in ice. What I really care about is if they will be as easy to connect and maintain.

As to proposals for Houdini 11 (12 more likely) small additions (unordered):

1) HOM access to cops.

2) Enhancements to tree view, basically making it fully interactive control of nodes (copy/paste/move/parent/replace/selecting nodes in different subnets etc).

3) The same goes for material pallete. Currently you can't even move materials between networks with it.

4) Practical implementation of Categories across whole Houdini.

5) Rearrangement of vops/shops/vex-vops etc. There is a whole backward compatibility garbage, and yet there is a lack of important features like layering materials, scripting support for vex code generation (similar to RAT), which would allow things like texture conversion on the fly etc.

6) Properties editor. Again infrastructure is there, but there is a lack of interface to it. We should be able to easily add/replace/remove/copy properties between multiply objects while seeing the whole picture of a situation (both on object and materials level). I imagine this could be a mode of tree view (or spreadsheet) with properties in columns and objects in rows.

7) Full support for mental ray materials.

8) More procedural geometry shaders, like point cloud instancer, cvex-sop procedural geometry.

Link to comment
Share on other sites

  • 3 weeks later...

It would be sweet if for dops when the solver is run, for each object it would create a curve/path based on points with an instanced object attached to it. This way once you've cranked out the simulation, instead of needing to render a large cache of bgeo, you can have just one instance of geometery saved, and possibly be able to dop hundreds of things based. Pretty much merge pops and dops like some one said. Then you could go right in an animate the sequence, with key frames, or chops. I wouldn't even care if it was slower, because the over all pipeline would be so much better.

The ubershader would be good... I keep on growing my own the more I work on my thesis. It does become heavy for a file size for something the size of my project like a 1mb per an a copy is insane when you do an entire junkyard. It would be great for small little projects, or fast needs. Especially if it was built into Houdini as oppose to an otl, so I can just select it from a menu and then rip out the guts I don't need(currently I just rip the guts from almost every other shader and build it onto the reflective shader). If the default of it was organized into nice sections with netboxes it would be a plus, too. Just put an on and off switch with the defaults off for each folder heading with diffuse(BaseColor) defaulted on. A test switch at the diffuse level would be good, a toggle that would lock the regular diffuse colors and turn it to 50%gray lambert when you need to just test any of the other parts like your irradiances, or your reflection separate to know what is screwing up the shaders look.

ambient/lambert Header

-Color Map

-specular

-reflection

-occlusion

-irradiances

-displacement -True Displacement toggled off but on this tab not hidden or in the properties tab, sometimes all you need is a bump map....

-properties

+all those other things I didn't mention like Subsurface scattering.

...enough slacking time for me, time to get back to work...

Link to comment
Share on other sites

It would be sweet if for dops when the solver is run, for each object it would create a curve/path based on points with an instanced object attached to it.

Can't you just extract the transform animation using a Dynamics CHOP? It you would then be up to you as to how to use it.

Link to comment
Share on other sites

Can't you just extract the transform animation using a Dynamics CHOP? It you would then be up to you as to how to use it.

As edward said you can use CHOPs to tack your transforms and create a path. Is easy and very useful.

Link to comment
Share on other sites

This is driving me insane: keyboard shortcuts are mouse-context-sensitive, which means that if you're hovering the cursor over a network pane and press "w", you'll add a tree view to it, but if you press the same key over a scene view, you'll toggle between shaded and wireframe. That's all fine and dandy, however, there are some special cases where this doesn't make as much sense. Mostly when you have a dialog box opened and need to type something in it. Something that happens way too often to me - editing an inline VOP in the built in editor, and the mouse cursor is blocking a word. I move the cursor off the word, type something only to realize that behind the editor window I just unleashed a barrage of mostly painful activity due to the fact that my key strokes where sent to wherever the mouse is hovering. This leads to an endless hide and seek (specially in smaller fields) where i have to chase the mouse away to see what I'm typing, but be careful not to push the cursor too far off or else I wouldn't be typing in the field anymore.

I'm actually not sure on how to enhance this behavior, but it's definitely far from perfect.

cheers,

Abdelkareem

Link to comment
Share on other sites

That sounds like a bug with the text editor widget? For regular parameter input fields, it won't type elsewhere even if I move my mouse outside. The focus stays inside until the Enter key is pressed or I click on somewhere else. I can't see why this behaviour can't be the same for the text editor widget.

Link to comment
Share on other sites

-Utilize the GPU and/or OpenCL to speed up interactivity over the whole application, as well as DOPs/POPs.

-uneven sphere prims for ODE solver; support for all of Houdini's constraints

-integrated Bullet/HOT

-same Spacebar + LMB/MMB/RMB for channel editor table view (spreadsheet), as is used in the graph editor

Edited by goldleaf
Link to comment
Share on other sites

Thought of something else. It would be cool if, by adding a modifier to the Q hotkey (for repeating the last operator), you could repeat the last operator, with the same settings that were last entered. Could be really handy.

BTW, thanks to anyone who works on Houdini and reads these posts! You're doing awesome! Thank you!

Link to comment
Share on other sites

  • 2 weeks later...

1.SSS like either 3Delight or Renderman quality where we can use displacements on top of it will be good if its fast

2.Full Utilization of Multi CPU and Multi GPU. I want to use 4 Gpu cards each having 2 Gpu processors with QuadCore Quad Processor Xeon with 32 GB of RAM on my machine...

3.Fur renders can be much faster

4. Point based GI and Brickmaps in Mantra will be good

5. HQueue can have more gui options like graphs and a very powerful Python API along with Mailing ability after the render tasks are finished.

please help us

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