Jump to content

symek

Members
  • Content count

    1,968
  • Donations

    100.00 CAD 
  • Joined

  • Last visited

  • Days Won

    74

symek last won the day on November 14 2020

symek had the most liked content!

Community Reputation

367 Excellent

7 Followers

About symek

Contact Methods

  • Skype
    szymon.kapeniak

Personal Information

  • Name
    Szymon
  • Location
    Waw/Pol

Recent Profile Visitors

24,136 profile views
  1. 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
  2. gRPC with Houdini HDK advice?

    Can't you just port Java snippet to VEX or Python/C++ and free yourself from the burden of inter-process communication? I know tinkering is fun, but can be very frustrating when involves real-time... anything. If that's not possible 1) I would start from asking if those chunks single process will be occupied with have to communicate with each other? Do they have boundary condition set by their in-progress neighbors? Because if not, you can avoid distributed computing all together by slashing Java array into chunks and pipe it down to many Houdini's independent sessions (concurrent, not parallel, which is easier). If that's not possible 2) I would consider trying Houdini's distributed simulation mechanics first. If you setup distributed FLIP, you'll notice that most tricky business is handled with two nodes called: Gas Net (Field) Slice Exchange, and afaik they will happily exchange any given point attribute or volume over the network's attached chunks. They don't ask what sort of computation is taking place, so you could distribute any VEX snippet or C++ operating on points/volumes over nodes (by just distributing something like a POP sim). If that's not possible 3) I would look into Houdini Engine, which is built around Apache Thrift. In the easiest scenario you can run Python process (with hapi module) and connect it with any number of other python sessions. And those will have entire Houdini inside them running. If you insist on using Java as a data server, you could use Thrift on its side to communicate with Houdini Engine. Using Thrift just spares you time as it's already in Houdini. If that's not possible 4) I would consider using one of Houdini's headers like UT_NetMessage or UT_NetStream for raw data transfer. You can even see the example of how the former one is used in VDB slice exchange. In such case you would have to marshal data for network transfer, there are number of options out there, including FlatBuffers, which is funny, because... FlatBuffers has a builtin support for gRPC, so you get both at once, but gRPC, as name implies, was built for Remote Procedure Calls, not transferring loads of data, so it might not operate as good as you wish with many gigabytes of it. Low level network in nice package (like mentioned HDK headers) may work better (or not)... Also something designed entirely to deal with terabytes over the wires like Arrow might be waiting for your call. hope this helps, skk. ps frankly speaking if you would have been really badass, you would stick to OpenMPI
  3. Change in your shader behavior compared to PointVops comes from a single fact - stack it on top of everything you already know, and all of this will make sense again. Fact is: in Mantra (as probably any other renderer) world origin is at the camera position.
  4. I really have no idea. After Scientific Linux collapse there is only Oracle, which isn't exactly an alternative to IBM you would dream of. There is still time left, maybe they buy RH support for a 2-3 years, and start to migrate either to Debian or to some CentOS fork this situation effectively may produce?
  5. You could try this: hconfig -h HOUDINI_TEXT_CONSOL Also, have you tried using Windows Linux Subsystem? Seems to be good deal for GNU folks trapped in Windows wonderland. I don't have any experience with that though.
  6. Sure. Link to help. Basically: hython script.py [optional params] where script looks like: import hou hou.hipFile.load("myscene.hip") ...
  7. OK then. This is probably good idea. Mykola work from github is probably 80% of the work anyway. Hopefully someone can look into that.
  8. I understand that. The question is what kind of geometry on Houdini's side you're foreseeing as a good source of vox data. Volumes are direct representation of voxels in Houdini, but are hard to work with unlike, say, packed primes, which you can copy, scatter or model directly. This has important consideration for the exporter. EDIT: In other words, could you create an example scene with game-level (very simplistic), you'd like to see in .vox format?
  9. What kind of geometry you want to export to .vox? Assuming you want to generate art-directed objects consisting of cubes with colours from a palette it seems Houdini's volumes don't fit as much as packed prims for example. I really don't know much about voxelized art creation, so I might be off.
  10. Epic Games Invests in SideFX

    Afaiu it's more of a kind of a grant money. SideFX might have a big impact on Unreal's landscape, but it's too small to make it happen soon while keeping FX in its focus. It's like Unreal saying: Hey, we like what you're doing, could you make those things faster? SideFX: We don't have enough resources to allocate more of it in games. Then Unreal on that: No problem, we're actually struggling with financial over-liquidity. Can we invest in you some? Cloud gaming and Houdini, endless landscapes, procedural assets streaming on demand, oh my...
  11. Quite newsy, isn't it? https://www.sidefx.com/community/epic-games-invests-in-sidefx/
  12. Anybody using RTX 2080Ti with CentOS?

    Have you had older card working on that system or it's a brand new install? We use RTX2080Ti here with CenOS7.6 (with oldish driver 418.x though), no problem. I would rather suspect this is general driver installation issue, not related to cards' model.
  13. Massive slowdown at Merge Node

    MergeSOP effectively creates new geometry object consisting of primitives of its inputs. Houdini can usually avoid actual copy, but I suspect that depending on a state of input geometry it might be forced to do even more. Copying attribute requires hardening it, which means baking all intermediate stages, removing holes, sorting etc. It can take a while. I don't know how Houdini handles copying packed prims, but it might be yet another story. Whatever it your case, you shouldn't merge geometry for rendering. People usually do the opposite: so even if peaces are kept together for some reason (like sim), they are at the very end separated into many objects for rendering. It's cleaner and easier to handle, it's better performance-wise both for exporting to renderer and for rendering itself.
  14. Sorry, no time to look into your example, but this code used to worked:
×