Jump to content


  • Content count

  • Donations

    100.00 CAD 
  • Joined

  • Last visited

  • Days Won


Everything posted by symek

  1. Rendering IFD files

    OK, that's a good reason for using IFDs (unless you can install HQueue there, which simplifies this task a lot). Google says for Windows looping command would look like bellow, but I don't know a thing about MS shell. for /r %i in (*) do mantra -f %i Actually there seems to be bash for Windows these days too, lol.
  2. Rendering IFD files

    Neither of that. Single IFD file contains a single frame definition, but you can't write ocean.$F.ifd as $F is Houdini's specific variable. You need to loop over files. Depending on a OS you're running on this gonna be simple expression like (Linux): for file in `ls *.ifd`; do mantra -f $file; done You typically have some sort of script for doing such things. Why you're trying to render from IFD file? If you'd like to render from a command line on a single computer, you may take a look on hrender script provided by SESI. It will take a hip file and render specified ROP from command line. No need to export IFDs (IFDs are mostly useful for render farms, and funcy production render orchestration...)
  3. Broken Mosaic Node?

    Could you attach frame sequence making you trouble? Another thing is that Cops are sensitive to image resolution change in sequence. Are those files all the same?
  4. Rendering IFD files

    mantra -f /path/to/ifdfile.ifd <optional image.pic> By default mantra will use ROP settings embedded in IFD file, but you can overwrite them in command line like: mantra -j8 -Va -f /path/to/file.ifd image.exr All of this is explained in a first link my first post.
  5. Broken Mosaic Node?

    Seems to be working here. Are you sure your frames are correct. Maybe some frames are busted, and COPs can't open them? (it's 100x512pix)
  6. Rendering IFD files

    Once IFD file is on disk, you don't use Mantra ROP, but render with command line: http://www.sidefx.com/docs/houdini/render/batch#mantra Also on a wider context: http://www.sidefx.com/docs/houdini/render/ifd_workflows hth, Szymon.
  7. Boujou import problem

    IFAIR you can merge them all into one geometry as points with a single ObjectMerge SOP, and wildcards in the path. Every Null Object has a point inside it. Something along the line: /obj/Boujou_fbx/somesubnet*/null*/point1
  8. Installing Nuke plugins linux

    I'm not even sure if Nuke NC can import custom plugins, last time I checked, it didn't use any compiled stuff.
  9. Substance Painter to Principled Shader

    What texture format did you exported in?
  10. cant rename node with variable

    Not sure if this is related, but you have a bug in second line, since selectedNodes() returns a tuple, so you can't call children() on that. Also setName() can throw an exception if name isn't correct, like empty string, so most probably your getChildrenName has some issue.
  11. @numpt vs npoints (VEX vs Hscript)

    Whatever you put into wranglers they are VEX script statements, whatever you put into parameters they are Hscript expressions statements (or Python's ). Both can do similar things (like giving you a number of points in a SOP), but they cannot be mixed or used exchangeably. Different languages, different purposes, different places of appliance, notably with some amount of overlapping functionalities likes functions for querying geometry, generators of random numbers etc.
  12. Random values for material inputs

    Did you put $PT inside material parameter? If so, it won't work as $PT is a local variable meaningful only in SOPs' context. If you wan't to drive saturation per point, you have to create an attribute in SOPs, and bind it to shader parameter. Or use something what is available in shaders, like uv, prim number etc.
  13. Refreshing COPs operators has been buggy in recent versions of Houdini. Promote Texture Name parameter outside material network while it's in default value (Mandril.pic), then - being outside shader natwork - change Mandril.pic into Cops' path. It should start magically work. hth ps pink color is Mantra's secret way to inform you that the texture is missing. You can customize this via HOUDINI_DEFAULT_TEXTURE_COLOR env. variable.
  14. Why not use Houdini's awesome Help Page to find hou.Node.setName(): foo = hou.node("/obj").createNode("geo", "foo") foo.setName("newerFoo")
  15. Controlling Focus Distance

    You're welcome :). I think the only Mantra dependency is adding Pz to planes' set. Otherwise it relies only on pixel value from a viewer, so if only your renderer puts some pixels there it's should work for it too.
  16. Controlling Focus Distance

    Indeed there is. Just to illustrate a concept: - copy $HFS/scripts/ipr/pickpixel.py to ~/houdini16/scripts/ipr/ - comment out the very last line (hou.ui.displyMessage(...)) - append (in the same scope, just bellow): if not "Pz" in viewer.planes(): rop_node_name.parm("vm_quickplane_Pz").set(1) viewer.startRender() else: value = viewer.pixel("Pz", px, py) camera = rop_node_name.parm("camera").eval() camera = hou.node(camera) camera.parm("focus").set(value[0]) For a first time you will have to Ctrl-Click twice if there is no "Pz" plane, otherwise Ctrl-click on IPR pane will set distance on rop's camera. cheers, skk.
  17. OBJ Import Material Links

    If you have a choice you could try FBX, which supports basic materials. You could also look around as there were a couple of MTL parsers for Houdini around. It's a trivial task if you know a little Python. Unfortunately Houdini is hardly used in a scenarios where obj files with mtl becomes handy. Also most Houdini materials seriously overcomes MTL specification.
  18. OBJ Import Material Links

    Houdini OBJ importer actually supports materials assignment, it just doesn't import / create them based on mtl files - you can spot a primitive attribute shop_materialpath pointing to something like /shop/Material_name (as found in obj file). Importer doesn't touch mtl file though, so materials have to be created manually. Note also that materials assignment inside OBJ file itself is based on primitive groups, which also end up in Houdini, so you can assign new materials based on those groups rather than rely on per primitive attribute.
  19. Considering how PTEX ignores entire ecosystem of assets creation, and how game originated tools heavily relying on UVs, reinterpret those assets pipelines without f*cking it, it's hard to believe PTEX has any future as long as a plain polygonal geometry is involved.
  20. Well, despite of the warning about VEX not supporting animated parameters, for years placing $F inside a shader body simply worked. There is a subtle nuance here though, and it't hard to see, since GUI wise all Houdini parms look the same. There are two different things involved here: shader's variables (inputs inside Shops/Vops) and parameters on a nodes. Basically think about Vops (material builder or anything involving nodes and vex) as a pure string based code generator. Code listening will be generated inside Houdini, but interpreted in a different context (inside Mantra), so expressions (usually evaluated inside Houdini) don't fit. Promoting them outside a shader body, allows them to be correctly evaluated prior execution (passing the result to shader body as plain old data variable). Seems like different types of Vops involved subnets has different opinion about what is possible though.
  21. Two minute papers

    Very few research papers fit to immediate implementation. The unfortunate side effect of the citation system (JIF) is an urge of frequent publishing among scientists. It renders a plethora of research with questionable value. They usually indicate general research and progress towards some new possibilities. What is actually implemented few years ahead is a common middle ground different scientists have made available for practitioners. Some exception might be the enhancements to the technology which is already in use like, say, XPBD for Position Based Dynamics.
  22. Detect surface using VEX

    Since you're tracing over second input's geometry (?), tiny correction is needed (note first argument); i@intersected_prim = intersect(1, v@P, direction, new_position, u, v); I would also recommend initializing new_position, u, v for extra safeness (it used to be mandatory, not sure now). hth, ps sorry also for previous criticism, I didn't notice that naming convention isn't actually very clear in that case.
  23. Detect surface using VEX

    in SOPs: intersect() in surface: rayhittest() or trace() Just a friendly remainder, that it is generally recommended to use docs page before asking basic questions on a forum