I believe enabling 'thin walled' under the 'Geometry' tab of the MTLX standard surface or on the Quick Surface LOP would be the fix for 'thin' refractive objects. Not sure if that is what you're looking for though.

kodra
Is there a way to quickly change how the visualizer works?

For example, when you check the visualizer of an integer attribute from the info window, the visualizer assigns a random color to each unique integer by default.

I'd like to change it to "mark", in other words, just showing the integer itself as text.

I know I can click the edit button here:

Image Not Found

But it's quite weird that while we can toggle the visualizer from info window, if we'd like to change it we need to find the edit button at an entirely different place... it feels like the old info window got a pretty face but its functionality is as ugly as before.

You can CTRL click on the visualizer toggle to bring up the visualizer customization options. This existed in the previous MMB info window as well.

Here is a simpler setup without the foreach loop and using the new Sweep SOP, which for this case will be much faster than polywire and includes a ramp for the profile.

Cheers,
Scott

I'm not sure from your description exactly what you are attempting to do, but you could start quite simply by using a sweep SOP?

If you want to build something from scratch, you could also begin with an Orientation Along Curve SOP and Copy To Points, or even a Copy To Curve SOP.

Hope this helps,
Scott

OneBigTree
I take that as a big NOPE.
Pity…

The above selection will work correctly, and edge divide the correct tool for your example.

Unfortunately, it is quite an old node which means some legacy behavior which is probably unexpected.

In the case of edge divide, the order of your selection determines the direction/order of the new edges. So, if you select ‘around’ your box in one consistent direction, everything should work fine.

Obviously this is not a desirable interaction, and is a known issue which we hope to address.

Cheers,
Scott

It probably should mention the hotkey next to the RMB menu entry, but to be clear the hotkey inverts the base operation, which is slightly different than enabling it there via RMB.

Having said that, there is a prompt that says, “Press or Hold the midpoint key (A) to switch between merging at the targets point position or merging at the midpoint.”

Nevertheless, good catch!

McNistor
I understand the need to have the “group” and “target group” distinction and it does confer procedural power to the new SOP. I want that and I need it.
So in order to not give only flak, here's some constructive suggestions on how to not totally ignore the viewport functionality needed in direct modeling.
So, “group”(G) acts as both “target” and “source” when “target group”(TG) is disabled (default). So having points designated only to G (TG off) will produce something based on w/e is set by “output positions” (default - average value), like here:

Image Not Found

When the latter is enabled, w/e is in G it will snap/fuse to TG. This makes “output positions” rule obsolete, since G will snap/fuse to TG, for the case in which TG has only one point.

Image Not Found

For TG with multiple points, each G point will look for the nearest TG point and as the “snap distace” increases, they will ultimetely collapse into a single TG point. This is harder to show in images, but you can surely test it out.

With these in mind, perhaps having a selection prompt, as many other shelf tools have, is the best way to deal with these:
- select one or a few points, call Fuse SOP and auto-assign that to G
- press enter (i still don't know why Return is still used for these instead of shift+RMB, or any thing else that doesn't require moving the hand from one side of the kb to the other) to select TG, if any
- enter again to commit on G selection only
I might haven't thought this through very thoroughly, so issues could exist with this, but it's no excuse to be left with the current abysmal snap/fuse workflow in the viewport.

Yup, very reasonable. If you haven't created an RFE, please do.

Cheers,
Scott

Andy58

Ondrej
Houdini 17 will have a new option to continuously export the view changes to the camera so you don't get that snapping back to your camera interest on mouse release. This option effectively just applies the constraint after each processed mouse motion to give a smooth motion. I don't know whether this specifically addresses your particular problem, but I thought I'd mention it.

Hello Ondrej,

did this ever make it into H17? If so, I have a hard time finding it.

Thank you
Andy

Hi,

In the viewport, under the camera menu ( The icon which says ‘no cam’ by default ), there is an option near the bottom of the menu called ‘Export View Continuously’. This is the feature that Ondrej had mentioned previously.

Hope it helps!

Cheers,
Scott

McNistor
The volatility aspect seems therefore linked to the feature itself, not a specific key. A “make multi-snapping volatile” RFE is in order.

