Jump to content

StepbyStepVFX

Members
  • Content count

    190
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by StepbyStepVFX

  1. Moana Island Scene [Dataset]

    Hey Atom, what are your render times for such scenes ? Particularly the ones with so much instances ? (and what machine ?). This is just for me to know what I should expect...
  2. Pop Grain issue! Please help!

    CHOPS are slow and sometimes complicated (not too many tutorials over there), but once you dive inside, it really opens new possibilities ! I really love chops !
  3. Pop Grain issue! Please help!

    In this case, that’s simple : - create a NULL after your sim, this where you will fetch the translation data of each point - create a CHOP network - inside the CHOP network, create a Geometry CHOP node, set it to fetch the animated tx, ty and tz and make it point to the NULL sop node you added inside your network. I let you look at the tutorial below to look at how to set it up correctly (you need to adjust some parameters like the frequency at which you sample the channels etc.) - add a filter node, that will « blur » your channels. You can adjust the width of your smooth filter. - back to your sop network, add a Channel node after the null, to fetch back the translation channels of each points. Basically, what is does, is that it takes the translation (position) of each points and consider it like a « signal » / curve. Then you can do signal processing on those curves, in that case you can smooth it. Then you re-export that and it will override the initial position of each point. Bear in mind that smoothing will kill the popping/flickering of your particles, but it will affect all other particles as well, so you need to apply that only to your popping particles. And be carefull when deleting particles : make sure you identify the particles consistently over the frames of your animation : to build the curves, the chopnet needs consistent id values over the range of sampling. Otherwise, you will mix positions of different particles and/or re-apply smoothed channels to the wrong particles and it will mess everything. Selecting the right particles to smooth the movement maybe probably the trickiest part :-)
  4. Pop Grain issue! Please help!

    Maybe you can try a POP Wrangle to « clamp » the speed of particles ? Another thing you can try is to simulate like you do as a first pass, then use CHOPS to clamp or filter/smooth the channels of positions. I use that with RBD sometimes, but with lots of points, it may be heavy...
  5. tree destruction - getting that "bendyness" into it ?

    Hi, Maybe an idea is to do it in two times : - a first where the tree isn’t broken into pieces / splinters, and maybe even just a proxy geo that you simulate with FEM, with the roots attached on the ground and your collision object to give the deformation. - then a second that starts during the first sim, at a point in time where you like the « bendyness » of your FEM tree, but using a fractured version of your tree at this step of the first simulation, using classic RBD with maybe some spring constraints to keep some « bendyness » and fluidity in the fracture... Hope this helps, although I did not opened the file (running out of time...)
  6. Small tablet or laptop for Houdini

    Hey, look at what MSI is doing on laptop workstations, with nvidia cards. I have one since 2015 and it is working like a charm. Hope this helps.
  7. VEX: get attribute values into an array

    If one wants to run it in Detail mode, one should indeed use the npoints(0) function that returns the number of points of the first stream of geo incoming in the Wrangle node. That being said, I don't see the point of running that code on Points, as it basically process the same thing npoints times :-)
  8. Packing circles of different radius

    I tried an algorithm that plays with the radius of circles given some fixed points, but it is not optimally packed. Moving the points on top of that would bring better results.... I share the file although that's not quite a good solution. To get a better solution I think it would require an algo that would be using an iterative process with both the radius and positions. packedCircles.hip
  9. Packing circles of different radius

    Interesting challenge again :-) Maybe use a point wrangle, and use nearpoints to return, for each point, the closest point surrounding it. Then store an attribute with half of the distance between the 2 points. Call it firstRadius for this example. Then in a second pass (another point wrangle) we can see if there is room to increase the firstRadius of each point, depending on the firstRadius of surrounding points. Store a list/array of, say, the 10 closest points of each points. And for each points of this list compare the distance between your current point (ptnum) and the point of the list you are iterating in, and the sum of their firstRadius attributes. Take the point for which this difference is minimal, and increase the firstRadius accordingly. Then instance a sphere or a circle with the radius stored in FirstRadius. Not sure if my explanations are clear... I haven’t tested, but I am curious to see if this works. Maybe tonight :-)
  10. UV boundaries to edges

    The way you would do your own VEX "Connectivity SOP" with "Use UV Connectivity" and therefore determine a border of your UV is by returning the list of all vertex associated with a point, and check if the UV attribute is the same for each one. If one vertex relative to a point has different UV attrobute, then the primitive it belongs to is on another island. So to compute the "class" of each island, a non optimal algorithm could be : take a primitive, assign it a "class" number attribute, list its prim neighbours (take its points, and use pointprims function to retrieve the prims containing this point); then for each points of this prim, list the vertices that refer to it; for each vertices, retrieve the prim to which it belong, and assign the same "class" number to neighbour prims only if the vertices refering to the same point have the same UV attribute. If not, skip the primitve. Iterate over all neighbours prims, and for all those prims that has the same "class", list their neighbours that hasn't been assigned a "class" (to avoid infinite loops over the same island), and apply the algorithm until there are no neighbours that (i) hasn't been assigned a class attribute or (ii) that hasn't been skiped in that loop. Then iterate on the "remaining" primitives (the ones that has not yet been assigned a class or that has been previously skipped because belonging to another island). I am pretty sure this can be run more efficiently to avoid some prims to be visited several times before being assigned a class, but this should work...
  11. UV boundaries to edges

    I think you can also use the Connectivity SOP node, with the UV function. It creates an attribute that you can later use to define groups.
  12. Extra small particle effects - flour, powdered chalk, etc

    I would definitely use a POP network to drive the biggest chunks of chalk. I would then create a particles trail to those chunks and use that as a source for a fluid/smoke sim...
  13. Break constraints problem setting attributes at sop level

    Strange it doesn’t work... maybe it is breaking and deleting the primitive correctly, but reimporting it from sop afterward ? To avoid that, check if your constraint network in SOP context (outside DOP, where the Geometry Source of you Constraint Network is pointing to) is « animated » or considered time dependent. In this case, you have to manually set Overwrite with SOP to 0 on the Constraint Network DOP node, and delete the default expression inside this parameter. In short, it will import your network once at the start, and then relationship will live only inside DOP without being updated from SOP. And check that your display flags are set correctly to your last node in SOP Solver, sometimes i make this simple mistake :-)
  14. opinput question

    The color goes to the center of the grid because the @myP is set to zero, which indicates the @opinput_P returns 0, for most of the points : don’t forget that it returns the position P of the corresponding point in your opinput1, and there is only 1 point (with id 0). As the wrangle run the code over each point, the @myP is OK for point 0, but as soon as it iterates over the points that have a number higher than zero, it can find the opinput1_P of the corresponding points in this input, because there are not. That’s why I used the point(1, « P »,0) = it stands for (input1, Position P, point number 0) Not sure if I am clear :-) The @opinput1_attribute is OK when you look for « bijective » streams of geometry in terms of topology (or at least when what you seek to do doesn’t need to reference any particular points, as in this example)
  15. Help to solve my struggle and to finish my suffering

    Hi, I can't encourage you enough to watch those video from Entagma, where they talk about creating geometry, space colonization algorithm and much more stuff that you can use as your primary toolbox to achieve what you're looking for (and by the way, learn how Houdini works :-) :
  16. opinput question

    The Point Wrangle is running th epoint over each point of your grid, therefore when you write @P=v@origP, you are basically telling him to change the position of each point of the grid to v@origP, which is the null vector (because it hasn't been set to anything else previously). So the grid collapse. Can you explain what you are trying to do ? What is the "current position of the grid" ? You talk about the center of the grid ?. If you want to color the points of the grid proportionally to their distance to the center of the sphere, then maybe just put that code into tha wrangle : v@myP = point(1,"P",0); @Cd = fit(length(v@P-v@myP),0,5,0,1); Don't forget to use fit() because your length maybe outside of what you can display (r,g,b) values should be between 0 and 1. If you want to color them based on the distance to the closest point of the sphere (because it is deformed and you want that to influence the color), then use that code instead : @Cd = fit(xyzdist(1,@P),0,2,0,1); Hope that helps
  17. Python numpy geometry question

    I am not an expert but I would store info in different .txt files : a first one with all the points and their coordinates (each line with the point number, 3 coordinates, separeted by coma or else), a second one where lines contains prim number and its vertices numbers, and finally a third one with the coresspondance between vertices and points number. Then, using dictionnaries, you could rebuild the points, and recreates the primitives using hou.Geometry creation methods. http://www.sidefx.com/docs/houdini/hom/hou/Geometry.html Hope that helps
  18. Detect Collision intersection in bullet sim

    I understand better. What you can do is run a Connectivity SOP to create an attribute that will be piece-specific, then loop over each piece, create a nested loop and run a boolean to have the intersection between the piece of outter loop and piece of inner loop. Not sure if I am clear, but the idea is to « test » each piece of your model with each other piece and just keep the intersection. Therefore it will be easier to visualize... Noit fantastic but it can work :-) By the way, the Boolean SOP is eligible to multithreading when you place your loops into a Compiled Block, to accelerate the process if you have many pieces. http://www.sidefx.com/docs/houdini/model/compile Hope this helps you
  19. Detect Collision intersection in bullet sim

    The impacts are recorded (if option is on - it is by default) as data for your object. You can see them and use those impacts within a SOP Solver node plugged onto your rigid body solver. By the way, you can use an impact analysis node to filter those impact data (there can be a lot... ) : http://www.sidefx.com/docs/houdini/nodes/dop/impactanalysis.html Concerning concave objects: there are many ways to solve that to get more accurate results in collisions : you can break it (voronoi fracture for example) and check the "Create Convex Hull Per Set Of Connected Primitive " in the Bullet data tab of your packed object. Don't use the Concave object option : it is truly unstable, and you get inter-penetrating objects all the time with that option. It really sucks... Hope that helps
  20. breaking glue and hard constraints;

    Instead of changing the constraint name, you could just put it in the broken group, and append a dlete node after your Wrangle, setup to delete primitives that belong to broken group. So just replace the line s@constraint_name = "pin_broken"; by @group_broken = 1; and append a delete node with the group mask with "broken" inside.
  21. LIDAR to Heightfields

    They say that if you want to work on your Lidar point cloud as a VDB primitive you have first to convert it using Convert VDB Points SOP. Under the hood, heigthfields are 2D volumes data , so I guess I would : import your files with Lidar Import, then convert to VDB, then to volume and play with volumes wrangles to transfer data from this volume into a 2D volume called heigth. That’s not straightforward but it seems this is the only way
  22. Infrared Foliage effect

    Me neither, I was just a hobbyist :-) By the way, Wikipedia was not existing by that time, and I understood just today, thanks to you, why there was this "glowy vegetation" : The prominent blooming or "glow" often seen in the highlights of infrared photographs is an artifact of HIE [the name of the B&W Kodak film I used] and not of infrared light itself (nor even of all IR-sensitive films). This is because although conventional photographic films have an anti-halation layer that absorbs scattered light, HIE lacks this backing. I will sleep less ignorant tonight... :-) I am wondering, now, if I had the same glow with the IR Ektachrome. But anyway, seems the DSLR performs better that those films, so they are the new reference I guess, if someone wants to fake it.
  23. Dirty effect on principled shader

    You may also wants to play with the curvature VOP :
  24. Random Voronoi Fracturing

    Voronoi patterns have a clear "mathematical" definitions, hence their recognizable look. So you can't stop them fracturing that way :-) BUT : there are ways to deform your geometry before fracturing it with Voronoi, and doing the reverse transform afterward on the fractured pieces. Here are two methods I remember : - one method is using simple transforms node (to elongate the geo on 1 axis with scale, and doing the reverse after fracture, to create shattered wood pieces for example) - other method by using noise (like a mountain sop deformation), keeping the old/original position of points as an attribute of the deformed geo, fracturing it, and then using the original position attribute to reverse-deform the geo (I don't remember how exactly, but maybe using a pointdeform sop, or maybe just interpolating an "original position" attributes for the newly created points). Maybe you already knew those two methods and were seeking more exotic ones ?
  25. Infrared Foliage effect

    Well, I can’t tell, I never bought a smartphone :-) (but I use the one my company gave me). I admit I never looked at the price of such modified DSLR, just read some articles in photography magazines I buy from time to time... One thing I remember, that can be useful if you want to achieve the real IR look, is that it was very difficult to have a good focus, IR rays converging at a different focal point, and that apart from that, there was kind of a glowy effect around vegetation... maybe it was just focus problem, but maybe it was different air temperatures that was radiating from around the vegetation. If I can find my old negatives, i will try to scan that and publish it to you guys. Maybe you had a different experience with a modified DSLR Skybar ? But if matching this IR film look is not the main purpose, indeed, just changing the colors of the shaders and playing with gamma on the final image may works well without too much complications. see U guys and Artemis don’t hesitate to share your results ! I am curious to see what you get !
×