Thanks for the response.

I figured that something like this would be the case, will have to look into the options you mentioned.

John Terenece

Hey @mikeudin,

Thank you for reaching out to us. In short, there is no good answer to your question.

There is no guarantee that anything will ever run on the main thread. You must always check yourself with c4d.threading.GeIsMainThread. Scene computations, e.g., ObjectData.GetContour is run in parallel off-main-thread and is therefore subject to access restriction to avoid access violations, i.e., crashes. There is no "hack" for this. The essence is that you cannot have both the benefits of sequentialism (can use shared resources) and parallelism (is fast). There are of course data structures which allow you to handle a singular resource from multiple threads, but doing this always entails lining up multiple users in a line, each waiting for users ahead in the line to be done, i.e., hidden sequentialism. In Python this might be hard to grasp because Python itself mostly ignores the concept of parallelism and we only experience here the side effects of the parallelism of the underlying C++ Cinema 4D API.

There is also the problem that your request does not make too much sense for me on a practical level. Imagine having a plugin MySpline which opens an error dialog once its GetContour method strays from the right path.

A user now edits one hundred instances of MySpline at once and triggers the error. Cinema 4D sometimes executes passes two or three times in a row to resolve dependency problems. This would then mean that you would open three hundred error dialogs for one user interaction (if that would be technically possible in the first place).

In general, no node should open any form of dialogs on its own. Opening a dialog after a button press in the description of a node via NodeData.Message is okay.

When you are hell-bent on doing this, you could do this:

Add a field to your plugin, e.g., self._error: str = "". When you are in your GetContour and an error happens, instead of raising it, simply write it to _error. Implement any NodeData method which often runs on the main thread. NodeData.Message is a good candidate. On each execution of it, check if _error has content and if you are on the main thread. If so, display the message and then null _error. You will still need some kind of throttling so that the user is not spammed with the same error over and over again. I.e., you need an "only-new-errors" mechanism. It is up to you to implement that.

An alternative approach could go via core messages. But that is also non-ideal because setting off a c4d.SpecialEventAdd will work from a non main thread but will cause the global core message lock to engage, which is of course a bad thing to happen and exactly the "no-hack" problem I described under (4).

You could also try using c4d.StatusSetText and the other status functions. While not officially supported, they will work from non-main-thread environments. But there is no guarantee and we do not officially support this.
Cheers,
Ferdinand

@ferdinand Thanks for your comprehensive explanation. I really appreciate that.
Cheers

Thanks for the response.

That's what I figured would be the case.

Thanks for the response, that seems to have solved the problem.

Hello @ferdinand,

alright I see. I already thought that you would teach me once again that the naive thought I put up here would'nt hold up to the real world. 😄 😄 😄

Thanks for the explanation and the example you provided. I guess that will do just fine. As always much appreciated! 🙂

Cheers,
Sebastian

Thanks, that was exactly what I was looking for.

John Terenece

While rethinking about it last night, it may not be that slow if on user interaction you just flush the main group and re-attach already existing dialog.

