@i_mazlov Thanks,it works!

Hi Ilia, Thanks a lot for the quick and clear reply! That makes sense. I had a feeling it might be a limitation of the current API. I’ll definitely follow up with the Redshift team on their forum to confirm whether there’s any workaround or future support planned for accessing those fields. Appreciate your help and the reference to the related thread! Cheers, Anthony

Hey, Node attributes are things that are directly present on a GraphNode. You could also call them fields, because a GraphNode like many things in our API has qualities of a DataDictionay, i.e., you can write values over keys into it, just like for Python's own dict. Such node attributes (for true nodes) are then rendered out quite similarly to port values in the Attribute Manager but they are fundamentally different from ports, as users cannot drive their value with a connection, i.e., the value of a port of another node. And a port also always requires another GraphNode attached to the true node¹ for which they are a port, while the attribute sits directly on the true node. An attribute, e.g., the name of a node, will also never show up in the node representation in the graph. In the screen below I for example right clicked on the RS Reference node and invoked Add Input > All; but things like Name, Color, Show Preview etc. are alle not listed. [image: 1744368637847-174097cf-d777-49d2-b0ea-0057c8474a5e-image.png] That is because they are all attributes and not ports. There is unfortunately no absolute rule like 'everything in Basic is attributes and everything else is ports'. While it holds (for now) true that everything in Basic is an attribute, especially Redshift also puts attributes into other tabs. They usually only appear in more complex scenarios when dealing with port bundles and variadic ports, but they exist. And just for clarity, attributes do not only exist on nodes that are what our API calls 'true nodes'¹, but also on other GraphNode types, e.g., a GraphNode representing a port. It is just that they are usually not rendered out to the GUI there and more of an internal nature (nodes have a lot of internal attributes). Cheers, Ferdinand ¹ GraphNode instances that represent what the end user would consider a 'node', e.g., the RS Reference node, and with that excluding GraphNode instances that for example represent an input port.

@i_mazlov Thanks

Ah, super! thank you.

Thanks a lot @i_mazlov ! The issue is solved !

Fantastic @i_mazlov ! Both issues are solved, thank you so much ! Cheers, Flavio Diniz

Hi @ferdinand, Sorry about missing that post. This exactly solved my problem, thanks. Dam

@ferdinand said in SAVEDOCUMENTFLAGS_AUTOSAVE still added to the recent file list?: But please provide instructions on how to use your code when required in the future. oh shit, i'm so sorry. you're right. completly missed this one. ... and of cause thanks for the explaination / clarification.

Hey @T1001, I am still not 100% sure how you all mean that. But in short what you are doing is not possible in the public API and also only to some degree in the internal API. First of all, Cinema 4D only supports HDR in the viewport and it must be enabled by the user: [image: 1744104813146-f4036fae-fdc3-44bd-bd44-b876a51f4699-image.png] I.e., viewport effectively means Drawport API. What the docs write there about the only the viewport is only semi true, because you can embed a drawport into a GeDialog (but that functionality is still not even semi-public I think, but we could change that in a future release). I am not quite sure what you mean by 'integrating a custom OpenGL pipeline into a plugin'. When I take this at face value, I would say you cannot do this. The Drawport API is an abstraction around effectively Vulkan and Metal. We do not write OS specific graphics API code anymore. This goes as far as that we have (sort of) our own shading language (MSL). You cannot just draw with OpenGL into a GeDialog, because that dialog will not be drawn with OpenGL and we also do not offer a direct access point to drawing handlers. I assume this all has something to do with implementing some kind of render buffer? I really would recommend then applying for the Maxon Registered Developer program to get access to the Drawport API. Just as a warning ahead, the Drawport API is not totally undocumented but not documented to the same degree as our fully public API. It is an API from graphics API experts for graphics API experts. You seem fairly knowledgeable there, so this might be just your thing, but you have been warned, there will be less hand-holding there. Cheers, Ferdinand

@ferdinand said in How to simulate a drag behavior with UA?: All it it does when the users starts to drag, according to Maxime, is inject the asset object into the document, make sure there is no object selected and then enable the place tool (and probably set the mouse cursor) This is my solution in my mind, definitely take a try after work.

Hi Sebastian, correct, it hasn't been included into 2025.2.0. The next minor release will likely have it fixed though. Cheers, Ilia

