Hi, without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

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

That are great news, but sadly I am not a Phyton User

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

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

Hello @wuzelwazel, thank you for reaching out to us. I am sorry if I gave you the impression that this will be fixed with S24. This issue is still on our radar, but it does not have the highest priority. I am also unfortunately not a liberty to give you a time frame when this will be done. Thank you for your understanding, Ferdinand

Hi, ten times slower sounds rough. It is probably because I was a bit lazy and used a lookup table (visited) to traverse the scene-graph, which is a rather expensive thing to do. Feel free to use the fixed traversal if performance becomes an issue here. Cheers, Ferdinand

thank you both @a_block for enduring my beginner questions and zipit always keeping it precise and clean ,,, I managed to get an old script to run 20 times faster by just finding junk I was able to cleanup ! Even though as a beginner I sometimes do not know what I am doing this profiling helps to find stupid code! so few more scripts to cleanup.

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

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

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.

@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??!

hi, Sorry for the delay of this answer, we simply missed your post. When using STRING READOUT_WIDTH { ANIM OFF; } it's important that you initialize the parameter in your Init function. Otherwise uninitialized type will be a int. At some point, the code is comparing the old value type with the new value. That's why it's waiting for a Int while you provide a Str. (feel like a bug to me) I don't see the problem using STATICTEXT or STRING. It does create the expected fields. The StaticText can't be Animated anyway, i would remove the ANIM OFF STATICTEXT PYPREFERENCE_STATICTEXT {} STRING PYPREFERENCE_STRING { } about the border around the static text you can declare the field like this in your ressource file: STATICTEXT PYPREFERENCE_STATICTEXT_BORDER {BORDER;} Cheers, Manuel

Hi, without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly. Cheers, Ferdinand

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.

Hi, @Cairyn said in The asymmetric matrix inversion issue: I guess it depends on the point you want to make... I would mostly agree, but my point point was more the other way around. Not that shearing is a thing you commonly want to do, but the fact the you should be aware that c4d.Matrix will not enforce an orthogonal basis. Because if you thought it does, you could for example think that my_frame = c4d.Matrix(v3=my_normal) would be a sufficient way to construct an orthogonal frame where my_normal is k and then carry out some transforms with it and wonder what the heck is going wrong. @Cairyn said in The asymmetric matrix inversion issue: This has, in fact, been a point I thought long and hard about... What I meant with that passage was the story which has been attributed to many famous programmers who left a complicated piece of code only commented with "and here comes the tricky part". Usually told as a testament to both their technical genius and their communicative shortcomings. The often (at least silently) admired notion is that "everything is self explanatory for a smart person". Which of course is neither true nor very "cool". I feel you are drifting a bit into that direction. About the linear algebra stuff. In my opinion there is no wrong or right there, you can do a good job with a very coarse and with a very fine model. Although I think often the geometrical meaning of linear algebra has been neglected in teachings about it. Especially Cinema's "matrices" (which in my book do not really qualify as matrices) can be very well explained as linear maps which will automatically will make all four principal transforms intuitively clear. Everything that is left then is to explain that matrices are just another way to write a linear map, i.e. a linear combination of vectors representing a coordinate system. Cheers, zipit

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.

Hey guys, just wanted to let you know, that I've cracked the case in the meantime. Here are my findings: def convert_matrix_left_to_right(m): # http://www.techart3d.com/2016/02/convert-left-handed-to-right-handed-coordinates/ # m = op.GetMg() new_m = c4d.Matrix( m.off, m.v1*-1, m.v2, m.v3) return new_m def rotate_y_axis_180(): # Construct your own matrix based on rotation of axis # https://www.mathworks.com/help/phased/ref/roty.html x = c4d.Vector(-1, 0, 0) y = c4d.Vector(0, 1, 0) z = c4d.Vector(0, 0, -1) off = c4d.Vector(0, 0, 0) return c4d.Matrix(off, x, y, z) def GetGlobalRotation(obj): m = obj.GetMg() new_m = rotate_y_axis_180() * convert_matrix_left_to_right(m) return c4d.utils.MatrixToHPB(new_m, order=c4d.ROTATIONORDER_XYZGLOBAL) Indeed you have to convert from a left-handed (c4d) (hpb) to a right-handed (houdini) (xyz) coordinate system... plus I've found that you need to add 180° to the y axis, so I constructed a matrix in rotate_y_axis_180 that I can multiply to my converted matrix. Hope it helps someone... Thank you guys for your input! Have a great weekend and stay safe! Cheers, Lasse