Houdini 20 Wishlist

[sebkaine]

Hi Vince i hope you have great hollidays my friend, and thanks for sharing your detail pov about USD. There are points where i agree with you and other where i am not.

like i said :

- ability to exchange assets between DCC's is a good idea.

- layering the work of all departement is also a good idea when you have big team of artist.

But those advantage come at a price, the price of a very complex scene description language, that imply a specific and time consuming way of working, that will only be rewarded if you are inside of a certain spectrum of CG production.

I have the belief that people in an other part of the spectrum will only loose time and flexibility by going the USD way.

With solaris you can create complex light rigs , infinite versioning etc .... but you also have a LOT of workflow methodology to follow to be able to do so. And that methodology cost you time, and thus money. And if you are not working on big show where at least 100 artists are at work together to create at least 200 shots, i am not sure you will get the reward in efficiency that you have expected when working with solaris/usd.

My point is that pre solaris we had mantra, now that karma has arrive mantra will be very soon stoped and thus legacy. So now karma is the way. But karma is solaris/usd exclusive. so for those who don't want to use USD, we don't have any default render engine.

For me the fact that sesi push us to do layout / rendering with .USD is not a good thing. because again the complexity and the price to pay to get the benefit is on a Katana level of production. Sure you can do Marvel or Pixar movie in Katana. But using Katana to do some dirty commercials or motion design animation or even layout a sets for a low sepc game or a AAA game is a non sense. But when using solaris to do so i have this feeling of using the wrong tool to solve a simple problem who don't need such a high level of complexity.

 

My point is that the beauty is to have choice !

- you can use Solaris / USD if you work on the spectrum of production that will reward his complexity.

- But you can also have the choice to bypass it to stick to . GLTF only or .FBX or .ABC only if you prefer to.

I would really prefer to stick in SOP for my scattering / level design task, then if i need to i could then conform and import them in a USD workflow.

I have no problem if people think it is a better idea to layout directly in USD, but at least i would like that the set of layout tools in SOP stay on par with Solaris.

Cheers

E

 

 

 

 

 

Edited August 23, 2022 by sebkaine

[vinyvince]

I guess it's probably a question of human resource and priority for Sidefx.  One thing is certain, USD and its integration is called to be changed if they want to reach that "copy paste" paradimn.

It's for sure quite tiring to have built new networks and scene graph which tend to become quite baroque quickly, just to convert your scene to a USD scene in a proper way while the screen is already live in your viewport and ready to render..

Im not sure our producers start add this time to the schedule... Or let's say certainely not.

And not everyone know how. While it's easier to find people who will render straight and not having to take care of this time consuming extra steps..  If you are a freelancer, you basically have to take one week of unpaid holidays to learn this

Ideally that should be transparent and the different contexts should be more linked till the start. I guess when using some strict naming convention which could help automate to the USD step building less painful and faster...

By the way, is ther enot a way to just brute force your full scene from SOP and just be able to render it more or less straight away in Solaris? I thought sidefx did a specific node which internally convert everything to LOP but at least you should nore much take care of it..

v*

[sebkaine]

2 hours ago, vinyvince said:

Ideally that should be transparent and the different contexts should be more linked till the start.

This sum up exactly my point. modeling / layout / texturing / rig / anim / geocaching should remain agnostic and stay in a common trunc, where you have choice on what geo format you like the most. then when all is set you can now decide where you wanna go.

- Unity with Hengine for low / mid spec interactive XP.

- UE with Hengine for high end spec interactive XP or Cinematic

- Traditional rendering context for fast and simple rendering with popular engine : arnold, octane, rs ....

-  Solaris context when you want to be able to work in an efficient way with multiple users on complex shots with lots of iteration and many redundancies between shots.

USD as geo exchange format is still very interesting imo what Frederic Servant show at 4:00 is really cool and i 100% agree with you on that :

Arnold USD loader

