Jump to content


  • Content count

  • Donations

    100.00 CAD 
  • Joined

  • Last visited

  • Days Won


symek last won the day on May 22

symek had the most liked content!

Community Reputation

385 Excellent


About symek

  • Rank
    Grand Master
  • Birthday 09/26/1975

Contact Methods

  • Skype

Personal Information

  • Name
  • Location

Recent Profile Visitors

24,592 profile views
  1. Getting Houdini Global Vars With Python

    or just hou.hscript("setenv -s") and since we are not valetudinarians : cpio &> /dev/null -D /tmp/ -i < scene.hip && fgrep "set -g" /tmp/.variables hehe.
  2. no problem, that was rhetoric question That's the thing, internally you don't have to worry about anything, you can even link Blender with HDK, although HAPI allows you to avoid even that (by linking with HAPI instead of HDK). If you start selling things to third parties, then you have to be worried both about SideFX license and GPL. As Daniel_Daniel said, SideFX in its HEngine license might put some safety measures in case someone will do wrong thing with it (like making new Houdini) or renting your HEngine license in internet what HAPI effectively allows you to do.
  3. Yes, this is interesting. HAPI source is not GPL, but, say, I would write HE for Blender, then all I have to do is open source (GPL) my code, and then HAPI (nor Houdini) doesn't have to, since neither I have control over HAPI, nor Houdini is linked with Blender. Now this changes for SideFX, since they do control HAPI and GPL magically applies to them (to HAPI), or doesn't it?
  4. Append Point Wranger SOP and change Attribute To Match parameter (on Binding Tab) to @whatever_id_you_used_on_both_geo (my_id) and then bellow code will just work: @P.y = v@opinput1_P.y;
  5. Doesn't it mirror HOM/Python? This should work: SOP_MyNode::SOP_MyNode(OP_Network *net, const char *name, OP_Operator *op) : SOP_Node(net, name, op) { setUserData("nodeshape", "cloud", 1); setColor(UT_Color(UT_RGB, 1, 0, 0)); }
  6. Most Houdini Engine plugins are embedded in closed source applications. You definitely can do this, HE will use license anyway. If you want to sell it to third parties, it's probably good idea to talk to SideFX though.
  7. Howdy!

    Jesus Christ, we are sad people. 17 years.
  8. Mantra doesn't render in ACES?

    If all the inputs to Mantra are in ACES, Mantra output is in ACES also. If your color parms and textures are correctly adjusted, you are fine.
  9. Sorry, I haven't noticed that before. You probably solved it already but for a sake of completeness: it isn't typically necessary, because current geometry is available in a shader as geometry attribute (via parameters binding) , but generally, yes, volumesample() will work in shader context with op:/path/to/geometry as long as geometry is present in IFD file (which is the case, when /obj/object has the display flag active). You can export additional volume to a IFD and set its renderable parm empty to make it invisible, but people usually dump volumes on disk to keep IFD files small.
  10. I don't think Linux distribution has anything to do with that. More likely it's hardware <--> drivers <--> Houdini interoperability. It's really pointless to compare studio's computer on CentOS with private's Win10 - unless they have exactly the same hardware and deal with the same files! (which as rarely the case) It's more likely, that your gtx 2080ti with recent drivers on Windows 10 works well with specific Houdini build viewport code while displaying not so many textures in test scenes, while studio computer floated with 8K/32bit textures fails miserably after Nvidia driver refuses to allocate buffer due to lack of VRAM, due to chrome's youtube allocating more VRAM, due to switching to higher resolution etc etc, and Houdini can't do anything other than NOT display texture. Aside of that, yes, glitches are annoying. Best way to deal with that is report a bug with as many specifics as possible.
  11. Note this: Basically, geometry is accessible in Mantra as long as it was exported to IFD file as an renderable object. In some cases Houdini can do it even for you (as in case of textures from COPS). So, I didn't say you can't use volumesample, I said you can't use OP_Director to bake geometry from nodes present in Houdini - neither in current frames nor previous one. Mantra doesn't have access to Houdini nodes. It sees static objects (GU_Detail) as exported to IFD file which are named by their Houdini paths. To access arbitrary geometry, you would have to save it to disk, or... use HEngine rendertime procedural to load loads of geometry at rendertime (inside your HDA) and do your trick there.
  12. Ok, but you realize that in shader context you won't have access to node's geometry (entire OP_Director business doesn't exists neither in Mantra nor Karma)?
  13. I'm not sure what you're trying to achieve, but whatever it is, you seem to have chosen wrong path. VEX is high performance streaming instructions language. All data it operates on, should be static, monotone arrays of numbers it can slice up and process concretely. Your code is equivalent to embedding web browser in GLSL shader (my shader could access texture from http server! lets do it! LOL!), you can image such thing doesn't make any sense. Additionally you ask VEX to access Houdini's nodes concurrency, which requires locking, so you end up with high contention of threads (they mostly wait), and entire function has exponential complexity over time. I'm guessing it's slower than Python. I have a sneaking suspicion that thing you're trying to do can be accomplished without extending VEX (if accumulating attribute's values over time is what you're after), but if you insist on using C++, this part context.setTime(CHgetTimeFromFrame(i)); GU_DetailHandle gd_handle = surfaceNode->getCookedGeoHandle(context); should be inside VEX_VexOpInit callback, which should do all preliminary job only once before actual computation takes action. Note, that ifaik VEX by itself doesn't guarantee single execution of that callback. It should be guarded by proper atomic primitives by you. Again, I highly doubt you need this extension, but whatever are your feelings about it, it definitely shouldn't access external nodes concurrently and recursively from within VEX extension.
  14. hython: setting thread count?

    hou.setMaxThreads HOM function:
  15. gRPC with Houdini HDK advice?

    Fractals on Processing! Very nice project, but definitely something that should be ported over to Houdini. The neatest version (imho) would use OpenCL SOP. And distributing over network via DOPs is still applicable. Have fun! but hurry up, because some folks here might be interested as well