Apologies, I thought my mention of the Voronoi Fracture's ability to generate vertex map tags (itself being a generator that deals with variable geometry) would be clear enough, but I suppose a casual mention doesn't suffice for an app this complex, haha! Yeah, it's really all about overcoming that immutable nature of the vertex map tag. I'm generating them on parametric objects and I need them to be able to adapt to changing point counts. Just like they're able to do on editable polygon objects. Which means I have to create a new tag each time the host object's geometry changes and update anywhere else it's linked. That's where TransferGoal() comes in. Where my function was failing was a result of TransferGoal() not only updating the BaseLinks, but also the variables within my code. So in my function, once TransferGoal()is called, both vmap and replacement_tag variables end up referencing the same tag (the new one), leaving me without a variable filled with the old tag to delete. Passing True as the second argument left my variables alone and only updated the links, essentially making it work perfectly. So passing True or False to TransferGoal() didn't make any difference as far as the BaseLinks were concerned. Those always updated correctly. If I had to guess I would say it has to do with the memory addresses of the objects being transferred... which is just more reason to avoid ignoring that little instruction in the sdk;) I'll trust the devs on matters of memory handling lol. Turns out it's quite easy to work around. Since I insert the new tag directly after the old tag I can simply use GetPred() to find the old tag and successfully delete it. As far as your question as to whether I would consider this desirable or expected behavior, I would say no. I would much prefer that my in-code variables remain as they were before calling TransferGoal, because as it currently is I'm left with two distinct variables that hold the same object. In other words, I'm left with redundancy and it ends up preventing me from doing more to the old BaseList2D object. In my case, it happens to be relatively easy to re-find and re-reference that BaseList2D object, but that might not always be the case. But yeah, now I have a working skeleton function (that doesn't break the rules lol). Just gotta bulk it up with appropriate checks and I should be good to go! Thanks for your help @zipit! Cheers! Kevin

@zipit Hi, thank you for the message. Yes, I believe I already understood everything you explained and I do appreciate your efforts. I knew I wasn't doing anything with the descid in my code, I was just confused as to why when I change one attribute, I was getting MSG_DESCRIPTION_POSTSETPARAMETER messages from all of the attributes as opposed to just the one attribute. Perhaps it is something else in my code that is sending those. Regardless, it isn't hugely important, I was trying to be as efficient as possible. Thank you.

@m_magalhaes Thanks Manuel! When I fill-in only Inner edges in NgonBase::BuildNgon, then it surprisingly works I don't know why I tested all combinations except this one There are still some minor glitches, some inner edges are randomly not hidden, but ngons created are valid for all the cases I have tested. Random glitches are easily fixable with forcing all inner edges to be hidden. I will test it more, but this seems to be reliable for now. NGONS import - read outer edges directly from Pgon::*m_Edge array NGONS export - with NgonBase::BuildNgon(), filling Inner edges only, and force hide inner edges on quads. Thanks a lot Manuel, Your help has been very valuable to me. Regards, Viktor.

