🧵 Untitled Thread
Anonymous at Thu, 13 Oct 2022 17:51:57 UTC No. 921906
I havent used Painter in a while but I assume this is true. tell me if I'm wrong.
>You can import lights and objects in a abc or fbx and have your scene appear exactly as it would in the final render in your DCC. You can author material X shaders in Painter and plug them directly into Redshift in maya and have a 1:1 representation
Is this worth getting Redshift over? I only have a 3060. Currently using Cycles X (great gpu support) and occasionally Arnold (horrible gpu implementation)
Anonymous at Thu, 13 Oct 2022 21:13:41 UTC No. 921925
>>921906
>FBX/ABC
learn USD and how it packs/transfers stuff, or you'll be left behind.
Anonymous at Thu, 13 Oct 2022 21:38:56 UTC No. 921933
>>921925
Looking at help.adobe.com it only lists ordinary file formats like exr, tiff, jpg, png, etc. And how does this factor into material x which describes shaders and is used with redshift where usd describes objects and doesnt depend on one renderer?
Anonymous at Thu, 13 Oct 2022 22:02:53 UTC No. 921940
>>921933
with USD, when implemented in end stages - You will get render results that are in ideal scenario 1:1 to every supported rendering engine. give it a few years, but keep an eye.
Redshift or Anrold or any other on the horizon should support it, and it will not be as much of a issue when choosing rendering engine.
Anonymous at Thu, 13 Oct 2022 22:05:55 UTC No. 921943
>>921940
you misunderstand me.
I need 1:1 from the viewport of Painter into the viewport of Redshift and preferably Cycles. Right now I plug painter maps into cycles principled v2 and it doesnt look the same at the same settings.
I need to know if I can do this with Redshift and material x within maya. I'm extremely heavily invested into maya
Anonymous at Thu, 13 Oct 2022 22:09:30 UTC No. 921947
>>921943
Oh sorry Anon.
If its not 1:1, double check Your colour setting exports (srgb,ACES, etc. make sure You get correct color space)
🗑️ Anonymous at Thu, 13 Oct 2022 22:39:02 UTC No. 921953
>>921947
how do i set up cycles x to accept material x from painter? Allegorithmic has a plugin on github that only supports arnold and arnold is hell on gpu (constant freezing, crashing), while cycles x is nice and smooth. This is also why I was considering redshift
>https://github.com/AllegorithmicSA
>This plugin adds support for simple MaterialX support for Substance Painter. It currently only support arnold and Metallic/Roughness workflows
Anonymous at Fri, 14 Oct 2022 00:17:51 UTC No. 921962
>>921943
if you're comparing painter's open gl viewport with offline pathtracers expecting 1:1, it'll never happen
even if you're comparing iray or b/w renderers thing will be a little different with the same maps. usually you just have to dial in the roughness with some ranges and mess with normal and displacement strength.
that stuff will never change, even once matx gets fully implemented (which imo will never happen. each dcc will fill feature gaps with their own matx compatible nodes like sidefx already do with some stuff)
Anonymous at Fri, 14 Oct 2022 00:46:04 UTC No. 921965
>>921962
my friend, i thought the whole point of material x was that it transferred 1:1 from different dcc's using input->material x->output
Anonymous at Fri, 14 Oct 2022 10:48:10 UTC No. 921995
>>921965
that's the point in theory, but the reality of it is probably going to be a bit messier.
1. render engines despite following the same shader spec (autodesk standard surface) will not produce 1:1 results. don't ask me why this happens, but renderers have a look to them.
2. materialx native nodes right now are missing a lot of stuff. for example this:
https://www.sidefx.com/docs/houdini
this is a materialx node that only exists in houdini right now. if you transported this over to maya, it would just break.
3. usd lights don't even have a spread parameter on them right now, but you can enable spread via renderer specific controls which right now don't work universally.
and i barely use this stuff, there's probably a million more little things like that i don't even know about. over time a lot of stuff like this will get resolved, but imo renderer guys will continue to build custom matx nodes because no one wants to be crippled by waiting for the shared spec to update.
Anonymous at Sat, 15 Oct 2022 19:46:23 UTC No. 922130
>>921995
>1. render engines despite following the same shader spec (autodesk standard surface) will not produce 1:1 results. don't ask me why this happens, but renderers have a look to them.
lets say you use the same renderer in multiple packages. Say, you buy a license for redshift or prman and do your work in both maya and houdini - all you have to do is author a matlx file in one package and you can bring it over to the other DCC and have a 1:1 setup. You wouldnt be able to do that with karma.
Wouldn't this be ideal?
Anonymous at Sat, 15 Oct 2022 20:25:20 UTC No. 922134
>>922130
oh sure, that's would be great. hopefully development on matx compatible nodes will be 1:1 with native nodes in the future.
i'm being quite critical, but i do think matx and usd are great initiatives and it's pretty amazing that people seem to be on board. i'm just a bit of a sourpuss by nature, so i look at the promises of interoperability between renderers and see it being less ideal than the pipe deam.