So you need to modify your `def _DrawQuickTabGroup(self)`` method like so to only display visible dialog:

def _DrawQuickTabGroup(self, onlyVisible=True): """ Creates and draws all the SubDialog for each tab, take care it does not hide these according to a selection state. Returns: True if success otherwise False. """ # Checks if the quicktab is defined if self._quickTab is None: return False activeIds, activeNames = self.GetActiveTabs() # Flush the content of the group that holds all ours SubDialogs self.LayoutFlushGroup(ID_MAINGROUP) #self.GroupBorderSpace(left=5, top=5, right=5, bottom=5) # Iterates over the number of tab to create and attach the correct SubDialog for tabId, (tabName, tabGui) in enumerate(self._tabList.items()): toDisplay = tabId in activeIds if not toDisplay: continue self.AddSubDialog(ID_QUICKTAB_BASE_GROUP + tabId, c4d.BFH_SCALEFIT | c4d.BFV_SCALEFIT, 0, 0) self.AttachSubDialog(tabGui, ID_QUICKTAB_BASE_GROUP + tabId) self.LayoutChanged(ID_MAINGROUP) return True

Then in the Command message instead of calling DisplayCorrectGroup you should call _DrawQuickTabGroup like so:

def Command(self, id, msg): if id == ID_QUICKTAB_BAR and self._quickTab: self._DrawQuickTabGroup() return True

Regarding your question and classic Tab, find an example in Remove a GeDialog Tab Group but as you can see this is also not possible to remove a tab without redrawing everything .

Cheers,
Maxime.

hi,

yes, KillDocument is not necessary in that case.

Cheers,
Manuel

Hello @ferdinand,

sorry for coming back this late. Work kept me quite busy. 🙄 😄

@ferdinand so, I had a play with your code example. It works like a charm and also seems to have a lot of potential for all kinds of update/dirty checking issues.

Thanks again @ferdinand for your help, the effort you always put into answering our questions and the eloborate examples you come up with!

Cheers,
Sebastian

Hello @HerrMay,

Thank you for your reply, and please excuse that I have overlooked it.

Maybe a little bit off topic but since we're already talking Treeviews. There seems to be a bug too when it comes to multi-selecting objects in the Treeview. At least when using c4ds native BaseList2D objects.

Without wanting to be rude, that statement is too vague to make a bug report out of it. The thread is quite old and therefore not the most reliable source of information, geared towards C++, and from what I see, not even conclusive in the assessment if there is a bug or not. I see there a user claiming that there is a bug, and another user, probably a Maxon employee, being skeptical about it.

We are happy to file bugs, but we need a reproducible case. And just as a heads up, us filing a bug does not necessarily mean that we will fix soon or at all. I understand that this can be disheartening, but we must prioritize where our bug fixing efforts are most needed, which can lead to minor bugs being pushed for a long time.

I have closed this thread due to its age, please feel free to open a new thread when you want to discuss that other bug. The thread is still be tracked due to its to_fix tag.

Cheers,
Ferdinand

Hello @ferdinand,

when trying out your function to traverse shaders I noticed that for two materials in the scene it yields for the first material all the shaders of itself but also all the shaders of the second material. For second material it works like expected and yields only the shaders of itself.

After fiddling around a bit with some other code of you from this post I think I ended up with a function that is yielding all the shaders from a material iteratively.

Find the code below. Maybe this will help others. 🙂

Cheers,
Sebastian

def iter_shaders(node): """Credit belongs to Ferdinand from the Plugincafe. I added only the part with the material and First Shader checking. Yields all descendants of ``node`` in a truly iterative fashion. The passed node itself is yielded as the first node and the node graph is being traversed in depth first fashion. This will not fail even on the most complex scenes due to truly hierarchical iteration. The lookup table to do this, is here solved with a dictionary which yields favorable look-up times in especially larger scenes but results in a more convoluted code. The look-up could also be solved with a list and then searching in the form ``if node in lookupTable`` in it, resulting in cleaner code but worse runtime metrics due to the difference in lookup times between list and dict collections. """ if not node: return # The lookup dictionary and a terminal node which is required due to the # fact that this is truly iterative, and we otherwise would leak into the # ancestors and siblings of the input node. The terminal node could be # set to a different node, for example ``node.GetUp()`` to also include # siblings of the passed in node. visisted = {} terminator = node while node: if isinstance(node, c4d.Material) and not node.GetFirstShader(): break if isinstance(node, c4d.Material) and node.GetFirstShader(): node = node.GetFirstShader() # C4DAtom is not natively hashable, i.e., cannot be stored as a key # in a dict, so we have to hash them by their unique id. node_uuid = node.FindUniqueID(c4d.MAXON_CREATOR_ID) if not node_uuid: raise RuntimeError("Could not retrieve UUID for {}.".format(node)) # Yield the node when it has not been encountered before. if not visisted.get(bytes(node_uuid)): yield node visisted[bytes(node_uuid)] = True # Attempt to get the first child of the node and hash it. child = node.GetDown() if child: child_uuid = child.FindUniqueID(c4d.MAXON_CREATOR_ID) if not child_uuid: raise RuntimeError("Could not retrieve UUID for {}.".format(child)) # Walk the graph in a depth first fashion. if child and not visisted.get(bytes(child_uuid)): node = child elif node == terminator: break elif node.GetNext(): node = node.GetNext() else: node = node.GetUp()

Hello @fwilleke80 ,

without further questions or postings, we will consider this topic as solved by Thursday 01/06/2023 and flag it accordingly.

Thank you for your understanding,
Maxime.

Hey @jh23,

For me in R21.202, the delay is gone once you activate "Frame Dependent" parameter, both for editor interactions (see my previous posting) and an animation (see below). Am I overlooking here something?

0_1671203270269_ik_ani.gif

The large question is here probably what you would consider an animation. When you pile other expressions on top of this, which have incorrectly set up priorities, then you can run into the "needs-two-updates"-problem to evaluate a new state, regardless of Python being involved or not. I am not saying that this is "your fault", instead, I am just pointing out that the problem could lie somewhere else. It could also be that R20 behaves differently than R21, although this seems unlikely. As lined out before, R20 is out of scope of SDK support. The current official SDK support boundary is S26, and I currently have no access to a R20 license.

Cheers,
Ferdinand

Hi Kent, so far for the moment the viewport drop operation are more related to scene management rather than scene creation. By that I means except for an asset being loaded which create new elements (scene, object, material, etc...) other drag command are just here to act on the active object.

So regarding drag operation for file, only DRAGTYPE_FILENAME_IMAGE is allowed and an object should be selected, then a texture tag will be applied to this object and a new material with the texture will be automatically assigned. DRAGTYPE_FILENAME_SCENE is not supported.

For DRAGTYPE_ATOMARRAY it is only allowed for some particular categories, like layers to be applied on the active object or even materials for the same condition, so in any case the layer/material should already be part of the scene.

So for the moment the only workaround would be to create your own temporary asset and pass this asset to be inserted into the document. For more information about the asset API I let you read Asset API - Handbook but this is S26.0+ only.

Cheers,
Maxime.

The workaround is to have your scenehook priority over 2k. Remember this priority is reversed, the lowest, the latest to be called so you can delete what have been done by other scenehook. (if you are using the draw function)
The function will call scenehook beginning at LIMIT<Int32>::MAX to 2000 included.

This bug was introduced more than 10 years ago after fixing another issue. The code is old and would need a session of refactoring.

Cheers,
Manuel

Hey @kbar,

sure, no pressure and that all sounds reasonable, I was just offering options. And to be clear here: I am not optimistic for this being user fixable. But you never know for sure until you have tried.

Cheers,
Ferdinand

@m_magalhaes

Thanks for the response.

Might be able to use your idea as potential solution.

John Terenece

I would recommend against changing anything in the scene from within GetVirtualObjects(). Rather do it in Execute().

Cheers,
Frank

Thanks for the response Ferdinand, I thought that that would be the case.

John Terenece