Njordy

LukeP
Looks like nothing from SideFx for Siggraph

Houdini HIVE SIGGRAPH 2021 [www.sidefx.com]
But nothing about H19, and I'd say aside of the one named "Worldbuilding with USD" and "SideFXLabs 2021 | New and Improved Workflows for Artists" it's the most boring and uninteresting selection of classes. :/ Sorry. I'm bitter and spoiled.

The USD thing is really boring.

Here is my wild guess as to what we might see in H19. At the beginning of the release talk for H18.5, Cristin Barghiel stated that SideFX considers the current KineFX system to be only a starting point for character animation in Houdini. Houdini 19 could become "The Character Animation Release" if they have invested time building the right tools. If they add a robust procedural system for creating animation controllers, improve tools such as weight painting and blendshapes, speed up viewport playback with GPU node evaluation, and revamp the (horrible) graph editor and animation UI to make it fun for animators, they could plug one of the biggest gaps in Houdini becoming full-pipeline software.

I am eager to escape the clutches of Maya so this may also be a bit of wishful thinking. But it could happen

@SiriusLizard i hope your wishful thinking will materialize

I also hope for the release of Karma GPU. I like, for example Redshift, but I don`t want to shell out more money for a renderer than the actual 3D software and never warmed up for external renderers anyways.

While I agree with you that you shouldn't give money to Maxon, I think you're missing out by not considering 3rd party render engines. The entire industry works on them, and I like to believe that they have done their research and determined that it is the best solution.

Obvious not for H19 but according to this job opening the viewport will get some attention in the near future: https://sidefx.bamboohr.com/jobs/view.php?id=57 [sidefx.bamboohr.com]

Sygnum
I also hope for the release of Karma GPU. I like, for example Redshift, but I don`t want to shell out more money for a renderer than the actual 3D software and never warmed up for external renderers anyways.

I'm really looking forward to further Karma developments but I think people should probably temper their expectations for Karma GPU. Setting aside the fact that Karma is still in Beta — if we take a look at V-Ray, Arnold, and now Renderman XPU, it seems like the road from production-quality CPU renderer to a production-quality GPU renderer is usually a long and slow one. V-Ray GPU is okay-ish now after years of development, Arnold GPU sucks by most accounts, and Renderman XPU isn't remotely close to viable for final frame rendering.

If you need GPU rendering now, it's probably best just to go with Redshift or Octane.

the trouble with third party renderers is that it actually devalues Houdini support.

There is tremendous value in being able to roll up to the latest build when a critical fix becomes available. That's not always possible when the renderer is not built against that build.

G

ps: Worth pointing out that Juanjo has been stellar in that dept, but we are ultimately at the mercy of another party's schedule.

keyframe
the trouble with third party renderers is that it actually devalues Houdini support.

There is tremendous value in being able to roll up to the latest build when a critical fix becomes available. That's not always possible when the renderer is not built against that build.

G

ps: Worth pointing out that Juanjo has been stellar in that dept, but we are ultimately at the mercy of another party's schedule.

I don't think it devalues it at all. It highlights houdini's total lack of a stable API. Plugins needing to be re-compiled every production build or daily build if that's your jam, is just a fact of life.

Other 3rd party engines could take a leaf out of 3Delights book, and make the plugins open source, freely compil-able.
Whatever houdini build I want to use, I just grab the 3delight plugin, and compile against it in 5 mins. Done.

3delight houdini plugin [gitlab.com]

I can't speak for anyone else, but I can promise you that for \ME\ not being able to access daily builds due to this external dependency problem (which I created, admittedly) ABSOLUTELY lowers the value of the support that I'm able to take advantage of.

I used to live by the daily builds... now having switched to redshift, it's production build only, for the most part.

The cost of support remained the same, but the frequency at which i'm able to use it dropped off significantly.

G

keyframe
I used to live by the daily builds

But why? I mean if you're a hobbyist and you're just messing around with stuff without any real production needs, sure. Otherwise what is the need for quite literally updating Houdini version every day? Most high-end VFX houses haven't even switched to 18.5 yet.

For one - I work in commercials, and our project horizons are much shorter. Our software stack and dependency list is also very short, and this affords us the ability to roll out critical fixes very quickly.

