Houdini 12 Wishlist

[Stalkerx777]

Ability to move objects in viewport with middle mouse BTN , outside the handle!!! Like in maya, xsi.... It would be so helpful for animation. Please add this feature! IMHO, it is must have for animators. Right now it's tedious to grab handles and switch to "align to view" , and then aim your mouse at the handle.

Edited March 21, 2011 by Stalkerx777

[Dennis]

-vopnetworks on the object level, the objectnode should have a vopnetwork like container where You can do all kind operations (vector, matrix,...) on all parameters.

I would just love a feature like that.

Other than that I just want SPEED and the possibility to mix materials without having to enter the actual VOP Network.

[LaidlawFX]

the possibility to mix materials without having to enter the actual VOP Network.

I'm confused by this, and I've heard it many times. I don't write the software so you don't have to answer. I like it and understand it pretty well so maybe I'm a little blinded now.

Would you like something that is simpler in control like Maya's hypershade and 3dsmax's material palette, with more global ubershaders shaders that you can wire together, or do you want something like an all python shader like prototypes shader? or are you leanign towards something else.

Vops gives you the possibilities to makes shaders more completely than any other nodal base shader outside of proprietary render-man slim based packages. It hands down beats everything for complexity, like maya, modo, 3ds-max, xsi, or slim like plugins. Also with their surface model it is very similar to wiring together these controls even though you are in vops.

I complain about better openGL, a better default material shader set, and more documentation. Also better and more education programs for this stuff like the third party cmiVFX. I just get confused when I hear this comment.

-Ben

[Dennis]

Laidlaw, you are right. I also like the way you can create materials in Houdini better than any other system and I would never want a system like 3DS Max instead.

What I want is an additional layer on top of VOP shaders where I can just blend complete materials.

If I have created two rather complex materials separately from each other and have their parameter interfaces set up really nicely I would not want to copy and paste all the nodes from one material into the other material, mix them internally and create the whole parameter interface more or less from scratch. To keep it short, I don't want to create a third material to mix them together but just have another node do that for me and keep my materials untouched.

I hope this explanation clears things up a bit.

Edited March 21, 2011 by Dennis

[LaidlawFX]

Laidlaw, you are right. I also like the way you can create materials in Houdini better than any other system and I would never want a system like 3DS Max instead.

What I want is an additional layer on top of VOP shaders where I can just blend complete materials.

If I have created two rather complex materials separately from each other and have their parameter interfaces set up really nicely I would not want to copy and paste all the nodes from one material into the other material, mix them internally and create the whole parameter interface more or less from scratch. To keep it short, I don't want to create a third material to mix them together but just have another node do that for me and keep my materials untouched.

I hope this explanation clears things up a bit.

That make sense, so shop level outputs for all nodes, and a python based blend node at the shop level that you can call as a shader.

That's something that would be very useful.

[zarti]

... .

To keep it short, I don't want to create a third material to mix them together but just have another node do that for me and keep my materials untouched.

...

yup ! sometimes shorter is better =) and i agree with you in there ( shading context primarily )

from my very modest pov , i think that actually ' something ' is missing . maybe a medium layer which keeps dealing with the increasing complexity as you build the material . at the same time this ' medium thing ' could make possible that certain subnets , as the first thing that comes into my mind , could be manipulated / shared / referenced between materials and accessed from upper levels too ... pardon the blurriness guys =)

i do not know exactly , but in short ... i feel something is missing there in order to be more productive .

... and something else ; more optimized Medium-Size parts offered by hou-makers . not a must , but helpful imho .

in fact i was referring to similar things when i posted few posts above " tools built with houdini's own tools " .

those wd be a kind of documentation in themselves too .

--

...

I complain about better openGL, a better default material shader set, and more documentation. Also better and more education programs for this stuff like the third party cmiVFX. ...

+111

.cheers

[pbowmar]

I complete agree about a Material Mixer thingy, but IMO it has to be done "right" or it won't be useful.

By "right" I mean it has to generate VEX code like VOPs does, which of course allows custom attributes to control the material mixing etc.

VOPs already offers this, but at a level that doesn't please people...

