Jump to content

symek

Members
  • Content count

    1,911
  • Donations

    100.00 CAD 
  • Joined

  • Last visited

  • Days Won

    69

symek last won the day on March 21

symek had the most liked content!

Community Reputation

319 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,775 profile views
  1. 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?
  2. 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.
  3. 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.
  4. 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"?)
  5. 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!
  6. 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())
  7. 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.
  8. 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?
  9. 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.
  10. 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?
  11. 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.
  12. There is no stupid questions as long as you are not asking about things written on first page of the manual... On the other hand these questions have their answers on docs site and pdf I mentioned earlier (have you read it?). Pretty much every example of SOPs have parameters and deals with geometry. Yes, Houdini's parameters interface is a little nightmare, but even with copy/paste approach you can do most. // An array of names and labales used in GUI. static PRM_Name names[] = { PRM_Name("my_float", "My Float Parameter"), PRM_Name("my_int", "My Int Parameter"), }; // PRM_Template has many, many variants accomodeted to different scenarios. These two are the simplest cases. PRM_Template SOP_MySuperPlugin::myTemplateList[] = { PRM_Template(PRM_FLT, 1, &names[0], PRMoneDefaults, 0, &PRMscaleRange), PRM_Template(PRM_INT, 1, &names[1], PRMzeroDefaults), PRM_Template(), }; Yes, in fact it is Houdini's geometry container. Read its header carefully as you will be working with it a lot. You should read at least this: https://www.sidefx.com/docs/hdk/_h_d_k__geometry.html // create geoemtry container // (any geometry supported by Houdini can be stored here) GU_Detail gdp; // create 100 points inside. gdp.appendPointBlock(100); // create point atribute, called 'N', with length 3. GA_Attribute * na = gdp.addFloatTuple(GA_ATTRIB_POINT, "N", 3) // handler simplifies access to attribute per point. You almost never should use row attribute like above. GA_RWHandleV3 normal_h(na); // offset we will use to access specific point GA_Offset ptoff; GA_FOR_ALL_PTOFF(&gdp, ptoff) { // handy macro simplifying iteration over points auto pos = UT_Vector3{static_cast<float>(ptoff),0,0}; // lets create some positions, UT_Vector3 holds most vectors like pos/normals, colors etc. gdp.setPos3(ptoff, pos); // handly shortcut for setting points' position. You could also set position the same way we set normals bellow. normal_h.set(ptoff, UT_Vector3{0,1,0}); } Did you read and compile any examples? All of above is from examples...
  13. I don't think it's available for a long time now, not to mention it wouldn't be much of help considering changes in HDK happened in recent years. Current HDK documentation (in doxygen format) both as an online pages and downloadable are on SideFX site: https://www.sidefx.com/docs Also note probably little outdated $HFS/toolkit/slides/HDK12_Intro.pdf which covers a lot about Houdini's general concepts. I presume you're still struggling with HDK, but as long as you won't ask specific questions ("how to do x thing"), no one really can help you.
  14. Transfer Attribute - Parameters

    You are confusing attributes with parameters. Attributes are data attached to geometry primitives (like points or polygons). Parameters are knobs, widgets visible in GUI which control node's behavior. Now, while some nodes are aware of certain attributes and can modify their behavior based on per point/prim values (usually acting like a multiplier on parameters), it's not obligatory. It's an extra feature provided whenever (a) it makes sense (b) it's possible (c) someone at SideFX was fancy about it. It's specially easy to make an attributes aware node if it's implemented in VEX (and many Houdini's nodes are wrappers on VEX snippets), but it's not the requirement (some C++ nodes use attributes as well) . Anyhow, you should always refer to the docs to find out what attributes (if any) are supported by the particular node. In your example scene MountainSOP was working with height, because VEX overrides by default input parameters values with geometry attributes of the same name. I modified your scene to somewhat working version to illustrate the concept. Note though that not always varying parameter's value per point/prim makes sense or is obvious to implement. For example my soft transform with point cloud filtering doesn't work, but I didn't have time to think about it. In all cases these are linear interpolations which might or might not work for particular scenerio (which is exactly the reason why attributes cannot, in general, control all parameters). AttributeTransfer-Parm.hipnc
  15. Return X component value

×