We don't habitually roll out new builds just for chuckles, but when we file a SEV1 that gets fixed ASAP, we love being able to deploy it.

The upside of not being high-end I guess.

G

ps: when we used mantra, I would regularly use Beta and sometimes Alpha versions in production as well.. because I like pain, it seems.

Jonathan de Blok
Obvious not for H19 but according to this job opening the viewport will get some attention in the near future: https://sidefx.bamboohr.com/jobs/view.php?id=57 [sidefx.bamboohr.com]

Thank God! This is literally all I want from SideFX right now. So tired of the drudgery of the current, crashy viewport.

keyframe
For one - I work in commercials, and our project horizons are much shorter. Our software stack and dependency list is also very short, and this affords us the ability to roll out critical fixes very quickly.

We don't habitually roll out new builds just for chuckles, but when we file a SEV1 that gets fixed ASAP, we love being able to deploy it.

The upside of not being high-end I guess.

G

ps: when we used mantra, I would regularly use Beta and sometimes Alpha versions in production as well.. because I like pain, it seems.

Is there a reason you have to use one version? I regularly use the prod version for lighting with a plugin that requires a fixed version but do other work in a newer version if some bug is fixed or a newer feature is needed.

Jonathan de Blok
Obvious not for H19 but according to this job opening the viewport will get some attention in the near future: https://sidefx.bamboohr.com/jobs/view.php?id=57 [sidefx.bamboohr.com]

Hopefully....I have found with each release the viewport becoming increasingly 'pita' for not updating properly in too many cases.

Midphase
While I agree with you that you shouldn't give money to Maxon, I think you're missing out by not considering 3rd party render engines. The entire industry works on them, and I like to believe that they have done their research and determined that it is the best solution.

I actually even switched from C4D physical renderer to Redshift recently during a production because the internal, heavily neglected physical renderer was getting slower by the minute. I`m with you regarding the research and stuff but I`m just fed up dealing with the hassles of checking if the DCC`s version is compatible with the version of the renderer AND the render farm I`m using. This is not a fictional case, it happened in the above project. I just think that any DCC vendor should have an up to date production renderer so they don`t end up like Arnold or Redshift, which now are in the hands of a competitor of Sidefx (or Autodesk or Maxon).

BabaJ
Hopefully....I have found with each release the viewport becoming increasingly 'pita' for not updating properly in too many cases.

i don't know what kind of update problems youhave but i have update problems whith transformation... i select a bunch of points press T and the selection goes back to the previous selected points, i press S again then T again to work. that's an uber pita

keyframe
I can't speak for anyone else, but I can promise you that for \ME\ not being able to access daily builds due to this external dependency problem (which I created, admittedly) ABSOLUTELY lowers the value of the support that I'm able to take advantage of.

I used to live by the daily builds... now having switched to redshift, it's production build only, for the most part.

The cost of support remained the same, but the frequency at which i'm able to use it dropped off significantly.

G

Not sure what kind of crazy external dependency you have created, but it doesn't sound ideal at all.
I don't really see much of a difference in requirements for Commercials Vs features. We are all generating the same bits
and pieces, so I'm curious why the need to live on daily builds, etc.

As mentioned above, why not lock off the lighting/rendering version of houdini, and keep it tied to the 3rd party engine, or
even good ole Mantra.

Not trying to derail it, but it seems like your workflow has bound you up in this diminished returns scenario.

As I said, the external dependency IS redshift.

And while switching versions isn't a big deal in its own right, we do sometimes (often) have a single hip file that runs the entire gamut of the job. I couldn't have a lighting/rendering file version since they are often the same file as my asset prep, and fx file.

It's possible to split the hip file, obviously. But this not how we choose to work currently.

G

Ahh,

I know we are further derailing from the topic, but here are my thoughts.
As tempting as it is to have all of your scene construction in one monolithic hip file, it's a really bad idea
for a couple of reasons.

One of them being the external dependency of course, but what I mainly find, is that troubleshooting rendering issues
is made a lot easier when your lighting scene is purely that. Just imported caches, shaders, lights. No wondering
if some component of your hip is being caught during scene evaluation and breaking things. Also makes packaging up
an issue for RS Devs to evaluate when it's just a cache + lighting setup. Eh, conversation for another time!

Cheers

L