wombat Posted July 6, 2023 Share Posted July 6, 2023 (edited) What I am trying to do: I would like to pre-compile a custom vop function (specifically a function, not a material with surface and displacement). This pre-compiled function's outputs would be used in a larger shader network to generate the base_color, roughness, metallic and disp inputs of a Principled Shader node. The reason I want to pre-compile this function (contains a lot of nodes) is to reduce the Mantra startup time (which, in my particular use case, would be > 6 min without pre-compiling and < 30s with pre-compiling). Approach 1: I first attempted to use the Material Builder's vex code caching feature to pre-compile my custom vop function. I used Parameter vop nodes to add custom outputs to the Material Builder node and wired these into the corresponding inputs on the Principled Shader. This worked for base_color, roughness, and metallic, but when plugging the Material Builder's custom output into disp it generated correct displacement but bad normals (see the attached screenshots). Approach 2: Since the above method was not working, I instead tried manually compiling the custom function to vex code with Save > Save VEX Code to File, and then #including this vex code inside a Snippet vop. This approach solved the bad normals issue seen in Approach 1, but it has a caveat. The issue with Approach 2 is what I will refer to as "tweak time", the time to see something update in the Mantra render view (with Mantra already running) when a parameter is changed/tweaked in the shader network. If I use the snippet version (Approach 2) of my custom function as an input to base_color for example, I get a way longer tweak time than when using the Material Builder version (Approach 1) of my custom function. In my actual shader setup this amounts to a 2-minute tweak time vs a 1 second tweak time (i.e., the 2min tweak time is approximately the same amount of time it would take to just restart mantra, so something isn't right...). Having to wait 2 minutes every time I tweak a parameter in the shader network is not ideal. Questions: 1. Can the bad normal issue associated with Approach 1 be solved, if so, how? 2. Can the tweak time issue with Approach 2 be solved, if so, how? I have attached a simplified hip file demonstrating the issues associated with the above two approaches. Any help resolving this would be much appreciated, so thank you in advance. Approach 1 (bad normals): What it should look like: pre-compile_custom_vop_function.zip Edited July 6, 2023 by wombat Quote Link to comment Share on other sites More sharing options...
wombat Posted July 11, 2023 Author Share Posted July 11, 2023 No one has replied yet, so I am wondering if the question is unclear? More generally, what I am asking above is how people go about creating an “uber” (lots of nodes) VOP function without incurring a major Mantra startup time hit (due to compiling the vop node network to vex every time). The purpose of this “uber” VOP function would be to generate basecolor and disp for the principled shader. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.