Sampling color at vertexes

On 05/08/2014 at 15:20, xxxxxxxx wrote:

Thank you very much, Scott. It is returning no errors now.
Now I have to make my code work with it. Still a lot to do.

On 05/08/2014 at 16:31, xxxxxxxx wrote:

As it is now, it crashes.
I'm calling SampleColorAtVertices(b_source); and "b_source" is an object that I get from a Link field, with:

BaseObject* b_source = (BaseObject* ) data.GetObjectLink(PPT_SOURCE,doc);

This object contains a material tag with a simple Checkerboard shader in the color channel.
As soon as I execute it, it crashes :-(

On 05/08/2014 at 17:11, xxxxxxxx wrote:

Does it crash if you use the code on an object that's not in your link field?

If not. Then maybe you need to fill in the other LF parameters. I'm not sure if they are required or not.
BaseObject *linkedObj = (BaseObject* )bc->GetLink(obj, doc, Obase);


On 06/08/2014 at 02:15, xxxxxxxx wrote:

Yes, it does crash even with an object that I get from:

BaseObject* b_source = doc->SearchObject("Cube");


On 06/08/2014 at 04:53, xxxxxxxx wrote:

Well now I am trying to use Int32 and Co even in R14 code.
One can simple invert "legacy.h" for older C4D API versions.

Like this:

    typedef LONG Int32 ;
    typedef ULONG UInt32;

>Yes, it does crash even with an object that I get from:
How and where does it crash ?

Is the object attached to the document ?


On 06/08/2014 at 05:43, xxxxxxxx wrote:

Yes, the object is in the document, created manually, so it is live.
I have the call to your routine inside the Message method (it is invoked by pressing a button).
I simply get the object and call your routine to print out the color samples of the vertexes.

On 07/08/2014 at 06:24, xxxxxxxx wrote:

This is strange.
I have done some simple test and it work fine on R15.
Could it be that there are some problems with back porting to R13 ?
By the way the older code that worked for R13 is still there in git history.

On 07/08/2014 at 11:40, xxxxxxxx wrote:

I tried searching for it and indeed I found it.
But it lacks a lot of the stuff that is on the latest version and I can't even start to figure out a way to make it return the average color of vertexes :-(

On 07/08/2014 at 11:54, xxxxxxxx wrote:

Tried to re-use the latest version again. Cleaned out all the errors but I still get the crash :-(

On 07/08/2014 at 12:12, xxxxxxxx wrote:

It kind of sounds like the problem of trying to grab an object that isn't ready to be grabbed yet.
What kind of plugin are you making Rui?

So far I've only used the code like a script in a CommanData() plugin, on the active object. And it works fine (except for the ProjectPoint() method stuff).


On 07/08/2014 at 13:15, xxxxxxxx wrote:

It is a ToolPlugin.
It shows a Link field in the Attribute Manager and it would sample all the colors of the vertexes of the object to store them inside a database.
The Message method, as I have it right now is this one:

Bool polypaintfrommaterial::Message(BaseDocument* doc, BaseContainer& data, LONG type, void* t_data)   
     if (type==MSG_DESCRIPTION_COMMAND)   
          DescriptionCommand *dc = static_cast<DescriptionCommand*>(t_data);             
          LONG button = dc->id[0].id;   
          if (button == PPT_TRANSFER)   
               BaseObject* b_source = (BaseObject* ) data.GetObjectLink(PPT_SOURCE,doc,Obase);   
               if (b_source==NULL) return TRUE;     // no source   
return TRUE;   

The Link field only accepts polygonal objects. And the object I drag into it, has a material tag.
But, as soon as I press the button, it crashes.

On 07/08/2014 at 14:42, xxxxxxxx wrote:

I could be completely off base here. But humor me anyway.:wink:
You might not be grabbing the object.
The tool AM is really a subdialog. Which is different from the AM in Tag or Object plugins.
So it might be that you're using the Linkfield code for Node plugins instead of the Linkfield code for GeDialog and subdialogs.

Here's some code I ripped out of a tool plugin

//The subdialog class for the tool plugin  
class ToolDialog: public SubDialog  
      LinkBoxGui *myLink;  
      BaseContainer    *toolData;  //A container we'll save the dialog values in so they don't constantly re-set  
      virtual          Bool CreateLayout(void);  
      virtual          Bool InitValues(void);  
      virtual          LONG Message(const BaseContainer& msg, BaseContainer& result);  
      virtual          Bool Command(LONG id,const BaseContainer &msg);  
// ....the other subdialog methods here .....  
LONG ToolDialog::Message(const BaseContainer &msg, BaseContainer &result)  
  LONG mid = msg.GetId();  
  //Use one of the BFM messages to get the link  
  //Because BFM messages are intended to be used with dialogs  
  if(mid == BFM_SYNC_MESSAGE)  
      BaseObject *lop = (BaseObject* )myLink->GetLink(GetActiveDocument());  
      if(!lop) GePrint("empty");  
      else GePrint(lop->GetName());  
  return GeDialog::Message(msg, result);  
// ....the other subdialog methods here .....  
//The actual Tool plugin class where the tool does it's thing based on the subdialog settings above  
class MyTool : public ToolData  
      ToolDialog *dlg;   
      virtual SubDialog           *AllocSubDialog(BaseContainer *bc);  
      MyTool() :ToolData(), dlg(nullptr){ }  
      virtual LONG                GetToolPluginId() { return PLUGIN_ID; }  
      virtual Bool                InitTool(BaseDocument* doc, BaseContainer& data, BaseThread* bt);  
      virtual const String        GetResourceSymbol() { return String("mytool"); }  //The name of the .res file  
      virtual Bool                GetCursorInfo(BaseDocument *doc, BaseContainer &data, BaseDraw *bd, Real x, Real y, BaseContainer &bc);  
      virtual Bool                MouseInput(BaseDocument *doc, BaseContainer &data, BaseDraw *bd, EditorWindow *win, const BaseContainer &msg);      
      virtual void                FreeTool(BaseDocument *doc, BaseContainer &data);  

What I'm saying is...Are you 100% sure you're really grabbing the linked object correctly?
Have you tested it by asking for the object's name, or something like that before trying to run Remo's code on it?


On 07/08/2014 at 14:46, xxxxxxxx wrote:

Well, the code I'm using is from another plugin that I coded and it is working perfectly. The other plugin even includes two fields to link to two different objects (it is a transfer function) and it all works perfectly.
The basic functionality of this new plugin is, mainly the same (in the way that it works, not in what it does), so I'm re-using the code.

On 07/08/2014 at 14:50, xxxxxxxx wrote:

I tried replacing the call to SampleColorAtVertices with GePrint(b_source->GetName()); and it printed out the name perfectly.

On 07/08/2014 at 15:14, xxxxxxxx wrote:

OK. Then I'm out of ideas.
I usually run code that I'm new to in a CommandData() plugin first as a sort of script. Before implementing it in an actual plugin.
That way I know that the code is working before I attempt to add it to some other plugin.

I haven't used his code in anything else yet.


On 07/08/2014 at 15:33, xxxxxxxx wrote:

Well, I may have not adjusted the code from Remo correctly.
Would it be possible to see your adjustments to compare them with mine?

On 07/08/2014 at 15:51, xxxxxxxx wrote:

Sure. I can send you my CD plugin if you want.
What's your e-mail again?


On 07/08/2014 at 15:58, xxxxxxxx wrote:

Thank you very much in advance, Scott.
My mail is [email protected]

On 08/08/2014 at 04:39, xxxxxxxx wrote:

I had to fire it up on Parallels to check it out (I'm on a Mac ;-) )
It works.
But as I used your code in my plugin, it crashes the same way :-(

On 08/08/2014 at 07:11, xxxxxxxx wrote:

Then the problem has to be in your plugin.
Do you know how to use the debugger?
The error you get from it might help you figure it out.


Edit-- FYI
I have to correct myself a bit.
That stuff I was saying about the subdialog is for the older type of ToolData plugins.
I think you're using the newer DescriptionToolData plugin. Which uses the .res file. And is a bit different from the older ToolData plugin.
I forgot that there was two different versions of the tool plugin.