graham
The AttribWrangle and AttribVOP SOPs are essentially point/prim/vert attribute manipulators.

http://www.sidefx.com/docs/houdini12.5/nodes/sop/attribwrangle [sidefx.com]
http://www.sidefx.com/docs/houdini12.5/nodes/sop/attribvop [sidefx.com]

Yes that slipped my mind. I was using it in my Color SOP

Although it still has some limitations such as not being able to use getbbox, relbbox VEX functions. There is also the major issue of being restricted to group types that match your attribute type, unlike AttribCreate SOP, where you can use a point group to create primitive attributes, as it does automatic conversion.

My wish would be an OpenVDB-based Flip solver variant. Also, an OpenVDB-based SDF representation for rigid bodies would be cool, too. (Although I heard there's some technical difficulties regarding that, but it would definitely worth trying )

Also, I wouldn't like to feed the flames, but whoever finds Houdini “hard” to use, I recommend learning about digital assets ASAP. It's true that Houdini doesn't always provide all the high-level tools one wants – but you can always build it. It's a great thing.

Also allow me a shameless plug: we (a few friends) have a completely free digital asset library called qLib – lots of example images on its facebook page, for example –, which can easily have some of the tools that are felt “missing”.

(What I realize on an almost daily basis is that one thing that's missing from Houdini in default is easy and quick attribute visualizations, like this:

https://www.facebook.com/photo.php?fbid=534530209914101 [facebook.com]
https://www.facebook.com/photo.php?fbid=534534709913651 [facebook.com]

For me, the default Houdini visualization options just take too many clicks. Now whenever I watch a tutorial there are always moments when I think “now would be a time to drop a visualizer node there” – okay, I stop talking about how much I like drinking my own medicine )

Ah, a few more random things came to mind:

- CVEX-processing of mantra delayed load procedurals would be _really_ useful (e.g. then I could store only the relative lifespan of particles in the geo file, and generate pscale/width and color/opacity attributes while rendering – now I have to do heavy data-processing for that. But I'll ask this in the tech forum, perhaps I'm not aware of a solution that already exists)

- I know this'll sound vague, but the compositing component (COP) could get a bit more emphasis (both in terms of stability and in UI aspects). I think it's great, and in the long term it would worth to keep it going, for various reasons.

One long-term reason is that although right now “the” compositing app is Nuke, but this can easily change in a few years (anyone remembers Shake?), and having a solid background to build from would be a good thing. (Who knows if there won't be a “Houdini COP” variant a few years from now?)

- It would be really nice if ROPnet renderings were able to run in parallel to the main Houdini application. Pretty please?

Allow me a few personal-opinion remarks about things I read earlier in this thread:

- GPU-based stuff: I'm glad that others explained in more detail the issues with GPU-based “anything”, and I don't have to do that: generally it works _until_ you run out of GPU memory. It's also (probably) a big maintenance burden, so it's fine for relatively “simple” things like fluid sims, I don't think it's realistic to expect a GPU-based renderer. A particle simulator however is a different beast! (A good start would be along the lines OpenCL-based Particle Advect DOP or POP, perhaps…) Multithreaded _and_ GPU-accelerated particles would be reeal nice.

- “Be faster”: I think there should be a vote for the “top 3 nodes you'd like to be faster/multithreaded” to get specific answers (I'm guessing SOP context…)


cheers,

A more easy way to activate Licenses.

More HUD-space handles, at the moment we only have a slider.

+1 for COP love (:

Ability to use masks for subnets/HDA COPs using the side input
Working cook timers for COPs
Pixel Shader COP
Faster Compositing View if possible?


Overall the COP context is very powerful and intuitive, just needs a bit of enhancing.

riviera
My wish would be an OpenVDB-based Flip solver variant. Also, an OpenVDB-based SDF representation for rigid bodies would be cool, too. (Although I heard there's some technical difficulties regarding that, but it would definitely worth trying )

You can use a VDB sdf directly into dops for collision, set volume sample and put your vdb path in the volume proxy, and play with the sample subdivision like in the iso offset node to edit the resolution, works also with flip and smoke solvers too.

PS: I don't know if Houdini convert internally to standard volume primitive, but the speed is awesome with big terrains and flip.

alejandro

riviera
My wish would be an OpenVDB-based Flip solver variant. (…)

You can use a VDB sdf directly into dops for collision (…)

PS: I don't know if Houdini convert internally to standard volume primitive, (…)

AFAIK it does convert it. (Although the net result might be faster, easily).

What I'm talking about is to use VDB volumes to represent the velocity volume field of a flip fluid, for example. Ideally, this would mean much more efficiency and precision.

Right now one thing you can slow flip fluids to death is to try to simulate multiple thin strands or “squirts” of fluid, because:

- you need a very low particle separation value to get the fluid details right (if you don't have it, Reseed might even just kill your particles and you'll have practically no emission) – this means a high velocity volume resolution, internally

- once there's multiple streams, the simulation's overall bounding box starts to grow, and due to the high-resolution velocity (etc) fields, it slows down after the first few frames.

There might be technical difficulties I'm not aware of, but if all the internal volume fields of FLIPs were represented with VDBs, it would probably be much faster and more accurate (due to VDBs adaptive resolution nature). Even the FLIP solver's volume limits would became an utility instead of a necessity (ie. it's there to limit the growth of the flip fields).

Same thing goes with the SDF representation of rigid bodies. I find Houdini's RBD solver quite stable and accurate, but the SDF representation can be difficult to generate for things like:
- thin geometry that are not axis-aligned (e.g. a long thin box, rotated 45 degrees around two axes)
- self-intersecting geometry (e.g. parts of a skinned character)
- etc.
Again, the sparse or “adaptive” nature of VDBs would help a lot.

riviera
Again, the sparse or “adaptive” nature of VDBs would help a lot.

If you have data that is _not_ sparse, OpenVDB might even use more memory than otherwise. I wonder what happens if one converted a field of random noise values into a VDB and save both to disk as .bgeo, checking the file sizes.

It's not clear to me how much sparsity there is in velocity fields to begin with, so your mileage will vary with VDB velocity fields. For collision SDFs, the collision algorithm typically needs to know for a certain position in space, how far it is to the surface. In VDBs, this information will only be accurate around the narrow band near the surface.

edward

riviera
Again, the sparse or “adaptive” nature of VDBs would help a lot.

If you have data that is _not_ sparse, OpenVDB might even use more memory than otherwise. I wonder what happens if one converted a field of random noise values into a VDB and save both to disk as .bgeo, checking the file sizes.

I suppose VDB won't be that effective if you fill up a volume with random values, but I'd guess for most fluid simulations random values are not the case, so a more realistic test would be to compare (say) a flip tank sim velocity field stored in both a regular volume and a VDB one. (But it's a good suggestion, I'll do a comparison sometime.)

Anyway, the situation I described above happens on a regular basis where we end up large containers with “sparsely placed” fluids. That's why I suggested that a VDB-based flip variant might worth looking into (and that what I saw from VDB operations, they seem generally way faster than their “regular” counterparts).

Update: I did a quick test, of a 200^3 scalar volume, filled with a random pattern, and interestingly, the VDB version doesn't consume much more memory (regular volume takes ~30.5MB, vdb is ~32.5MB – also see scene file as attachment).

edward
For collision SDFs, the collision algorithm typically needs to know for a certain position in space, how far it is to the surface. In VDBs, this information will only be accurate around the narrow band near the surface.

I did some experiments with VDB SDFs and I see what you mean. To put it another way (not accurately, though) what would be needed is an SDF-type extrapolation for “empty” VDB volume positions (like in Primitive SOP->Volume Border Type: SDF).

This is an “interesting” shortcoming, especially that there _are_ SDF-related vdb functions, so clearly it's an intended use, but this behaviour complicates things. Is there no workaround for this behaviour?

riviera
This is an “interesting” shortcoming, especially that there _are_ SDF-related vdb functions, so clearly it's an intended use, but this behaviour complicates things. Is there no workaround for this behaviour?

Well, for FLIP the collision SDF only needs to be accurate within a certain bandwidth, namely enough to correct any particles that end up inside the collision objects, using the gradient to push them outwards. You can increase the bandwidth generated by VDBFromPolygons using the Exterior Band and Interior Band parameters, in either voxel or world space.

I've had success using 4 * FLIP particle separation for cached .vdb's, using the largest particle separation I'll frequently be testing with. While the resulting VDB won't be quite as compact as with a really thin bandwidth, you'll get good collisions.

This is a simple test of using VDB From Polygons to create both a collision SDF and collision velocities at the same time, then brought into FLIP using SourceVolume:

https://s3.amazonaws.com/vfx/zombie_vdb_source_vol.mp4 [s3.amazonaws.com]

Then those same cached VDB's are used as a VolumeProxy and sampled at half-res into a StaticObject for use in a (totally gratuitous) whitewater sim:

https://s3.amazonaws.com/vfx/zombie_vdb_source_vol_ww.mp4 [s3.amazonaws.com]

I tested at higher-than-necessary res for the VDBs: the VDB file containing both the SDF and collision velocity was about 28Mb per timestep, at a max res of . A character walking through water like this is a bit of a torture-test for FLIP, so good collisions are a must.

I can make post the .hip (without geometry I'm afraid) if anyone's interested.

Hi Johner,

What type of collision method did you use? particle or move to iso?
Because I have serius problems with the particle based method (particles leaking thought objects) only when I fetch the collision field and velocity with a source volume.

johner, your videos aren't working for me. can you upload them directly to the forum or post them some other way please?

zdimaria
johner, your videos aren't working for me. can you upload them directly to the forum or post them some other way please?

Save the link to disk. Play from disk.

Seems like Amazon S3 isn't giving back a viable MIME tag for the browser to know what to do.

I started a new VDB / collisions thread here [sidefx.com] to avoid cluttering up this thread.

johner
I started a new VDB / collisions thread here [sidefx.com] to avoid cluttering up this thread.

Cool, thanks, I was about to suggest that myself (I didn't mean to pollute with off-topic stuff so heavily… sorry for that)

Just let me re-state this: what I “wished” for H13 is a flip solver that's VDB-based _internally_ (which is quite different from building fields with VDB and passing them to the current solver, although that gives many improvements already).

I checked out the VDB white paper, and although it's very sparse (har har) on the subject, it says that it's possible to use VDBs for simulation purposes (Navier-Stokes is explicitly mentioned). I don't know if anyone did even a prototype of such a thing, though (in-house, or whatever…)

If anyone is feeling a little generous today, here are my simple but effective workflow enhancements

1. Changing a group name should update all group references automatically.

2. MMB-ing on menu parameters should allow cycling between menu items in a continuous loop, one by one. After the last item, it goes back to the first one.

This is a huge workflow booster. How many times you look at the viewport, and then look at the menu parameter, click and select the next one, look back at the viewport, and repeat it, instead of looking at the result in the viewport while changing the value without looking at the parameters, just like how numerical parameters allow you to.

3. Pasting copied nodes should update all the references based on where they are copied to.

If you are copying nodes or a node network inside or outside another network that is deeper or shallower than original, the references still use the old depth, and this requires the artist to update all references by hand.

So if you are copying a node that uses this expression:

point(“../box1”, $PT, “tensile”, 0)

and copy the node inside a foreach node for instance, then the expression will still be the same and break because now it would have to be:

point(“../../box1”, $PT, “tensile”, 0)

Collapsing a node network into a subnet automatically does this. It should also be done on each paste if the levels of depth is different between the source and destination.

4. Better support for multi-monitors.

5. Renaming nodes that use $OS, should update the group names.

I use the opname function but this should also work like opname in regards to updating group names automatically

Hope it's a modest suggestion for you guys. Happy Fridays

I know, the priority of Houdini is to be the best in special effects. I don’t know Houdini at 100% so maybe I can request some existing features.

Other:
1.To have the ability to offset the position of point numbers, primitive numbers,….
2.If there are 2 or more points at the same position, maybe point numbers should be display in columns with specials colors.
3.To have the ability to change all components color and components size. Example: color of the selected edge, color of the selected point,…..

Edges :
1.Edge snapping like Primitive Snapping( V )
2.“Display edge numbers” like “Display point numbers”

Curves:
1.To be able to manipulate interactively geometry curve like animation curve : Break slopes, align slopes,….

UV
1.Like “uvpelt” methodology, new algorithm to be able to have a cross shape from a cube (uvpelt = distorsion).
2.To be able to manipulate UV like others 3D package. A new uv node(or uv subnework) with a new window available with RMB like spreadsheet. The idea is to have a graphic wrapper of basic uv nodes. We manipulate “uv” interactively and nodes are generated automatically in background in the uv subnework.

Modeling:
1.To orient and/or move the transform gizmo (translate, scale, rotate) according reference edge(s), reference point(s), reference primitive(s) or reference objects(s) to manipulate a component.
a.Example with one reference edge : select a cube face, activate the good function (here edge blabla function), select a reference edge(1 edge of the cube for example). Now, the selected face(primitive) can be manipulating according the position or/and the orientation of the reference edge with 3 Results according the gizmo mode:
i.“Rotate gizmo” : gizmo position = selected reference edge midpoint position and orientation = aligned with “reference edge normal”
ii.“Translate gizmo”: gizmo position = no change and orientation = aligned with “reference edge normal”.
iii.“Scale gizmo” : gizmo position = selected reference edge midpoint position and orientation = aligned with “reference edge normal”

Animation:
May be a new window where we can choose one or more chopNetwork. The GUI read the contents of chop networks to be able to manipulate interactively animation clip like animation Mixer (XSI) or trax editor(maya). And all no common chop nodes are visualized like “special clips”. The idea is to have a graphic wrapper of basic chop nodes. So we will manipulate “animation clip” interactively and nodes will be generated automatically in background. If we will directly tweak chop network then all new no common chop nodes will be visualized in the Houdini trax editor like special clips.