Houdini 9 Wish List

[Mario Marengo]

Mantra improved a *lot* in this last release (and I'm not just talking about IPR), and I know some more resources are being diverted its way, so... exciting times ahead, people!!

Here's my pie-in-the-sky, all-in-one, who-needs-sleep, Mantra/VEX wish list (and look sharp coz it'll all change by tomorrow! ;-):

*. Something similar to that other renderer's "gather()" construct -- or some similar per-trace construct (with the no-hit case handled as well, natch). While implementing something like this, maybe do one better than the other guy, and allow for a user-defined sampling distribution (maybe using little textures of a parabolic projection of the hemisphere a-la McCool?) -- or some other back door that the user can use to help things converge faster.

*. Read-write access (persistent writes, that is) to the various caches (irradiance, pointclouds, etc) from VEX (with "cachelifetime" control?). And of course, unification of the various cache file formats -- but this is likely happening already(?) -- would be nice.

*. Related to previous: extend caching formats to support (labeled) user attributes (of the base types).

*. Improved accuracy on ray hits (rayhittest()) for some surfaces (NURBs).

*. Oh yeah, those long-time favorites: Time derivatives (time,dtime,dPdtime), arrays, ray labels, multi-segment MB, texture-baking directly from inside a shader (onto a 3d-texture format), a world space (haha, aren't I annoying!?)

*. Since the rendering side is not opened to the HDK, it would be nice (make that, *NICE*) if VEX provided an "Rx Library"-type thing: a dso with an API to some of the important Mantra bits:

a. all the noises (ri_hnoise.so is currently incomplete),

b. texture lookups for all the formats (environment, texture, shadow+dsm),

c. read/write for 3d formats (i3d,tbf, -insert new unified format here - ),

d. render state info: the usual set, but with support for user attributes (i.e: to enable message passing between shader and dso)

e. An "Ri Filter"-like API for IFD would save people a lot of grey hairs from cobbling together their own IFD parser/filter in some ungodly scripting language ;P

*. Here's dreaming: open up VOPs to the HDK! No; really!

*. Things to better support mixed (Mantra+RmanCompatible) rendering environments:

a. (VOPs, general) add user control to the compilation stage.

b. (VOPs, rman ctxt) let user set the compiler+flags

c. (ROP) make the prman rop more generic so one can add/remove options/attributes from/to the basic set (this may be impossible, dunno) -- some way to customize a rop for rman-compatible-renderer-X without SESI having to keep adding to the hard-coded list.

Oh, and after doing all that, don't forget to plug MarkE's brain to the Insta-Doc machine so it's all documented in beautiful low-level detail

There's probably more that I'm forgetting, and I *know* that none of the above is news to the developers, but since we're listing stuff, well, it can't hurt, right?

!!Rock on, Mantra!!

Cheers.

[Marc]

I'm sure nothing we mention in this is news to the developers... hopefully it helps SESI get a clearer view of whats needed out there in the wild (no, not your Wild, CORE )...

[meshsmooth]

http://www.sidefx.com/index.php?option=com...light=selection

here i made a RFE for houdini 7

here is my rant... surgestions were made on it but it stil holds together

the group selection could be passed from operator to operator.

Consider the faces selected after a polyBevel.

If you have an "inpsel" (short for input selection) group that was created and over written by every operator with its alteration to the current selection. then you could use this to increase the procedural ism in your network. The group would have the unique probity of being able to have more than one selections named the same name so it will not be a regular group but this should be manageable because the selection is only relevant to the sops it is wired into.

If SESI was to go to the trouble of making this feature they may as well add the selection modifying tricks of interactive modeling programs, like growing and shrinking selections, converting from one type to another, boundary edge selections, etc.

inpsel short for input selection

It could be controlled with expressions like

inpsel : to select the previous input selection

inpsel(e) : to convert the input selection to an edge selection

inpsel(v) : to convert the input selection to an edge selection

inpsel(f) : to convert the input selection to an face selection

inpsel(boundE) : to select the boundary edge selection

inpsel(+) : grow the selection

inpsel(+,+) : grow the selection twice

inpsel(-) : shrink the selection

inpsel(-, -, boundV) : shrink the selection twice then select the boundary vertices

etc.

If the preference was set to use input selections where possible then expressions could be created with keystrokes. Say on a grid some faces in the center are selected then extruded with say 3 divisions. Then a PolyBevel is added with the selection set to inpsel(boundE) selecting the edges on the outside of the faces selected. Append a polyExtrude inpsel(f) to select the faces and extrude them. Append another polyExtrude this time inpsel(+,+) to expand the face selection the faces ?c.. etc.

As an workflow inpsel would be a default selection unless the user manually selected any faces. If the user hit a hot key to grow the selection it would be added to the command inpsel(+) as they keep using selection modifying operations they add to the command e.g. inpsel(+, +, boundE, f, +, e) If the user at any time makes a manual selection of faces the selection converts to a numbered face selection. The expression is committed when the user right clicks

If inspiration is needed just look at Wings3D and the like to see what procedural modification of selection could be like. Check it out, it is on windows and Linux

[edward]

-- hair solver in DOPs, and a hair toolset

23014[/snapback]

There's no hair toolset right now, but there's the Wire Solver in DOPs which is more or less a hair solver.

[digitallysane]

There's no hair toolset right now, but there's the Wire Solver in DOPs which is more or less a hair solver.

23027[/snapback]

I know, but as you said, it's "more or less". Too much effort it's needed to create a basic hair setup. I think a full hair ("styling" if you wish) toolset it's needed.

Dragos

[eloop]

Not sure what you mean here Mario ? A HDK implemented VEX function be turned into a VOP with a bit of "outer" and "inner" VEX wrapper code on the type properties dialogue. I managed to get the HOT functionality into a VOP by doing this after a bit of experimenting (some docs wouldn't go astray here :-).

-Drew

*.  Here's dreaming: open up VOPs to the HDK! No; really!

[Mario Marengo]

Not sure what you mean here Mario ?

Hey Drew,

Well, here's the thing: the way I see it, there are different kinds of VEX-dso's:

A ) A plain function that holds no state (just some global initialization) and is meant to be called once per shade point. It's generally "cheap" to compute, and all it needs is its parameters and the optional init/cleanup functions. This would be the most common type.

B ) A function that fronts for (is an API for) the instantiation of a persistent object (usually with the lifespan of a frame). The object needs to hold state (which we'll assume is "expensive" to create) and so the interface has two stages: 1. Parameterized construction, and 2. Per-shadepoint sampling or "lookup". Several instances (parameterizations) may be needed per frame.

C ) A pre-processing function. One that is only meant to exist within Houdini (as a VOP), because its job is to, for example, pre-process some in-session information and encode it for later use by types 'A' or 'B'. Like the others, this also translates into an inner-code call to a custom vex function, but the construction of that call string is based on resources that will no longer exist at render time.

