Bugfix: Houdini Mantra IFD local submission

[MustafaJafar]

Changelog Description

Mantra IFD extractor local submission was failing because its extractor didn't include render_rop

Testing notes:

1. publish mantra ifd local and on farm. it should work.

[MustafaJafar]

I have a question:
I'm not sure about the workflow of using published ifds ?
Also, how ifds are related to these temp paths ? e.g. what would happen if I deleted them after publishing the ifds ?

[moonyuet]

I have a question: I'm not sure about the workflow of using published ifds ? Also, how ifds are related to these temp paths ? e.g. what would happen if I deleted them after publishing the ifds ?

This is just providing the temporary storage for ifd file if there is any.

We need to double check the integrate.py and resourced_file.py to see if the related family of this extractor is included. It seems that it doesn''t get published correctly and it doesn't show up in the loader.

[MustafaJafar]

Note:
As far as I know the published IFD files will keep the link to the original generated temp data in the workfiles which can error if the temp data are deleted.

Thus, I've enabled Save Geometry Inline
As I have no idea to publish the generated temp data along with the IFD files while updating the link between them.

[moonyuet]

Note: As far as I know the published IFD files will keep the link to the original generated temp data in the workfiles which can error if the temp data are deleted.

Thus, I've enabled Save Geometry Inline As I have no idea to publish the generated temp data along with the IFD files while updating the link between them.

maybe we can just add an optional validator to check for the temp to avoid the error with the temp file storage.
EDIT: I mean the validator to check on whether Save Geometry Incline button being turned on.

[moonyuet]

I tested with houdini, all functions work.
I think it may be good idea to add optional validator to check on the Save Geometry Incline button being turned on, but it can be in different PRs(if anyone needs that)

[BigRoy]

Containing all the geometry into the output file means you're basically bloating the filepath a lot. I really feel like this is the opposite of what a 'render' file should look like - it should be a lightweight file whenever possible.

I understand the comment as to what is hard about changing paths in the output files - but I'm wondering, why would we need changing anyway? Is it because of mixed farms, etc?

Also, if this is a "local" submission - do we even need the IFD file? Or what's this about?

Aren't IFD's intermediate files just used for rendering? They don't need publishing - they are not proxies. They are just files used for the current render. If it's a local render - then technically it can almost live in memory or transparently be in a temp folder on the local machine?

[MustafaJafar]

why would we need changing anyway? Is it because of mixed farms, etc?

As far as I know it's not only about mixed farms but also about having the IFD files with the correct data.
and keeping that link may produce IFD files that points to a wrong/non-existing geometry files.

Also, I doubt this problem is going to occur also with farm IFD publishing.

Aren't IFD's intermediate files just used for rendering? They don't need publishing - they are not proxies. They are just files used for the current render.

I'm not sure about the why we have IFD family I can obly remember it was added by @moonyuet in ynput/OpenPype#4903
Could @moonyuet you shed some light ?

[moonyuet]

Containing all the geometry into the output file means you're basically bloating the filepath a lot. I really feel like this is the opposite of what a 'render' file should look like - it should be a lightweight file whenever possible.

I understand the comment as to what is hard about changing paths in the output files - but I'm wondering, why would we need changing anyway? Is it because of mixed farms, etc?

Also, if this is a "local" submission - do we even need the IFD file? Or what's this about?

Aren't IFD's intermediate files just used for rendering? They don't need publishing - they are not proxies. They are just files used for the current render. If it's a local render - then technically it can almost live in memory or transparently be in a temp folder on the local machine?

We can just remove the entire product type instead. i mean same thing has been raised by @fabiaserra before

[fabiaserra]

yeah I don't see a point to keep IFDs around, as opposed to ASS files which have more benefits as you can use them as an exchange format across the different Arnold plugins

[fabiaserra]

has there been any progress or plans on separating the extraction/render of nodes from the publish?

[BigRoy]

has there been any progress or plans on separating the extraction/render of nodes from the publish?

As far as I know, there hasn't no. Might be one for Dee Coureau (I dont know his Github handle).

[fabiaserra]

has there been any progress or plans on separating the extraction/render of nodes from the publish?

As far as I know, there hasn't no. Might be one for Dee Coureau (I dont know his Github handle).

I'm waiting for the 0.3.0 breaking release (this week?) to update my fork and migrate to ayon-core and test any new features before I start being loud in the DCC fronts again, right now I'm busy making the Shotgrid sync stable

[MustafaJafar]

has there been any progress or plans on separating the extraction/render of nodes from the publish?

As far as I know, there hasn't no. Might be one for Dee Coureau (I dont know his Github handle).

it's @dee-ynput

[MustafaJafar]

Marking this PR as a draft in favor of this comment #75 (comment)
waiting till making a decision whether to remove the IFD product type or not.

[antirotor]

I don't think that we want to publish IFDs at all. Let's remove it in another PR.