As already told by @zipit, I'm terribly sorry for coming so late here. I've prepared a full example showing how to fill a VertexColorTag in the ObjectData::GetVirtualObjects() and use this values to color the triangles shown up in the ObjectData::Draw() method. My code actually uses the VertexColorTag::SetColor()/GetColor(). [image: 1605105495571-5b4213d8-e4b4-434a-ad71-5ef0d69be6ea-image.png] The VertexColorTag in this case is not specify to each vertex of the triangle but specifies the color for the whole triangle: this is because the tag is created in the ObjectData::GetVirtualObjects() and store color for each point of the cloud, but then it's used in the ObjectData::Draw() method to specify the ObjectColorProperty used to color the drawn PolygonObject. As far as I know the BaseDraw::DrawPolygonObject() ignores any VertexColorTag assigned to the PolygonObject to be drawn. BaseObject* PC_12974::GetVirtualObjects(BaseObject* op, HierarchyHelp* hh) { // check cache before continue BaseObject* cache = op->GetCache(); if (cache) return cache; // init the random gen and get a arbitrary number of tris _rndGen.Init(GeGetTimer()); _randomTrisCnt = (SAFEINT32(_rndGen.Get01() * (1 + _max - _min)) + _min); // allocate a PolygonObject and fill it with points randomly PolygonObject* po = PolygonObject::Alloc(_randomTrisCnt, 0); if (!po) return BaseObject::Alloc(Onull); // fill the points array with random positions Vector* points = po->GetPointW(); for (Int32 i = 0; i < _randomTrisCnt; i++) points[i] = Vector (100.0 * _rndGen.Get11(), 100.0 * _rndGen.Get11(), 100.0 * _rndGen.Get11()); // look for VertexColor tag BaseTag* tag = po->GetTag(Tvertexcolor); // if not existing just create a new one VertexColorTag* vcTag = nullptr; if (!tag) { tag = VertexColorTag::Alloc(_randomTrisCnt); po->InsertTag(tag); } vcTag = static_cast<VertexColorTag*>(tag); vcTag->SetPerPointMode(true); VertexColorHandle handle = vcTag->GetDataAddressW(); // fill the vertexcolor tag with random values for (Int32 i = 0; handle && i < _randomTrisCnt; i++) VertexColorTag::SetColor(handle, nullptr, nullptr, i, maxon::Color32(_rndGen.Get01(), _rndGen.Get01(), _rndGen.Get01())); // update host object po->Message(MSG_UPDATE); return po; } Bool PC_12974::TriangleOnPoint(const Vector &pos, PolygonObject& po) { // given a point create a triangle centered over there. Vector* points = po.GetPointW(); const Matrix poMG = po.GetMg(); const Vector posMG = poMG * pos; if (!points) return false; // set vertexes positions for the triangle. points[0] = Vector(0, 0, _triangleRad) + posMG; points[1] = Vector(_triangleRad * Cos(-PI / 6), 0, _triangleRad * Sin(-PI / 6)) + posMG; points[2] = Vector(_triangleRad * Cos(-PI * 5 / 6), 0, _triangleRad * Sin(-PI * 5 / 6)) + posMG; // create the polygon CPolygon* polys = po.GetPolygonW(); if (!polys) return false; polys[0] = CPolygon(0, 1, 2); return true; } DRAWRESULT PC_12974::Draw (BaseObject *op, DRAWPASS drawpass, BaseDraw *bd, BaseDrawHelp *bh) { // skip anything but OBJECT drawpass if (drawpass != DRAWPASS::OBJECT) return DRAWRESULT::SKIP; // check for the object and its cache if (op && op->GetCache()) { // get the PolygonObject from the cache PolygonObject* opPO = static_cast<PolygonObject*>(op->GetCache()); // look for the attached VertexColor Tag BaseTag* const tag = opPO->GetTag(Tvertexcolor); if (!tag) return DRAWRESULT::SKIP; VertexColorTag* const vcTag = static_cast<VertexColorTag*>(tag); // retrieve the read-only handle ConstVertexColorHandle vcTagHandleR = vcTag->GetDataAddressR(); // get the points and iterate over the VertexColor to set the color // of each triangle drawn maxon::Int pointCnt = opPO->GetPointCount(); Vector const *points = opPO->GetPointR(); for (maxon::Int i = 0; i < pointCnt; i++) { maxon::Color32 vtxCol(0.0); // get the color if (vcTagHandleR && vcTag->IsPerPointColor()) vtxCol = VertexColorTag::GetColor(vcTagHandleR, nullptr, nullptr, (Int32)i); // set the color in the ObjectColorProperties ObjectColorProperties colProp; colProp.usecolor = ID_BASEOBJECT_USECOLOR_ALWAYS; colProp.color.x = vtxCol.r; colProp.color.y = vtxCol.g; colProp.color.z = vtxCol.b; colProp.xray = false; // allocate the temp triangle PolygonObject* tri = PolygonObject::Alloc(3, 1); // set the color prop, create the tri and draw! tri->SetColorProperties(&colProp); if (TriangleOnPoint(op->GetMg() * points[i], *tri)) bd->DrawPolygonObject(bh, tri, DRAWOBJECT::NONE, nullptr); // free the tri PolygonObject::Free(tri); } } return DRAWRESULT::OK; } Feel free to comment and again sorry for the silence. Riccardo

