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.

Hi again; just to close off the topic here's what I ultimately found: A lot of the delay that causes the choppyness of the motion is apparently an issue with EventAdd(). I require this call to update the Attribute Manager for the current camera, and to start the recalculation of the interactive render region. But as it seems to refresh about everything, the call causes a noticeable delay before the next viewport refresh comes through. (It is surprising that this call takes longer than a redraw of the viewport, and it is very hard to time as EventAdd() just posts a message to the queue, so I cannot actually measure the execution duration.) The scene camera is slower than the viewport camera. CollieMouse treats both the same, in fact, all handling is done through a CameraObject that I get in a similar way as the one you posted above. Yet, the redraw is slightly slower by itself, and there are apparently things indirectly happening for a scene camera that take even more time (even when expressions are switched off). There is not much I can do about that except allow the user to suppress certain refreshs for the sake of a smoother Space Navigator experience. I'm still not sure what some of the DrawViews() flags exactly mean, by the way. I guess I can ignore the HIGHLIGHT ones for now, but what are INDRAG, INMOVE and FORCEFULLREDRAW really doing, and when do I need to use them? I see that you use INMOVE in your code (but not NO_EXPRESSIONS which surprises me).

Ok Thanks

Right, that's kinda what I thought. I guess showing "<< MULTIPLE VALUES >>" for all four values will have to do (it's not that big of a deal, it just kinda looks ugly on the UI). Anyways, thanks for your help! -CMPX

Hello, there should be header files for all shaders. The header file of Xgradient is xslagradient.h. The header file of Xvertexmap is xslavertexmap.h. best wishes, Sebastian

@a_block It was the ID. I did use a random number, apparently one too many. I didn't think it would matter for testing but I guess I was wrong! I figured it would be something dumb like that. It was just weird it pointed me to that line for the error. And yes sorry my code snippet was confusing, I thought it was standard practice to put RegisterObjectPlugin on multiple lines for easier reading. Thanks again!

yeah! I got it! Thank you very much！

Thanks Riccardo, I think we reached the bottom of this issue. I just finished implementing a workaround, getting the tag associated with the shader, it's polygon, points and uvw tag, then paint each face with the average vertex value in a bitmap using GeClipMat. Working really good! Best, Roger

Hi @merkvilson, this is a limitation actually the tool Phong Break selection and the modeling command MCOMMAND_PHONGTOSELECTION are two completely separate things. So the only solution available to you is to manually break the Phong. I'm sorry we can't help you more on that, Donovan points you to the correct direction with the neighbor class. Cheers, Maxime.

Hello, ColorDialog is just the Python version of C++'s GeChooseColor() function. It uses the flags DR_COLORFIELD_ICC_BASEDOC and DR_COLORFIELD_ICC_BPTEX which just define the proper color profile. Typically is is enough to just set 0. best wishes, Sebastian

Sorry about that, I'd noticed that the API was literally wired up to return the value from GetId() inside GetValueId() by default, so I figured that was answer enough... though I suppose that's kinda why I was asking in the first place- I wasn't sure what sort of situation would require two separate IDs. Thanks for your response though, that certainly clears up why there's two different functions to handle that. -CMPX

It seems quite simple, reading your code. However, that is python and I'm doing it in c++. I was trying to attach the old code I was using, but the uploader only allows for images. However, I'm now trying to make more generic, by internally baking the material, as it allows for more complex material assignments to objects. I'm still struggling but I will try to solve it myself, before coming back here