search

juno-fx / Terra-Official-Plugins

Official plugins for the Terra system
MIT License
0 stars 0 forks source link

CG apps support #88

Open ddesmond opened 3 months ago

ddesmond commented 3 months ago

As a "variation" of a working cg studio we want to cover certain department needs and its outputs. I am basing this on a "default set of apps" to cover some aspects of artist work. The list is of no particular order but a direction from which we should take what we need to setup a minimal set of apps we would like to support. Each app may come with its own license server or a shared one like RLM. Some apps can cosnume Deadline UBL hours https://marketplace.thinkboxsoftware.com/usage-based-licensing Some apps are pure FOSS

3d authoring and rendering:

2d authoring:

Edit:

Texturing:

3d Tracking:

3d scanning:

Utilities + Misc:

Asset libraries support:

aldmbmtl commented 3 months ago

Do we need to come up with a priority list for these? For me, I could see the following being prio.

  1. Blender (@skeleturtle already has a lot of this working with Filemanager)
  2. Houdini
  3. Unreal
  4. Resolve
  5. MRV2 (I think this is already working?)
  6. Nuke (already done)

We should first prioritize getting these working since I think this will cover the full pipe. We should also get this working on our own internal pipeline first. Then if we want to enable things like Pyblish, we should do that for just the studio side. The initial offering from Innovations should be just a base pipeline with no 3rd party if we can help it. Then we can offer Pyblish as a plugin or something.

skeleturtle commented 3 months ago

I agree on blender then houdini.

3rd party apps are bottom of the barrel for me.

aldmbmtl commented 3 months ago

@ddesmond I think @lamepennies mentioned something about how Houdini is kind of replacing the need for something like VRay or other renderers? Do we need support for them in the long term? I think Arch-Vis uses VRay a lot actually. So we probably do need it. But for the studio side, do we need to VRay or Redshift support? I would prefer to avoid Redshift at all costs because of their licensing model. The don't want to support interactive licensing cloud side. Which makes no sense imo, but that's just me. I am fine with putting Redshift last on the priority list for support for now.

skeleturtle commented 3 months ago

Houdini can use vray to render. I'd assume initial focus would be Solaris and usd though.

aldmbmtl commented 3 months ago

Yea, Solaris is what I think @lamepennies was mentioning. But @ddesmond may have an opinion on that.

ddesmond commented 3 months ago

I would def go with an app for each dept:

As for rendering we would need to support both karma in solaris and mantra as a regular houdini render so it works in all scenarios. While houdini is being worked on we would then connect houdini engine to unreal so we have a seamless integration there. We also want to use swarm in unreal on the farm to be able to do more fast processing work.

As for assets we def need megascans and materialx, hdri haven and some opensource material library. Megascans will soon die, but are integral part of unreal so a proxy of some kind will be needed.

Lets compile a list then we can detail tickets about each app and its integration status.

aldmbmtl commented 3 months ago

Sounds great. Once we get that list agreed upon, lets get it started and make the best CG Pipeline the world has ever seen!

I agree with whatever you and @skeleturtle come up with. All I ask is you build your dream pipeline :)

lamepennies commented 3 months ago

If armor is similar to other industry standard software then go for it but I don't think we should install anything super different than substance or mari.

Solaris was something like USD but working. At some point, we'd need to build a scene tool that tags everything so CG people know what belongs in there. This could be Solaris-based or USD. I don't know enough to say which one. My last 2 studios were switching over to Solaris because USD takes too long. And you can use the rendering inside of Houdini versus needing another package.

Just my 2 cents

claudfx commented 3 months ago

I'd add cascadeur to the list for down the line. Have yet to deep dive it but looks really promising: https://cascadeur.com/

As for my top 3 priority picks, it would be:

ddesmond commented 3 months ago

just to demistify - Solaris is an USD Stage, it follows one direction of many how to work with usd data and Karma is based of hydra which is native usd renderer. But i understand what you are saying @lamepennies If we are gona go USD way then solaris is the way to go (altough still rough and many things are just not there yet...) We should then based our geometry caches to be USD and follow that route with ABC as a backwards compatible if need be.

Depends who we want to cater first (our vfx studios target group) we can also pivot around that selection. Hi level tools like Katana / Mari and so on (gaffer, VRED) - they are "a standard" but in reality only big studios can afford that and everyone else is pivoting around houdini / maya mostly....

Thou I am not against any app per se, just questioning the usability and popularity of those tools in "mid-hi" range or whatever target user group we would have.

I suggest all to check Ayon supported list of apps here: https://ayon.ynput.io/features/ Nedless to say ayon / openpype is now being used in hundreds of studios around the world...

Those are all insights into what we are going to support in our CG pipe.

ddesmond commented 2 weeks ago

moving this to terra plugins so we can split this into multiple tickets and clear up whats installed vs whats in pipe