That's right, there are certain ‘states’ which are volatile, meaning that they can be activated by pressing and holding a hotkey, or ‘tapping’ the hotkey to move into the state in temporary way.

A similar mode for the attach/detach handle operation is in development.

McNistor
A “make multi-snapping volatile” RFE is in order.

This feature is on the list of things which we would like to tackle in future updates.

McNistor
You keep inviting users into alpha/beta that spend 90% of their time in wranglers and then probably read in astonishment “mean” posts like this from “frustrated” users.

I'm not quite sure where you got the impression that we are astonished by ‘mean posts from frustrated users’. We generally understand the source of the criticism and are sympathetic to the frustrations felt by users. Arguments presented by users are often used internally to try to guide development efforts to help alleviate pain points. That said, development time and resources are limited, and things that may seem like easy fixes from the outside are not always that simple when it comes to actually implementing them. Something like the volatile states mentioned above were part of the most recent effort to update some of the ways a user can interact with Houdini. This process will continue into the future, and hopefully things improve across the board over time.

McNistor
If I don't classify as a devoted user that tries to contribute with constructive criticism and feedback, judging by the number of RFEs and posts documented with pics and gifs, in the limited field that I'm competent, then fuck whatever is considered a devoted user around here!

Alpha/Beta access is necessarily limited due to the resources required to track and respond to those users who have been given access. It is likely that there are ‘devoted users’ who are not part of the alpha/beta process. We try to include users from different disciplines as much as possible to make sure we get useful feedback on ‘in development’ features - that includes modelers, riggers, animators, etc. I seem to recall that you were part of this process for the release of Houdini 14, but I could be wrong about that.

I don't think there were any questions in your last post, but hopefully this response helps clarify anything that was left unasked.

Cheers,
Scott

Hello,

We actually added a volatile edit pivot mode into h17, which is part of the ‘align handles to geometry’ workflow that you mentioned. Unfortunately, the hotkey wasn't properly assigned for the release. We'll try to take care of that in an update.

In the meantime, you can search for ‘volatile edit pivot mode’ in the hotkey manager and try it out for yourself.

Cheers,
Scott

On the Subdivide SOP, there is an option near the bottom of the parameters called ‘Vertex Attributes’. Assuming your UV's are vertex attributes, you can set how the values are interpreted after subdivision in this menu.

The method you're looking for is probably ‘linear everywhere’ which simply adds the subdivision without affecting the UV attributes at all. Potentially, you may instead want ‘Sharpen Boundaries’ which will leave the boundaries alone but allow some deformation of the interior UV values.

Cheers,
Scott

Hmm,

Its also possible that you'll need to switch to Reize Static, rather than dynamic.

Then make sure the final size/position of the containers are stored on the cluster points. That way, the ‘edge’ of the container will live in the right place in space the moment it appears.

(use a foreach on the points, or vops trickery if you're clever ). Just timeshift to the end of the cluster animation so they aren't shifting around on you.

Its likely that that particular cluster doesn't have enough of your source ( density I guess ) present on the frame its created so the resize container resizes down to nothing and then can't find the density once it does show up.

You may need to simulate in continuous mode, or delay the resizing of containers a frame or two to give the density a chance to build up before the resize….resizes.

Mudvin
Nice explanation, thank you very much for this one.
I'm also digging pyro masterclasses from this site, but still example scenes would be nice. Much easier to tweak ready scene than building your own from zero.

For example i'm still cannot understand how to achieve that level of detail like in that volcano image - is it very dense grid simulation running for a week or distributed on ferm, or it's some upres, and what is the proper way to do upres, and does all those shelf tools actually will work if i will introduce some custom changes into AutoDOPNetworks, and lots more questions.

Mudvin,

For the volcano simulation, the final simulation was quite high resolution which accounts for alot of the detail you are seeing. I believe the final simulation time for 400 frames was around 8 hours. Also, Coen is correct in saying that most of the detail/shape is coming from the shaping tools. Additionally, in order to get the correct ‘column’ of smoke for a volcano, you need to control the temperature field so that most of the heat stays inside the smoke ( low temperature diffusion ). Also, in this case the sim wasn't retimed since I wanted the cloud to develop slowly and build naturally.

We plan on releasing most of the demonstrations as tutorials along with .hip files in the near future.