Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Stalkerx777

Members
  • Content count

    302
  • Joined

  • Last visited

  • Days Won

    7

Community Reputation

62 Excellent

4 Followers

About Stalkerx777

  • Rank
    Illusionist
  • Birthday 03/02/1984

Contact Methods

  • Skype alexx_houdini

Personal Information

  • Name Alex Rusev
  • Location Vancouver, Canada

Recent Profile Visitors

5,971 profile views
  1. Seems like you have a layout problem somewhere. ScrollArea relies on its widget sizeHint(), read here: http://doc.qt.io/qt-4.8/qscrollarea.html#details
  2. I believe you need to add $HFS/houdini/python2.7libs to system's PATH variable if you're on Windows.
  3. It should be possible to do using Qt event system if you familiar with it. What you need to do is to install eventFilter to Houdini's QApplication instance, and catch QMouseEvent there. Quick untested code from the top of my head: app = QApplication.instance() class Filter(QObject): def eventFilter(self, event, **kwargs): if isinstance(QMouseEvent, event): if event.button() == Qt.RightButton: # DO stuff return super(Filter, self).eventFilter(event, **kwargs) app.installEventFilter(Filter())
  4. Python interpreter runs in the main Houdini thread, so anything you do in python will freeze Houidini UI. Depending on what are you trying to achieve, try Mouse CHOP Also, see hdefereval module which ships with Houdini.
  5. If you really need to run c++ callback you can try this: #include <HOM/HOM_Module> HOM_Module &hom = HOM(); HOM_playber &playbar = hom.playbar(); playbar.addEventCallback(...); P.S. Should work in theory, haven't tested it.
  6. I don't have Linux version sorry. It's extremely easy to compile on Linux.
  7. Make it full Qt app, and stop worrying about bells and whistles, the community does the rest.
  8. I think it's really a matter of choice and preferences. For me, Qt it's just the only way to go with colossal flexibility. And since PySide ships with houdini, it's no longer a dependency to take care of. Anyway, the more options we have the better right?
  9. Exactly the same would be in Houdini: def houdini_send(msg): import socket HOST = "localhost" PORT = 12100 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((HOST, PORT)) s.send(msg + '\n') res = s.recv(1024) s.close() return res But consider using hrpyc instead for general interaction. http://www.sidefx.com/docs/houdini/hom/rpc
  10. http://www.sidefx.com/docs/houdini/hom/hou/expressionGlobals
  11. Just leave it here: P.S. At the time i played with this, Houdini was not Qt-based. Now it is, and with each release integration will become better and better.
  12. Hey, resurrecting 11 years old post is not a big deal right? I NEVER needed an unique ID for a years! But now this is what i'm looking for. We have hou.Node.sessionId() but it's valid for current session only. Ideally i would like to have hou.Node.uniqueId() and hou.nodeById() It's really rarely needed, but in my case would be a solution.
  13. For now i came up with OnLoaded event handler: for inst in kwargs['type'].instances(): inst.matchCurrentDefinition() I will report it as bug.
  14. Hi there. Here is the deal. Suppose we have a SOP operator foo_x implemented as a DSO. At some point we decided to deprecate it in a favor of VEX version of it. As far as operator name and parameters interface are identical, i expected this to be an easy task. If i remove original foo_x dso from Houdini path and replace it with otl, existing hip files will pick up an otl version, however when scene loads, all foo_x operators become unlocked and empty inside! I didn't expect such behavior. Matching current definition helps, but this is not a solution. Any thoughts on that? If someone have experience in replacing an old operator of one type with a new one of different type(otl->vex, dso->vex, otl->dso) please share.
  15. Thanks to SESI support, i figured out that ambiguous name resolving requires you to specify operator context, like this: Sop/opname::0.1 If you confident that opname is a unique name, you can do this: */opname::0.1 If you have namespace you can leave it, or replace with *: *::*/opname::0.1 By default all namespaces are displayed in TAB menu. This can be changed in preferences: Edit > Preferences > Shelves and Tab Menu