Type A is a piece of cake to wrap up as a VOP -- the inner code is just a call to the function. Sprinkle some outer-code includes as needed and we're done.

A typical example of this type would be a custom perlin or worley noise.

Type B is a little trickier. Here, instantiation usually returns a unique handle which is later used by the lookup calls. The trick is what form the handle takes in the context of SIMD, but it's quite doable. An example of this type would be any function that needs to process a file -- say, an importance sampling distribution for HDR environment maps, where each unique file reference in the shader(s) becomes a separate instantiation (+handle) of the sampler (whose lifespan is the duration of the parent process).

Everything is fine while rendering frames with Mantra, but an interesting situation develops when this type is wrapped up as a VOP. Let's say the user is building a vopnet with the shaderball displayed in a viewer. Here the parent process is Houdini, so if the user plunks down our VOP and references 10 different maps while experimenting, there will now be 10 unique instantiations in RAM, 9 of which are no longer needed. And there's nothing the dso can do (AFAIK) to distinguish between rendering inside Houdini (shaderball) and rendering "for real" (Mantra). Not a big deal I suppose, but things get even more interesting for the next type.

A simple example of type C, would be a custom encoding of a RampCOP.

Say your custom VEX function takes a string representation of a ramp -- it's really an encoding of a COP but your function doesn't care where it came from as long as it's a valid string that it knows how to process. The VOP, on the other hand, takes a reference to a RampCOP and is responsible for encoding it as a string, which it then inserts in the parameter list of the dso function call inside the inner-code. Here now, we have a situation where there needs to be a clear distinction between "I'm a VOP" and "I'm a VEX function". And there are other subtleties in this case: for example, if the parameters of the COP being referenced change (the user tweaks it), then the VOP needs to be notified so as to re-encode it, but "it", in this case, is a singular instance of the RampEncoderObject (the VOP), not some handle-based scheme as in 'B', because the COP reference itself hasn't changed (just its parameterization).

I've managed to circumvent the 'C' problems by implementing the encoder as a custom (HDK) expression function. This works well when used inside a SHOP parameter, but suffers from similar problems as 'B' (and more) when used inside a vop net. So, very "hacky" and a long way from "bullet-proof".

Sheesh! Sorry for the long post, people. :ban:

