davpe

answering my own question - it's stored directly in .shelf file (including scripts), and it's relatively nicely editable with application like Notepad++ or something similar

Hello friends, I've got a questions I couldn't find an answer for in docs but maybe somebody will know. I've been messing around with my custom shelves and by accident I managed to remove all the tools I had in my custom shelf (stupid me). Later on I found out I haven't really deleted them, I only removed them from the shelf and they keep living somewhere within Houdini (if you click Edit Shelf I can see it in the Tools list - as shown on the picture). My problem is that there is a shitload of tools and I don't remember what am I exactly looking for by name. This Tools list doesn't offer any filter or search functionality and going through the entire list is tedious. On top of it there is a lot of random "tools" that I used just for testing stuff and I'd like to remove those. In short, I'm wondering where can I browse these in some more convenient manner, and eventually remove the ones I don't care about?? It doesn't seem to be living anywhere in $USER_PREF_DIR Anybody? Thanks, D.

to recreate a path attribute you need to work each piece in for each loop (for each named primitive) or else things get mixed up as you can see. so, voxelize each "path" piece separately and then (still inside loop) copy over the path attribute from the geometry before it has been voxelized. don't use attribute transfer as that is proximity based. use attribute copy that works on element number basis. normally this wouldn't work but sice the path attribute it just one value per any currently processed piece it does not make any difference.

you can have any number of stylesheets, both on scene level and object level. I tend to use scene level stylesheets however, as they're more versatile and I've experienced some odd behaviour when object level and scene level stylesheets are mixed together (may already have been fixed thou). Stylesheets rely on json language and I think it's currently not possible to populate stylesheets using Python. However, with Python you can create an empty stylesheet and inject it with pre-existing json script, containing all the assignments and overrides. This json script can be either written from scratch, or generated from an existing stylesheet (that's a good way how to take existing material assignments and deploy it to different hip files). cheers, D.

It does the trick if your mesh subdivides nicely...

if you only have a flat surface (like a mirror) then adjusting geometry normals should be good enough (default normals smooth any corners < 60 deg). if it's a more complex shape then naturally more polygons = more accurate reflections.

given you've got your uv coordinates on rest mesh and the animated mesh is the identical geometry with the same point numbering: copy point positions from animated mesh to the rest mesh (attribute copy SOP). done. if rest and animated geo is not exactly the same, for any reason, use point deform SOP.

you're welcome. it is as simple as it gets. either you go back to the original asset, do the adjustments there and export a new version or you have to unpack the geo in houdini and do the changes there. there is no alternative to this i'm afraid. anyways, i'm not sure what you mean exactly by textures not lining up with UDIMS unless unpacked. packing does not have any effect on how uv coordinates are deployed. if the render looks differently when unpacked my guess is there must be something wrong with how you apply materials/textures in houdini.

the reason why packed geometry is so fast is that you don't have access to all the data (unless you unpack it). that is the idea of it - you exchange some flexibility for speed. so what you should do you should do is to prep your assets first as normal geometry, and then use packed data for rendering (so it's fast even with very heavy scenes). at rendering phase it's assumed you don't need to see textures or anything like that in viewport, and the priority is to make things as lightweight as possible. so even very heavy scenes can be manipulated comfortably. if packed prims allowed what you asking, it would, from nature of things, make things slow again (as you already found out), and therefore there would be no benefit from packing them. if the geo is too heavy to work with, you have three options - 1) split it first and unpack only the parts you need, 2) get faster workstation or 3) optimize where possible so you have less data to process

principled shader is like a standard shader in Mantra now. you can also use Classic shader, which used to be called Mantra surface before principled shader was implemented.

there is a Labs/Gamedev tool just for that. conveniently called "remove small pieces" i think, or something along those lines

from what i see you just need to remap @curveu attribute: @curveu = fit(@curveu, 0, 1, 1, 0); // by adjusting numbers inside the brackets you drive the resulting thickness and then do your thing with @pscale and it should be it

ok i don't wish to fight and i certainly don't think vfx and games don't have anything to learn from each other. quite opposite actually. i just did not understand how your comment relates to the original question, which was how to do this stuff in houdini. i posted an example with a short description how i did it. your reaction was UE and Eevee is more interactive than Houdini. i guess everybody can agree on that but what is your point, i don't know

Yes, Unreal and Eevee are realtime engines and it's main feature is speed. Both also come with some painful limitations steming from it's realtime nature, which prevents it to be used as a reliable film production tools (so far). But isn't this thread about how to make a detailed ground to match the plate, in Houdini? Discussing rendering capabilities of UE doesn't seem to be relevant to the original question. I don't know exactly what you mean, I guess that's a workflow specific to realtime rendereres. Seamless blending is typically achieved by making the cg extension look as close to the real thing, and then by compositing

hi, 1. the issue with mplay - not sure what exactly is it complaining about but my guess is you missing a codec or something that you need to save the video file 2. the warning on Mantra ROP is just a note that a default light have been created automatically as you don't have any lights in your scene (with no lights render would be completely black) 3. if you render from Mantra to disk, you'll end up with sequence of frames anyways. it's common to use some compositing program if you want to save it as video.