Jump to content

Leaderboard


Popular Content

Showing most liked content on 09/19/2016 in all areas

  1. 4 points
    Hey people, take a look at my bachelor thesis film „CRYSTALLOtroph”. It was made at the UAS Kaiserslautern. The tools were Houdini and Nuke. Have fun watching!
  2. 3 points
    First assignment for my Houdini/TD Independent Study. Had to rush it out because another project I was going to turn in this week is being problematic, so the node graph is kind of kludged together. Will animate a demo once I get the UI worked out. Needless to say, I'm pretty new at this.
  3. 2 points
    Ok I managed to get it working. So it looks like you dont have to create fracturepart attribute at all. I dont know why its said in help you have to. What controls the tearing is fracturethreshold attrib (per point). And once this goes under Fracture Threshold * -1 (defuault 0.1 whould be -0.1) the fracture will happen. At least this is how I understand it And a file if you want to check it out (sorry for hiplc format I dont know if this open in apprentice too) TearingClothTest_v002.hiplc
  4. 2 points
    well, finally it´s all just math, so basically yes. however, the main difference is not the math itself but how it´s used. it might help to think about it like this: in houdini you are working mainly with geometry described by discrete data in 3d space and represented by spatial coordinate points, edges and polygons. this is basically what computer graphics is about. it´s about how you generate and modify geometry. precalculus and calculus on the other hand is much more about "pure" math and less about geometry, in other words, the level ob mathematical abstraction is much higher. in calculus you use geometry only to visualize functions and equation. well, it´s a bit simplified but in general i think its true ... so, if you read a book about computer graphics you´ll find it alot easier to make use of this knowlege in houdini because it´s related to geometry and not to functions. this doesn´t necessarily mean that it´s easier to understand but it´s at least much more direct "transferable" and usable. take for example derivatives. the mathematical formulation for the gradient is very simple and easy to understand but how do you use it on a quad mesh? you won´t find the answer in calculus but most probably you can find it in books about computer graphics. on the other hand, if you don´t know what a gradient is and what it does, it´s maybe not the best thing either.... to cut a long story short, if you really want to know how and why things work like they do, and i assume thats the case, read both books in parallel. thb, i didn´t read one for some time, so i leave this to others. the links by oskar seem to be quite good. hth. petz
  5. 1 point
  6. 1 point
  7. 1 point
    I haven't read it yet, but it was recommended on http://realtimerendering.com book list and it's got good reviews on Amazon. 3D Math Primer for Graphics and Game Development, 2nd Edition by Fletcher Dunn et al. As for calculus, there is an old book Calculus Made Easy by Silvanus P. Thompson. Free to download at Project Gutenberg. If you find KhanAcademy's math lessons too long or just want text instead, check out amazing Paul's Notes. This is by a professor, started intially for his students. More cool resources: CodingMath on Youtube. Tightly edited. To the point. 3Blue1Brown on Youtube. More general math. Probably what Igor meant in the original post. Nature of Code. A book about programming behaviors and forces. Could be an easy first step to understanding how solvers work.
  8. 1 point
    Hey Diego! Sure! Here is a very basic FLIP surface tension implementation using laplacian as a factor; You can change from Laplacian to Curvature to see some little differences, But for most cases Laplacian works better for my tests, and even better yet for smoke, as you can see in the example file, the FLIP sim behaves almost like a pyroclastic cloud at the begining, so imagine this in a gas sim. Hope That Helps! Alejandro ST_tutorial.hip
  9. 1 point
    Here's a quick mock up from your file. There's several things I did in there. Use Null objects for the controllers. This serves two purposes: 1) It prevents them from being rendered by default, and 2) It provides convenient options for default "control" rigging geometry. Added Grid SOPs inside the controllers to serve as the actual lattice geometry so that we can just merge them into the rig object. Added a new /obj/GLOBAL_TRANSFORM controller as the parent Positioned the controllers into place and then ran "Clean Transform" on them so that their local parameters are zero for animation. In the rig object, we merge the grids from the controllers and use them as the lattice. Since we're using the "points" mode, it doesn't matter whether the grids are connected or not. For the "rest" input in the Lattice SOP, I just inserted a Null SOP and then "locked" (red node flag) the grids while they were at the desired rest position. This "freezes" the geometry to act as the "rest". So now we can just animate the control objects and have it directly affect the rig Turned off the selectable (green node flag) on /obj/rig since we don't want the user to select/move it Finally, I deleted everything unused. rigTest_v01_edward.hipnc
×