Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


pezetko last won the day on June 8 2016

pezetko had the most liked content!

Community Reputation

94 Excellent

1 Follower

About pezetko

  • Rank

Personal Information

  • Name
    Petr Zloty
  • Location
  1. Eevee type OGL Viewport/ROP

    If you want to render in a game engine why not to use Unity or Unreal Engine directly? After the recent problem in Maya when all the scene textures weren't able to fit into GPU memory at all and Blender Eevee demos on youtube showing just simple scenes I hope SESI target for this kind of viewport instead:
  2. Dynamic Christmas balls

    Just move the constraint points on Christmas balls up (and pivot down). See attached scene, modified nodes are yellow. xmasballs_2.hip
  3. FEM Copies (for Optimization)

    Do Solid Embed on single berry before you do copy to points?
  4. Stop Cloth sim and send to RBD sim

    Look at switch solver.
  5. Houdini 16 Wishlist

    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)
  6. Houdini 16 Wishlist

    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)
  7. Houdini 16 Wishlist

    Did you try to save your desktop with switched wiring style in H16?
  8. viewport slow; pc build check

    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.
  9. Houdini 16 Wishlist

    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...
  10. Houdini 16 Wishlist

    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.
  11. Scarabée

    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
  12. Houdini 16 Wishlist

    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
  13. H16 at Siggraph?

    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.
  14. 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.
  15. Pascal's 16 bit compute

    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.