Hey @bojidar, So, I spent again some time on trying to debug this, and this time manually stepped through the deserialization of 1053286, i.e., your material type. And I am not really any wiser to what is going wrong there. This could be related to a change one of developers made for 2024 to GeAliasGoal, a precursor to what you see as a BaseLink in the public API. But when I look at how it steps through the chunks of the hyper file for your material, I do not really ever see that parameter being deserialized. I think this is more a Tech team than an SDK team issue as they own that part of our APIs. I would have to ask you to file a bug report via our bug tracker for this. Please make sure to include: Reproduction steps. The file. You can also include your code, but that is of less importance. Please give me then also a note when you have done this, so that I can attach the relevant people and make sure that they get access to a license of your software. I could also file the bug report for you, the problem would be then however, that you could not see it, as you can only see your own reports as an MRD. I.e., you could not take part in the comments/discussion attached to the issue. I would recommend that you submit it yourself. When you run into problems, ask Deyan, or reach out to us via mail. Cheers, Ferdinand

Thanks for the reply, @ferdinand. I can confirm that below syntax doesn't work. I still get the same error. AdditionalLinkOptions=%(AdditionalOptions) /DELAYLOAD:"mydll.dll" I'll see what alternatives I could use.

Hey thanks for the report, I indeed fix one issue with the InsertLayer but in your case it was another one, sadly there is no workaround for you (except the one you found). The fix will be provided in the next release. Cheers, Maxime.

Hey @peter_horvath, Just as an FYI, you are currently limited by the issues lined out in the video, i.e., you will have to use LoadFile at the moment to get a meaningful particle simulation (or let the document be cloned by RenderDocument). The Simulation team has already fixed that issue, it will be delivered with the next major release of Cinema 4D, i.e., 2025.0.0. In case you want to test that fix, I would recommend moving this discussion over to the beta forum. Cheers, Ferdinand

Hi @pyxelrigger there is no real way to execute a script outside of Cinema 4D without Cinema 4D. The only option is to execute c4dpy which is a complete Cinema 4D instance run as a python interpreter. For more information about it, please read c4dpy manual. Note that you have the same limitation as a standalone Cinema 4D so you can't execute multiple c4dpy instance at the same time or they need to be in different folders. Except that note that tkinter does not come by default with Cinema 4D, so you will need to install manually and don't really officially support, so it may or may not works, but from our personal experience in the SDK team, it should work. Cheers, Maxime.

Hey @ThomasB, Thank you for reaching out to us. Without your code we cannot really help you, we are not the oracle of Delphi There are many things which could go wrong in your plugin. But in general what you are doing is correct; add a dummy point object with your snap points to your cache, when you want to introduce special snapping points for your custom generator object. Snapping onto the points of the returned geometry should work out of the box (but snapping sometimes struggles a bit with deep caches). There is however only limited support for adding special snapping points, as it is not really intended to add you own snap logic in that manner. The snapping module both in Python and C++ does not allow you to implement your own snapping logic, you can just read some data. You should also keep in mind that the snapping is an older part of Cinema 4D which has its flaws. You should check if your problem also does occur when you try to snap onto the converted cache of your object (current state to object). If that is the case, you know it is not something your plugin does, but simply the fact that the snapping struggles with that specific geometry/scenario. Cheers, Ferdinand

Thanks, buddy! It worked. To be honest, I never really understood what Message(c4d.MSG_UPDATE) was all about, and now ExecutePasses is new to me

Hey @spedler, only the simulation team can speak to the exact details here, but my guess for why it is how it is, is the pesky cpu-gpu upload penalty. If you would upload pre sampled data, or even worse sample on the CPU, this would really slow down any GPU advantage you have. I doubt that this is any different for the GPU part of Xparticles. One could think about plugin access for CPU-sims but most users are likely never going to use that if they can avoid it. The simulation device is set in the simulation scene and by default GPU. [image: 1713257356914-08c2f454-96fb-4d92-9adc-8247e47fc44f-image.png] The more realistic thing would be that we provide some compute shader like access. I could go here into the details of the new particles and the challenges of providing such compute shader access to them but that would be the famous "counting chickens before they hatch". Let's first see how many users and which user type (scripting technical artist vs. C++ development professional) wants a deeper API access for particles. Cheers, Ferdinand

