Leaderboard

i came across exactly the same thing. the outer layer is simply casting an undesired shadow which can be easily removed in shader with isShadow VOP:

micropolygon can offer a good performance with volumes, particles, hair, DOF, and MB. it's not friends with anything pbr or raytraced thou. that means any modern pbr shaders, area lights, raytraced environment lights are bad and will render quite slow. if you wanna go with micropoly, stick to shadow maps and old school shader models (lambert, phong...). that makes it largely obsolete these days unless dealing with heavy volumes or particle sims,and perhaps some other special cases that are difficult to raytrace. heavy geometry and instances are not benefitting from micropoly in any way i would say (maybe rather opposite bcs unlike raytracing, micropoly needs to fit an entire scene in memory at once, if i understand it correctly)

hi yeah texture is also a valid way how to approach it. performance-wise it will be much less efficient than using geometry blocking (sampling noise). I think using geo blocking doesn't actually add anything to the render time (why would it?). currently there are no other options out of the box for driving "directionality" of area light sources, other than already mentioned. of course if you are resourcefull enough you can build your own light shader. that's one of awesome things about Mantra that it's so open to allow you to do that. me, in most cases, can get the job done with spot light sliders or geo blocking, (or maybe using multiple parented lights) , and light texture being the last resort in some special cases. very much depends what the scale of your scene is - for small scenes using textured lights can be perfectly fine, with larger scenes less so. cheers.

Well, internally, next frame, when the P updates, pprevious will still contain previous P, until it's updated to P at the end of the frame, usually by Gas Integrate So technically it is previous P during the solve

Set Flow SOP preview: 1. https://vimeo.com/347248950 2. https://vimeo.com/347476024

updated cache_chain_001_fix.hiplc

@targetv is used by solver as a velocity of the medium the object or particle is in (air, water, whatever) It couples with @airresist, which sets the resistance of such medium (as a product of medium density, drag coefficient, ...) So even at 0 it @targetv will still affect your velocity as it will drag it down whenever @airresist is not 0 One way would be to animate @airresist to 0 so it will not affect it at all Or just don't use @targetv, update @v directly within DOPs when you need to give the impulse @force is another option, as you mentioned

functions that write to not current point like setpointattrib() or create new geometry like addpoint() etc. Are queued in point order and executed on a single thread after all multithreaded code However that doesn't really matter in your case as much as the fact that in the single wrangle point() function will never read the updated "y" attribute, it will always read it from the input from so that's why 2 wrangles work for you You can always flip your code to be other way around and therefore more multithread friendly Like make all points look within the certain radius for points 17 and 306 and in the loop of found points they will change @y accordingly, as each point will only change its own value it'll be able to read it back using @y within the for look as expected

I love when I ask here and then I have a thousand ideas just cause I asked it here. So theres this attribute called stopped. i@stopped = 1; makes that set of particles to stay steady

I have modified your scene to allow both uv and shop_materialpath to flow through the fluid simulation. The higher the resolution, the better the quality of the attribute transfer. I generally discard FBX materials that are generated by Houdini and use a wrangle to re-write the @shop_materialpath to point to the material context I am using. Sometimes /shop, sometimes /mat. I have added a wrangle near the end of the Genesis3_Male node inside the FBX import node. This wrangle uses a simple IF statement to detect the old material name and reassign a new one that points to /mat context. Inside the /mat context I have dropped down a Principled shader and renamed it to "Face". Go ahead an extend this code by writing the material path code for the other 16 materials on this object. Then you can populate your /mat context with shaders and plug in your maps to those materials. if(s@shop_materialpath =="/obj/gen3_fbx/materials/Face") { s@shop_materialpath = "/shop/Face"; // Or use the /mat context. s@shop_materialpath = "/mat/Face"; } ap_119_FLIP.hiplc

Hey guys, I found the solution now. So even in duveil's file there were some problems that didn't make it work in the end. The first block has to have "fetch feedback" instead of "fetch input" to make it work just like the old loop. File atattched. ForLoop_wrong_done_right.hipnc

Smoothing geometry may help a bit. It will leave UVs straightened and tileable and reduce interpolation zigzags. It will also help UV Flatten to output proper geometry without such big distortion. Also you may try Delta Mush, it may simulate results you need. Swap UV with P, then apply DM on straightened UVs using UV Flatten output as a second input: delta_mush_uv.hipnc