Compare links



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

    On 14/08/2003 at 05:06, xxxxxxxx wrote:

    Hi Arndt,
    something is running wrong there then :) 5159 is the Typedefinition for the cubeprimitive but 5100 is the typedefiniton for a polygonobject! So it seems, the ->link maybe returns the polygonized original object?



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

    On 14/08/2003 at 05:21, xxxxxxxx wrote:

    That's what I think, too. It the same with NURBs objects. The returned type indicates that they are converted, but the objects from the list have the correct typ. It seems that the volume data return the converted objects.



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

    On 14/08/2003 at 05:50, xxxxxxxx wrote:

    I think this is a limitation of the inexclude system. (The same that makes it impossible to exclude parts of a HyperNURBS object from a light.) It doesn't keep track of generated objects.
    (Placing tags on the objects is a bit more failsafe, since they aren't removed by most generators.)



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

    On 14/08/2003 at 08:20, xxxxxxxx wrote:

    Thanks for your comment Michael, but it seems as if the INEXCLUDE_LIST at least gives back the right type of the listed object (I haven't tested other container data yet). The VolumeData gives back the converted object.
    So it seems I have to "downgrade" to the old "search by name" procedure to compare objects from within my shader. I hope this will be fixed or at least someone finds a workaround for this.



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

    On 14/08/2003 at 11:23, xxxxxxxx wrote:

    I am trying to work around this using the Object IDs that can be read from VolumeData during rendering (vd->Obj_to_Num(RayObject)). Up to now I failed to see any system in the generation of these number. First I though that the documents first object is "0", then all the following objects (GetNext();) are numbered till the end of that hierarchy is reached. Then the numbering continues with the GetDown() object and so on until no more objects are found, but this is not working. The object numbers seem to follow another counting method. Could someone please shed some light on this.



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

    On 17/08/2003 at 12:42, xxxxxxxx wrote:

    This code seems to work for me, i.e. I look upwards in the cache hierarchy for matches as well:

        
        
        #include "customgui_inexclude.h"
        
        
        
        
        Vector SDKGradientClass::Output(PluginShader *sh, ChannelData *sd)  
        {  
          GeData exdata;  
          sh->GetParameter(DescID(SDKGRADIENTSHADER_EXCLUDE), exdata, 0);  
          InExcludeData* exd =   
            static_cast<InExcludeData*>(exdata.GetCustomDataType(CUSTOMDATATYPE_INEXCLUDE_LIST));  
          if (exd && sd->vd && sd->vd->op && sd->vd->op->link)  
          {  
            Bool object_matched = FALSE;  
            BaseObject* op = sd->vd->op->link;  
            BaseDocument* doc = op->GetDocument();  
            while (op && !object_matched)  
            {  
              for (LONG i = 0; i < exd->GetObjectCount(); ++i)  
              {  
                BaseObject* eop =   
                  static_cast<BaseObject*>(exd->ObjectFromIndex(doc, i));
        
        
        
        
                if (eop == op)  
                {  
                  object_matched = TRUE;  
                  break;  
                }  
              }  
              if (object_matched) break;  
              op = op->GetCacheParent();  
            }  
            GePrint("Matched: " + (object_matched ? op->GetName() : "none"));  
          }  
          // ...  
        }[CODE]
        
    


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

    On 17/08/2003 at 15:05, xxxxxxxx wrote:

    That's a great help Mikael. Thanks a lot!



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

    On 18/08/2003 at 11:38, xxxxxxxx wrote:

    I am running into an related problem now.
    Everything seems to work fine until I use a couple of these shaders in one material. The GetObjectCount() command gives wrong results (I get a value of 10 for some of the channel shaders though their list is empty).
    Could it be that the InExcludeList needs to be allocated or freed in any way, too (like customdatatype gradient or splinecontrol)?
    I tried this within the Init and InitRender classes, but got crashes and errors.
    Thanks!



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

    On 18/08/2003 at 12:07, xxxxxxxx wrote:

    No, I think the InExcludeList should be managed by the GeData object. Please see if you can narrow the bug down a bit.



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

    On 19/08/2003 at 02:52, xxxxxxxx wrote:

    I am starting to get nervous now :-)
    I get C4D crashes all over the place now after a few lines of the scene have been rendered. There must be something funny with the InExclude_List implementation when accessed from a shader.
    I stripped my script down to just a few lines of code that do about nothing but returning a simple color, but I still get the crashes. Here is the code from the Output routine I am talking about:

      
    VolumeData *vd=cd->vd; if (!vd) return Vector(1.0);  
    Matrix     cam_matrix=vd->GetRayCamera()->m;  
    Vector      pStart=vd->p;  
    Vector     cam_pos=cam_matrix.off;  
    Vector     sicht_vektor=!(pStart-cam_pos);  
    Bool          Test=false;  
    GeData exdata;  
    chn->GetParameter(DescID(EXKLUDE), exdata, 0);  
    InExcludeData* list =static_cast<InExcludeData*>(exdata.GetCustomDataType(CUSTOMDATATYPE_INEXCLUDE_LIST));  
      
    LONG list_cnt=list->GetObjectCount();  
      
    //----Check object names now  
      
    if (list && vd->op && vd->op->link)  
         {  
         BaseObject* op = vd->op->link;  
         BaseDocument* doc=op->GetDocument();  
      
         for (LONG i = 0; i < list_cnt; ++i)  
              {  
              BaseObject* eop = static_cast<BaseObject*>(list->ObjectFromIndex(doc, i));  
              if (!eop) break;  
              if (eop->GetName() == op->GetName())  
                   {  
                   Test = true;  
                   break;  
                   }  
              }  
         }  
    return Vector(1.0);  
    

    As you can see I even removed all of the ChacheParent stuff to be sure that it has nothing to do with that. I have just one object in the inexclude_list and I am rendering quite a number of SweepNURBS objects that have this shader.
    I am working on a dual Mac. Maybe some multiprocessor problems?
    What could it be?



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

    On 19/08/2003 at 03:06, xxxxxxxx wrote:

    P.S.: I just switched off MP for rendering and it renders fine now. Switching back to "optimal" or 2 render threads starts to render as expected, but after a few line the status bar changes to running light blue and dark blue fields (heavy calculatons going on?) and then C4D crashes.
    Is there anything I can do to make this more MP friendly? Looks like a bug to me...



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

    On 23/08/2003 at 10:42, xxxxxxxx wrote:

    I just wanted to let you know that it seems to work now. I rebuild the material and now it renders fine. Seems the material got corrupted at som point during tesing. Thanks for your help so far.


Log in to reply