Jump to content

symek

Members
  • Content count

    1,915
  • Donations

    100.00 CAD 
  • Joined

  • Last visited

  • Days Won

    71

symek last won the day on July 3

symek had the most liked content!

Community Reputation

328 Excellent

5 Followers

About symek

  • Rank
    Grand Master
  • Birthday 09/26/1975

Contact Methods

  • Skype
    szymon.kapeniak

Personal Information

  • Name
    Szymon
  • Location
    Waw/Pol

Recent Profile Visitors

22,957 profile views
  1. PRM_TOGGLE help

    just a quick look:
  2. Journal's gems

    How much I love those sparks of humor in the darkness of (programmers) life: Houdini 17.5.303 Fixed a bug where carefully crafted VEX code could result in a crash. Sat. June 29, 2019
  3. Sure there is: Geometry Introduction cheers! skk.
  4. Houdini stores geometry attributes in continuous chunks of memory containing float/int values (i.e. arrays in C parlance). In other words Houdini's geometry is not designed with object oriented paradigms called array of structures (AOS) where every element is created and stored separately, but it exhibits design called structure of arrays (SOA), which keeps all values of all elements of particular types together. In time, during geometry processing, some of the points /prims might have beed deleted or rearranged. To mitigate the cost of altering those arrays (what basically means allocating new ones), Houdini can decide to leave "holes" in those arrays after entires which are not valid anymore. Because of that Houdini needs to keep track of offsets from the arrays to the actual elements, so that algorithms know where to find right values (that is: third array's entry might not belong to third point in geometry). You can see how it works in action. Create a bunch of points (Grid->Scatter), check that map offset equals points numbering(+1). Now append delete SOP and nuke half of incoming points (operation: Delete by Range) and see what's happened with map offset. Now for second point, map offset equals 3, not 2. Then Append SortSOP and see how point ordering and Map Offset equal again.
  5. I literally haven't done anything except changing constant color to bounding box to emphasize the effect and it does work here (17.0.416 - OSX). COPS have some issues with refreshing. They might not notice your changes and keep displaying old image. Maybe this is your problem?
  6. When To use compression For BGEO

    All depends on whether your actual data processing (the one you perform, not SOPs/DOPs in general) are I/O bound or CPU bound. Compression just trades off one for another. Decompressing takes time, the question is is it less than the time difference between reads of compressed and uncompressed files. Depending on your hardware AND processing the answer may be different. In case you can afford storing cache on SSD disk, most probably compression doesn't make sense (albeit the cost of *.sc isn't big anyway and increasing storage by say 20% is tempting). The slower I/O is (like network storage over the ethernet), the better compression will perform - given the sizeof(files) is high enough and timeof(processing) is low enough. Same thing. It's a matter of tradeoffs. *.sc compresses/decompresses faster for the price of bigger files. *.gz/*.bzip2 are smaller but also way slower for writing and reading. If you save the cache for later reuse and don't mind decompressing it beforehand, *.gz files might be fine. Practically speaking though disk space is so cheap these days, no one cares. Don't bother unless you really have to.
  7. Something like: const std::array<GA_Index,3> interesting_points = {0,13,56}; for (const auto & point_index: interesting_points) { assert(point_index < gdp->getNumPoints()); GA_Offset point_offset = gdp->pointOffset(point_index); UT_Vector3 pos = gdp->getPos3(point_offset); // ... do something with pos } It doesn't have to be inside a loop ofc.
  8. 17 export alembic with material?

    I really like this translation so I published it this time, but lets try to post in English next time? (where this "distiller" has came from, is it for "alembic"?)
  9. That pretty much depends on what you're trying to do with HDK, but chapter about operators and geometry are the must. Also note that if I say read documentation I don't only mean reading introduction to HDK, but above all the docstrings of the classes and methods from HDK headers. They are not perfect source of informations, but they carry a lot of crucial details about HDK. I'm far from being an expert, but the way I do it, is by first finding an example which does the most similar thing to what I'm trying to do. Then reading its source couple of time. Then follow doxygen link of methods used by the example. Read its docstrings and those which are linked to them. If you encounger appendPointBlock in the code, read its docstring along with other similar functions (like appendPrimitiveBlock). If case of doubt I first create a simple command line app to test particular lines, and I carry on from that point. Also note, that some of the older docstring are not in doxygen format, and you can't see them in docs' html page. You have to click headers' name at the very top of the page to open code preview, so you can read code along with docstring directly in the sources. Some of the most commonly used headers you should read from top to bottom many times (like GA/GEO/GU_Detail.h - if you deal a lot with geometry). HDK: Table Of Contents Introduction to the HDK Major Changes in the HDK Houdini Operators <--- Houdini Geometry <--- Houdini Digital Assets Houdini User Interface Using and Extending VEX Using and Extending HScript Rendering Getting Data In and Out of Houdini Houdini File System Utility Classes Another important chapter: GA Using Guide: Table Of Contents Introduction to Using GA Eliminating GEO_Point GA_FOR_ALL_GPOINTS() macro Handle Access to Attributes HDK_GA_Using_Handles_GA_AttributeRef GA_AttributeRefMap GA_Handle GA_PageHandle GA_OffsetArray vs. GA_OffsetList vs. GA_IndexArray vs. GA_Range Writing Parallel Algorithms in GA UTparallelFor(), UTparallelReduce() UT_ThreadedAlgorithm Threading writes across page boundaries Adding Custom Primitives Custom Primitives: GEO/GU Custom Primitives: Registration Custom Primitives: SOP creation Custom Primitives: GT (tesselation) The .geo/.bgeo file format JSON Schema Numeric Data Good luck!
  10. I totally understand your feelings of being confused at first, albeit I recommend reading documentation which holds most answers for your questions. For example: /// This method is created so that it can be called by handles. It only /// cooks the input group of this SOP. The geometry in this group is /// the only geometry manipulated by this SOP. virtual OP_ERROR cookInputGroups(OP_Context &context, int alone = 0); Right in the header of the example you're referring to is the explanation. More over, if you look inside its definition (*.C file),you will notice that all it does is calling: // implementation for just handling a point selection. 105 return cookInputPointGroups(...) so you click doxygen link again and see...: its declaration comment: so you scroll or search down to find cookInputPrimitiveGroup and... you have the explanation. It's vague, true, because the subject is complicated, but gathering all comments to this point you at least have a picture of what is going on here. Afaik you shouldn't worry about it at this point, just implement your cookInputGroup along this example. fpreal is Houdini's alias for floating point numbers (floats or doubles). By aliasing them (giving them custom name), SESI can control implementation and platform specific details. For example switch size of fpreal from 8byts to 4 bytes on some platform. They are the type of the value returned by the parameter. The way it is implemented in examples are just convention used by Houdini. You can use evalFloat() inside cookMySop() method too. Important consideration is multi-threading and locking of the node. Sorry, I don't understand that question. It means that cookInputGroups(context) can return one of error signals - most probably because node before your plugin returned error itself. Those errors signals are sorted in such a way, that those which are critical or invalidate further execution have greater values then those not so important. So in that case if error value is equal or greater than UT_ERROR_ABORT you know you should not go any further and return immediately. Again, just click doxygen link and see other options. gdp collects information about geometry. Most of this is contained in multiply attributes objects (which are vector-like underneath). "our own data" refers to those objects, because they are owned by gdp. Attributes have IDs modified every time attribute's data is modified. This way Houdini can track changes in geometry (this technique is similar to generating hashes from values, but cheaper). bumpDataId() informs Houdini, that attribute (P in that case) was modified by the user. This information is available for other nodes and viewport, and triggers recooking of their output. A commend above the code just clarifies that we have an option to not to worry about updating ID by ourself. Houdini can do this automatically. From the constructor of this class: // This indicates that this SOP manually manages its data IDs, 86 // so that Houdini can identify what attributes may have changed, 87 // e.g. to reduce work for the viewport, or other SOPs that 88 // check whether data IDs have changed. 89 // By default, (i.e. if this line weren't here), all data IDs 90 // would be bumped after the SOP cook, to indicate that 91 // everything might have changed. 92 // If some data IDs don't get bumped properly, the viewport 93 // may not update, or SOPs that check data IDs 94 // may not cook correctly, so be *very* careful! 95 mySopFlags.setManagesDataIDs(true); so above comment simply states that we will inform Houdini about changes in geometry attributes by ourself (using bunbDataId())
  11. VEX Function Source Code

    As I believe this is built-in function so you can't see implementation of it. For many other noise related stuff, take a look into $HFS/houdini/vex/include. In particular gNoise.h might be interesting for you.
  12. VEX Function Source Code

    Unless it's implemented in VEX header files (i.e. in VEX), its source is closed. Which one you're interested in?
  13. DPX image format?

    My cat theory was wrong? Bummer. It's rarely a problem these days (at least for us), but few year back it was major problem, so I could totally live with partial implementation.
  14. Don't take it in a wrong way, but I smell contradiction (not that I don't like contradictions in general). Paste in a line you don't understand as an example, and we will see what's wrong with it. Perhaps those people from SideFX do it all wrong?
  15. DPX image format?

    For some mysterious reasons Houdini had never supported it, unlike cineon - and for a fun part - they are almost the same thing. Unfortunately because of Cineon business collapse, it is dpx despite being older which had spread across the globe. We ended up with dead thing and without something being useful and common (we still get dpxs from DI from time to time) . It was RFE'ed hundreds of times without respond. It must be something like 'my cat has eaten dpx file and died' thing I suppose... Beside writing own plugin you can't do much. You can copy/paste code from OIIO, but maintaining it for HDK (recompilation for new builds) isn't fun.
×