Cheers,

Peter B

[efx]

I agree most of stuff so I don't mention about them.

I think that doing everything is obviously hard, especially in short term.

So, I really appreciate it if SESI can provide pretty good "HOW TO" or better help for especially compiling HDK for Linux(may be fine already, but), Win, Mac.

Already some nice guys post nice tips and how to, but these should be "officially" in Wiki or Help.

Then I guess more people can make and support for better tools.

And I want them to be focused on improving SPEED!!

I just needed to test the same thing with Houdini and Ice.

I like houdini but Ice was unfortunately much faster. Off course this does not mean Ice is better for everything.

Anyway, I wanna use Houdini.

that's all!!

Cheers

[Dennis]

I complete agree about a Material Mixer thingy, but IMO it has to be done "right" or it won't be useful.

By "right" I mean it has to generate VEX code like VOPs does, which of course allows custom attributes to control the material mixing etc.

VOPs already offers this, but at a level that doesn't please people...

Cheers,

Peter B

I like the idea that it would generate VEX code.

Maybe an easier way to incorporate this into the current system would be to leave the shader building paradigm as it is and just handle the problem on a parameter interface level. I would be happy if I could for example drop in two digital assets like "metal" and "rust", drop in a blend node and the parameter interface is built automatically for me. Therefore we would need to have the possibility to define the way the interface is built while creating those digital assets. Something like a rule based interface builder.

Edited March 22, 2011 by Dennis

[LaidlawFX]

maybe a medium layer which keeps dealing with the increasing complexity as you build the material . at the same time this ' medium thing ' could make possible that certain subnets , as the first thing that comes into my mind , could be manipulated / shared / referenced between materials and accessed from upper levels too ... pardon the blurriness guys =)

I think you are spot on. Personally, I kind of like the two layer effect of obj and sops, and the equivalent of shops and vops. I think adding a third layer directly would be too much. If shops had outputs and worked more like objects then I think you would get your fuzzy area, because you can just make a subnet if you need to get that medium level and if you don't need it you don't have to have it.

I'm afraid of them rolling back to the h10 and prior model with that type of medium step to combined the different shaders exactly. I want my multi-staging area for shaders like slim. It's awesome and soooo much easier to deal with, but the ability to combine shaders like a blend and subnets at object level would be sweet.

Edited March 22, 2011 by LaidlawFX

[LaidlawFX]

I like the idea that it would generate VEX code.

finality in VEX would be good, like if the compile parameter after you edited your node would save it as a compiled version. I don't get that thing exactly, but if it is suposively compiled it wouldn't have to redo it a render time.

I think if they also cleaned up the vops code so it didn't leave so much extra crap that would be helpful, too. Half of each vop's vex leaves so much extra code in there, and they could organize how it could compile better. It would take some work, but it could def be done.

drop in a blend node and the parameter interface is built automatically for me. Therefore we would need to have the possibility to define the way the interface is built while creating those digital assets. Something like a rule based interface builder.

I wouldn't mind a rule based interface builder, it would help a lot since stuff would need to be unique allowing you to call stuff better, and a set of basic rules would help with coding interface design better.

I'm afraid of it building the interface automatically for me, you would have to have one hell of a robust naming convention for that, or an extremely simple and clean cut, between two tabs type of thing. The more intricate it could get the more disaster I see it, but it would be one hell of an interface if it could do that. It be cool if you could elaborate more on what you think of that.

[brianburke]

I complete agree about a Material Mixer thingy, but IMO it has to be done "right" or it won't be useful.

By "right" I mean it has to generate VEX code like VOPs does, which of course allows custom attributes to control the material mixing etc.

It'd be great to see vex evolve into a class/struct based language a-la rsl. If vex was set up this way, we could still hack around in vopnets (a struct builder vop) without touching the majority of the shader or even having the majority of the shader live in the scene (for example a 'surface model' struct could be precompiled on disk and simply wired up in a vopnet). As it is right now there's a huge amount of redundant code/compilation....

I feel like this would solve a lot of problems people are having with the shading workflow and also provide optimizations.

