Jump to content

Anas Alaa

  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Anas Alaa

  • Rank

Personal Information

  • Name
    Anas Alaa
  1. SOP_PointWave example questions ....

    I really respect your help ,, thank you very much..
  2. SOP_PointWave example questions ....

    Wow man thanks for this very much.. What chapters are important in yhe documentation to start? As i don't find what I need to understand always.
  3. Hello guys ,,, I am a beginner at the world of HDK .. I am struggling with the basics and simple examples to understand how things are going here So , I am greatly seeking your help though I might ask some stupid questions (many of them xD) I have read a lot of examples and have inquiries but let's stick to the example here https://www.sidefx.com/docs/hdk/_s_o_p_2_s_o_p__point_wave_8h-example.html https://www.sidefx.com/docs/hdk/_s_o_p_2_s_o_p__point_wave_8_c-example.html Firstly , I will describe my problem in the first file virtual OP_ERROR cookInputGroups(OP_Context &context, int alone = 0); I don't understand what this actually does ... Is it restricting the cooking to a specific group or what?? look at its code in the other file , sorry , though it's explained here , I don't understand ... it's my bad but sorry again for seeking for help for such basics . OP_ERROR SOP_PointWave::cookInputGroups(OP_Context &context, int alone) { // The SOP_Node::cookInputPointGroups() provides a good default // implementation for just handling a point selection. return cookInputPointGroups( context, // This is needed for cooking the group parameter, and cooking the input if alone. myGroup, // The group (or NULL) is written to myGroup if not alone. alone, // This is true iff called outside of cookMySop to update handles. // true means the group will be for the input geometry. // false means the group will be for gdp (the working/output geometry). true, // (default) true means to set the selection to the group if not alone and the highlight flag is on. 0, // (default) Parameter index of the group field -1, // (default) Parameter index of the group type field (-1 since there isn't one) true, // (default) true means that a pointer to an existing group is okay; false means group is always new. false, // (default) false means new groups should be unordered; true means new groups should be ordered. true, // (default) true means that all new groups should be detached, so not owned by the detail; // false means that new point and primitive groups on gdp will be owned by gdp. 0 // (default) Index of the input whose geometry the group will be made for if alone. ); } ________________ private: void getGroups(UT_String &str){ evalString(str, "group", 0, 0); } fpreal AMP(fpreal t) { return evalFloat("amp", 0, t); } fpreal PHASE(fpreal t) { return evalFloat("phase", 0, t); } fpreal PERIOD(fpreal t) { return evalFloat("period", 0, t); } /// This is the group of geometry to be manipulated by this SOP and cooked /// by the method "cookInputGroups". const GA_PointGroup *myGroup; Here , I don't know what is fpreal ??? Are those a type of variables or parameters ??? Why do we declare those like that though we just declare parameters in the other .c file ??? Also , why do we declare a group here though we are using OPLockInputs to lock our cooking to the input geo ?? _______________ In the second file ,, // Here we determine which groups we have to work on. We only // handle point groups. if (cookInputGroups(context) >= UT_ERROR_ABORT) return error( Here , I don't understand what this means . // If we've modified P, and we're managing our own data IDs, // we must bump the data ID for P. if (!myGroup || !myGroup->isEmpty()) gdp->getP()->bumpDataId(); Also this , what is the difference between other data of the sop and our data ?? I think that my words don't actually mean anything .. SOP_PointWave::SOP_PointWave(OP_Network *net, const char *name, OP_Operator *op) : SOP_Node(net, name, op), myGroup(NULL) { // This indicates that this SOP manually manages its data IDs, // so that Houdini can identify what attributes may have changed, // e.g. to reduce work for the viewport, or other SOPs that // check whether data IDs have changed. // By default, (i.e. if this line weren't here), all data IDs // would be bumped after the SOP cook, to indicate that // everything might have changed. // If some data IDs don't get bumped properly, the viewport // may not update, or SOPs that check data IDs // may not cook correctly, so be *very* careful! mySopFlags.setManagesDataIDs(true); } here , I think we make the sop able to change its data only without cooking everything in the viewport and also cook only the changed geometry ?? is this right or what ?? This what I have ,, sorry again ,, IF any of you can help with any of these things even a small information or a quote from the documentation , please help. Thanks in advance , I am trying my best to not ask about many things to not waste ur time .
  4. Didn't you think of these fluid solvers? How are they made? How to build them? We will talk about the theory of the process of building fluid solvers in my new course understanding fluid solvers on MIX Training. This is volume 1, volume 2 soon! http://mixtrn.com/course/understanding-fluid-solvers-volume-1/