Anyway; I *think* that a custom VOP, by virtue of knowing that it's a VOP, would be able to handle unusual cases like 'B' and 'C' (and the memory management issues associated with them) properly. But I haven't by any means explored all possibilities, so there may be ways to deal with all this without custom VOPs.

I'd love to hear other people's ideas on this.

Cheers!

[3__]

ah, ye olde wyshlyste...

most covered on the forums already:

1. most sops that should output groups don't, polyextrude

is an exception and its group output tab should be standard

for all sops that create geometry.

2. edge groups. these should also be supported as a soup group output as mentioned above.

3. vops arrays - for handy little things like unbiased interpolations...

4. there should be a more robust method of spatially identifying

geometry selections. hopefully to prevent small topology tweaks from

breaking the rest of a sop network.

5. a pop-up list of available attributes/variables when the '$' symbol is typed

in an expression field.

6. an option to store/use shadow-maps in memory when a path isn't specified

(for shop-less lights).

7. The light aperture should be lockable to the light cone via checkbox.

8. more efficient handling (display, interaction) of very heavy scenes.

9. multiple-output shader vop-networks {where each output is a shader in shops}.

10. bring back ICE-style time offset sliders & f-curve for binary cops.

11. fast 2D tracking for cops.

12. fix cops epileptic display refresh, bring back H4-style dual displays.

13. next/previous image-in-directory hotkeys & buttons for mplay. or add an

optional file browser pane.

[sibarrick]

8. more efficient handling (display, interaction) of very heavy scenes.

23055[/snapback]

What are you thinking of here? beyond the interactivity option that already exists, something like the old Prisms poly culling on a per object basis or a LOD thing, or something else?

[stevenong]

Hey cpb,

7. The light aperture should be lockable to the light cone via checkbox.

23055[/snapback]

You can do the above through the light's handle. RMB on the handle & select "Link Cone and Frustum"

Cheers!

steven

[thekenny]

i miss the storage of jack positions while editing geometry. ( like Cplanes or views )

It was a nice feature ripped from our hands ever since 4 arrived on CD.

-k

[michael]

it would be nice to have options for changing the display type when tumbling - shaded display then BBox while tumbling etc...

What are you thinking of here? beyond the interactivity option that already exists, something like the old Prisms poly culling on a per object basis or a LOD thing, or something else?

23057[/snapback]

here's the start of my list:

1) expose more of the interface to the user through scripts/hotkeys etc

2) more info/sorting options in all file dialogs

3) HDA parameter panes/custom panel builder, ideally something wysiwyg that can be used for both custom panes and HDAs

4) add Display/Template/Render icons to Tree View and object browsers

5) DOPs eg files in real world scales/units

[Guest Guest_Pbowmar_*]

it would be nice to have options for changing the display type when tumbling - shaded display then BBox while tumbling etc...

You can do that already, if you're using Houdini 8

here's the start of my list:

[michael]

You can do that already, if you're using Houdini 8

here's the start of my list:

23073[/snapback]

well then it was a good idea last year

[keltuzar]

quick question,

when can one know which feature will be implemented and which one will be thrown to the garbage bin?

[pbowmar]

The day Houdini 9 goes gold, or possibly later Seriously, some major stuff gets snuck in the last week or two before Beta finishes.

quick question,

when can one know which feature will be implemented and which one will be thrown to the garbage bin?

23077[/snapback]

[malexander]

  The day Houdini 9 goes gold, or possibly later smile.gif Seriously, some major stuff gets snuck in the last week or two before Beta finishes.

Yes, the major stuff that likely won't work for that major version.

We're seriously trying to cut down on that.

[keltuzar]

so it is for a fact that it will be a 9.0 version.... ie there must be some new stuff adding into the software from its 8.0 version rather than simply polishing up the software and making it more versatile and releasing an 8.5....?

[malexander]

"Houdini 9" is simply a convenient way to say Houdini8 + 1, the next major version after 8. In the past major releases have included 2.5 and 5.5, so the next major release doesn't *have* to be 9. Release version numbers depend on the alignment of the moon, continental drift, length of the growing season, etc..

Fixes and minor feature backports are continually added to 8.0 builds, making a minor releases somewhat less necessary than they used to be (a la 3.1, 4.1). However, if major feature 'X' must be released now for some reason, a minor release may be considered (8.x). But it's not very common.

The careful reader will notice I've not said much either way in this post

[MADjestic]

a)CFD + instruments to handle 50 mlns of particles on an average hardware.

b)Hardware Shaders and possibility to build Shaders v3.0 in VOPs. (is it possible already?)

c)I don't know if it's possible - but could SESI possibly consider lowering the price of Master License to, say, 10K$? - so that an artist could afford one, not a studio.

Z