Jump to content

Houdini 10 Wish List


Jason

Recommended Posts

  • Replies 184
  • Created
  • Last Reply

Top Posters In This Topic

I got a link in a mail from odforce so now I’m urged to reply. :)

Since I have a modeling fetish this is what I would like to see in Houdini ”X”. Xoudini?

Basically make it viewport centric and make it work really fast. Cram in all the cool intuitive stuff you could invent or fetch from other applications and make it work in Houdini.

I understand your modelling fetish, but there are other H users too. Node based approach and proceduralism have always been central features of H. Now you are asking to forget it all together and turn Houdini into another XXX clone. Though I do like your ideas about more modelling\texturing tools in H, I strongly doubt that most power-users are same enthusiastic about H becoming viewport-centric.

cheers.

Link to comment
Share on other sites

I completely agree with MADjestic. One dangerous fact - lots of newcomers wish to see ready to use things which could be easily done using existing tools (and most of the time studios develop own tools instead of using standard ones): uber shaders, sops (remember those doors/windows tools from 3dsmax?). I wouldn't like to see another one _a_bit_more_procedural_ Maya. Houdini was laconic software, easy to understand with only necessary base tools but who knows what will be Houdini X if SideFX will implement _all_ requests :blink:

Edited by hoknamahn
Link to comment
Share on other sites

I believe as you MADjestic that it is not everyones wish. I think that the proceduralism and destructive modeling can work together nicely though. If you could customize all keys for instance then you could assign PolyExtrude to say ctrl+shift+left mouse button and say ctrl+left mouse button to EditSop translate or something as easy as bringing back the rightclick for commit. And if you have pre-selection highlighting then you don

Edited by SoulVector
Link to comment
Share on other sites

Even destructive editing in the procedural network can be even more procedural. Take the EditSop for instance. If you would of have a History list inside the edit then you could easily step back in the modeling process which is many times a trial and error type of workflow. Why? Because undoing 20-30 step or duplicating an Edit takes away time and it would be an easy way to keep track of edits.

You can do this already by using a sequence of Transform or Soft transform SOPs instead of one Edit SOP.

Really, I'm all for modeling improvements (because there's a lot to be done) but if one wants nonprocedural fast subdiv modeling there's always Silo for 150 USD or Wings 3D for free. Why should SESI (who, as seen in this list, has lots of stuff to do :) ) spend time trying to implement something completely against the Houdini philosophy?

Dragos

Link to comment
Share on other sites

modeling request

I have a silo license so I am not bothered by workflow of organic modeling in houdini.

but if SESI developers really want to polish the subd modeling tools ,

please watch some of videos posted on silo website.

They are short but to the point!

http://nevercenter.com/videos/

while we are on the page of organic modeling , check out the uv tools headus uvlayout.

http://www.uvlayout.com/index.php?option=c...r&Itemid=38

Link to comment
Share on other sites

Personally I bought Silo in 2005 though I don't use it much. But I am an avid Wings user as you also suggest :) And it is a good question that you ask. Why should SESI care when their approach is procedural. And the same question did strike me for version 9 since after all they did change to a selection-action from version 8. And to be honest I can't give one good answer to that but to say that the more I can customize and streamline a workflow the faster and more personalized it will get.

We tried to come up with an answer in another thread on here, and I think the general consensus is this. If SESI wants to broaden their userbase, then generally the first thing people encounter in a new package are the modeling tools. If said modeling tools are frustrating to use, then very few people will get beyond that into the true power of the software. While modeling tools are not strictly Houdini's forte, they should still have something that's workable to not alienate the noobs ;).

Personally I'm happy with the modeling tools as they are... however I was one of the crazy few that did organic modeling in Houdini 2 (the dreaded model SOP), and believe me the tools are light years ahead of that. Having said that though, I'm not a modeler by trade and I can definitely see how they can be improved to make them better for people who do have a modeling background.

And I vote a great big 'no' to the non-procedural modeling suggestions here. That would be going back to the old days.... the old, dark fearful days, where modeling was like pulling teeth and the add SOP was your greatest ally (shudder)..

Link to comment
Share on other sites

just as Marc says, i vote a big NO to the model sop too, it simply makes no sense to hunt other apps that allready do that in a faster and more usefull way in this case, since i guess we all want Houdini to develop further in the animation and fx areas, it has a meaning the sidefx calls houdini a 3d-animation-package.. is there anyone missing modelling in motionbuilder??? modo, silo, zbrush, blender, wings etc. all those are there to give you the best modelling tools available and you can go from them directly to houdini, so i for myself miss nothing on the modelling side..

