Compare links

Helper

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

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

Hi Samir,
stupid me. My script still used vd->op in one line which only gets the first object and not other objects behind it if the the ray passes through the scene. vd->op->link did the job. Thanks!

Helper

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

On 12/08/2003 at 01:58, xxxxxxxx wrote:

Sorry, it still doesn't work. By comparing two BaseObjects just the type of both objects is compared and not if the objects are identical or not.
So I guess I have to work with the links in this case? How do I get a link from a BaseObject?
I am missing an example how to use the BaseLink::GetLink command for this. Thanks again.

Helper

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

On 12/08/2003 at 15:01, xxxxxxxx wrote:

Hi Arndt,
well, actually it shouldn´t check their types $:\$ you cannot use a getlink on a baseobject. It´s more like a container... You need to create a baselink with Alloc (or AutoAlloc<BaseLink> bl) and then use SetLink to kind of assign the baseobject to the baselink. But I doubt it will make any difference for the pointer is the same as the one you have already... (or rather a pointer to the pointer of the baseobject, but doesn´t really make a difference if you compare those pointers or the ones you already own..)
odd it´s not working (sorry, I haven´t had the time to test this yet myself)...

Helper

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

On 12/08/2003 at 23:46, xxxxxxxx wrote:

Hmm, I see. I tried it again and comparing the BaseObjects just works if they have different types (like "Osphere" and "Ocube"). If both are Ocube for example I get a wrong result. I'll try the link thingy.

Helper

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

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

I still get wrong results with some kinds of objects. I get the BaseObject from my INEXCLUDE_LIST and compare it to the just rendered object and get wrong results in some cases. Here is the code. Maybe I am missing something, but this is odd:

  
BaseObject *obj=(vd->ID_to_Obj (poly_id, &vind;))->link;  
//Go though all objects in the list and compare them  
for (LONG counter=0; counter<list_count; counter++)  
   {  
   BaseObject *obj2=(BaseObject* )list->ObjectFromIndex(doc, counter);  
   if (obj==obj2) GePrint("Both are equal");  
   }

Helper

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

On 14/08/2003 at 04:26, xxxxxxxx wrote:

Are you sure obj isn´t NULL?

Helper

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

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

I am quite sure as I get different types (via GetType();) for the objects though they are identical. I have two cubes in my testscene. One cube has type 5100, the other 5159, but both are unconverted cube primitives.
So I guess that something is messing up the type of the objects. Confusing...

Helper

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?

Helper

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.

Helper

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.)

Helper

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.

Helper

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.

Helper

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]

Helper

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!

Helper

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!

Helper

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.

Helper

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?

Helper

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...

Helper

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.