Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

118 Excellent

1 Follower

About LaidlawFX

  • Rank
    Houdini Master
  • Birthday 02/23/1985

Contact Methods

  • Website URL http://LaidlawFX.com

Personal Information

  • Name Ben
  • Location Toronto, ON
  • Interests Getting away from the computer
  1. Overall: I'm trying to limit unnecessary cooks of this create geometry generator as it is relatively expensive. I don't want traditional work, or even on creation, to cook the node as you will incur this cost. As for FileCache node, as far as this system, that will happen down the road. I just wanted to clean up this code/generator as much as possible internally. I was thinking about using a switching mechanism between a null and the generator, with a following cache node to store it after the cook, but that is a bunch of events that needs to happen. I was kind of hoping there was a python with button equivalent for it.
  2. The button call, the print and other functions run via button call. Thanks . However, the geometry creation part does not work. It errors on the Geometry Creation. GeometryPermissionError: Geometry is read-only. Edit: I attached an example hip file with the original concept and the new button update. PythonSopCreateGeo.hip
  3. Hello, Currently I have a python sop where in the code section it creates geometry each time the node cooks. I would like it to only cook/update on a button press, and cache it in-between pressings. Is this possible, and how would you structure the code to do it? Thanks, -Ben Edit: https://www.sidefx.com/forum/topic/25493/ - Similar thread.
  4. I'm very curious, about this too. I'm moving today so I don't have access to phone. One I know bad idea would be to copy boxes to the point with random scale, the biggest one select first and remove from the group, and you can perform a check for over lap. And then correspondingly add smaller boxes.... A better idea is to use the same vine growth method with food, but in vex... A third idea would be to use a noise function and clamp to 5-6 tiers. I think there is a function in vex(math in general) that does this. No guarantee there would be not be an L, but you may be able to pick an appropriate noise function for the variety like a small perlin. Good luck. Hope u solve it.
  5. For a quick solution you can make or use a tool like mine. http://www.orbolt.com/asset/LaidlawFX::QueueSOP This allows you to queue the pressing of buttons in series. a fancy version of opparm -c in python. Unfortunately Orbolt makes you split it up for each context, so this one is just for sops. But you can make the same node available in all context. This would be just short of a render farm distribution. It is heavily production tested as i use the logic at each studio so i can go home. PM if you have bugs or want more details.
  6. You are MMB not RMB.
  7. In sops on the node with your geo with UVs. You can RMB on it Save > Texture UV to Image...
  8. I loosely believe you can only have materials assigned at the object level, with FBX export. So you need to split your geometry up like that.... but... The real test is to apply two materials per a face/primitive in maya/max import it into Houdini and see how the imported tree looks like, that will tell you for certain, how it needs to be exported. Edit: This thread may be helpful.
  9. IMO, it really comes down to how much rendering you are doing and how much time you have to babysit. If you're only rendering a few short sequences in a day, and if you are only working in Houdini I would say use Hqueue as it is free, or just run the nodes in a series. However, if you are going to use your one machine 24/7 to render from multiple programs, with multiple hardware needs per the computation type. Any farm would be better and reduce your overall workload and gain you higher efficiency. i.e. all the time you spend queuing up the next render. You can run that math in excel to see how much time/cost it saves, by taking a previous project and counting all the layers, programs, and time per frame it cost. You can even find the time between jobs it took to run between the last frame written to the next frame written, either with your previous render farm, or how much time it took you to press render on the next sequence. This time allocation can even go into how late you had to stay up to be your own render wrangler, testing for failed frames. No render farm will save you if you end up just rendering a bad sequence, but all the other allocation issues you won't have to worry about. IMO, Overall deadline is a good farm. I enjoyed working with it and I would recommend it. But there are hundreds of farms out there. We had another thread going about this.
  10. Awesome!
  11. Unfortunately I think at this point you need to recompile the source code for it to get it to work. The last time it was compiled with the binaries provided was for a version of Houdini you can't access anymore on an older version of Max. For people who have a computer sci degree this should be pretty simple, for those with art degrees it's a bit more of a pain. If you are working with peers pin down a co-worker that can help you recompile for your version. Inform SESI that you would like them to support the max plugin internally if this would be a common workflow for you, so they can allocate resources if enough people ask. Best of Luck.
  12. Maybe just limit the highlight style so it's generally less obtrusive, too.
  13. Good luck with your bug submission. Out of curiosity how are you cloning Houdini to the network? Is Houdini installed per a node, per a common software server, or on the workstations? Generally speaking Houdini as a whole is pretty "low level" i.e. Houdini Engine vs Houdini (FX, Core...) Also maybe it could be the format you are writing too. If it uses a third party writer like FBX as opposed to .bgeo there is a limit to what they can change in that type of code. Make sure you give SideFX a good repo, otherwise they'll only be able to help so much.
  14. Not really. You should submit a bug to SideFX with an example scene encase there is a bug. Especially with as much details about your system setup as possible. It could be a fringe case with your hardware setup. If you really don't believe it's the hardware, it could be competing software or your farm that is grabbing your nodes access, i.e. Nuke stomps on Houdini, or your farm software is not sophisticated enough Qube vs Hqueue. It has been a while since I ran into that issue, but the last few years I've gotten to work on very corporate data server hardware.
  15. I would say the reverse that the scene level should just be called the object level as it is the more common Houdini vernacular among studios. Scene mostly exist in some sparse documents and a few Houdini headers, it's just more prominent in 16 now. i.e that right corner text overlay that didn't exist before. However, ever single context know shows the more formal name, too. Instead of /mat/ being Material it is VEX Builder. SideFX overall would have to pick one name and go with it for every context for the industry to change.