you can just grab directly an .usd file with full geo plus metarial assignation inside the renderer. You use a subset of what usd offer but you don't have to deal with all the features and all the complexity. 

it's like doing C++ but with restricted set of features, no polymorphism, no operator overloading , no multiple inheritance are allowed, you just use simple class and inheritance, because for your needs , you need to keep things simple.

Thus You just grab what you need and you can then limitate the level of complexity you accept to pay.

 

Edited August 23, 2022 by sebkaine

[skomdra]

On 8/23/2022 at 9:55 AM, sebkaine said:

With solaris you can create complex light rigs , infinite versioning etc .... but you also have a LOT of workflow methodology to follow to be able to do so. And that methodology cost you time, and thus money. And if you are not working on big show where at least 100 artists are at work together to create at least 200 shots, i am not sure you will get the reward in efficiency that you have expected when working with solaris/usd.

 

Very interesting discussion guys! 

I was wondering, isn't it possible to make your own hda-s for that (a LOT of workflow methodology to follow) and not repeat tedious tasks over and over again? There are even TOPs which can help you rename your assets, put them in the right folders, etc, and help you never do any extra cost of time and money. The big team vs indie studio argument seems a bit superficial since even the indie artists will in one point want to take a part in a bigger production, involving more collaborators, so I would imagine it is in their interest to learn the big studio methods. And if we are talking about one person experimental instagram shops, how can this be a priority for a serious software company like Sidefx? In my opinion, Sidefx can offer some high level HDA-s, python scripts, etc, to offer some good scenarios, and that way help people to adopt USD technology more quickly, rather than going backwards and trying to make a fist full of indie artists happy (and I am saying that as an indie artist myself)  

[vinyvince]

Big part of the USD solaris push is not only the metaverse stuff, or multi format asset for delivery onj multi platefoom in one stream, but in film, show are getting more and more shots, which required collaboration between different vendors. And clients are pushing to not only share the geometry as before, but also lookdev with material X stuff....

 

It's a big topic, you could see interesting discussion on Sidefx, from how Rise has done it, how Folks tried to reorganized the old sidefx bar scene 'and using lot of TOP nodes), DD too...

There a funny anecdote  .Disney was planning to migrate in 18 months. it tooks  3 or 4 years

At least i will prefer to face Solaris and USD, than to send maya to houdini to Katana 

If houdini and Solaris were fully open source like blender , we will see a huge boost , the power of world contribution ... You can't beat that

Im don't know how the position of central pipeline software like shotgun on this....

[sebkaine]

Thanks for you feedback guys,

again i don't agree with all of them, and that's the hard part of doing software where you need to please very various user pool. I will not continue to rent to much here about solaris, because it is the feature request topic. That would be better to create those debate in a solaris section, where people could argue about the pro and the cons of USD/Solaris. Feature request wise just having parity between the layouts nodes in SOP and SOLARIS would be great. Because if you design an env for a unity realtime game that you want to combine with Hengine, why bother with solaris ? But if you want to access all the cool new stuff you have to use solaris, having to do so feel like something not elegant and straightforward imo. 

Cheers 

E

 

Edited August 29, 2022 by sebkaine

[vinyvince]

* Better Python script editor. (with clean color coded syntax , similar to sublime with python module)

[mikuspikus]

Proper autosave feature (yes, I just lost an hour of work :D). Current one works in a weird way - you have to enable it every time (easy to forget). Why not just turn it on every time by default (or global toggle) and if someone didn't save at all display a prompt "please save the damn project, you woked for 20 minutes without saving stupid". Something like that

[vinyvince]

Epic show the way with auilding of a framework for custom Machine Learning deformation model, with result for realtime gameplay... You could easily imagine how much you could push the principle for non-realtime film VFX work...

