Jump to content

LaidlawFX

Members
  • Content count

    937
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by LaidlawFX

  1. 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.
  2. 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.
  3. Transfer HDA animation

    It's good to know you're pipeline is just in Houdini. * IMHO, you can ignore this part, just don't build yourself too much into a single software centric pipe. One software generally won't be the solution for everything, and production every-software has it's strengths. For instance Shotgun, Nuke and Houdini all go hand in hand. So if you are doing strictly shot based work from anim to rendering, like a film or commercial pipe. Plus if you are not working on the part of the pipe to help your animators read from a library of animation cycles you can simplify it pretty quickly. Also not working on something to help FX team then it's pretty simple. For Lighting/Rendering just go with geometry caches. This way the lighting artist/rendering person only needs to read the caches from each respective department. On your character rigs you will just need a render button, that will export your geometry sequence .bgeo.sc to a project/sequence/shot#/department/asset/version structure or something similar, you can get real fancy with the file structures. For instance, for relative common asset just replace common in the corresponding hierarchy, and mirror of authoring scenes, and machine generated content. If you want you can even include an .xml/jsn for meta data on import, or include it in the details attributes for custom tags of information, static asset, frame range viable, render option etc... This way your Lighting artist can just load all assets from the same hierarchy. By having all the geometry cache in the same known structure it becomes easier with out a program like Shotgun to manage the asset dependencies to auto load all assets on launch of the .hip file based on file locations. Sometimes it's good to export the animation channels out on the rig/hda, as you can use the same animation caching method that your animators will use. Save you from developing an extra system. But you are going to need a geometry cache system, that is the most common production tool across all studios. Also for FX artist, it is sometimes really needed to have the entire rig for simulations and FX work. Character TDs doing grooming, cloth, or rag dolls for instance would need them depending on the work flow. If you save your T-pose in an easy to access mode on your HDAs this becomes easier, but since DOPs can inherit object transforms easier it can be a toss up depending on your artist. For materials yes you can keep them in the rig. The thing to remember is they are only a string attribute on the primitive, so you can bend and twist this string to your hearts content. It also really depends on the complexity of your production, or are you building a pipeline for a studio to do hundreds of projects? Are you doing a simple commercial no change in materials for the whole sequence, or are you doing a fashion commercial where every shot is the same pirouetting ballerina rocking different clothing? Also are you shading an entire crowd or just one character. You do not want to have hundreds of the same material loaded in a scene in that case. You would want to have a load detector for a common material area, if this material has been loaded do not reload it. All thousand characters would use the same material, this will certainly render simpler and keep your scene file manageable. Also do you need per shot flexibility on adjusting the materials, especially for the light artist? The possibilities for mantra and comp have gotten so many amazing options than two decades ago you may not need any of those if you have a competent compositor and one person to set up the shot. Hope it helps, there are a lot of questions to reflect on scope, scale, desired functionality, flexibility, time and resources... So not really one best answer with out those variables.
  4. 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.
  5. Transfer HDA animation

    So an aside that may have found more of what you want... There are the Python Panels: Autorigs, Pose Library, and Character Picker that ship with Houdini. These have been updated by I believe Michael Goldfarb. Here as an example: https://www.sidefx.com/tutorials/autorigging-masterclass/ So it may be worth not listening to me, and looking into those and getting in touch with SideFX, before I take you down a more complex path, lol. Sorry these are new tools I do not use in production. At the heart of it you would want a library where you could save your different animations too. So Walk, Run, Sit, etc... You would need to be able to read and to write from these files to the parameter pane. You may want to split up the rigs export to different components even like upper and lower, or other component pairings. You can do this with say FBX files, chops with chan files, etc. Storing the animation with FBX may be good if your animators liek to use MotionBuilder, Maya and other programs. I would say your most studio robust and flexible would be encoding all with python. You can even go into the realm of making your own Python Panel in Houdini to help manage the files on disk and help import, including nifty images/gifs of the the different exports. I believe the python panels mentioned above can be used as examples if not used directly to get you started.
  6. Transfer HDA animation

    There is no standard tools per say. But you can copy and paste the nodes/HDA from one scene to another from two open sessions they use the same copy buffer, or merge the hips from the file drop down. If you want to invest time you can script it, or make the several different nodal methods to copy the info/hda.
  7. How much RAM is too much ?

    We had a run away sim on RIPD in 2012 that would eat up to the max 128 gigs of ram on the server farms in Taiwan at the time. Generally this should be an extreme outlier like it was. The Shape of Water team in Toronto had a few sims that did this too. Every film generally has one or two shots that depending on the artist will use up this much ram for a sim. Another case is if you are doing some heavy handed photogammetry where you toss hundreds of photos at it, as opposed to a proper plate set of like a dozen high resolution photos. A more practical math for evaluation is for farm nodes we usually do 1 cpu core to 2/4 gigs of ram for rendering. So if you get one of the new thread rippers and your machines is part of the farm, it can be used to run dozens of small jobs or a massive sim. So for a comp Render node or FX render node. Most studios on average have worker stations at 64 gigs of ram. It's generally cheaper for a studio to give them a second box than over doing the ram.
  8. Can not Type [ or {

    Are you using a non-us keyboard? Sidefx does not really support different keyboards styles. Otherwise I would check out your keyboard setting. We have also had keyboards die in the past.
  9. vertex animation textures BBOX size

    It is probably for the best now if you just use an external calculator at the moment to change the value manually. Unfortunately there is a bit too much to explain to help you out with this issue to say where to put it. I would have to explain a lot of the fundamentals of Houdini to you in order for it to make any sense. Apologies I can not be as helpful. Perhaps someone else can give you some help?
  10. vertex animation textures BBOX size

    Are you talking about the values in the HDA? Depending on at what point your are talking about it's as simple as putting in the /100 or *.01 in the correct location for the value you are looking at. For instance in my version I change the settings to allways output the right value for Unity/Proprietary as that was our primary platform(s) as opposed to unreal. -Ben
  11. Houdini 17 Wishlist

    That is certainly an annoying one.
  12. Read files through a loop

    Another alternative is that you can do this in a python sop too. With a loop just merge each iteration of Geo to the main Geo.
  13. Vertex Animation Shader Culls Geometry

    What engine are you on?
  14. Houdini Points to Unity Line Renderer

    Hello Oliver, Welcome to the forum. We were just having the line rendering the issue the other day, lol. For animated FBX, use the Vertex Texture Exporter, or you will have to animate your geo at the object level. Each element in a separate object with each animation on that object, and then export the whole object level tree. When exporting for the frame range $F does not really apply in the case of FBX as it spits out one monolithic file, not multiple files. I highly recommend the Vertex Texture Exporter, as it will be more efficient for almost all FX cases, as opposed to traditional FBX rigs. The mesh is still FBX, but the animation is really a fancy displacement shader. The process is a lot cheaper at runtime unless you are doing complex stuff like characters that are blending motions. The unity FBX importer does not import lines or points/vertexs it will cull them out. FBX does store them though. You would need to make a custom unity importer, which there are a few unity forum post about on the interwebs. You will need to be a bit more on the tech side to do it. The alternative hack is to make polygons out of your points/vertices and lines so they import. Dirty I know, but it depends on how complex your pipe is. If you are working on a side project I would recommend this. If you are working at a company I would recommend the later. Make sure your normals are on the vertex level, and that your points are fused for your geometry for FBX. Also visualize the face normal, this can be reversed from the your vertex normals. Use the reverse node to flip the face normals. This generally happens when you build a mesh in a few different ways. I could open your file, but I'm lazy This reverse winding of the face can have different issues for different rendering programs, especially which way it interpolates the normals in your case invisible.
  15. Empty locked node

    The file on disk should not be affected, your right. If it crashed while saving then it could. I take it you have not recovered the files from $TEMP? That is what I was imagining happensed, as that is the most likely scenario. Another possibility did you change major versions? Could be something with how they changed geometry storage.
  16. Empty locked node

    This will happen when a scene file crashes, and you open it again. The crash file only save the info that is in the system memory, not stuff like geometry. Once the locked node Geo is gone it can not come back. It is more like a short term temporary buffer. Great for performance testing, or for sharing files on odforce. Generally speaking you should only lock nodes temporarily. For long term use you should use a file cache node or something similar. This is the same as other software systems, albeit it may not be as obvious.
  17. Hello, Create a new node change the settings to the default you would like, and then go to the gear menu in the parameter dialogue and save the "Permanent Default". Do not worry this does not change how it "Permanently" it will save an .idx file in your personal preference. You can remove or move that .idx from your personal preference to anywhere in the $HOUDINI_PATH in order to distribute it through out your project. There are even are even more zanier ways to change the default preference, but that is the most robust and simple in most cases. -Ben
  18. Environment Variables - Houdini

    Generally speaking you should set system and other environment variables not related to Houdini in the shell, or to the system, before launching Houdini. You should not use Houdini.env for production use like that. I do not believe it will let you set non houdini environment variables. Plus there is no reading from the Houdini.env . Though that would be easy to test pretty quickly if something has changed. Usually having a python like wrapper that injects all the variables into a shell prior to launching is the best. As you can use this same system on other DCC too. Also side note, If you are messing with $HOME you should try and use $HOUDINI_USER_PREF_DIR instead. There are some known programs that do try and use $HOME, which is why SESI made the $HOUDINI_USER_PREF_DIR so you don't break other stuff. Hope that helps
  19. Render Farms

    Get in touch with your SideFX representative/support they can help you
  20. Render Farms

    Hello, I'm looking to find out what off the shelf render farms people prefer currently for production; likes and dislikes? Short background: We need to use our nodes for Houdini, Max, Maya, fume, and a few other software. Currently about ~100 nodes, and we don't have a dedicated render farm technician so the most hands off, off the shelf is the best. I have experience with Hqueue, Rush, Deadline, and Qube, so I am looking for any additional off the shelf software, too beyond those. Thanks -Ben
  21. Random Voronoi Fracturing

    You will have to contact Orbolt support if you are having issues. The assets are free on Orbolt, but they are black boxed as their primary draw back. The methods everyone has mentioned in this thread are all used in the setup, so this is more just a visual example case. All the ways to modified voronoi as in this examples to build an HDA like this are on the forum. It is only on Orbolt if you do not want to pay the, Iron Price, if you understand the game of thrones parlance.
  22. Random Voronoi Fracturing

    This would be an example use of what everyone has been saying. There are many files on the forum for all these patterns if you look around. https://www.orbolt.com/asset/LaidlawFX::voronoifracture::1.0
  23. Hello Tanya, Welcome to the forum. Sounds like you dove in pretty deep. While making your lightning system is great for a lot of productions and learning. Have you tried to use the Lightning preset on the L-system sop? A bit old school but it should have most of the functionality you seek, with plenty of seeds. If you place down a geometry node at object level, and then drop a Lsystem sop, you can then hit the gear icon an pick from the presets lightning or any other of the branching patterns. Then you can play with the Generations tab to control the growth. The Lightning preset has Random Seed set to $F which means you can scrub the timeline to quickly test different cases. Otherwise you can break that channel and use the ladder bracket to quickly change up seeds so you can animate the generation over time. I'll let others go into some of the other methods you can use like in vexpressions, too. There a few other post out there too you can look into on the forum, especially in regards to different growth systems. Have fun and enjoy the journey.
  24. Houdini 17 Wishlist

    You can post these on the tools thread.
  25. can we get normalized curvature of a volume?

    Feel free to send in an RFE to SideFX. Your request will get lost in the forums here. https://www.sidefx.com/bugs/submit/ I think you may be looking to work with SDF Volumes? Otherwise perhaps just asking for a stock HDA that fits/normalizes for you. http://www.sidefx.com/docs/houdini/nodes/dop/volume.html -Ben
×