Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


LaidlawFX last won the day on April 6

LaidlawFX had the most liked content!

Community Reputation

139 Excellent

1 Follower

About LaidlawFX

  • Rank
    Houdini Master
  • Birthday 02/23/1985

Contact Methods

  • Website URL

Personal Information

  • Name
  • Location
    Toronto, ON
  • Interests
    Getting away from the computer
  1. HQueue Problem

    Yeah log into the clients with the account they will be using and make sure they have access/permission to read/write to the necessary drives. It seems silly but this where most issues stem from. HQueue is pretty simple in the grand scheme of render engines. You will always need a license per each client/process. Mantra Render tokens are free so you just need to ask your SideFX representative and they will grant you them. As for processing geometry on the farm you will need Houdini "Engine" licenses these used to be called hbatch licenses. They cost a bit, but you can also use Houdini in any other host application you want nowadays, too, so they make it worth while.
  2. +1 don't. Scale a camera, scale the environment. If the environment get's extremely out of wack to do so, then the camera is probably at the wrong scale. Sometimes if you track a camera the solution maybe be correct, but at the wrong scale.
  3. HQueue Problem

    Make sure you log in to that box/blade and you try and access the directory and drives from that user account. Permissions is generally the biggest issues around these problems.
  4. @numpt vs npoints (VEX vs Hscript)

    The software has been actively developed for over 30 years, so while many would agree on simplifying the language choices, there are many reasons there are different languages. That is the same as asking everyone on Earth to speak one language or all of programming to use only one language. Each of them were developed for good and for worse, for their specific reasons, and depreciating stuff is actually amazingly hard. F1 did a really nice explanation of a few of them. There are even more languages and modules Houdini can use too, like HDK or opengl, and all the various hybrid languages. Houdini is a full DCC, not a program designed to do just one functionality. For instance VEX is a vector language that is C/RSL derivative language developed for fast processing on a CPU for point information and color. While python is extremely shitty for handling geometry, but really well designed for interchangeability and ease of coding, for instance having different CG programs talk to each other. OpenGL is strictly designed for GPU functionality and hardware differences. But neither of these languages would be good for building a program like C#.
  5. You can change the unit systems in Houdini under Edit > Preference > Hip File Options. bytw, Maya and Houdini have the same scale and unit size by default and Katana should based on how it was created at Sony too. It sounds like your scene files are not in standard human scales. All physic calculations are done at human scale as the baseline whether for lights or simulations. If you are dealing with .0001m you are dealing in micrometer's and that's not what most CG math solutions are designed for which can explain your biggest issues. "Normalizing" the assets is pretty common if your pipeline does not produce standardized assets. With your import/export HDA you can include a scale, or fancier normalizing calculation so that it changes it so your calculations are the same to produce consistent results. This also helps because for physic simulation calculations, the parameter values you end up entering are in a more human contextual space. At a previous studio they had decimeter as standard which worked for the game engine, but made physics appear too faster or slow relative to in the game.
  6. Copy geos on grid with random position and rotation

    This is called copy stamping, or instancing, in Houdini. Look for those terms and you'll find lots of help on it. Here are the help docs on it. http://www.sidefx.com/docs/houdini/copy/_index
  7. Houdini 17 Wishlist

    For the python sop take the create spare parameter button from the wrangle sop. This makes quick setups soo much easier.
  8. Reload cache after crash Houdini

    From inside DOPs did you save out the data as a .sim? Otherwise you will not be able to relaunch the sim, from the last point it wrote that file. As a heads up most people don't write out .sim as it's a very large file with tons of data, that takes up a lot of disk space. Most companies have a system where they save only a few files of leading trail of the sim, and then delete the rest.
  9. hou.OperationFailed handle & format

    Cool. I'll give it a go.
  10. hou.OperationFailed handle & format

    Hello, I was wondering how you format to handle a hou.OperationFailed exception. I was using the below function to convert the file sop to python, because yeah... http://www.sidefx.com/docs/houdini/hom/hou/Geometry#saveToFile but in order to catch the exception it raises hou.OperationFailed http://www.sidefx.com/docs/houdini/hom/hou/OperationFailed So this is not the case for try, except in python. My Houdini Feng Shui is just not showing me the way at the moment. Thanks, -Ben
  11. writing a .bgeo through python

    Thanks to the past
  12. Houdini 17 Wishlist

    Yeah the old uber shader versus the multitude of shaders. I would say as long as those monolithic nodes have good ui design then i'd be ok with them keeping some. The add and delete sop are definitely good candidates for demolition.
  13. Games vs Game Development Toolset

    The Games Shelf is unlike other Houdini feature. These tools are just incorporation of standard nodes, that would generally be TD tools at every studio. Which for a lot of folks save us from recreating the same magic sauce at each studio we work at, standardizing some common task. Also these tools are not developed by the engineers that need to go through the normal protocols of creating/supporting a software. The Github Source will have the latest and greatest set of tools, but these are in development and not hardened tools enough where they would be incorporated into the package. You'll notice a lot of the ones actually in the Game shelf are not even hda, but subnets. Once a node/tool is incorporated into the package, SideFX needs to maintain support for it for a lot longer. Generally they are hesitant to include just any type of tool for this reason. Thus why a lot of antiquated nodes are still around for backwards compatibility. This type of development allows more active involvement and allows early adoption for consumer. If it's a great success then you may see it incorporated as full tool. Once it's fully supported by SideFX I imagine there is less reason for them to have it on the Github, consider it a form of graduation from R&D to fully supported. So which tools you use depends on your needs, whether you need the latest and greatest, or the hardened tool. Give props to the guys who support the Github, they do good.
  14. Houdini 17 Wishlist

    I would enjoy if SideFX cared more about the UX of each node's parameter interfaces. Some of the new nodes are increasingly getting better. But there are soo many nodes that are just clunky to use. The conversation about the Add Sop highlights it. It's a very ugly UI for a nodes parameter lay out when you sit there and stare at it. Another reason to look forward to it being split up. Having to make multiple clicks in a parameter's interface to get to the more common usage area of it is unclean. They need a heat map of each node's parameter use, and do some spring cleaning.
  15. Exporting FBX with animation to Unity

    If you import a skinned object into Houdini, like a standard character rig. You can see how it is set up. This is way easier to see than explain. The alternative is a bone per a point rig. It seems you found the vertex animation method, which is cheaper anyways.