Anyone? :/

Hey all,

I have some guide hairs in vellum and my orient (point-)attribute which is generated using the guide deform sop is "flipping" (sign changes on orient vector components). This causes the guides to freak out during simulation, showing randomly changing length, jittering and weird behaviour etc.

Knowing that vellum needs a stable orient attribute to produce stable sim results, I tried to delete that orient attribute coming from the guide deform sop and instead let it be calculated on the vellum constraint node using "compute missing orientation". The values are somewhat the same and somewhat also different, but I also see some "flipping" orientation values from frame to frame on some guides.

If I disable the orient attribute on the guide deform sop (create orient attribute off) and on the vellum constraints sop (compute missing orientation off), I assumed no orient is calculated for my guides, but to my surprise, I still have an orient attribute present after the vellum constraints sop. The even bigger surprise was, that this orient attribute produced a totally stable sim.

This left me rather confused, and I hope you guys can maybe shed some light on whats going on here.
Why is my orient attribute flipping, how can this be prevented, and what (where) is the best way to calculate a stable orient attribute?

I unfortunately can't provide a hip-file showing the issue cause my current project is under NDA, but I still hope you guys can make some sense of what I say. I am using Houdini 18.5.392.

Thanks in advance and all the best,
Scratch

Hey all,

sorry all for the late answer - busy days!

I can only agree with what antc/Matt said. Tamte has pointed out a valid challenge of the “push” approach, and building in some flexibility for custom control (opt out etc.) is certainly a good idea.

Thanks again to everyone for all the usefull contributions to this topic!

Hi antc!

Thanks again for your explanations, this (all) makes a lot more sense now!

So, you could aways reference the sym-link inside the USD-file, and then - manually or by using pipeline scripts / tools - define to which file that sym-link actually points to. You could define that those links are pointing to the “latest-”, “latest approved-”, or “specific-version”, which can also be used to lock versions or even whole dependency trees. Another advantage using sym-links: you can change the version without having to republish the usd-file. The path to the sym-link inside the USD-file can be either an actual path or something meaninfull that an Asset Resolver then “translates” to an actual path on disk.

Or, if I get your first post correctly, have a sym-link for each asset within the shot-directory which you can point to every asset version within the asset-library.

Balancing granularity (many assest vs. fewer highlevel assets) is also important, as you have to change/update/manage all the sym-links.

Please correct me should any of this be wrong. I'm also aware that my sumary is super-simplified and in reality requires a lot of brain/pipe-magic to be robust and smooth, especially when combined / hooked up to shotgun/ftrack etc.

But, the concept is way clearer now, so thanks again to the two of you (antc, Matt), for taking time out of your busy schedules to help me figure this out! I'm sure there is still lots more to learn about USD/Solaris, but this is very cool progress!

Thanks to both of you for taking the time to write such detailed replies! Much appreciated!

So what I think I understand:

Asset Resolver:
Instead of using a real file-path as reference-file-path, you can use some sort of expression (like a search query) that is then read by the Asset Resolver (on load) and converted (resolved) into an actual filepath on disk.

Advantage:
The reference paths in the USD files are separated from the actual file location on disk.
USD can e.g. “talk” to shotgun (ftrack etc.), to get the v002, or the latest file's path on disk etc.

That enables you to either go for a pull or push workflow / approach / pipeline:

Pull: you use version numbers, e.g. ‘asset=box&v=2’ as ref-path, or even a hardcoded file-path (skipping the asset resolver). Assets, but also department layers like “layout”, “anim”, “fx” etc. get versioned, and you just load/update to whatever version you need. That “gated” approach might be a bit more conservative, but on the other hand also very save (causing less issues or specials situations that need handling).

Push: you would always default to ‘asset=box&v=latest’ as ref-path (or latest approved, or latest non-declined, etc.) and the asset resolver always returns (the filepaths to) the latest files when loading a shot/scene. (I assume that works kinda similar to sym links). This approach ensures that updates are propagated downstream quickly, but it is at the same time a bit more risky (prone to error), and thus needs thorough approval structures and - to still have control when needed - the ability to lock versions at certain points.