Link to comment
Share on other sites

I see how you have gotten over 1800 posts; I'd have as many as well if all I had in each post was a single character. :lol:

It was your cue to explain in further detail what you're talking about in regards to the realtime renderer and how it would be of benefit

Link to comment
Share on other sites

1. Non-linear animation editor (like maya TRAX)

2. renderable icons on nodes in vex builder (as slim, sler or shaderman);

3. render region tool as in XSI (with handle to rule Antialiasing quality), and make it more stable (now it often crushes Houdini)

4. work with many objects (exp. in UV editor) :unsure:

Link to comment
Share on other sites

It was your cue to explain in further detail what you're talking about in regards to the realtime renderer and how it would be of benefit

The benefit of a real-time renderer is pretty obvious, and is mentioned in that single sentence-- for use in games.

For the rest, which he chose not to quote, please see here:

http://forums.odforce.net/index.php?s=&amp...ost&p=43015

Link to comment
Share on other sites

The benefit of a real-time renderer is pretty obvious, and is mentioned in that single sentence-- for use in games.

For the rest, which he chose not to quote, please see here:

http://forums.odforce.net/index.php?s=&amp...ost&p=43015

Doesn't it seem like a complete departure from what their target audience is though? Most games have their own rendering engines these days, and it seems like a pretty competitive field to me. Anything SESI does in that regard would have to be on top of their high end tools work, and so I doubt it would be worth much to anyone.

M

Link to comment
Share on other sites

Doesn't it seem like a complete departure from what their target audience is though? Most games have their own rendering engines these days, and it seems like a pretty competitive field to me. Anything SESI does in that regard would have to be on top of their high end tools work, and so I doubt it would be worth much to anyone.

M

Totally. Houdini has a lot to offer a games pipeline I think. But for them to create a rendering engine wouldn't be worth the effort at all.

Link to comment
Share on other sites

With my little experience these are the things i really would like to see.

1 - Investment in putting the compositor up to date, specially important is the tracking, rotosplines and paint tools.

2 - Integrate the fuzzy logic engine from Massive Software, this would bring so much power to Houdini... why reinvent the wheel? is it possible? Also, better integration so we can import/export to Massive.

3 - Higher level manipulation tools (rotate camera/object based on a line, on a plane, on a point) Find camera lens and position based on horizon and line adjustments (look at sketchup)

4 - Better production ready shader library compatible with prman/mantra/mental ray (the shaders should compensate do the behavior is coherent on all three render engines). Common production shaders like car

5 - PSD integration to be able to manipulate textures in PSD format from Photoshop and have a proper layer manager inside Houdini. This would streamline the texturing workflow.

6 - Full support for Mental Ray

7 - Sound filters/gates to the chops module, this module seems a bit left behind in a way.

8 - Animation Layers

9 - Motion capture High level editing tools, for this i imagine a intermediate character like the one in MotionBuilder could do the trick of abstracting whatever the rig is thrown onto it. Specially useful would be path manipulation so we can modify walks easily.

10 - Bundle PFTrack tracking engine inside Houdini as a node would be a great time-saver on many many things.

Link to comment
Share on other sites

I vote a strong "NO" for SESI spending countless programmer hours developing a more silo-like modeling tools. Personally, I use Max for all of my non-procedural modeling needs, and won't be using Houdini for that anytime soon. And to capture a new market, it doesn't just have to be as good as max/maya/silo/zbrush/etc it has to be "better." This would be a very large undertaking in a very saturated and non-lucrative market. If the free-apps are even starting to pop up, it doesn't make a lot of sense to turn a high-end effects program into a $20 modeling utility.

I think Houdini's place is proceduralism and animation, so the main-stay stuff, particles / dynamics / animation etc should get the most attention. The reason I'd opt for non-procedural editing in COPs and CHOPs is because it's very tedious to get these "large" and folder-based file types in and out of Houdini. So, for operations that would need an effect / then an edit / then an effect on top of that, it's definitely more efficient to have it "in-software".

Static, non-procedural geometry however, this issue rarely applies I think, and at the most it's versioned and usually always at the start of the pipeline in terms of rigging or procedural scene etc.

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