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.


  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

90 Excellent

1 Follower

About pezetko

Personal Information

  • Name Petr Zloty
  1. Do Solid Embed on single berry before you do copy to points?
  2. Look at switch solver.
  3. It's possible to add it by hand to hou.session then it works but is tied to scene. Try to run it in event loop callback (I modified my previous post to include this code)). hou.ui.addEventLoopCallback(init_rounded_wirestyle)
  4. Indeed, it's saved as user data. But you can run this script in 123.py or 456.py import hou def init_rounded_wirestyle(): """ Set wire style for all Network Editors""" n = hou.paneTabType.NetworkEditor i = 0 while True: editor = hou.ui.paneTabOfType(n, i) i = i+1 # iterate over all editors if not editor: break # switch wiring style wire_style = editor.pwd().userData('wirestyle') if wire_style != 'rounded': editor.pwd().setUserData('wirestyle', 'rounded') # just in case if i>100: break # fix for running this after UI load (not ideal) hou.ui.addEventLoopCallback(init_rounded_wirestyle)
  5. Did you try to save your desktop with switched wiring style in H16?
  6. Please try most recent build first. I think this was fixed in first daily builds right after H16 release as was mentioned in multiple places across both boards. If that problem persists even in most recent build, please submit a bug report with your hip file and your Houdini info to help solve this issue. Having hope is nice, but taking action make difference.
  7. Just a bit more about unified (context-free) network (maybe this could be just a joke than anything else) : I think you can recognize this (and it's clearly not the best piece of the procedural node based system out there): And this is almost empty scene...
  8. Maybe I'm bit of old school but actually I don't mind having single contextless environment. I would prefer that. And I would love to delete pre-build CHOP context without hesitation. Actually I would like to be able to modify textures with COPs and CHOPs and fetch them to SHOPs/VOPs and link them directly next to OBJ or SOP context in single multi-threaded network without having to jump between "subcontext" like I have to now. Yes from ui point of view Tab menu would require a huge amount of smart stuff to be effective to use and not to be cluttered. Katana tried to solved that by its "progressively filtered zoom out menu" (I don't know if they have some naming convention for that), 3dsmax has quad-menu, Maya has gesture circular menus etc... I don't know what would be best for Houdini. I suppose that Houdini also pulls out data in a different way then Katana or Nuke graf does as these applications results usually in single output while in Houdini we can do a lot of stuff that are not connected at all. But it seems that all of them are merging in term of target functionality with just a bit of different specialization. In Nuke I don't like that you have to have "convertors" to switch from 2d to deep or 3d and back. Also I don't like they tried to solve cluttered tab menu with removing aliases. Having to search for opposite operation is not intuitive to me and using that left button pane with sub-menu is too old school to me But mainly I was trying to point out that those pre-building contexts helped us to run a bigger shows quickly with limited knowledge, zero pre-production time and almost zero pipeline scripting or "supervisor" intervention into 3d pipeline. I'm not defending separated contexts as only best possible workflow as it's clearly is not and it was evolution and extension. I see basic pre-build contexts as nice start for new users to get familiar with this unique software and to be able to read other scenes easily before moving to customization for their pipelines and workflows.
  9. Couldn't you just update servo.otl with parameter that will allow you to pick another usb port for another instance of that asset? If you want to duplicate hda to create different hda (otl) use Operator Type Manager: http://www.sidefx.com/docs/houdini/assets/install
  10. Try attached tool, unpack it to your %HOME%/Houdini 15.5 folder (readme is included). It adds custom shelf with 5 buttons. You can reassign keyboard shortcuts to those tools if you don't like default ones (stored in HotkeyOverrides). I posted it long time ago on sidefx forum. It was written for Houdini 14, but it's working in 15.5.565 too (tested under Windows with default desktops). That sounds nice, but in bigger team with small number of pipeline programmers this is not the best way to go unless you are delivering only final pictures or caches exclusively. Having pre-build contexts and basic set of rules like: objects go always only to /obj/, materials only to /shop/, ROPs only to /out/ helped us to run quickly projects with team of people who had minimal or zero experience with Houdini without any serious problems or slowdowns and with only simple or no pipeline scripting. I think you can imagine the mess if you have to finish or fix multiple scenes from different users you never seen before just right before deadline. And if artists would be allowed to put nodes in every context they personally prefer instead to standardized places it would became a long job. E.g. having materials all over different contexts like having some materials inside shop sub-context inside sop sub-context in obj context, another in shop sub-context in cop2 context and so on. Also possibly having name conflicts as some materials are different version just copy pasted and unlinked from originals or even modified. Or having some mantra rops in /out/ context and other in /obj/ropnet/ or in worse places that... That wouldn't be nice. Naturally I would end up with something similar that is already there. I think good example is DNegTV presentation about they Bogeyman workflow with Clarrise. Having pre-build those standard/common/uniform places to put stuff is great in bigger team where time is rare. Yes, now I would like to delete some of those contexts as I don't use them on some projects at all. And I can see that maybe sometime in very far feature we would see a single contextless environment. But having the "forced" naming means I can open old assets from one project and materials from different and they will be internally linked as basic context names are still same between versions. I hope that till that happen we figure out some strong future proof convention for placing and linking all data. pz_switch_context.zip
  11. I really hope those icons was only joke experiment what is possible with new system. I was like... when I saw them. Sincerely I would be a really ashamed having director next to me and having to work with application with those icons But overall really nice stuff guys! I'm looking forward to Christmas time.
  12. This comparison was heavy biased: http://forums.cgsociety.org/showthread.php?f=87&t=1121380&page=2&pp=15 You can see more realistic render times and better looking results from correctly set up render engines in that thread. I wouldn't believe Furryball's guys a single number imho. Speed isn't the most important stuff for renderer. Price, stability, scalability, support and setup time plays important roles too.
  13. So new GP102 and GP104 "Pascal" cards are worse then their Kepler predecessor for OpenCL sims? So what about (new) Radeon Pro WX and Radeon Pro Duo cards? http://wccftech.com/amd-radeon-pro-wx-7100-workstation-card/ This could be better $/performance then Nvidia. As Tesla P100 prices wasn't revealed yet even Radeon Pro SSG looks interesting.
  14. There is a little arrow icon in the right top corner of the Tree View (Auto-dive into the network). Is this what you want? Or you want something like Auto Frame to the selected node? (Like when you are pressing "F" key in network view to frame to selected node) - I think this could be done with selection callback. I don't think there is any build-in option for this in 15.5 currently. You could fill RFE for that. It could be similar toggle button in Tree View as "Auto-dive into the network".
  15. I compared that OpenCL smooth against Smooth SOP on 1000x1000 grid on the the Xeon E3 1650 v3 vs Nvidia GTX760 and speed up is really big. It depends on the size of the data set. Only issue is on the systems without GPU (OpenCL support) or when there is not enough GPU RAM. petz: If you set dopnet to Timeless and on the Dop Object turn on Solve on Creation Frame it will be solved for current frame so you don't have to do Timeshift to next frame (but Timeshift is still useful to remove time dependency).