Good to hear!

Hi @ferdinand, thanks for the feedback, I've got it working with your suggestion. The method B was correct but the undo part was wrong ( the undo step was applied on the original objects instead of the new ones, thus leading to a mess when performing an undo). I also added the bit part to keep new objects folded in the OM. Here is the code : # CopyDeformers import c4d doc = c4d.documents.GetActiveDocument() def main(): doc.StartUndo() objs = doc.GetActiveObjects(c4d.GETACTIVEOBJECTFLAGS_SELECTIONORDER) if len(objs) >= 2: # Get the last selected object active = objs.pop(-1) # Get the deformers deformers = [i for i in active.GetChildren()] # Copy deformers to selection if deformers: for o in objs: for d in deformers[::-1]: dcopy = d.GetClone(c4d.COPYFLAGS_NO_BITS) doc.InsertObject(dcopy, parent=o) doc.AddUndo(c4d.UNDOTYPE_NEW, dcopy) o.SetBit(c4d.BIT_MFOLD) doc.EndUndo() c4d.EventAdd() if __name__ == '__main__': main()

@ferdinand Thank you very much! I got the min and max distances also working with your input! I used the code example from the docs to traverse through the DeformCache and it worked instantly

Hi Adam, thanks for the update and the workaround!

Hello @hSchoenberger, Sorry, but this is a C4D SDK question! It is NOT about the Octane SDK. "How can I list all installed renderer plugins in C4D with their version?" Although you have put your sentence into quotes, that was not what you asked, your questions were: Is there any way to get some information about renderer plugins? I want to get the version of the Octane plugin. So how I can loop through all plugins loaded and get some information from the plugins like the version? And I answered that: There is no public interface with which you could get the version of a plugin. And when plugins provide version information on their own, you must ask their vendors about that. You can access the flags a plugin has been registered with BasePlugin.GetInfo, the disk-level is in-accessible for you. You can detect installed render engines by looping over all video post data plugins and check if they have PLUGINFLAG_VIDEOPOST_ISRENDERER set (this assumes that the to be detected render engine sets this flag on registration - which is usually unavoidable as you otherwise cannot hook in the render system of Cinema 4D, but there might be 'rogue' render engines out there which side step things). import c4d doc: c4d.documents.BaseDocument # The currently active document. op: c4d.BaseObject | None # The primary selected object in `doc`. Can be `None`. def main() -> None: """Called by Cinema 4D when the script is being executed. """ plugin: c4d.plugins.BasePlugin for plugin in c4d.plugins.FilterPluginList(c4d.PLUGINTYPE_VIDEOPOST, True): if (plugin.GetInfo() & c4d.PLUGINFLAG_VIDEOPOST_ISRENDERER): print (plugin.GetName()) if __name__ == '__main__': main() # Example output for a vanilla installation. Physical Redshift Viewport Renderer Cheers, Ferdinand

@ferdinand Oh wow! Thank you so much for letting me know about Keenan Crane, as I was not familiar with him. I am in awe of the exhaustive list of tools he and his lab have published. The Globally Optimal Direction Fields paper seems indeed to be exactly what I am looking for. I was also surprised to see that I had already skimmed the Youtube video of the paper back in December. Thank you so much @ferdinand for this invaluable piece of information. Time to dive in! Cheers!

Hey @JACK0319, Thank you for your issue report, I have fixed it and it will be shipped with the next release. Cheers, Ferdinand

Thank you, it works perfectly!

Hi Ilia, At this point this seems a bit over my head, but it seems to be what I need, thanks! Dan

@czt_306 It looks realy cool!

Hey @mogh, I know that you did not meant any harm and the word hijack was a bit strong - which is why reworded that before you answered. But topics should remain focused on a singular thing, the specific question of the original poster, rather than being a collection of questions from multiple people which roughly align with whatever broader topic they see embodied in a thread. Cheers, Ferdinand