Jump to content


Popular Content

Showing most liked content on 04/16/2018 in all areas

  1. 2 points
    The previous preset of .idx used to be ascii before they made if binary to optimize performance, however, this reduce the amount of control you can have with the system. Source and revision control are impossible in a binary format. You can longer edit by hand in each preset which is really needed for production control. Additionally you want to be able to have per project control of presets, which I can not at the moment recall if the previous ascii .idx could handle i.e. for each HOUDINI_PATH variable you have be able to add each new preset to the list for studio and project control. The previous system of having all the presets in one file, I'm not personally a fan of as I would like each preset to be it's on file. The old presets have their own custom format, which was not intuitive, so documentation and a standard jason or xml format would be helpful. For those not used to hand editing presets, which I'm guessing is nearly everyone in the last five years or more, perhaps a UI from within Houdini. This UI could also help all the new people. Also allowing for some more complex preset controls, like node name, color and shape that are now maintained by different systems. This may include also other on name change, ondeleted, on input change actions. Which it would be nice to perhaps have a way to subscribe a bit to the presets, and maintain more of an active link, so that you know that this node is actively prescribed to that preset so when the studio updates the node preferences they can update. While perhaps dangerous in some ways, in the course of a large production, in order to say change a whole sequence of .hip files or Houdini Engine .hda options for a level team. A studio could change the options on demand instead of tryign to change the defaults on the node which may not be at issue for the other half the studio. For instance, all volumetric redering mantra nodes need to have a better tweak, or you need to autocorrect all the settings because some juniors keep messing with the settings and you want to lock down or hide the parameters. Something I am not a total fan of but perhaps needed in the world of Orbolt where people are selling assets, is to be able to add these presets to the .hda. In production this would generally be more a piece of shit decision, but in the world of smaller teams this may be helpful to store all related items of an asset together, especially now that we can store asset in their uncompressed version. The current work around for this system is to make your own python preset system. Which is a bit on the companies burdensome side. This also means you now have multiple preset systems to maintain. The old Gear Menu setup, the newer wrangle drop down menu setups, and then your own studio one. Additionally this brings to light that unlike the L-System preset, now with wrangles people expect presets to live in multiple places. A lot of newer people not even being aware there is a preset menu in the gear menu. One of these should be eliminated in preference of the other. So that means to take all of one system and put it into the other including making it more production friendly. Which in reality means going to all the wrangle nodes and putting those options in the gear menu, to make one homogeneous system. Additionally fixing all the under the hood reason why those options were not included in the gear menu solution. While in theory it is OK to have two different preset options in two different places, when accounting for studio options it really makes three. At the end of the day this really just highlights the issue at hand that the original system needs to be upgraded.
  2. 1 point
    Use a Point Wrangle, and for each point calculate the vector that goes from the camera to each point, normalize it, calculate the dot product of this vector and the normalized « aim » vector of the camera (I don’t know what kind of setup you have, if the camera will move etc... but it should be easy to compute or to create), and use the arccosine trigo function to get the angle (should be Y if the aim vector and the « target » vector toward each points are in the horizontal plane) Hope this helps
  3. 1 point
    It is possible to make them collide in the same dop network, or at least to make the wire affect the packed geometry simulation. For the collision from RBD to wire I haven't found a stable solution yet that can work with complex geometry. I've tried recreate your scene with just the wire hitting a thin fragmented wall and looks like some collisions happen after 30-40 frames the wire pass through the wall. Anyway wire can collide with RBD non packed objects. Packed RBD I don't think can collide directly with wires. So you have just to add an intermediate step. First I've disabled the direct collisions between wire and packedgeo. Then I've added two RBD objects one for the wire and one for the rbdpackedobject. You can add here the collision geometry you prefer. For example: in the rbdobject1 I've make it editable, and inside in defaulgeo I've imported the wireobject and copied/packed to every point one sphere. At the DOP network level of the rbdobject1 put "deforming object" ON and "active object" OFF, so it updates every frame. Everything else you can modify it as you prefer. Same thing with the RBD object of the wire. The only difference is that here there are the usual problems with the collision geometry of fragmented objects. Inside its defaultobject I've used collision source for generate a VDB volume, and I think it's the most accurate. Just an idea, maybe someone here on the forum have a better solution. COLLISION GEOMETRY OF THE WIRE: ONE WAY COLLISION: MUTUAL COLLISION:
  4. 1 point
    Random placement using Cellular noise. cop_random_tiling_v2.hipnc
  5. 1 point
    if(rand($F)>0.5,1,0) should do the trick ?
  6. 1 point
    Houdini Digital Asset to visualize arrays of matrices attributes. https://www.orbolt.com/asset/prb::MatrixDisplay::1.0 Cheers
  7. 1 point
    Got a bit bored and thought of this thread, so here are some roughly similar gif recreations from Bees&Bombs. knotwave waves on waves triangle sweep six chequered waves six.hipnc chequered waves.hipnc knotwave.hipnc triangle sweep.hipnc waves on waves.hipnc