Notice the chest area especially. It is trained using the output of a FEM solver that preserves volume. A neural network applies per vertex corrections dynamically. You can theoretically train on any type of deformation. We can also simulate cloth deformations (without dynamics). " UE 5.1 will ship with a ML Deformer framework to build custom models and a new model we call Neural Morph Model. This allows high quality deformations in real-time. Character below uses ~1 mb of ML memory and takes below 100 microsecs on CPU and 40 micros on GPU. "

https://t.co/HM5dy8q7jL

Edited October 8, 2022 by vinyvince

[vinyvince]

On 05/10/2022 at 11:12 PM, mikuspikus said:

Proper autosave feature (yes, I just lost an hour of work :D). Current one works in a weird way - you have to enable it every time (easy to forget). Why not just turn it on every time by default (or global toggle) and if someone didn't save at all display a prompt "please save the damn project, you woked for 20 minutes without saving stupid". Something like that

You could force houdini to make all started sessions shared the same env. Python script 456.py is executed everytime houdini load a HIP (and 123.py for a new scene).

You could load a custom desktop too if yours didn't showup automaticaly

[BlackCater]

In the solaris tree panel, you can preview the material icon. Double click the material name to enter the corresponding node.

[Jaanus]

I'm guessing this thought might have already come up, but just to mention if no one has:

Integration with the rapidly developing ML image generation solutions.

This could be an opportunity to also upgrade the COP2 context, now with enhanced ML features.
 

I don't fully understand what is shown in this video linked above, but it appears stability.ai are working on some node-based machine learning image generation solutions. Would be great to see what could be done in Houdini with some similar tools.

[vinyvince]

Could i mention a new version of Houdini-engine or not?

That would not be a luxory..

 

[bollili]

My top 5:

Faster and more intuitive usable chops.

Feature parity of obj context with solaris scene manipulation (e.g. dynamics for object positioning).

Lens tilting (not only shifting) for cameras.

3rd party support for render cop.

Overhaul of wren: a modern renderer for vector graphics.

[matEvil]

pop vop - by default set the input on first, second, third, fourth context input. and move the "Input" tab as first tab in UI

attribute wrangle sops - collapse the block of VEXpression

For now that in my list, if I think another I write.

 

 

[sebkaine]

It would be nice to have a new Houdini Engine licensing policies. 

Today if you are a small company with floating license. You have to pay $795 per year per machine which is perfectly fine. Paying a fee when you do use houdini in batch mode, is perfectly fair. You need to use mantra / karma / or any Dop / Sop processing on your farm it's ok to pay the right to access Houdini. 

But when you need to just render a scene in an external engine, a scene that just contain loaders to .bgeo / .abc / .vdb files in Arnold / Vray / Redshift / Octane, i don't find fair to have to pay the full price to just open the scene and send it to the engine on the renderfarm. I just don't render or process anything with houdini, i just send my scene to the external render. 

Thus each time i said in place i work that it would be better to switch the render to houdini and stop using the other software i would not name, i always get this answer. How much it cost ?  And in fact when using arnold for exemple which is $500 per year, you have to add the $795 cost to each arnold license, thus $1295. so it cost a lot More. So they always said, why do you want to pay 1295$ per machine while it cost only $500 with the other software. Why do we should pay the right to send our scene on the farm $795 ?

I could do full .ass export for each scene but in small shops where there are not strong pipe dev or houdini dev it's rarely an option. And when company use a mix of render engine you add another layer of complexity. 

My point is that it would be great to have

- Houdini Engine , an engine that process data or render image using houdini tech and that cost $795 for accessing this technology

- Houdini Batch which basically would only open a scene and let the external render engine render it, be free or cost much less , because it do much less.

Cheers

 

Edited May 24, 2023 by sebkaine

[Librarian]

All reconstruction of help files and adding a new files in collection.

[Jaanus]

ML-trained VDB growth systems. Something where one VDB could be morphed into another, possibly guided by some geometry (for example direction curves).

ML-trained explosion systems, for example, ML-trained rigging, etc. People at NVIDIA and on Unreal Engine are clearly working on some of such stuff and would really fit the Houdini workflows.