Hi @a_block Thank you for your answer.

Thanks @Andreas I watched Py-LiquidPainter, but I did not really understand That said, for the parameters, I understood how to do

Hi @rsodre, thanks for your feedback, and glad you solved your issue. Regarding the DisplayControl I let you read this topic: SceneHook and DisplayControl. Manuals, for scenehooks is definitely something we consider. Cheers, Maxime.

Hi Roger, I'm glad you were able to identify the issue and made some progress. And thanks for taking the time to share your findings with the forum. Much appreciated! Cheers, Andreas

Hi Franck, backward and upward compatibility for the current major release is something we really consider and try our best to not break. Unfortunately, for R20 plugins, they need to be recompiled to make them compatible with R20 SP1. See C++ Index or either in the R20.026 changelog. You may encounter an issue with plugin compiled with R20.011 (see the R20.026 changelog) since you may override maxon dedicated IDs which will break for sure some C4D/plugin stuff. Cheers, Maxime.

Sebastian, Added tags. Not really a question but a request. I thought that I had read about people adding a TreeView to the AM using GetDDescription() but maybe it wasn't as well fleshed out as they (or I) suspected. I will look into the custom data type and GUI for it. Please mark as Solved. Thanks! Robert

Hello, Thanks for the responses. I thought that this might be the case and just wanted to clarify it before moving forward. John Thomas

Thanks Riccardo, I will look into that.

I am trying to register multiple plugins that are instances of the same class, but do slightly different stuff (in this case construct different menus). I am getting some external data that I would like to put in a dictionary with the plugin ID as keys. I could then get the correct data set for each plugin by comparing the pluginID from e.g. within execute with the pluginIDs in the dictionary. But for that I would need a way to retrieve the pluginID of the class instance whose execute function was called. Edit: I figured out a way. I can pass the pluginID when initializing the plugin in the register function and save it as a class member in __init__

Hi, while I'm glad, this was already solved, I just wanted to add a link to an old thread in the archive, which might be helpful for future readers due the contained code snippet: Select polygons from Selection Tag. Cheers, Andreas

Hi Sebastian! Thanks for your answer. I was looking for something a little more flexible than registering multiple plugins, but I guess GetSubContainer will have to do

Thanks Riccardo! Now I understand - thanks to your side note. And of course I understand, that this goes hand in hand with your guidelines. Cheers, Robert

Thanks, I was wondering how to access the data. This will come in useful further down the line. Cheers, Kent

Hi @merkvilson, sadly this is not possible to add something to the attribute manager, since the attribute manager is a special window, and the menu is hardcoded. Sorry. Cheers, Maxime.

Hi rownn, thanks for following up. Can you elaborate more on I wasnt able to get the "customlength" by offset.? Actually looking at your screenshot and assuming that the red-labelled refers to what you actually consider "wrong" and the green-labelled to the right, I think that the red-labelled is indeed correct since it actually lies in the middle of spline considering that the start point is the top/right vertex. At the same time, the green-labelled point is the one that you can obtain when passing 0.5 to SplineHelp::GetPosition() which is the 50% of the spline parametrization not of the spline length. Assuming a linear rectangle is used as shown above the code below shows the behavior I describe: def main(): sh = c4d.utils.SplineHelp() sh.InitSpline(op) splineLength = sh.GetSplineLength() halfLength = splineLength / 2 midPointOffsetIncorrect = halfLength / splineLength midPointOffsetFromReal = sh.GetOffsetFromReal(midPointOffsetIncorrect,0) midPointOffsetFromUnit = sh.GetOffsetFromUnit(halfLength,0) mtx = c4d.Matrix() midpointRed = sh.GetPosition(midPointOffsetFromUnit) # which in this case is the same of offsetFromReal midNullRed = c4d.BaseObject(c4d.Onull) midNullRed[c4d.ID_BASEOBJECT_USECOLOR] = 2 midNullRed[c4d.ID_BASEOBJECT_COLOR] = c4d.Vector(1,0,0) midNullRed[c4d.ID_BASELIST_NAME] = "MidRed" mtx.off = midpointRed midNullRed.SetMg(mtx) midpointGreen = sh.GetPosition(midPointOffsetIncorrect) midNullGreen = c4d.BaseObject(c4d.Onull) midNullGreen[c4d.ID_BASEOBJECT_USECOLOR] = 2 midNullGreen[c4d.ID_BASEOBJECT_COLOR] = c4d.Vector(0,1,0) midNullGreen[c4d.ID_BASELIST_NAME] = "MidGreen" mtx.off = midpointGreen midNullGreen.SetMg(mtx) doc.InsertObject(midNullRed) doc.InsertObject(midNullGreen) c4d.EventAdd() Best, Riccardo

Awesome, that's exactly what I needed to know- thanks for the reply! -CMPX

Hi Riccardo, I spoke with SolidAngle. Eventhough the problem has nothing to do with Arnold, they helped us to solve the issue. There is a different behavior on Python when using BaseBitmap and MultipassBitmap for multiple renders. We render thousands of elements from the object tree in C4D. When you reuse a BaseBitmap the depth information will be saved for every element. However when you do the same with a MultipassBitmap, it will only store the depth information for the first element. Strangely this does not apply to the beauty image. The solution is simple. We set up a new MultipassBitmap for every render call. In hindsight, we should have initiated a new bitmap even for the BaseBitmap. Thank you for time, David

Hello, yes, you can use resource files to define the dialog layout. Or combine layout files and code. def CreateLayout(self): self.SetTitle("Dialog Test") # load dialog from resource file if self.LoadDialogResource(10000, None, 0) == False: return False # set a different title self.SetTitle("New Title") # disable a GUI element self.Enable(10001, False) return True See GeDialog Manual and Layout files. best wishes, Sebastian

@r_gigante thanks for explaining this workflow, and how the vertex tag is implemented. For my case, I discovered it's easier and safer to listen to the tag's object (when I update the tag it will invalidate a dependency list it's in), then sum all the values to detect changes, for either vertex map and color. This works well for undos too, because if I make several paintings in a row and start undoing one by one, the DIRTYFLAGS_DATA and HDIRTYFLAGS_TAG are not very reliable. They come down on the first undo, but stay with the same value on subsequent undos. R.