Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

pezetko last won the day on July 11 2020

pezetko had the most liked content!

Community Reputation

138 Excellent


About pezetko

  • Rank

Personal Information

  • Name
    Petr Zloty
  • Location
  1. CacheIt -- HDA

    Hi, I haven't seen this HDA, but that error sounds like it is py2.7. In python 3.7 reload is no longer build-in. So for Python 3.7, you have to use: from importlib import reload Reload function is usually used during development to quickly modify module code without restarting the application. So its usage could be probably omitted (just delete/comment out the code like this): reload(something)
  2. Python 3, using old Python 2 scripts

    Hi, you forget to call the method. print (my_geo.children) prints that method object. Not calling it. You need: print(my_geo.children())
  3. Default autosave

    Hi, it should be the same. Just tested both 456.cmd and 456.py on 18.5.514 (apprentice) on Windows 10 and it is working fine (456.cmd script is running on scene open/new file). O would prefer 456.cmd over 456.py as the python version modifies the session module and it could result in inserting this script multiple times if you don't add guard against that. Btw: Now the 123.py works only in Houdini FX. The Core has houdinicore.py instead. https://www.sidefx.com/docs/houdini/hom/locations.html#startup Alternatively, you can use pythonrc.py it is running only on startup (same as 123 scripts). But for always-on autosave, I would go with 456.cmd variant.
  4. use intrinsic info in shaders

    Hi, in Mantra you can sidestep the problem with stylesheets and cvex for primitives. E.g.: Data Binding to intrinsic:indexorder In this example, I'm targeting packed primitives themselves. If I would add subtarget: Primitive I could target individual polygons on a rubber toy. You can find some examples in the crowd section of the documentation. packed_target.hipnc
  5. Docking another Application into Houdini's UI?

  6. On Windows, you can use https://www.dependencywalker.com/
  7. Cascadeur

    Cascadeur is not bad but general UX was not good in the previous version. Rigging is also lacking a lot. Some animators hate the AI that adjusts the poses for them. Hope they improved the UX in the rewrite. The license policy for open beta is also very nice. For another potential Maya rival, there is also https://rumba-animation.com/ It all depends on support, speed, stability, and pricing policy. Maya has a huge advantage in API and prevalence.
  8. [Solved] Custom LiDAR importer with python

    Just realized that there is a difference between inFile.x (x position with scale and offset applied) and inFile.X (X position without any scale or offset). So Lidar Import SOP produces scaled and offset position from las. And for the laz there is laszip executable from https://rapidlasso.com/laszip/ that you have to have somewhere on your PATH. There is also c++ based laz-perf https://pypi.org/project/lazperf/
  9. [Solved] Custom LiDAR importer with python

    Requests for Enhancement: https://www.sidefx.com/bugs/submit/ I was able to download the file from google drive but my old K4000 can't display it in Houdini.
  10. [Solved] Custom LiDAR importer with python

    Just a few more optimizations to native python types, and testing on bigger las file. Python laspy SOP is 1.2 - 1.6x slower than Import Lidar SOP (1.6x if I apply scale, offset and add classification attribute what Import Lidar SOP does not perform), not bad. This is the code: from laspy.file import File import numpy as np node = hou.pwd() geo = node.geometry() file_path = geo.attribValue("file_path") def load_color(inFile): missing_color = ["red", "green", "blue"] for spec in inFile.point_format: if spec.name in missing_color: missing_color.remove(spec.name) if missing_color: return None color = np.vstack((inFile.red, inFile.green, inFile.blue)).transpose() return (color / 255.0).reshape(-1) # transform from 1-255 to 0.0-1.0 range) with File(file_path, mode='r') as inFile: # --- load point position coords = np.vstack((inFile.X, inFile.Z, inFile.Y)).transpose() # 632 ms scale = inFile.header.scale # should be already np.array offset = inFile.header.offset # there is no offset in simple.las example from laspy library # --- compute scaled and offseted positions and transform in 1d array pos = (coords*scale+offset).reshape(-1) # 300 ms geo.setPointFloatAttribValues("P", pos.tolist()) # 2203 ms # --- add classification attribute geo.addAttrib(hou.attribType.Point, "classification", 0, False, False) geo.setPointFloatAttribValues("classification", inFile.Classification.tolist()) # 450 ms # --- load color colors = load_color(inFile) if colors is not None: geo.addAttrib(hou.attribType.Point, "Cd", (1.0,1.0,1.0), False, False) # add color atttribute geo.setPointFloatAttribValues("Cd", colors.tolist()) # --- load intensity geo.addAttrib(hou.attribType.Point, "intensity", 0.0, False, False) # add intensity atttribute geo.setPointFloatAttribValues("intensity", (inFile.intensity / 512.0).tolist()) # transform from 1-255 to 0.0-1.0 range)
  11. [Solved] Custom LiDAR importer with python

    Nice, I think fast ssd is much more important nowadays. I didn't try *.laz with laspy, may worth a try. I know I submitted a few RFEs for Lidar Import SOP, one for *.laz support as well as one for supporting a newer version of *.las format. If you find some of those features important, submit yours, more "votes" (RFEs) doesn't hurt Btw: if you replace np.concatenate(array) with np.ravel(array) the second one is 10x faster. And this is even faster than the second one (but only few ms). array.reshape(-1)
  12. [Solved] Custom LiDAR importer with python

    Julien means the same thing I already mentioned. Loading and building attributes in Python is much slower than doing same thing in C++ most of the time. Lidar Import SOP is a fast C++ node compared to pylas. Loading your *.las example takes 20ms with Lidar Import SOP on my machine but same file takes almost 6 seconds with Python SOP with pylas (3 seconds just for transforming numpy nd array to serialized form and another 2.5 seconds for setPointFloatAttribValues method). If you do have enough memory and you do end up reading most of the file anyway it's faster just to use Lidar Import SOP to load all points fast and then use Python SOP to add only additional data that Lidar Import SOP cannot read (like classification) and blast what you don't need. Like this:
  13. [Solved] Custom LiDAR importer with python

    Hi, no, this is just default comment from Python SOP. In the latest version, https://forums.odforce.net/applications/core/interface/file/attachment.php?id=56259 classification is just an integer attribute on the points.
  14. [Solved] Custom LiDAR importer with python

    If you have any memory issue just check latest update version that using try/except block https://forums.odforce.net/applications/core/interface/file/attachment.php?id=56259 I'm not sure if laspy does implement context management protocol (so using "with File() as file_pointer:" statement may not close the file at exit) Just verified that and with File() as fp: statement works as it should.
  15. [Solved] Custom LiDAR importer with python

    You are welcome. Submitting RFEs doesn't hurt. C++ implementation is still much faster than laspy, but it's possible to do an easy and quick specific modification for las import until LIDAR Import SOP gets some improvements without going the C++ route. I attached an example with adding classification as an attribute (added closing the las file to avoid memory issues). I added an updated file: pz_load_las_with_python_classification_attribute_memory_fix.hipnc as it looks like context management protocol is not implemented in laspy (with File(): block will not close the file at exit) so I switched to try/except/finally instead. It will not error on the node, so watch python console for exception logging.