I am also having trouble to get the Status bar to update while a script is running. My old scripts using Callcomand nevertheless update the Status bar fine ...?!? nevermind got it working again ... mistake on my end. (passed a small flot to the statusbar instead of 0-100. kind regards mogh

@kbar Thank you for the reply and helpful link. And for anyone look to get this working with your Description files: (from https://c4dprogramming.wordpress.com/2013/05/10/long-cycles-with-icons-and-separator/), put the plugin ids in your Description header and this in your Description resource file: CONTAINER Omyobject { NAME Omyobject; INCLUDE Obase; GROUP ID_OBJECTPROPERTIES { LONG MYOBJECT_ICONCYCLE { CYCLE { MYOBJECT_ICONCYCLE_ITEM_0; -1; MYOBJECT_ICONCYCLE_ITEM_1~Ocube; MYOBJECT_ICONCYCLE_ITEM_2~Opyramid; MYOBJECT_ICONCYCLE_ITEM_3~1021433; } } } } -1 creates a separator.

hi, Confirmed, thanks @mp5gosu. That also work if the shader is inside another shader. Cheers, Manuel

@zipit Thank you, Ferdinand, for looking into it!

Nice

@rsodre please refrain from discussing NDA-protected topics.

Hi Manuel, thanks for the info! If smooth is set to false, the wrong positions disappear in deed. The distribution of the positions, however, is much uglier. It requires the user to change some specific attributes of the spline to make it look nice. But I think, that's ok for now. Thanks again & greetings, Frank

Indeed a better sdk will be better. I actually also hope that sdk can recognize which parameters of the object are activated in the object manager. I know that because c4d supports opening multiple object managers at the same time, this is really convenient. But it will also make it impossible to know which object manager the user is using, so there is no way to identify it in the current SDK.

@zipit I'll post code with my scenes/screenshots in the future. Setting the value in MSG_DESCRIPTION_POSTSETPARAMETER fixed my issue! Wow, how do you know all of this stuff??!

Thanks for confirming! The strange thing is that I can reproduce this even in R20. Seems, not many people use this function to open URLs. I'll mark this as solved then, as my solution presented in this thread works flawlessly on all R2x releases. Cheers, Frank

Hi thanks for the report this was already reported in Phong Tag with ObjectData and this is going to be fixed in the release after R23 SP1. Cheers, Maxime.

Great! Thank very much @m_adam!

Hi, I did not really expect an answer, I just did put it up to make you guys aware. Regarding your reply, I agree with most of it and am aware that there a some hurdles to overcome in mapping C++ interfaces to Python, i.e. that you do run into problems in general when you want to express overloaded methods in Python. But as @mp5gosu pointed out, my major point was that the function does not accept named arguments at all. Which is mainly a problem because the docs tell you explicitly otherwise in two ways. First of all the docs say explicitly that all arguments are optional which implies for Python usually that I can pick and choose in which arguments I can pass by passing named arguments. And secondly, you print out the signature as Vector.__init__(x=0.0, y=0.0, z=0.0) which implies the same. I would have probably ignored all this and booked it under "that's for me to know and for you to find out", if it wasn't for the fact that the method does not raise a TypeError on attempts of feeding it with such unknown named arguments. Which can make this quite critical IMHO. Cheers, zipit

@m_adam Thank you for your answer. C++ documentation have a "Example" show how to use flags in CAMorph.SetMode, but python documentation not (at least in R21.022), i compared the C++ code with Python, then went back to the C++ documentation and found this.

RE: This is a limitation you also have with the visual selector Not really. You can multiple select hotspots and/or controllers in the visual selector. Anyhow, thanks for the response. I guess there is no way around this.