Locking versions -> instead of using “latest”, setting a specfic version to use. There won't be any more updates until the version is unlocked again.

Cases that most likely require locking versions:
Rendering -> Locking versions of renders that have been sent to the farm, so they don't get updated while waiting to be or being processed.
Creative choice -> When there is a decision to stick to / or roll back to an earlier version due to creative reasons / technical difficulties etc. (Although you maybe could just publish that older version again to make it the latest version).

What I don't understand (yet):

How do you actually lock versions?
Is that something the asset-resolver enables you to do? That expression/query ‘asset=box&v=2’ or ‘asset=box&v=latest’ is written into the usd files (instead of actual reference file paths) and I assume once that usd file is written, the asset resolver just reads the query, resolves it, and the DCC app takes that info and loads the files accordingly. But the Asset Resolver can not change the referece path inside of files, or can it?

Locking dependency trees?
If you lock e.g. layout.usd, does the entire dependency tree within layout.usd get locked aswell? Meaning all assets nested inside of layout.usd which consist e.g of model.usd and material.usd etc.?


Thanks again, I can't stress enough how helpfull this discussion is!

Thanks for your reply Antc!

antc
Most studios have some kind of asset publishing system where each new version of Box (using your example) would be written out to a new version. Other processes happening concurrently (layout, renders etc) would be reading older versions and therefore unaffected by the ‘latest’ version of Box. Once a version is published it is never modified.

Yes, that workflow (a “pull-pipeline” when I understand correctly) is what I am used to. Someone publishes a version, and the following departments/artists “pull” those updates in as required / told to (updating via shotbuild (and choosing the versions to load) or manual imports etc.).

antc
Using an Asset Resolver and versioned assets you can pretty much choose whether you work using a push or pull model.

That is interesting! I would like tho understand this Concept of an Asset Resolver (AR) better. So, when you load a shot in say, lighting, you would bring in the “layout.usd” layer, which is full of references to assets (=other usd-files), wich could be also full of references to other files (materials etc.). So all is heavily nested (correct me please if I am wrong).

How does this AR now determine which versions to load/use? All those files are as said nested in layout.usd. Does this AR change the reference-filepath of the references of nested usd file inside other usd files depending on some rules? If so, how? Can you maybe give me an example how that could work? I tried to read about it here: http://graphics.pixar.com/usd/docs/api/ar_page_front.html [graphics.pixar.com] but I have to admit that it still goes a bit over my head.

Thanks again to the community for the support! I hope this also helps others and not just me. The topic is for sure super interesting!

Hey all!

I am currently learning USD and ran into an issue I am unable to understand/resolve.

When you e.g. have an asset, “box.usd” which contains “box_model.usd” and “box_materials.usd”.

Once you start using box.usd as an asset in layout (if I understand it correctly), every change you make to the data inside that box.usd are live and automatically propagated forward through the pipeline to every scene that uses box.usd (nested references).

