Correct me if I'm wrong, but didnt 3Delight do a complete rewrite from scratch, which brought OSL support along with it? What I mean by *drop* is, a feature drop - as in OSL/fast VDB for 3Delight - not that 3Delight was just created this year - LOL

Embergen is at like, what, version .01 or something and their next drop will include a crap ton of features, only again limited by VRAM - but orders of magnitude faster than CPU sim(s), that's for sure.

I'm not confusing the two, the USD spec has been public for years, nothing stopping you from rolling your own consumption of USD data in your pipeline, but what Hydra represents is the published standard of consuming USD data for rendering, and *poof* that's how we got all those Hydra delegates in H18. Why?, because now the barrier to mature an engine in Houdini (or any Hydra host) is greatly lowered - no more HDK headaches.

I mean, just like some engines support Alembic directly as well, and have been for years, but there's no *Hydra* equivalent for Alembic, everyone has to roll their own for Alembic in their pipeline, all in completely different ways.

I'm aware that Production Pipelines take years to change, as things just take that long to chew thru the pipeline/schedule…so, someone saying that ‘we dont currently do it that way’ is no surprise, but that doesnt devalue the bleeding edge tech.

@Daryl - what type of work are you doing? We are working in Vfx industry for 2+ decades and what you say doesn't hold up in any production environment. It comes across as an evangelist.

goat
@Daryl - what type of work are you doing? We are working in Vfx industry for 2+ decades and what you say doesn't hold up in any production environment. It comes across as an evangelist.

I dont work in Film/VFX industry, but, what does that have to do with Softimage still being used in Production?

Daryl Dunlap
I dont work in Film/VFX industry, but, what does that have to do with Softimage still being used in Production?

Thanks for being honest - you can't really advise on our industry then. All you have are the signals of what you think we need. You don't have the reality of what happens.

My apologies, Film/VFX is the entirety of the term “Production” - and here I thought it was the pipeline in which content is produced.

Daryl Dunlap
My apologies, Film/VFX is the entirety of the term “Production” - and here I thought it was the pipeline in which content is produced.

I'm sorry, I'm not following. Can you explain it for us. We are a little slower than you.

Right now, you are just putting jargon-salad out onto the forums, hoping it makes sense, as far as I can tell.

Before the thread gets locked… what are the issues or limitations of going through Hydra for final frame rendering?

Yeah, let's try to keep this civil and going. There's some very useful information that I'm learning.

XPU talk is up guys:….
https://developer.nvidia.com/gtc/2020/video/s22266?fbclid=IwAR1FpP9Y8FTnbbz3nunShaLLWxk6YLmYpTilSpJXnj96Y5wolB1du86Ttn4 [developer.nvidia.com]

Edit: Please ignore when the term “production” is used in the talk, it means something..um…nevermind.

Thanks for the link - the XPU talk is good as the second half defines some of the issues that currently block GPU from being a production renderer at the moment.

As seen in the last slide for subsurface scattering

* Performance on the CPU is good
* The challenge is making it efficient on the GPU
* Poor GPU utilization, currently not much faster than CPUs
* Similar is the problem of light transport in volumes

If it follows Arnold's trajectory, once XPU is public, no one will use the GPU side for production rendering, just like V-Ray etc.

Indeed. This highlights a few of the problems.
Regarding the HDK Daryl, you haven't tried to build anything for USD have you? That stiff is breaking and changing left
right and center, which as it's still not finished makes sense.
No hydra doesn't represent that. The reason a delegate can get off the ground relatively quickly is because hydra supports
not the full range of data you need to do final frame renders.
Embergen sims? We are talking rendering. Start stuffing huge resolution things in there and then see what happens.
I think Embergen's niche will be low mid res stuff that doesn't need complicated collisions, forces, etc, which is amazing.
It can mean getting some good ground coverage type fires etc for almost free.

DaJuice, that XPU video is great for showing some of the very real limitations/challenges involved with GPU.


Cheers

Lewis

I'm worried SideFx is trying to port Karma to GPU… I would rather see that effort put into optimizing the CPU version and speeding up its development.

jarenas
I'm worried SideFx is trying to port Karma to GPU… I would rather see that effort put into optimizing the CPU version and speeding up its development.

What they have said in the H18 presentation is 1. CPU version to production level and 2. Bringing a GPU version later (beta).

mandrake0

jarenas
I'm worried SideFx is trying to port Karma to GPU… I would rather see that effort put into optimizing the CPU version and speeding up its development.

What they have said in the H18 presentation is 1. CPU version to production level and 2. Bringing a GPU version later (beta).

I know, but for a limited set of resources, as reality is, I would rather see them spend them on Karma CPU with improved features and things like bidirectional path tracing than in a half-baked GPU version that, like XPU or Arnold, will be limited and missing features.

I guess rendering engines are a little bit like cars. Everybody was influenced by someone or some project.
We are all passionate, but we all want different things.

You will never use a Toyota prius to go camping in the amazon. Nor would you use a Jeep to save fuel.

Arnold/Mantra and Redshift is a little like that. You can pick which is which.
I want Karma to succeed, because it's being developed by the same company who brought us Mantra, which I really love.

Lastly, I really want to ask people to keep this clean and light-hearted. Some of us are here to feast on information, and don't want this thread to collapse.

jarenas
I know, but for a limited set of resources, as reality is, I would rather see them spend them on Karma CPU with improved features and things like bidirectional path tracing than in a half-baked GPU version that, like XPU or Arnold, will be limited and missing features.

I like to think that the team at SideFX is pretty good by now at knowing where to allocate resources and what is important to their user base. I trust that they will do what's right.

Speaking of which…isn't a Houdini 18.5 announcement coming due right about now? ;-)

Midphase
Speaking of which…isn't a Houdini 18.5 announcement coming due right about now? ;-)

Do you think so? Is there any sign of that apart from time since last release? Maybe I missed something!

anon_user_37409885
Ok, you have some nice work there, but I guess I'm looking for the very best GPU rendered work around. Does it compare to any Hollywood movie? If it's the future, it sure must be better than CPU rendering.

Hi! Im Look Development Artist)
I Use Redshift in 99% projects

Redshift for Netflix:
https://www.behance.net/gallery/90057919/Typerwritter [www.behance.net]


but he's not as good out of the box as Arnold, you need to understand what you are doing and everything will work out