On 04/08/2014 at 13:41, xxxxxxxx wrote:
It's not working for me Remo.
It works fine in UWV mode. But the other modes are not returning the correct color values.
I'm still trying to figure out why.
The trouble seems to be coming from the for() loop under: /// Sample using vertex position and uv.
-ScottA
On 04/08/2014 at 14:08, xxxxxxxx wrote:
This is probably because no data form TextureTag was used.
New ReadTextureTag() function may fix this.
On 05/08/2014 at 14:11, xxxxxxxx wrote:
I have changed all the Int32 to LONG, all the FLOAT to float, all the GetInt32 to GetLong, all the GetFloat to GetReal.
I also had to define PI and PI2
But now I also stumbled on:
maxon::BaseArray<Colors> colors;
I noticed that Scott also stumbled there but from your conversation I could not figure out how to make it work?
Have you managed to update all the code to R13, Scott? Could your R13 version work on my R14 code?
On 05/08/2014 at 14:50, xxxxxxxx wrote:
I used a GeDynamicArray Rui.
A Vector is faster. But I prefer to use GeDynamicArray whenever I can so Mac uses can also use my code too. I try to only use Vectors when I need top speed from my arrays. And in this case I don't need a very fast array.
Most R13 C++ code works in R14 and R15. Which is why I'm still coding in R13.
I replaced this in Remo's code
maxon::BaseArray<Colors> colors;
colors.Resize(pcnt);
With this R13 compatible code
Note: Don't forget to put #include "ge_dynamicarray.h" at the top of the code.
GeDynamicArray<Colors> colors(pcnt);
To print the color results I change Remo's print code to this
//Print the results
for(LONG i=0; i<pcnt; ++i)
{
//GePrint(RealToString(colors[i].sampled));
GePrint("VertID:" +LongToString(i) + " R:" + RealToString(colors[i].col.x) + " G:" + RealToString(colors[i].col.y) + " B:" + RealToString(colors[i].col.z));
}
It works fine for UWV mode.
But I have no idea how to make the new ProjectPoint() stuff work though.
I have no clue what Remo is doing or talking about with that code.
-ScottA
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);
-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