Hey @hSchoenberger, as I said, what we provided is mostly a workaround, we'll have to streamline things. I cannot talk much about the details, since I do not yet know myself how we will solve this. Please open new topics for new questions in the future, especially bug reports should remain clean. Our render pipeline, and that includes commissioning third party renders, converges into a singular point. There are currently four entry points into that pipeline: The built-in commands such as "Render to Picture Viewer", "Render View", "Render Region", etc. For them this pipeline has been built initially. Also headless Cinema 4D instances such as the command line or c4dpy use this mechanism when invoked for a rendering. The c4d.document.BatchRender, uses mostly the same route as (1), but the drawback compared to RenderDocument is that you must always operate with files on disk. I.e., you cannot just change a document im memory and then render it, you must first save it to disk, and also your output will provided on disk and not as bitmaps in memory. As stated before, this is the way I recommend. You should not have to apply an OCIO hacks here, we are at least not aware of any issues. The .net Renderer, a.k.a, Team Render, similar to (2) functionally, just more complicated. And other than for (2), not all third party renderers do support Team Render. RenderDocument differs from these three in that it does not take the full length of our render pipeline, but just a subsection of it. RenderDocument is used internally to render icons and preview images and was never intended to be the 'programmatic rendering interface' it unfortunately has been marketed as and is used as by many third parties. The advantage of RenderDocument is that you can easily operate in memory only without any disk activity. Whenever I was asked in the past, I always told people that using RenderDocument as a render pipeline endpoint is not such a good idea because that is not what it is designed for. Mainly because there are also other short-comings due to it not taking the full route in the render pipeline (animations for example or the render data handling). With OCIO this worsened, as we have intertwined the render pipeline, the Picture Viewer, and saving output to disk even more, i.e., things RenderDocument is naturally left out of. I simply do not know yet how we will fix this, as this is largely not my code. But for me it is clear that this must be simplified in Python. This could either happen in the form of fixing RenderDocument regrading its Picture Viewer and BaseBitmap.Save, i.e., BitmapSaver interactions, or by giving the BatchRender more RenderDocument like qualities. The solution to this will not be super simple, and it will likely not arrive within 2025. For now there is a somewhat functional workaround for RenderDocument and you can always use the BatchRender. Cheers, Ferdinand

Love the mxutils and GeDialog Changes, I use these features almost every time, thank you for having a more refined official version. Thank you to the SDK team for their work achievements Cheers~ DunHou

hi, i came up with this now... def hasGenFlag(op): description = op.GetDescription(c4d.DESCFLAGS_DESC_NONE) bc = description.GetParameter(c4d.ID_BASEOBJECT_GENERATOR_FLAG) return not bc[c4d.DESC_HIDE] if bc else False also its clear that "Generator" is a wide definition which doesn't match the Green Checkmark / Enabled GUI Element. in this sense the topic title is wrong bc i was just searching for a way to distinct objects having this GUI element from others which don't. (i can't change the topic title, i guess)

Hi sorry I fixed my code. Cheers, Maxime.

tend to be very complex computationally and therefore not very sensible to be implemented in Python. yeah, I forgot the BaseView, but whatever, I agree whit you. And this is just the beginning, I'm still in the research and testing phase. My final goal is to write a procedural tree generator, so maybe combine L-System to improve some performance, I'll also try to write an Octree. Thank you for your suggestion and reply. Cheers! Gheyret

Hi @Gregor-M please make sure that your script is executable before sending it to us. Since in it's current state it does raise Traceback (most recent call last): File "scriptmanager", line 53, in GetDown File "scriptmanager", line 33, in GetChildren AttributeError: 'Entity' object has no attribute 'children'. Did you mean: 'GetChildren'? I added self.children = [] within the __init__ of Entity and it fixed the issue but this indicate that you are working on a different version than us. But even with it I'm not able to reproduce any issue and everything is working as expected. With that's said your else statement within the SetCheck looks very suspicious and I won't be surprised that the behavior you are experiencing is coming from this else statement. Finally note that you can call the function TreeViewCustomGui.SetRoot to define a root. Then the root argument that is available in all functions will be pointing to it. Cheers, Maxime.

@i_mazlov Thanks for your help, it works well.

@ferdinand Thank you for your kind explanation. I will explore other options.