Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Everything posted by LaidlawFX

  1. Houdini 17 Wishlist

    Houdini 16 launch has been announced, February 21st! Time for the dreamers and the wishlist* to move on to the next major version. Perhaps a 16.5... as gleaned from the Amarok event??? So IMO I think the gauntlet has been thrown down. Houdini needs to be a fully fleshed out 3-D package that any person can create content in from beginning to end. No more weak spots, where you have to dive into another package, since you have no choice. Halo I mean COPs I'm looking at you. If I want to use another package that's fine, but I should no longer need to use another tool from my tool belt from the beginning to end of my 3-D authoring pipeline needs. Houdini Engine UI functionality needs to be more fully integrated into their host packages. Blueprint nodes in Unreal. Network editable nodes in Unity and Maya. Fully fleshed out UI options for parameter interfaces; rollovers, help, disable whens, hide whens. I should be able to create one tool for all my host programs, especially if they are SideFX supported ones. Lead Houdini Engine by example so when I want to implement it into my own pipeline or tools I know it can be done. A unified node context, I know this drives people banana's, but it should be a choice to work in different node contexts. Not a mandatory obligation that you need to be in /obj/ Scene, /obj/sop/ Sops, Dops, Materials, etc. to perform those task. Houdini was created with the combinations of several different programs as defined by these contexts nearly 20 years ago now. It's time to UNITE them all! We can still keep the old Context's just as POPs still lives under the hood, or you can just unleash the / context to us all, but it would be nice to work in a unified context i.e. Nuke. And as always it's the users responsibility to keep their network clean! Thank SideFX gods for the wire dots, and the circular contexts. More fully fleshed out presets. The shelf is good, but if I'm working a commercial or doing some R&D for a bigger project I need a full fleshed out setup. The setups exist out there, but I don't need to rebuild the same setup at every studio I work at. Additionally the Shelf tools needs some love. Just make them the same as hda with all their functionality. Add an Extract Content feature. Don't keep them the separate beast that they are. HDA's are powerful, shelfs are deprived and in constant sadness to their tool brethren. An example library for each node and code example that is easy to view and find. It's rare to find examples spread through the Houdini Doc's. If I could have the help Pane, or an example Pane that I could search through that be amazing. This could be tied in with more fully fleshed out presets. You don't necessarily need a lone example per a file, combined ones often make greater sense. The orbolt pane for instance. The upgrade to the Help docs has been awesome, including the more graphical documentation i.e. the packed sop. But those example files are trailing. More common studio tools that are predefined. Every studio ends up creating special importers and exporters that all in the end do the same thing. Just create a few common studio nodes, that can be easily manipulated. Either via python modules as they presented in their rigging tools, or by non-compiled file sops and rops. The Alembic ROP is a very convenient example of showing the code so you can manipulate it. I shouldn't need to have multiple different contexts and nodes to import and export geometry and data. An uber file sop to load them all. An uber filecache to export them all. One ring! My precious! I would still love to take all the older nodes like the point sop, and have them converted to vops/wrangles. Maintain the same parameter ui, but have a little button or switch that flips from a wrangle to a code version. There is a certain sense that there is still a layer of black box with each of these nodes. This is where the fabric crowd, and programmers say they don't understand what is happening, and flip a table and say they need to build it from scratch. I can understand the proprietary algorithms being compiled black box nodes, but the point sop... come on now, this isn't a dark secret to the world. This would allow us to retire so many old nodes. Speaking of which the node count in Houdini is only getting more ridiculous each version. There is no way one person can know them all. I LOVE all the new features, but there comes a point when there are too many nodes. The biggest hindrance to new people is not knowing that a node exist that they can use. Node acumen should not be a barrier to using Houdini. The Houdini learning curve is dropping faster and faster. However, I've used Houdini for a decade with a wide variety or projects, and I can easily say I have not used every node. That's cool, but it also ridiculous. There does not need to be a multiply, add, add constant, etc. a single math node would suffice, opalias that stuff! There needs to be a survey of all the nodes, alias them to a wrangle/vop and retire! retire! retire! those nodes. Plus make some useful example along the way. Ok I think I ranted enough. My blood got pumping for Houdini 16 and I'm stoked about the new toys. I can not wait for this new Lego set and to work on some more amazing projects. And yes I will make my nodes look like Legos... *As a note any true bugs of RFE's please send to SideFX Support. This is only an un-official wishlist, so we can compare notes, rant and rave.
  2. Setting $HOME location elsewhere

    Hello Tosh, Welcome to the forum. I'm guessing you are in France too. So I would hate to say I would recommend for you to remove the special character from your $HOME variable. Which means that if your user name contains C:\Users\usérnamé (on windows) to change your username to an e without accent. Hopefully you do not take this personal as I'm guessing the variable is your name. I actually converted my french install to windows for some of these reason to work easily with Houdini. You can send in a RFE to SESI to handle letters with accent in them, or to present the user with a warning prior to crash about this. However as most programming does not take into account accents I do not know how they could make enough exceptions to handle it, as it's a more pervasive programming issue. As far as work around. Try setting HOUDINI_USER_PREF_DIR help and link below this will explain it. Plus a post about someone else went through the same issue. Good Luck http://www.sidefx.com/docs/houdini/ref/env.html https://www.sidefx.com/forum/topic/37975/?page=1#post-173517 HOUDINI_USER_PREF_DIR The directory to store user preference files. The value of this variable must include the substring __HVER__, which will be replaced at run time with the current MAJOR.MINOR version string. On Windows and Linux, this defaults to the expanded value of $HOME/houdini__HVER__. On Mac OSX, it will also use this default if the directory exists, else it uses the expanded value of $HOME/Library/Preferences/houdini/__HVER__.
  3. Houdini 17 Wishlist

    I'll spin up a wish list for 18 when they officially announced the launch date of Houdini 17. There has been some hurt feeling on the timing of the creation of the wish list in the past. Also until they officially announce we do not know what features are actually included, and or cut from this next version. The same reasons we do not do a wish list for a .1, .5 or other build. We only had a single 14.0 no 14.5, and a 9.1 and 9.5. While, yes, it is true there is a general degradation of a wish list the closer to release it is, you don't want to necessarily jump the gun. Also as always. This is a wish list unaffiliated with Houdini support services. Even if there are bunch of them on here, lol. If you want to make actual Request for Feature Enhancements(RFEs), or submit BUGs please contact through your company support, or use the online submission process https://www.sidefx.com/bugs/submit/ The wish list is more for rants, and collaboration of ideas. Comments on the list do not have a direct causality to changes in Houdini, but there is a strong argument for indirect causality. As the more official requests from companies get in with common interest, the more likely a request will happen (besides the insane request ;).
  4. Houdini 17 Wishlist

  5. Use hscript to set linux variable

    My new best friend as of late. https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer When you click on a process in the properties you can see the environment variables for that process and level. It shows what symek is talking about about inheritance.
  6. Houdini 17 Wishlist

    -n flag when launching
  7. Shipping a hard drive is very traditional. DHL overnight shipping could be a more straightforward approach, time efficient, and probably cheaper approach(Hard Drive + DHL to which you can clearly line item the bill to the client). Plus you can include all the assets and files. Very 90s and 00s approach to handling data. Just remember if you are going to render online; you need to upload all the data, process it, and make sure it is received by the client correctly i.e. no processing errors. This can be time consuming and depending on how much you bill yourself costly, plus you need to be aware of how much the client is going to be flexible if the processing gets messed up. It cost a lot more money if you screw up rendering on a cloud, than at home. Grid Market is a good business, just need to pay attention to the economics of the situation. I take it remoting into their farm so you can monitor a new render on their machines is out of the question? If you are going to send files to an online cloud you could just go directly to their farm.
  8. Houdini 17 Wishlist

    Lol, just having a bit of fun
  9. Houdini 17 Wishlist

    Skynet... ?
  10. Houdini 17 Wishlist

    ... just add that in there at the end... no big thing
  11. Houdini 17 Wishlist

    In this regard I agree on this. This is the Katana realm. While you can make Houdini Obj network work like this with a bit of a pipeline team, it be better if it came out of the box a little more fleshed out. This is actually a known series of RFEs.
  12. Replacing Houdini Ground Plane In UE4

    It depends on what is triggering the animation, as an example see the forum post below. https://answers.unrealengine.com/questions/556925/animating-fbx-on-trigger.html You may want to use the Texture Vertex Animation for something a bit more perform-ant. It's a shader that you will need to trigger though instead.
  13. Use hscript to set linux variable

    Yeah I migrated from hscript and perl a few years ago. I still don't know why I learned perl... But pipelines are so much more immensely easier to write now. Stack overflow is my hero. Good Luck Sir!
  14. Trying to export whitewater to Unity Editor (alembic)

    You should really use the Vertex Animation exporter with a soft body export. Alembic will not be file size optimized at run time. Points are not rendered in Unity by default. You would need to make your own custom render option to do it. There are some tutorials for that. However, using the vertex animation tool set to sprite mode for the particles would be a better option too. More optimized and efficient.
  15. Replacing Houdini Ground Plane In UE4

    The groundplane dop allows you to point to a sop geometry. Make sure you look at the collision geometry though, as if the terrain is complex it may not reproduce it 100% with out adjusting the values.
  16. Use hscript to set linux variable

    What Bonsak said. Though you should really just do this in Python. Hscript has not been updated in many years, on it's way towards depreciation.
  17. Vertex Animation Texture Loader in Houdini

    Welcome to the forum Aaron! I keep forgetting to reply to this, but I have stuff in SOPs that allows you to debug it. A bit better than just in mantra. If you still need it ping again and I can dig out the setup.
  18. Houdini 17 Wishlist

    The ability to create New Operator Type... code nodes from HOM. It is a little bit rise of the machine to allow python to create python nodes. I didn't realize we couldn't and it be nice to wrap all HDA creations under similar script. These types of HDAs: http://www.sidefx.com/docs/houdini/hom/pythonsop.html Also allow the menu creation of those HDAs to be put in the same asset section as the rest of the HDA creation scripts.
  19. Transfer HDA animation

    lol. I would stick with alembic. It's a flat hierarchy. Once you import one you can see how the creation script modifies the default nodes. Then you can make an HDA from that imported files, that does the same, but all you need to change is the file it loads from disk. It's pretty obvious and interesting how it works. Then you can use the same alembic camera in all DCCs.
  20. Transfer HDA animation

    Once you get to the point where you are pulling library of assets, and modifying them for different sequences, shots and environments. Crowds, Cars, Fire hydrants, city blocks more standard Houdini bread and butter. Cool good luck!
  21. Transfer HDA animation

    Nope what you are doing with @shop_materialpath is the fundamental basics that has not changed in a long time. Albeit we do not use the shop context as much anymore... now we use materials, but they won't just shut it off at some point when they make the switch. Manipulating this path is the key for material assignments. It's always an absolute path, so if you store your materials at an object level context like /OBJ/MATERIALS (or always in the material context which I don't suggest) as you did it becomes real easy to reassign the materials with basic string edits, and especially python. You could make a string attribute like "material" as you were doing before or "name" as is common for dop workflow(though consult with your fx team first) and then use that to help you reassign materials if you need later. Having two string based attributes is really cheap as it saves them in a dictionary, unlike unique groups that use integers. Since it's a dictionary of values you can just list the unique instances of those materials, and create a respective hda with python based on where that material should be stored. So /OBJ/MATERIALS/Sequence/... /OBJ/MATERIALS/Shot/... /OBJ/MATERIALS/Character/... /OBJ/MATERIALS/Common/... you can also use those names to create the correct HDA (like principled shader) and apply the correct preset to those HDAs now however you stored them. There are a lot of possibilities here, so what ever works best for your system.
  22. Transfer HDA animation

    For shop_materialpath crack open the test rubber toy HDA that ships with Houdini. You will see how the material is applied to the geometry in the spreadsheet. You might want to watch some intro to lighting and rendering in Houdini. For the most part it has not changed in the last 10 years. The lighting nodes, mantra's ability, and the material networks have improved, but at the heart of it is the same pipeline. Hopefully in the future they will do a major update to the workflow * fingers crossed *. There are not many documented Houdini Pipeline workflows around Lookdev as that part of Houdini pipelines is actually on the rare side. So Disney, DD, Sony will have their own custom workflows, but smaller commercial shops will just have a few Arnold or other lighters do it on the fly. The FX guys in those shops just need to rock off a few quick materials, and for those folks the basic are enough. What you are asking for is a bit more rare. But then again welcome to Houdini \o/ Generally speaking I never use the material Library, nor do most productions. You can actually hide that pane. It's the only place in Houdini that has a crazy wrapper for placing HDAs. You can actually just create a shelf that drops the materials with those presets so that it is available in the Tab Menu. At the end of the day, it's just the same few nodes with a few shelf like presets. Which when you have to do a full production pipeline you will need to make yourself. As far as the groups you will need to have your lookdev pipe do the assignment of materials. If that means importing the geometry with groups then do it, once the materials are assigned, then you can get rid of the groups unless you need to dynamically change the materials down the road. Groups used to be real bad a few versions back so most people have moved away for them for attributes use. The only reason they are not as bad anymore is because they behave exactly like attributes, except for the legacy menu options. Lol, are you ready to tear your hair out yet, lol?
  23. Transfer HDA animation

    Nah not merging hip files. That would be quite dirty. You would use python to instantiate the required node/hda and apply the appropriate presets. Whether with the SideFX system, or probably more likely your own. The current SideFX system leaves much to be desired as far as presets. So for your materials, you only want a handful of studio HDA used by default for most lookdev. Generally only your FX artist should make their own shaders. You don't want to have different lighting models for each material it can get crazy quickly the more artist your team uses. Look at this talk on Houdini Pipelines. It will probably help a lot. You may be best off just using the stock shop_materialpath attribute, because you will need to bind the path and the material in the end to render in Houdini. You can avoid groups too in this way as you can not have two materials per a primitive. The groups are good if you need to reassign the materials, but that should only be done in lookdev.
  24. Transfer HDA animation

    These are certainly some good reservations about storing the materials as HDAs. No matter what you will have a massive collection of files to stores these materials. These materials could be substance materials, or as jason/python file as other examples to apply the same logic thoughts. As far as the shit loads of HDAs, you can store these appropriately in your HOUDINI_PATH or HOUDINI_OTLSCAN_PATH. This way you only load the HDAs that you need. These would be the separate load directorys you append on load. You can also import via python files from disk not already in those directories, which may be the best method. Houdini does not really care about how many thousands of HDAs you load, assuming you didn't build really bad HDAs that cook the world on load. Generally speaking you don't actually need that many HDAs for even a feature film. A couple hundred might be enough for all FXs and studio functions. A few dozen really matter in the grand scheme. As far as materials the whole concept is to have as common as pool as possible. You don't want a dozen ways to do car paint. You can also manage hiding the HDAs via OPCustomize file. So you could load all the HDAs and ophide them all by default. Look through that file and you'll see a whole pile of tricks. On creation of these HDAs, as you do not want to do them by hand, you can sort them by the tab-submenu paths, and update the OPcustomize, or any other corresponding HDA options, via python. This way they are organized better than by hand. Honestly, in the case of materials required for objects you do not want the Lighter to ever have to look up the correct materials for the objects. So seeing them all like in "All" shouldn't be a real concern. Only OCD like me and you notice or do anything about it. I've worked for many studios where people just tab and go. So there will be a level of automation you will need to develop for your project to load them either way. Cycle back to the shotgun conversation that can help manage that.
  25. Transfer HDA animation

    So yet again not a an extremely simple answer, so this will spiral out as you read through it more. To keep it simple with the materials. You can just use groups/attributes to define the different parts of your character and then with the material sop you can define your materials per a region. Plus what I think you are after is the material overrides. You can define the overrides to the shader on the mesh. So you could define the diffuse map per each primitive. This can get a bit expensive with the file size on disk, especially for an animated sequence, but you could theoretically have one uber shader for the whole production, and everything is defined via the mesh. You can do this at the object level, too depending on how you split up your object. Finding the happy medium is key. For a one person project, and for standardized shading models this might work out really well. An alternative that is similar and will not over use the material overrides, but still have all presets defined on your uber-shader, is by having packets of shaders within a material subnet HDA. So you could save all the presets shader for your character, for instance, all the clothing types in one material HDA subnet, that contains all possibilities. i.e. Ralph_Clothing.hda with the material subnet hda containing clothes/dirty clothes/clean clothes/pants A more advanced setup would be on import of your object with a file wrapper on your HDA, to parse the geometry or an external saved file for subsequent required materials. You can do it similar to the above, or even by creating the uber shaders dynamically in python and applying the presets directly in the scene. By applying the presets in the scene, say if you have a lookdev department authoring the materials, you may have issues maintaining their updates. However, with even more pipeline framework you can dynamically refresh those once they are updated. Another alternative, in the simple case is that the lookdev department authors their materials as HDAs too. Then you get the benefit of version control built in. But this requires you to build a lot more complex naming convention system, for storing HDAs, etc. There are also material stylesheets you can use. Jeff Wagner just did a few video's on those, but they may be more up your alley, a bit too much to explain in a forum post however.