edit: it'd be amazing to have full support for rsl2.0 in vops aswell (including support for structs)...

Edited March 22, 2011 by brianburke

[Dennis]

I wouldn't mind a rule based interface builder, it would help a lot since stuff would need to be unique allowing you to call stuff better, and a set of basic rules would help with coding interface design better.

I'm afraid of it building the interface automatically for me, you would have to have one hell of a robust naming convention for that, or an extremely simple and clean cut, between two tabs type of thing. The more intricate it could get the more disaster I see it, but it would be one hell of an interface if it could do that. It be cool if you could elaborate more on what you think of that.

Actually I haven't had any deeper thoughts on that. I was just thinking out loud. For the automatic thing I was also just thinking about a clean cut between the different materials via tabs and an extra tab for the blending. The different interfaces on these tabs however would have to follow certain rules or the material nodes need to have something like auto promoting parameters that I won't have to setup manually. I'm sure the deeper you wrap your head around something like this the more complicated it gets to make this thing powerful but controllable and not too hard to use.

Edited March 23, 2011 by Dennis

[zarti]

a.s.: actually i'm working on a set of DAs ( drawing primitives on viewport ).

what i was unable to 'achieve' , but think wd be useful to have is the ability to use Ordinary Geometry as Visual Guides ...

( see the first attached pic below ... )

1- the "radius" text attribute 'should be' always in the center of the radius line . in this case, this was easy because i used a primitive attribute .

2- the "bended arrow" which shows the direction in which the indices increase , is also an ordinary piece of geometry with the same attribute type like the above "radius" applied to it .

as you all already have guessed , turning on/off those pseudo-visual-guides wd give serious problems in a procedural environment .

( see the second attached pic below ... )

so here are my 'newest wishes' :

1- the ability to " declare any object as pure Visual Guide " ( something which appears only in viewports , or simply ; Hou doesn't consider its data down the flow )

( i modestly believe that this isn't hard to Do and wd be very useful )

2- the relocation of "Display Custom Attributes ON/OFF" inside the SOP context . maybe a new Node (?) ...

( iirc from some videos ive seen , in ICE you are able to visualize data with a rightClick menu over a pipe in their nodal tree ... . that is a nice implementation to be fair. )

.cheers

[zarti]

...

2- the relocation of "Display Custom Attributes ON/OFF" inside the SOP context . maybe a new Node (?) ...

( iirc from some videos ive seen , in ICE you are able to visualize data with a rightClick menu over a pipe in their nodal tree ... . that is a nice implementation to be fair. )

i think the Visibility SOP node is the place where those controls should be .

( maybe in parallel with those @display options panel for massive on/off switching . needs workflow testing maybe ... )

.cheers

[theflu]

i hope h12 has speed up, PBR van damme

(who is arnold )

[LaidlawFX]

I want the light linker list to be generated based on whether an object has a light/shadow/reflection/refraction mask or a category. Also if we have refraction mask there should be a refraction linker like the reflection linker, other wise get rid of the refraction parameter.

I want import block to be able to pick up call back scripts, and to not relative reference back to the object they were imported from or an option switch in the gear menu to disable this.

Also please cleanup up the syntax for the oparm list to be the same as, expression language, hscript, or python, there are too many different natives languages in houdini. Also some better help docs and examples on call back scripts, learning that stuff ain't fun when you don't have an example to go by, for standard task like calling multiple render buttons. Nobody wants to learn that by trial and error.

Legacy can kill, revolution and new is good every now and again, ask Thomas Jefferson, or the middle east.

[LaidlawFX]

I want change type to not keep the parameter when they are unchecked. like creating f_write1, f_write2, nearly consistenetly and geometry scale, display, control, type, orientation, or shaded mode from the null.

It would be nice if the null, could not accept shadow linking, as cited from the last post.

[abvfx]

One thing i would like is the option to make transform handles to be thicker. It may seem like a silly request but any form of character animation is pretty silly without thicker handles to grab.

[theflu]

-vopnetworks on the object level, the objectnode should have a vopnetwork like container where You can do all kind operations (vector, matrix,...) on all parameters..

Indeed.

this would be supercool!