Topics created by Amazing_iKe

Hey,

thanks for the extended code, but I still cannot run this, as it is only a fragment 😉 So, I only have a very rough understanding of what is going wrong.

A likely issue apart from you just having a bug in your hit logic, is that you use the wrong coordinate system.

if msg[c4d.BFM_INPUT_DEVICE] == c4d.BFM_INPUT_MOUSE \ and msg[c4d.BFM_INPUT_CHANNEL] == c4d.BFM_INPUT_MOUSELEFT \ and msg[c4d.BFM_INPUT_VALUE]: local_x = msg[c4d.BFM_INPUT_X] local_y = msg[c4d.BFM_INPUT_Y] scroll_y = self.dialog.get_scroll_offset()

I would have to check myself, but there is some inconsistency with which dialogs send mouse input messages regarding the used coordinate system. Sometimes they send messages in the coordinate system of the dialog and sometimes messages in the coordinate system of the gadget. Just print out your (local_x and local_y) and check if the values make sense as local coordinates as you seem to treat them. On GeUserArea are multiple coordinate conversion methods. I think BFM_INPUT in this context is in local user area coordinates but I am not sure, it could also be that you have to convert them.

The other thing is of course that you add this self.dialog.get_scroll_offset() on top of things. I assume this is sourced by something like GeDialog.GetVisibleArea? There you could also unintentionally mix coordinate systems.

Cheers,
Ferdinand

Hey @Amazing_iKe,

Thank you for reaching out to us. That RenderDocument does not support animations is only partially true. Effectively it does not for users, but that is more a regression than the lack of an actual feature. When you look into its documentation, you will see that many symbols and arguments are animation related. And when you send it a document which holds an animation, you are paying the price for rendering the full animation. The regressed state is however that you effectively only have access to the bitmap of the last frame of that animation. There is also the issue that the OCIO workflow with RenderDocument is a bit clunky at the moment. We have these issues in our backlog by I unfortunately cannot make any guarantees as to when we will fix them.

You have two options:

Render the document frame by frame yourself with RenderDocument and then assemble the animation yourself. Use the BatchRender, i.e., what is shown to the user as the render queue. You can use this in a fully programmatic manner, but you are restricted to rendering documents that have been saved to disk, and the output will also be put to disk. I.e., you do not have the 'memory only'-aspect of RenderDocument. There are many topics about this subject on this forum, for example here where I showed how you abstract some of the disc-only limitations aways. Maxime also recently added some features to the batch render like switching cameras and takes, which makes it less likely that you have to modify the file.

I cannot write examples for all possible routes here. You have to decide yourself which route you want to go, and when you are then stuck there, I will help you. What to pick depends on your goals. When you expect the renderings to be quick, doing it manually with RenderDocument could be a solution. For more complex animations, the batch renderer is probably the better route.

Cheers,
Ferdinand

Hey @Amazing_iKe,

Thank you for reaching out to us.

You do the same thing you did incorrectly in your other thread. You create an async dialog and you do not keep it alive. We would prefer it to keep things G-rated here. I.e., no nudity, no violence, and no weapons. I removed the image in your posting.

With that being said, and when I try out your script (with the dlg thing fixed). I end up with this:
fc83d223-abc0-4568-98fc-deb82596b059-image.png

I.e., it just works. But you docked your dialog (and so did I imitating what you did). I now cannot reproduce this anymore, but when I did something in my layout, I think I dragged a palette, I got a similar result as yours. That is not too surprising though as you implement here an async dialog in a hacky manner. You have no CommandData.RestoreLayout which would handle layout events for your dialog. Something getting out of whack with scroll areas is not out of question for such irregular cases.

Please follow the patterns shown in our GUI examples I would recommend to follow py-cmd_gui_simple_2024, it also contains code for handling layout events. I.e., this:

def RestoreLayout(self, secret: any) -> bool: """Restores the dialog on layout changes. Implementing this is absolutely necessary, as otherwise the dialog will not be restored when the user changes the layout of Cinema 4D. """ return self.Dialog.Restore(self.ID_PLUGIN, secret)

And to be clear, it is absolutely fine to share plugins with us here. It does not have to be a script manager script. Things should just not get too long. Feel free to anonymize your plugin IDs when you feel skittish about sharing them in public.

Cheers,
Ferdinand

edit: Okay, there it is again. Not exactly the same as yours but close. But I would still have to ask you to provide an example where this happens inside a valid async dialog implementation (with a command or a similar owner). It is not out of question that there is a bug but we still need a non-hacky example.

df89038f-124d-434f-8cde-3442bd9aebba-image.png

And just to be clear, using a modal dialog, e.g., DLG_TYPE_MODAL, is absolutely fine in a script manager script. Because then the GeDialog.Open call will only return when the dialog is closed (and you therefore do not have to keep the dialog alive).

The hack I showed above is only needed when you need one of the async dialog types in a script manager script for testing purposes.

@ferdinand Thank you very much for your response and suggestions.

I’ll make sure to follow best practices and provide a minimal, testable code sample when posting questions in the future. I’ll also give embedding a group a try.

Thanks again for your support!

Hello @Amazing_iKe,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment. Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support. Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions.

About your First Question

@Dunhou is right, this, querying for values is not possible with graph descriptions at the moment (querying for nodes is possible to some extent) . What you could do, is use a graph query to select some node over its properties, and then just write its ID. ApplyDescription returns the true nodes of a graph sorted over their IDs. Then you could grab that node you are interested in, get the port you want, and write the value based on the existing value. Or you could let graph descriptions be graph descriptions and just use the low level API directly. You can have a look at the Nodes API examples for some inspiration how this lower level API works.

On of the things I am working on at the moment, is extending the query ability of graph descriptions. What I have implemented so far, is nested queries (you can select nodes over them being connected in a specific way), more query operators (<, >, !=, regex, etc.), and something I dubbed query compositions that allows you to query one node property for more than one value, so that can do stuff like checking if something is smaller than 1, AND bigger than 0, AND not exactly 0.5, or that something matches the regex "$foo." OR "$bar.". What has been also added so far, is a new function called EvaluateQuery which allows you to run queries without having to apply a description. But this function also operates on the level that it will return nodes, and not ports or even values.

I of course also have thought about this, querying for values directly, but I have not implemented it for now, as you can do it somewhat easily yourself with EvaluateQuery (and to some extent even with ApplyDescription) by just getting the port and then its value. But I understand the alure, maybe when I have time, I will fit in a EvaluateValueQuery. The update was planned for one of later 2025.X releases, but at the moment it looks more like that it will be 2026.0.0.

When you need help with the lower level Nodes API, just open a posting here on the forum with what you got.

Cheers,
Ferdinand