entagma patreon

AHTYA 2.0 – pt. 11: Rendering A: Overview and Preperations

🕑 Added 2023-08-17 16:07:23 +0000 UTC

Comments

Andrey Davlikanoff

Hello, Chris! At 9:10 of this tutorial: I'm curious, why does the Color attribute gets lost after AttribRemap Node and therefore we need to use AttribTransfer? It seems like this is because of PathDeform node and if yes, probably, some of the nodes in Houdini do destruct attributes, don't they?

Bruno Suraski

Thank you, Chris! That worked out! I am looking forward to new releases on this course. I am really enjoying it.

Entagma_Chris

Hey! If your attrib is disappearing directly on or after the vellum solver, then it's most likely due to an old cache. The solver still has an output saved from before you added the color node above. To fix this, try hitting the "Reset Simulation" button on the solver, sim a few frames and then check if the attrib is there. If you happen to have a file cache node directly below the solver, you'll have to update that cache as well by hitting "save to disk", after you checked your vellum solver.

Bruno Suraski

Hi Chris, I am following your tutorial carefully. Is it possible when you assign the colour node to the "Flower Base", it does not "travel" to the Null "Flower Mesh"? I can see after the Vellum Solver, the Cd attribute disappears. Thank you

Chris Cousins

Thanks Chris that makes a lot of sense. The info (in CGWiki) about parallel nodes having to do more work is interesting, and updates to each node only affecting that specific node and not subsequent ones are a bit unintuitive to a Houdini user where you expect changes to ripple through the whole chain. It seems like a valid reason to use the long chain method anyway, so I'll try switching and see how I get on!

Entagma_Chris

Oh I should clarify: By "working on your own" I mean you're delivering rendered frames, not USD files to some other department down the pipeline.

Entagma_Chris

Hey! As with most things Solaris and USD this is not super straightforward to answer, but I'll try my best: First of all the "one long chain" method of noding is generally preferred in Solaris. However, the advantages you gain compared to your current style of noding for the most part only start appearing once you get very deep into the features of USD. One slight annoyance I can see with your node tree is that using two material libraries can lead to name conflicts, if two shaders in those libraries happen to have the same name. But in general: If you're working on your own and treating Solaris mainly as a way to build small scenes for your Houdini setups, there's no pressing need to change your nodetrees. There's also a nice little writeup on noding styles in Solaris on the cgwiki: https://www.tokeru.com/cgwiki/UsdGuide04

Chris Cousins

Thanks for this! Quick question about the Solaris setup. I've not used it much, but in the times I have I've found myself using a layout like this: https://www.dropbox.com/scl/fi/cl9bx5mvb2pu45mpini7u/Screenshot-2023-08-18-090429.jpg?rlkey=hqele6hujqxo2b9reieiakpww&raw=1 where the scene objects, lights and cameras have separate areas, and then are merged into the render settings. It just seems to make sense to me. However every single tutorial I've seen with Solaris (including this one) has everything linked in one long chain, and it's made me wonder if this is a valid way of building a Solaris scene and if there's any advantages to the long/tall way that I'm missing out on!