Sampling color at vertexes
-
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);-ScottA
-
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 ?
Remo
-
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).
-ScottA
-
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 SampleColorAtVertices(b_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.
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 { private: LinkBoxGui *myLink; public: 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 { public: 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); }; //etc....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?-ScottA
-
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.
-ScottA
-
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?-ScottA
-
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.-ScottA
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. -
On 08/08/2014 at 07:35, xxxxxxxx wrote:
No, unfortunately I don't know how to use the debugger
-
On 08/08/2014 at 09:06, xxxxxxxx wrote:
I don't have the Remo code in my plugin, like you have.
It is in a separate file that I include at the start of my source code, like this:#include "c4d.h"
#include "c4d_symbols.h"
#include "tpolypaintfrommaterial.h"
#include "c4d_helpers.h"
#include "remo_sampler.h"Could it be because of this?