Houdini 13 Wishlist

[SpencerL]

ESC key to instantaneously interrupt in SOPs and POPs similar to how it currently does in DOPs.

[symek]

This could be a issue tied with the ogl support of the shaders. In programs like vue, modo, or zbrush your shader to viewport connections are very direct, locked in so they can't be broken or moded,

OpenCL vex virtual machine would solve that problem . Seriously, quite a subset of vex is compile-able with GLSL, most noises, standard (non-pbr) lighting models, math, textures, which is enough to have an additional port in surfaceOutput for OGL. It's would be an user responsibility to wires things OGL can handle. (Something like a context switch would be handy too).

[Korhon]

ESC key to instantaneously interrupt in SOPs and POPs similar to how it currently does in DOPs.

Yes please!!

[symek]

Yes please!!

You wimps!

(it seems like interruption is done on per Sop basis by guarding expensive parts with some sort of UT_AutoInterrupt.* - which means either it doesn't work as expected, or it has to be used more often, ...or we need multi-threaded GUI...).

[sliver]

May be the most important for us : It should not be purchased by Autodesk

Edited December 9, 2012 by sliver

[zarti]

' wireless ' vop nodes ..

.cheers

[jonp]

"Detail" attributes in COPS that can then be worked with in VOPS, then exported to images as metadata.

[3__]

' wireless ' vop nodes ..

Like this?

http://web.archive.org/web/20110722200545/http://kk.kema.at/files/gfx/werk2.jpg

[zarti]

not sure what that image represents but here is what i meant with ' wireless ' :

something similar with ObjectMerge_SOP when it is referring to any node within the same SOP network .

so , in VOP contexts , there wdnt be necessary to drop 3 , 4 or more position_VOPs .

but just one instead and referring to its value through a ' wireless ' input parameter .

or for cases when we drop only one position_VOP and extend its connections into 3 , 4 or more other vop nodes ( usually far from the source vop node ) .

less wires .. =)

p.s.: initially i was ' inspired ' by WirelessLink tool found in Digital Fusion .

in there , it acts more like ObjectMerge_SOP but i think a similar ' technology ' wd be very helpful in VOPs context .

esp in SOP and SHOP states ..

.cheers

[LaidlawFX]

not sure what that image represents but here is what i meant with ' wireless ' :

something similar with ObjectMerge_SOP when it is referring to any node within the same SOP network .

so , in VOP contexts , there wdnt be necessary to drop 3 , 4 or more position_VOPs .

but just one instead and referring to its value through a ' wireless ' input parameter .

or for cases when we drop only one position_VOP and extend its connections into 3 , 4 or more other vop nodes ( usually far from the source vop node ) .

less wires .. =)

p.s.: initially i was ' inspired ' by WirelessLink tool found in Digital Fusion .

in there , it acts more like ObjectMerge_SOP but i think a similar ' technology ' wd be very helpful in VOPs context .

esp in SOP and SHOP states ..

.cheers

I know this isn't exactly what you want, but for cleanliness you can drop four position vops in front of each connection so you don't have wires running across the screen from one position vop. Mantra once it detect the first instance of a variable will store that. For instance subinputs to if nodes and subnets you can copy those a dozen times instead of using just one.

Albeit a more friendly wireless method linking structs and nodes would be preferable. Setting a variable and calling it later with out wires can clean up some strange messiness. It does scare a lot of code writers from vops to see massive spider webs.

Edited December 22, 2012 by LaidlawFX

[ikarus]

particle fluid surface needs to be able to output a field

[SpencerL]

Particle Fluid Surface SOP to have the option of using a Marching Tiles surfacing algorithm instead of the Marching Cubes currently used.

[Macha]

I'd like to see a better build in code editor. It would already help if it wouldn't pop up in a separate window but instead reside in the parameter pane.

[magneto]

When is all this supposed to happen? In March I assume?

Big thanks to SESI developers in advance

[Solitude]

particle fluid surface needs to be able to output a field

I requested (last May) that it outputs the field pre and post filtering in RFE ID #48420.

An alternative if you have it, is using Openvdb, since you have direct access to the fields being used to create the mesh from the particles.

[magneto]

Is Convex Hull SOP out of question for this round?

[SpencerL]

Is Convex Hull SOP out of question for this round?

It already exists....tetrahedralize SOP

[magneto]

It already exists....tetrahedralize SOP

Not really. The algorithm used in Tetrahedralize SOP does not scale well. It takes 15s for 100k points on my PC.

I meant a SOP that uses a dedicated convex hull algorithm like qhull or cGAL's convex hull.

[Solitude]

Not really. The algorithm used in Tetrahedralize SOP does not scale well. It takes 15s for 100k points on my PC.

I meant a SOP that uses a dedicated convex hull algorithm like qhull or cGAL's convex hull.

Presumably they are already using bullet's convex hull generation in dops -- I wonder if they can transfer that to a sop?

[magneto]

I never used Bullet yet. Does Bullet have its own convex hull generation tools?

I just tried adding a 100k points object as an RBD Object using Bullet's "As-Is" with "Polygons as Convex Hulls" option which seems defaults, and Houdini UI froze when I switched to DOPs for about 10 seconds.

I wonder if it's actually using Tetrahedralize's convex hull code