Jump to content

bentway23

Members
  • Content count

    79
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

4 Neutral

About bentway23

  • Rank
    Peon

Personal Information

  • Name
    Mark Reynolds
  • Location
    NYC
  1. OpenCL Exception: Could not open OpenCL program

    I do indeed, and it appears to match yours exactly (at least, the OpenCL lines do). I'm sure it's just an option I have to check somewhere. (I've noticed all along, both with this and with the previous Houdini build (18.5.408) that I would get an error any time I tried to use OpenCL with a pyro solver, but I didn't think much of it given how lightly I was using pyro. Today was my first time using an OpenCL node. I'm guessing it's just a setting I have to check somewhere.)
  2. OpenCL Exception: Could not open OpenCL program

    Forgive my ignorance--where is that?
  3. Hello! I'm trying to use an OpenCL node and the console pope up with the error in the subject line as soon as I click on it. Googling didn't help me--I updated my GPU drivers to no avail. I also added "HOUDINI_OCL_DEVICETYPE=GPU" to my .env file (per another forum), which didn't help. When I open the nVidia control panel to turn on OpenCL, it doesn't appear in any of the device manager settings, just OpenGL (and for the program-specific settings, Houdini doesn't appear at all). I'm running Windows 10 on a computer with decent horsepower and an RTX 2070 SUPER graphics card, so computer beefiness or up-to-date-ness shouldn't be a problem. I'm also running Houdini Indie (the latest build--18.5.499). Thanks for any help!
  4. Alrighty, I'm trying to export a very straightforward system to alembic for use in Maya. A very simplified version is attached--an emitter emits particles, there's a trail, those are added to create a line, and a polywire makes them into geo. This should be easy (haha), but I'm getting inconsistent results (user error, no doubt), none of which are the one I want. For the most part, the color sets are inaccessible--Cd shows up in the color set editor, but does nothing when used as Cd in an Arnold user data color node for a material. Also, the geo tends to be "flickery", and getting close to it in the viewport the Cd-based colors (visible, at least, in the viewport) are jumping about and it looks like there are occasional normals reversing. If I reimport an .abc into Houdini it seems to work fine. The closest to success I got was to write it out as a bgeo sequence and use Houdini Engine to bring that into Maya and write an .abc from Maya--the geo appeared okay, but the color set didn't carry over (even though I had "write color sets" clicked). What is wrong with my settings, or with the way my system is built? Thanks for any help! wires_example.hiplc
  5. This might be more of a Maya question, but I have yet to find a Maya forum where one can find an answer within a year . . . . (Also, I've Googled aplenty and this question doesn't appear to have been asked since 2014.) I'm exporting an alembic of geo for use in Maya. I've made sure the Cd values are promoted to vertices so Maya can read them, but when I import it into Maya, on the first frame (1000.0) the colors are clearly there in the viewport, and in Mesh Display-->Color Set Editor Cd(RGBA) shows. The thing is, the minute I change frames it is gone, not appearing in the viewport, not showing up through Arnold's User Data Color, and not in the color set editor--even if I go back to frame 1000 it is gone. I've tried it both with and without "export vertex colors" checked in the Arnold tab on the shape node in Maya and even if it's just on frame 1000(.0) with the color set showing Arnold's user color node isn't seeing it (or piping it into the render, at least). If I bring the import back into Houdini it works great. What am I doing wrong?
  6. Gentle nudge/push particles away from surface (using SDF?)

    This is great! I'm glad to see I was at least in the ballpark, and I was able to quickly create and inner "core" pushing them away from the center and taming that unruly mob by simply adding instead of subtracting the inner gradient. Also, the visualize tree is new to me and way better than the create-a-bunch-of-points-create-an-attribute-and-scroll-through-the-geometry-spreadsheet method I've been using. Also, I wasn't sure about "fill interior"--my approach was (theoretically) making a hollow VDB from the container walls and using the external-to-the-vdb-but-inside-the-container values for the sampling. Thanks so much!
  7. Alrighy, I have a big wedge of stupid in my head that is keeping me from doing this. I have particles emitting into a container (a super-simplified version is attached). I would like to get it where instead of the usual bounce/slide off a wall, the particles slow down and gradually move/are pushed away from the containing walls. I'm assuming this would be done using SDF/volume sample/volume gradient and a POP wrangle modifying the velocity based on the sampled values, but I just can't get it to work. I've seen lots of tutorials on using this approach to get particles to stay NEAR a surface, but my brain isn't adapting that to a nudge-away-from-a-surface instead of a nudge-towards. What am I doing wrong? The POP wrangle code-in-progress (the collider is input 2, the VDB is input 3): float samp = volumesample(2, 0, @P); vector grad = volumegradient(2, 0, @P); @v *= -grad; SOMETHING is happening, just not what I want. (And ideally I could have a second SDF inside the container pushing out, thus gently keeping the particles within a certain radius of the container wall, not going to the center.) Thanks for any help! example.hiplc
  8. Would there be a way to procedurally set the capture region for a bend deformer, for instance if you're using it in a for loop for the same object but with different sizes/rotations? I guess the main question would be figuring out its angle, as bounding box and centroid expressions could do most of the placing and sizing (except if the object was rotated the bounding box size wouldn't be accurate).
  9. Alrighty, I think I've found it, in case anyone else has this issue: When you create the new nParticles to attach the cache to you must first create the PP attributes. Then when you attach the (pre-existing) nCache it appears to read them in automatically. (I saw this on a separate thread, it just took a little toying about before I could make it happen in my own life.) Just hoping to be of service, because knowing is half the battle.
  10. Using Engine I have been able to import a particle cache into Maya just fine. Scale and color came through and were easily applied in Arnold. However, I need to recache the particles as a Maya nParticle cache to hand it off to someone else not using Houdini Engine. I can get it to cache the general position/lifespan, but it doesn't appear that any color/scale(radiusPP)/alpha(/transparency) information is in the re-cache. How can I make sure those attributes make it through to the nParticles (re)cache? Thanks for any help!
  11. My brain is having an issue here. I have a vellum sim that emits a new piece of geo every x frames. I need to take the final simmed geo (tet softbodies) and point deform the original hires geo. This wouldn't be hard to do the old brute-force way--by the end only four instances have emitted--but I feel like this is something a for each loop would be perfect for. The image attached shows my attempted setup (it's part of a much bigger project, not practical to upload). I bring in the cached sim and blast the elements I don't want for this step. I ran it through an assemble node (because I thought doing for-each named primitive would do the trick here, no success yet, though, so this might be unnecessary). Then there's a wrangle that takes the creation frame (from the vellum path name) and converts it to an integer "num" attribute, which (theoretically) a time shift could read to know what frame to freeze the simmed and source geo to get them to match up and then do a point deform inside the for each loop. (The reason I have to time shift the source geo is that the geo going into the vellum sim was rotating so that each emitted object would come in at a different angle. I referenced copied those transforms to the hires geo so they match in time and space for the beginning of the point deform.) The first (maybe last?) problem I'm having is that I can't get the time shift to harmonize with the for each loop. It's reading the attribute correctly and behaves right outside of the loop. Some other Googling indicates that it has to be connected to the node before the loop, but then I'm having trouble isolating which object to freeze. I've seen similar questions on various posts, but none seem to quite answer what I'm looking for here (or I'm just not bright enough to translate the fixes). Thanks for any guidance on this!
  12. So I'm looking for Test geometry: template head-- https://www.sidefx.com/docs/houdini/nodes/sop/testgeometry_templatehead.html But on Houdini 18.0.460 it doesn't appear as an option, alongside Crag, Pig Head, Rubber Toy, Shader Ball, Squab, and Tommy. Is this one of those hidden/deprecated nodes that has to be enabled?
  13. Is there a way to "smooth" a look at constraint, so it's a little less frame-by-frame precise and a bit more drifty? Thanks!
  14. pnoise: remapping output values

    I need a simple noise that loops over the course of five (or however many) seconds, moving the @P.x of the points on a line back and forth, and so I'm using pnoise. I would like to give it precise min and max values (I want things to be able to bump against each other but not intersect), which would be easy enough with a fit, but I haven't been able to find it's precise output values in any reference. Over the course of 120 frames the output appears to be 0.5-centric and it goes between 0.22398 and 0.800649, so it doesn't appear to be an even +/- any obvious value like 1 or 0.5. How can I find the actual minimum and maximum outputs for pnoise so I can make sure it hits zero (or 1) at its extremes? I've tried periodic noise in a point VOP but that seems very unwieldy. I know Unified noise can loop and is always 0 - 1, but it has a whole lot more to it than I need to deal with. (Plus I just want to know how to do these things in VEX). The only output value reference I've been able to find is that aanoise is -0.5 to 0.5 and unified noise is 0 - 1. If it makes any difference, here's what's tucked in my point wrangle (reference parameters on an outer master null): int offset = prim(0,"id",0); float roughness = ch("../MASTER/roughness",0); float frequency = ch("../MASTER/frequency",0); int period = ch("../MASTER/period",0); float noisemult = ch("../MASTER/outerNoiseMult"); float noiseval = pnoise((@Time*frequency)+offset, @P.z*roughness, frequency*period, 0); @P.x += (noiseval * noisemult)-(noisemult/2); //the noisemult/2 is to get them back to 0-centric Thanks!
  15. Far less annoying than having to manually create a visualizer each time. Works like a charm--thanks for the workaround!
×