Jump to content

symek

Members
  • Content count

    1,914
  • Donations

    100.00 CAD 
  • Joined

  • Last visited

  • Days Won

    71

Everything posted by symek

  1. 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
  2. Sure there is: Geometry Introduction cheers! skk.
  3. 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.
  4. 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?
  5. 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.
  6. 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.
  7. 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"?)
  8. 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!
  9. 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())
  10. 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.
  11. 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?
  12. 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.
  13. 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?
  14. 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.
  15. 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...
  16. 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.
  17. 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
  18. Return X component value

  19. 3d Volume from Image?

    Creating geometry beforehand is not a bad idea, because it lets you tweak otherwise hard to control process. Do you have a depth for you image? (from a render or stereo camera, or the challange is to create an illusion of such?). In case you want to go right from pixels to voxels and you have some depth channel, the example uses Houdini's render with P-plane, which holds depth in (RG)B channel. Anyhow it's just a gray image after all... volume_from_depth.hipnc btw:
  20. It actually tracks also rotation and scale but you must point to to a set of points on a tracked surface (as a point group or as points' indices). It will then use its positions to compute orientation frame or you can also create orthogonal frame on points and ask Rivet to use them instead (it will probably work faster that way). I don't know if this is best option to constrain OBJ to FBX bone, but just for the record, you can use Rivet for it.
  21. Multiply vectors to a plane (Trigonometry questions)

    int num_faces = chi("num_faces"); int nface = floor((float)@ptnum * num_faces / @numpt); float alpha = M_PI * (1+2*nface) / num_faces; int pin = nface * @numpt / num_faces; vector nml = set(cos(alpha), 0, -sin(alpha)); vector pos = point(0, "P", pin); @P = @P - pos; @P = cross(@P, nml); @P = cross(nml, @P) + pos; Those divisions by num_faces distract me, but I can't do better
  22. Requirements to learn hdk

    It's as easy or as difficult as in case of 3dsMax, Maya, Cinema4d, Modo etc. There is no difference as long as we talk about generalities. There are differences in details, like this one that HDK is not SDK designed for third party developers exposing some public API, but rather selection of Houdini's own headers. It means it's much more powerful and reacher environment, not necessarily as easy to use or as well documented as, say, Maya SDK. It depends on what you're trying to do with it. Have you tried some of HDK examples? You should. This doesn't mean you have to use C++, but - yes - making fully featured render plugin for Houdini will require using C++, for example for fast geometry output or IPR support. Python will play its role too. First option is using SOHO module (dedicated Python API for supporting third party renderers in Houdini). It allows you very easily to support lots of features which are otherwise hard to write by your self (tessellation, visibility flags, inheriting render properties etc). Most render plugins are mixture of C++ and Python, where C++ handles geometry export or IPR, and python anything else. Very often yes they can. Take a look on qLib library for example (http://qlab.github.io/qLib/). None of this is compiled C++ plugin afaik. Also Python is very capable language in respect to Houdini (much faster than people think if you know what your are doing with that). SESI (i.e. Side Effects Software Incorporated, although they've seem to changed it to SideFX - creators of Houdini) has to agree to support your plugin in Houdini Indie. All supported renderers are exceptions from a general settlement. This is because Indie has a certain limitations compared to a full commercial license (resolution and lack of render description file output I think). ..and you will be blessed by people modeling in Houdini (all three of them!), because there isn't many modeling tools for Houdini. Alexy makes such plugin (as you could already check). Afaik interactive plugin will require Python, because Python gives you the access to viewport states, C++ is optional, but I really don't know much about this aspect. Alexy (and probably others) does.
  23. Multiply vectors to a plane (Trigonometry questions)

    My brain is pleased
  24. Multiply vectors to a plane (Trigonometry questions)

    Oh man! You did art with those vectors. I'm jealous!
  25. Requirements to learn hdk

    You have to be more specific... It's the same as with any DCC application, with the difference that it's much easier in Houdini to make tools without C++ using just VEX,Python and HDAs and thus most custom plugins end up being not C++ (you need to have really good reason to use C++). Excellent! Nothings specially hard about it, albeit note that custom ROPs are not supported in Apprentice nor Indie. Your Cycles plugin will be available only for commercial users unless SESI decides differently. Technically you can create custom exporter without SOHO (thus working everywhere), but it's harder to support all features and might be considered as a violation of end-user license agreement (or not, again it totally depends on SESI consideration). Personally I think SESI should allow some sort of third party ROPs for noncommercial users, because it brings new people and their energy. It's possible but used to be harder than it should. With new viewport python states it's should be much easier. I don't know much about them though. You should probably consult someone like Alexey Vanzhula about it.
×