davpe

hey, i've just been looking into the same thing. In Maya Yeti menu, there is "Abc to Unreal" option (or something with a similar name, i don't have it in front of me now). That takes the resulting groom and exports it as alembic curves, which you can then attach to skin geo and deform in houdini. works like a charm. just be careful, it always exports the hair density you see in Maya viewport so make sure the viewport density = render density.

not sure what do you mean by falloff. there is no falloff in reality - I'd say the underwater environment has more less constant density. you can see objects close to the camera more clearly bcs there is less volume in between the camera and the object. objects located further away appear hazy because you look through a larger amount of water, thus the haze effect is more apparent. by that I think I'm stating the obvious thou, so maybe I don't understand your question. for underwater scenes I typically just create a box large enough to contain the entire scene, make it volumetric, give it a basic volume shader, dial shader parameters so it looks how i want, and that's pretty much it (regarding volume). if it looks just white, or black, then make the volume density much smaller (either on the object, using volume_VOP, or VEX, or in the shader). you can also try reducing the shadow density parameter to get desired haziness/brightness. lighting naturally plays an essential role too. also, scene scale affects what numbers you have to dial in to make it work. but the falloff I think you talk about is a natural result of seeing objects close to, or far away from the camera.

AttribVOP can run over any elements you tell it to (there is a "Run Over" dropdown menu on the VOP node). You can also bring different element attributes using import_Detail_Attribute_VOP / import_Primitive_Attribute_VOP / Import_Point_Attribute_VOP / import_vertex_attribute_VOP. i.e. using this you can bring vertex attribute into point VOP, for example.

i think you can still reference the Simple baker fom inside of TOPs and just iterate mesh variants on input.

not sure why exactly it doesn't work for you, but for batch processing and automation tasks I'd suggest you to take a look at TOPs / PDG, which is specifically designed for this kind of operations.

you don't typically print attribute data to console (but possible with Print VOP). instead you create an attribute with bind export VOP, then you can look at it using geometry spreadsheet, as you were advised. Data type (float, int, vector, etc.) is set directly on the bind export node. Then you have to pay attention which element the data is stored on. The emelent can be points, vertices, primitives, or detail (detail is like "object"). For better understanding how to use the Geometry Spreadsheet, i recommend you to read the docs. As for how to further use that data, that is a completely new topic, and quite a broad one, so hard to give any general advice without knowing what exactly you want to do.

i just ran into this issue as well, and I'm pretty sure this is not an intended behaviour. would like to see a solution to this, otherwise Solaris would be pretty much useless in collaborative environment.

well most importantly I think if you deal with 50k asset variations, which is like... I can't imagine what would you need that many for, but anyways - with that kind of stuff you don't wanna do any kind of manual editing as that would obviously be super tedious labor. instead you want to generate this by some controlable randomness. you need a system that takes some variables, add some logic related to them, shake it, and then let it generate many many houses, according to the rules you've put in. then, if you want to cherry pick and adjust some specific iterations, you can do it at the end of this process. obviously this is not a trivial task, and we're talking about multiple different challenges that each can be approached different ways. depends what exactly you need, how much time and skill you have, and how realistic result you want.

you can add any parameters to Texture Bake ROP if you click Edit Rendering Parameters (the cog wheel icon in the top right corner of parameter window).

I've seen this before and setting environment variable HOUDINI_ACCESS_METHOD = 2 in my houdini.env file has solved the issue in my particular case. from the docs: HOUDINI_ACCESS_METHOD This value can be 0 (the default), 1, or 2. It selects the method used by Houdini to check file and directory permissions under Windows. 0 checks the permissions of the current user against the Windows user and group permissions set for the file in question. This method may be slow on machines that use a network login server. 1 uses a different method for checking the Windows user and group permissions, but relies on functionality that is broken in Windows 2000 Service Pack 2. Method 2 simply checks the file attributes. This method is fast, but ignores the user and group permissions, and so may report that some files or directories can be written to when actually they cannot.

I was answering Petko Ganev's original question that was about time shifting alembic camera.

to make this info a bit more complete, you can also time offset alembics directly on alembic node by having an expression in Frame parameter. for instance $F + 10, or so...

what error does it say? mine wasnt working one time bcs GPU drivers.

can you do HDA perhaps? not sure whether that works with lights and stuff but maybe worth trying... in case you havent yet

actually, i was wondering about doing the same thing not too long ago, when I needed to do a camera timewarp. see the hip file bellow. in short, you need to extract a camera transform into an oriented point (with N, up, and all that jazz), and then use rivet_SOP to drive other objects around with this point transform. works quite well for me. cheers. camera_timewarp.hiplc