urlGrey

Hey all, I'm trying to rotate Object B to match Object A's local rotation with Python. I've been using objectB.parmTuple('r').set(objectA.parmTuple('r').eval()), but this seems to be very wrong ^^ There seems to be some euler shinanigans, for starters, so I was going to use a rotation matrix but I can't find some setLocalTransform equivalent, and setParmTransform is equally unhappy. Thanks in advance for helping me understand how Houdini prefers this to be done!

No--increasing the Fuse distance sometimes grabs them, but half the time causes problems elsewhere, as you could imagine. Yes! Thanks for that, f; I wasn't searching the right keywords, but I knew someone had to have asked, somewhere. Thanks guys!

Thanks, marty, I'll check it out! ....................Thank you, Noobini. The correct author of the linked video is the venerable Simon Fiedler. If I hurt Simon's feelings for referencing the blog that lead me to his video without mentioning Simon himself, I deeply apologize. Please find attached my setup alongside my most earnest apologies for posting these vexing questions without including a scene file. I have heard of 'scene file posting' before, but never thought the day would come when I'd have to take such drastic measures. elaborate_complicated_example.hip

Hello all, I'm using the pre-fracture transform method (following this Lester Banks video, specifically) to roughen up voronoi cuts. I feel like I've done this before without a problem, but now I'm discovering some little quirks in the form of misaligned points after cutting (see attached). Increasing the mesh resolution helps; it's even good enough, but in some cases it never goes away--some points that should share the same position are a little offset from each other. This is present even on my test setup with only a sphere, Attribute Vop to apply noise, and the Voronoi Fracture. Has anyone seen this before? Surely it's come up, but I couldn't find previous posts. Thanks! PS. The place I'm currently working at has Houdini 16--that's not it, is it? (I only ask that because it's the first time I've used 16 and I feel like I would have seen this behavior before.) Increasing the mesh's resolution and changing the Scatter seed until the problems aren't very visible has made it good enough, but I'd still like to know what I'm doing wrong/if there's a way to prevent this in the future. Thanks again!

Thank you SO much, Stalker! It was the Cache Object Transform on the Python Object. (!) Whew, I'm glad I asked; I don't know how long it would've been before I thought to turn it off, there xD Thanks again!

Hey all, Sorry to add another Python cooking question (I've seen a lot, searching), but here goes. I have two subnets, a 'source' (from an .fbx) and a 'target'. The Objects in each correlate by name, and those in the source subnet are keyframe-animated. I'm driving the target Objects via: sourceMg = sourceNode.worldTransform() # beep boop, additional calculations go here targetNode.setWorldTransform(sourceMg) It works great, but once Houdini caches the frame the script is no longer (apparently) cooked, which makes sense--I pasted my code into a Python Script Object for convenient testing, which I suppose is not its intended use. If the HOM documentation is telling me what to do instead, however, I don't see it. There's the 'Python object' page, but I don't know that this is quite the same. In short: my script works as intended, but after the scene plays through once, Python stops moving the target nodes (I'm guessing because Houdini quits cooking it, since it's not doing anything Houdini expects it to do, like make geometry). Where does a script like this belong? I'm sure there's something embarrassingly obvious I'm missing--it's just a little extra confusing to me because I have to manipulate everything on the Object level. Thanks in advance for the help! If anything's unclear, lemme know

I'm using ray tracing to render, but depth maps for shadows. Earlier I was kind of wrong--it went quicker just because of resolution and reduced pixel samples.

Hey Marc, I actually cached the simulation to disk as a bgeo.gz via the dop i/o, so that wasn't really a problem (directly, anyway, that I know of). The render started somewhat quickly, even, but by the early 100's (frame 120, say), it started taking an inordinately long time per frame. The kind of inordinate that's 45-55 minutes. Now that I've done some more investigating, I'm beginning to think the problem is somehow computer-resource related, or something similarly mysterious to me. I just jumped to frame 150 in the version I posted, only intending to check and answer your second question, and it took less than or around 10 minutes. The only difference is the lack of geometry, that I doubt mattered at all, and the camera... hmmm Oh, but that was just in the render view, by the way, not saved as a tiff to disk like the original was--which was 1920x1080.

Hello all! My work occasionally uses Houdini, so I've been trying really hard to learn the ins and outs this past year. I have a scene, here, that contains a large and fairly detailed smoke simulation. It starts out rendering quickly enough, but soon slows to the speed of a frozen snail glued to the bottom of a large brick. I've looked at several posts here and elsewhere on rendering smoke, and I have a general idea of what could be taking so long, I guess, but I thought it'd be wise to post my scene file and ask a kind soul to glance at it. Is it just the size and detail of the simulation that slows it so much? Some render setting? Both, equally? :shrug: The only difference between what I was rendering and the version I'm posting is the inputs and outputs (cache, render, etc) are deleted, and I also deleted what little geometry it had. The emitter is in a strange place because the camera move (deleted from the version I posted) and geometry were imported from another application. My computer is very fast, but if I should be more specific in that area just let me know. Thanks very much in advance. Grey smoke.hipnc.hip

Thanks edward! With C4D I get an error that says "This file contains unsupported data || Please try to export again as IGES type 126, 128 and 144 with parameter space curves", but it works great with Maya, which will suffice Thanks again; wouldn't have guessed. Nice signature. ~Grey This just in: Houdini-->Rhino (saved as IGES type 144)-->C4D works perfectly.

Hello all, I've done some googling, read the supported geometry file formats page and etc., but thought I'd swing by here to see if you guys knew the best thing to do or if this is even possible. My big picture goal is to get a (complicated) spline from C4D to Houdini and back again. Right now I'm trying to get any spline (curve) from Houdini to C4D (or even to another program and then to C4D). Am I missing something obvious? Thanks for the aid. ~Grey

Cool stuff, jonny. I'm kinda new to Houdini and copied your method for the lulz with a teapot--the trial is looking good (for me). Here are the first few frames (downrez'ed a bit for posting). I just lowered the particle separation.

Finally figured it out! I overlooked an example file and just stumbled upon it last night. I pretty much just copied what they did in "SourceVorticlesAndCollision" without the vorticles. All I had to do was switch out the multisolver with a smoke solver (which I didn't think would work until I saw that example file), and bring in the collision objects as shown. I guess it's nice that the smoke solver just handles it for you like that, but I'm still a teensy bit curious how you'd use the Collision Field to go about it 0.0

Hello. Long time lurker first time caller. I was following the sidefx advanced tutorial on fluid solvers from scratch (http://www.sidefx.co...2200&Itemid=344), which has been ++useful and helped me understand a lot of the fundamentals and workings of these things in Houdini. He doesn't, however, go into *collisions* until the flip fluid-style setup, and I need help understanding collision implementation with my current gas dealio (jpg attached). I understand I need an SDF volume (right?) and to use the appropriate non-divergent node, and I understand the data and fields and the solvers I've used so far. I tried making an SDF volume with a box and bringing it in via the sop scalar field node and trying to set up a collision field with it all, but I imagine that's more or less wrong. Attached is a screen shot of the very simple setup I have so far (ignore the bypassed nodes) that just incorporates density and velocity with a pump thrown in. Thanks for your help! -Grey (I also tried picking apart a dop network made from the pyro shelf tool and a rigid body, but, while it works, I don't know why:)