Daniel Flood, Technical Lead at UTS Animal Logic Academy, calls this a “push”-pipeline (https://youtu.be/o6VwS7VVx1I?t=383)
Minute 6:32: "Rather than requiring artists to pull updates into their scene we can simply determine that the next time an artist opens their scene there'll be new assets in the scene.“ He furthermore explains: ”We built-in controls to that as well because that can be a bad thing potentially".

And thats exactly the point I don't know how to handle/solve:
I get why you need to have controls for that. What if someone in lighting is currently rendering a version that uses box.usd, and the asset department simulatenously decides to update box.usd? That would update and screw the running renders, wouldn't it?

But how exactly can I prevent such updates from propagating forward prematurely and control when such updates take effect?
Or am I missing something here and that isn't really a problem?

Thanks in advance for sharing your insights!

rafal
[perhaps the metadata type was `int` instead of `bool`, which USD may be expecting.

Thanks for your tipp! I tried int / float and string like this:


and


and


and directly as bool (string?) like this:

The meta data value always changes , but the scene-graph does not react to it and still shows an instance. Wrong code / function maybe? (But it's not that big of a deal if it does not work using a wrangle. I by no means want to annoy/bother you with such a trifle. Configure primitive LOP works perfectly, and the wrangle was just out of pure curiosity as I said earlier.)

mtucker
Also, I'm told that the bug in extract instances has now been fixed.

You guys just rock! Thanks!!
If anyone else is reading this, Houdini 18.0.509 and up has the bug fixed. (https://www.sidefx.com/changelog/)

mtucker
just use a configure primitives LOP to set the “Instanceable” metadata on the primitive to false.

That worked, thanks a lot for that handy tipp! I was so focussed on using the extract instance LOP that I forgot about that simple option.

I also just for fun tried to do the same using an attribute wrangle LOP:
It did chang the metadata value when I inspected it, but didn't convert the instance for some reason. I guess that's not as simple as I assumed, but it does not matter actually. The configure primitives LOP works perfectly (and there is actually no reason to go for a wrangle). It was just out of pure curiosity.

Again thanks, you really helped me making progress here!

Thanks a lot for your answer, that works brilliantly!

I would have another question regarding duplicate LOP (instance) and extract instance LOP if I may.

To learn and to test some workflows I have duplicated (instanced) a bunch of my variants from above using the duplicate LOP. The transform primitives of the duplicates appear light blue (instancable prim) and the geo/materials dark blue (Uneditable “instance proxy” prims under an Instanceable prim). So far so good (I think).

I then tried the extract instance LOP to convert one of the instance back to actual geo to do some edits (just as a workflow test) but couldnt get it to work. The node errors out with the following message:


I'm sure I'm missing something / doing something wrong here. What would be the correct way of going about this?

Again thank you for your awesome support!

Hey Jake,

not sure if what you try to achieve / describe is possible. As far as I know, in order to assign a material, you need to have both the material and the primitive it goes onto present in the scene graph.

What you could work I think is saving the materials out in one file “materials.usd” and then have a layer for material assignment “material_assignment.usd”. that you can sublayer in again later down the line.

empty scene
sublayer / reference your models into the scene
reference your materials into the scene (“materials.usd”)
layer break (all edits from now onwards are on a fresh layer)
assingn all the materials
configure layer (“material_assignment.usd”) This will then (if my theory is correct) only contain material assignments.
USD ROP -> save your final result / layout (“layout.usd”).

Its not in one file as you requested, but might still be a solution that could work. You can update and version-track both files and it should work further down the line.

As an alternative to get all in one file (that might work but sounds tricky): Jeff showed how to use a anttribute wrangle to store a string comment on a material as attribute in his Houdini Hive Worldwide Asset Prep for Solaris talk (https://youtu.be/DI09YJLZ_6k?t=4863). Maybe you can use that workflow to store the material assignment information directly on the material and read it back further down the line when the materials need to be assigned. But that sounds over-complicated and I also have no idea how/if that even works. He also shows how to export materials to a separate file there if that helps.

I hope this still helps a bit, eventhough I couldn't fully answer your question. I am also still learning, so we are all in the same boat! All the best!

Hey all,

I am currently trying to wrap my head around variants in USD, and I would like to know if there is a way to have model- and material-variants both on one asset? (“Nested” variants?)

For example, I want to have an asset that consists of different shapes and materials (colors).

possible shape (variants): cube, sphere
possible material (variants): red, blue, green

In the end, I would like to choose something like “cube” “red”, or “cube” “green”, or “sphere” “blue”.

In the file attached, I tried to somehow “nest” the variants. My cube and sphere both have material variants (red or green), and those feed into another add-variant LOP that switches between the two (shapes with shader variants). In order to make it work I need to add a lot of groups ontop of the assets which “hold” the variants. It works techically, but it feels cluttered and not really like the way to go.

As an alternative, I thought about creating every possible combination of shape and material as variant, but having just 3-4 shapes + 3-4 colors as material will quickly increase the number of variants to an uncomfortably high number.

I could of course create an asset for each shape that only has shading variants, but I am wondering (for experimenting purposes) if what I describe above can be achieved in an elegant way?

Thanks in advance for your time and help!

Hey folks,

I am experiencing strange artifacts in my compressed fluid, happening under the surface (small dots / clamps of particles). It is also visible in one of sidefx's masterclasses:

https://www.sidefx.com/tutorials/h15-masterclass-flip-workflow-enhancements/ [sidefx.com] (minute 38:50)

It is not so problematic for meshing (at least not for my particular scene), but it messes up the white water emission because bubbles get emitted from those unwanted / artifact points.

I dived inside the fluid compress sop to investigate and saw that it has something to do with the surface field and culling. The culling leaves some points / chunks behind.

Did anybody experience the same and is there a fix to clean this up? (Beside cleaning it up manually by deleting points)

Thanks in advance for your time and efforts!

Thanks alot! I very much appreciate your help folks! There's a lot to try and cover for me, so I better get started

Thanks alot for taking the time to answer! I have to digest all you've said and will be back when I have any reasonable results!

If there is more to know, don't hesitate to throw it in

see ya soon!

Hey folks,

I'm currently working on a rock-fracturing/destruction effect using bullet for simulation.

I know bullet works with convex hull approximated collision geometry, and all input geometry (pieces) should be convex. This in mind, I tried to prepare my geo to be entirly convex, so no clustering on the voronoi fracture node, just regular voronoi pieces, which should be convex by default. The thing is, they are not entirly. In certain cases, where the input geo has some concave areas (unfortunately, a rock is not a sphere), the collision geo does not match the actual geo. After fracturing, when the pieces are packed back together, I end up having interpenetrating collision geo due to that unmatching pieces (which have a little bit of concavity). This is causing the simulation to explode on frame 1.

How can I prevent this from happening? How can I prepare my geo (a rock) in a way that my sim does not explode?

I know the RBD Solver does not have that problem, but I would love to use Bullet for this project because of it's glue-networks, which are a very handy, artistic tool to control your destruction/crumbling effect. Eventhough, is it better to stick to RBD when it comes to voronoi or fractured stuff in general?

Bullet-Solver
+ fast
+ easy to set up
+ nice (artistic) control using glue-networks
- popping simulation behaviour, exploding on frame 1 because of interpenetrating convex hull collision geo

RBD-Solver
- way slower than bullet
+ much better collision handling (volume based, therefore the shape, whether it is concave, convex or something, is more or less irrelevant)

Thx in advance for your help! I'm looking forward to your answers!

Cheers from Austria,
Philipp

As a alternative, you guys might want to take a look at cmiVFX “embers and Ash” tutorial. It has a very long and complete section covering all relevant topics regarding bullet , like bullet settings and parameters, glue-networks, fracturing techniques, etc. It is absolutely worth the money and may be a good addition to the sidefx stuff which will hopefully be available soon

http://www.cmivfx.com/tutorials/view/506/Houdini+Embers+And+Ash [cmivfx.com]

I was just going to ask for it too! Cool to hear it will be published! Its hard to find anything out there regarding this topic! It's something you inevitable come across when dealing with destruction shots.

Can you somehow tell when it is going to be released? I cant wait to get my hands on this!

I do not understand?

particles -> liquid surface node -> i get geometry -> feed into geo-lightsource.

or

heat field -> import heat field from dop to sop -> convert volume to mesh -> feed into geo-lightsource

both should work (what I don't know at the moment is how to get the heat field out of dop and into sop-level). But it should work I think.

No?

Hey there,

Yeah I know that Houdini is linear. I just didn't know where to set my display gamma to 2.2, have the color swatches adjusted etc. Basically I lacked the knowledge which buttons to press in order to view everything the correct way. But as said, I got it working (Edit -> Color Settings )

Geometry Light -> Interesting idea!
I could convert my pyro source particles to a volume, and the volume to a mesh. (or the heat-field to a mesh). Doing so, the Lightsource would dynamically adapt it's shape based on the sim-data.

I'll try that! Thx!