BabaJ

raincole
In other words, SideFX doesn't value indie users and doesn't want to hear their opinions.

As an Indie user myself - my experience is the exact opposite.
I've gotten so much help over the years from Support, unlike so many other software venders; SideFX has been tops in my experience.

Same here. We're not small enough to be "Indie" but with only a handful of licenses we're definitely not a "big" customer either. Of all the software vendors I've dealt with in multiple industries for the last 20+ years of my professional life SideFX is my gold standard. There's always room for improvement, but they are more responsive and have better systems in place for collecting user feedback than almost anyone else I've dealt with. Sure, I've got RFEs that were never implemented, but I've also reported bugs that were fixed in less than 24 hours, so I really don't have any complaints.

timurproko
For instance, having many thin separators between windows is an outdated approach to UI design.

Out of curiosity, what is the issue with this approach? Is it entirely stylistic or does it introduce functional problems and if so what are the more modern solutions to those problems?

eikonoklastes

timurproko
mess

for someone with so much design experience, you should understand that presenting a massive clot of text like this makes it extremely tedious to read.

You mean a post consisting of paragraphs containing 2-4 sentences each? I'm not sure I agree with the post's conclusions but calling its text a "mess" seems like a weird criticism.

lmnoc1
Consolidation and simplification are the keys!

I'm pretty sure the only node anyone actually needs is an Attribute Wrangle. That would certainly simplify the network UI, although it probably wouldn't make Houdini much easier to use.

I opened a ticket about this at the end of November. Even though it isn't listed in the help the flag is: /SideFXLabs=Yes
I haven't checked the daily builds since then, but they were going to update the documentation to include it.

I'm not familiar with the .he format, but if it is geospatial data GDAL [gdal.org] can probably convert it. Being a generic format, pulling the image arrays out of an hdf5 is a little more involved than some other formats, but GDAL should be able to do what you need.

Are you sure those renders are actually ACES and not ACEScg? That kind of reddish tint is the kind of thing that happens when your primaries are mixed up.

I'm sure there is a simple solution to this but for the life of me I can't figure it out so am hoping for some help.

If I have some textures named like:

texture_1001.exr, texture_1002.exr, ...
Then the normal UDIM expansion texture_%(UDIM)d.exrworks fine. However, if my textures are named like:

texture_1001.v01.exr, texture_1002.v01.exr, ...
the textures fail to load using specification texture_%(UDIM)d.v01.exr. I'm sure there must be a way to properly escape the texture path so that it evaluates correctly, but I can't seem to find the magic combination. Any hints?

When exporting cameras for import as projectors in to Mari, for example, it would be helpful to have the camera shape named the same as its parent transform. As it is now, when you import several cameras they all end up being named ‘cameraProperties’ and the original name that was attached to the XForm gets lost.

Rather than use an arbitrary name, it would be great if the exporter just used the same name as the parent xform. We're importing cameras in to Mari as projectors and it's not super useful to end up with dozens of different objects all named “cameraProperties”.