Jump to content


Popular Content

Showing most liked content on 05/26/2022 in all areas

  1. 1 point
    Yes, you need to learn Python if you want to be Houdini TD/dev that is useful in production. Also take VEX as another language that is a must if you want to be called a Houdini TD. But VEX is yet a different topic. If you know nothing about Python at this point, I'd recommend you to take one of the general Python courses available at codecademy.com, or similar online learning source. Also read through official Python docs where you can find detailed information about specifics of the language - https://docs.python.org/3/ Personally, I very much liked https://www.tutorialspoint.com/python/index.htm - this is by no means a complete guide to Python, but you can quickly find the most commonly used functions and syntax. Very handy if you starting off and don't remember even the basic stuff yet. As for houdini specific tutorials, I just looked at random tutorials on youtube showing how to do this and that. Other than that, I would also humbly recommend reading through my own notes that I was making while learning: https://vfxbrain.wordpress.com/2016/03/15/python-in-houdini/ With the same breath, I'd like to encourage you to make your own notes, because you will be forgetting a LOT of things while learning, and it will save you a heaps of time being able to go back to your notes and just look up how did you do some specific thing last time. Also I have to mention I am not really a developer myself, and to be honest, my code would be probably described as shit by any skilled developer - I typically use Python to build simple tools for myself, that help me avoid doing the "same 10 clicks" over and over again, or to overcome manual tasks that are too tedious. Being a full fledged developer requires yet another level of skill in terms of how efficient and clean your code is, and Python alone will probably not be enough. Other than VEX that I already mentioned, you will soon find yourself immersed into various OS related topics, network topics, maybe C++ if you wanna go badass, and other things that I would'n even dare talking about Good luck
  2. 1 point
    Hi, here is an approach. The formula is similar to your example only the parameter space is bit different. One value should be between 0 and 2 Pi. esher_spiral_mapping.hipnc
  3. 1 point
    @dyei nightmare looks lovely that whale in desert damm my fav one
  4. 1 point
    Here's one way, there's no doubt many ways to achieve this effect. As you say, if you set @v in sops and enable 'inherit from points' in rbd, it only works on the first frame. if you enable 'overwrite attributes from sops' and specify v, then it clashes with the rbd solver which is also trying to set @v, and your pieces fly away. One way around this is to detect the first frame a piece is made active, and only add @v for that frame. Here I use a timeshift to move the geometry back by 1 frame, and I copy active from the shifted geo to the normal geo with a new attib name @active_prev. In dops, I added a wrangle that just tests if @active != @active_prev. The only time they won't be different is on the first frame the piece is made active. As such, I add @v by pulling it directly from sops. The rest of the time, rbd will set @v by itself. chkbox_fix.hipnc