CSTO returning a null object



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 15/10/2012 at 12:19, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:    
    Platform:      
    Language(s) :

    ---------
    In the Execute() function of an ObjectData plugin, I take an object specified by the user and do CurrentStateToObject on it to get a polygon object.

    Most of the time this works fine, but it doesn't work with the Python Generator object. When I do the CSTO I always get a null object returned (an actual null, that is, not an object with a zero address), and it doesn't have any child objects which sometimes happens with CSTO. Doing CSTO in the object manager works as expected, of course.

    Anyone know why this is happening - I must be doing something wrong, but it works with almost every other object I've tried. The only other one that doesn't work is the new 'Proc3durale' object plugin - this also returns a null object. How can I do CSTO and get a polygonal object from these procedural objects?

    Thanks,

    Steve



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 16/10/2012 at 01:41, xxxxxxxx wrote:

    Can you show the code how you get the user specified object and how you use CSTO on it? Do you create a hierarchy clone before CSTO?



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 16/10/2012 at 04:25, xxxxxxxx wrote:

    Sure. The object is passed in a link field. The relevant code looks like this:

      
    // get the linked object   
    lnk = (BaseObject* )bc->GetLink(MY_LINK, doc);   
    if(lnk)   
    {   
         // clone the object   
         clone = static_cast<BaseObject*>(lnk->GetClone(COPYFLAGS_0, NULL));   
         // do CSTO on the object and return in BaseObject* res   
         cd.doc = doc;   
         cd.op = clone;   
         cd.arr = NULL;   
         if(!SendModelingCommand(MCOMMAND_CURRENTSTATETOOBJECT, cd))   
              res = NULL;   
         else   
              res = static_cast<BaseObject*>(cd.result->GetIndex(0));          // <---- 'res' is an Onull in some cases   
         // rest of code follows here....   
    }   
    

    I've omitted a lot of irrelevant stuff, error such as error checking for null pointers and so on, but this is the area which fails when the linked object is the Python Generator. As I say, in almost all cases this works fine and I get a polygon object. It's just that generator and the Proc3durale plugin objects which simply return a null object. And that null has no child object either, which you sometimes see with CSTO. It's just a plain Onull.

    Steve



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 16/10/2012 at 07:45, xxxxxxxx wrote:

    You should check that clone is valid (not NULL) itself.  Maybe the Python Generator isn't always reacting properly with GetClone().  That would be something to deal with the Python implementation more or less.  It could be just a matter of checking that and it will bypass invalid calls and evaluate when ready (when the cache is resolved).



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 16/10/2012 at 08:05, xxxxxxxx wrote:

    No, I always check clone (I left that out to keep the displayed code to a minimum). 'clone' is always valid, i.e. non-null. It's just that when it's then used in CSTO it always returns a null. Interestingly, Proc3durale is also written in Python, which makes me think that there's something different about generators written in Python.

    I know it can be done though because other plugins can use these objects in the same way I'm trying to do it :-)

    Cheers,

    Steve



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 16/10/2012 at 08:11, xxxxxxxx wrote:

    Well isn't that always the way, 30 seconds after posting the above, I solved it. What I did is create a new document using AutoAlloc, then inserted the cloned object into that and then did CSTO (using the new document). Works fine for both the offending objects.

    I'm assuming the action of inserting the clone into a document forces it to rebuild its cache?

    Steve



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 16/10/2012 at 20:03, xxxxxxxx wrote:

    That is most probable.  Also remember that if you are using CSTO in GetVirtualObjects(), the only way to do it safely is by using a dummy document (not the original one!).  It may have similar relevance in Execute() (ala "Important Threading Information").



  • THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

    On 17/10/2012 at 01:29, xxxxxxxx wrote:

    Thanks Robert. I can't say that in all cases I do use a dummy doc for doing CSTO, so it's a good time for me to review this. Also, the same problem and solution occur if doing CSTO in other functions such as ModifyParticles, ModifyObject, etc.


Log in to reply