This topic lines out how we deliver support and which topics are eligible for support. At the end you will also find a brief overview of what makes a good technical support question.
Forms of Support
Maxon Computer delivers support to third party developers in multiple forms:
- Cinema 4D API Forum: Ask questions about everything Cinema 4D API related, ranging from a simple Python script to the most complex C++ solutions.
- Cineware API Forum: Ask questions about everything Cineware API related.
- Zbrush API Forum: Ask questions about everything ZBrush API related.
Users can also reach out to us via our contact form, private messages on this forum, or
Please note that email and private message support requires a valid reason such as confidential data which must be shared, or NDA bound information which must be discussed. Direct support is not a shortcut to better support, you will receive the same support no matter where you apply. Support must be public by default so that all users can benefit from our answers.
Each morning, we discuss all support requests internally, so that users can benefit from the knowledge of all SDK group members. A support request will usually be answered within two workdays, in complex cases we might need longer to find a solution, but we will inform you about that.
Users who require enterprise support should apply for the Maxon Registered Developer Program where we also provide other forms of support.
Scope of Support
Technical support provided by the Maxon SDK group is bound by the following two criteria.
Full support and bug fixes are provided up to one major version back. So, when the most recent product is Cinema 4D 2024.1.0, we provide full support up to Cinema 4D 2023.0.0. Full support means in this context that we write code examples specific to the API version you use, and debug code with that specific application version you want to target.
Reduced support is delivered for Cinema 4D APIs up to
R21.0. Reduced means that we cannot provide bug fixes for these versions anymore and that we might refuse to write code examples for that specific version you are using, and instead provide a code example for a later version, leaving it up to you to migrate that code. Reduced support does not mean no support, we will help you as much as we can, but we cannot guarantee you that we will solve every problem you might have with five years old software.
Every other version is out of scope of support. This also does not mean that we won't answer your questions when you want to know something about the Cinema 4D R18 API for example but this will be limited to things we 'just happen to know'. We will not debug these older APIs for you, nor will we write any code examples for them.
In general, all support requests must be related to our APIs. We cannot provide support for the math and computer science that stands behind them. As an example, asking for how geometry transforms are carried out in the Cinema 4D API is a valid support request. Asking us how matrix multiplication works or what transforms are is not.
- We cannot provide support for third party libraries.
- We cannot provide support for code that violates technical requirements of our APIs such as the thread safety of certain methods.
- We cannot provide support on learning C++, Python, or one of their popular third-party libraries.
- We provide code examples but we do not provide full solutions or design applications.
- We cannot debug your code for you and instead provide answers to specific problems.
- We will not reveal non-public functionalities of our APIs.
- We reserve the right to refuse support based on our support rules or internal decisions.
Support Topic Rules
Additionally, these rules exist for all topics in support forums.
- Singular Question: The initial posting of a question topic must contain a singular question. Do not ask ten things at once, that makes it extremely hard to answer things. Break up your questions into multiple topics. Asking follow-up questions is allowed but they must be bound to the initial subject.
- Singular Posting: Users often discover additional information or even a solution before we can answer. Please consolidate your questions into a singular posting by editing your last posting. It is otherwise not only for us but also for future readers hard to follow the posting. Once we replied to a topic you are of course then free to reply in a new posting. But when you have follow-up questions, all information should again be consolidated in the most recent posting until we answer.
- Singular Subject: From all this follows that a topic must have a singular and sparse subject tied to a specific problem. 'My Nodes API Questions' is not a valid topic as it splits up into too many subtopics. A valid subject could be 'accessing node attributes' or 'traversing a node graph'. One could for example first ask 'how to get the name attribute of a node?' and then ask a follow up question about 'how to get the icon attribute too?'. This specifically applies to plugins, just because you have two problems with one plugin does not mean that they should be asked in the same topic.
When asking a question, you should follow these rules as it will increase your chances of getting good and fast support.
- Briefness: Your posting should explain in the first sentence where your problem lies. Avoid writing lengthy paragraphs about tangential subjects. This goes hand-in-hand with the one question rule of our support topic rules. Keep your questions short!
- Repeatable: Your claims or problem should be repeatable for us. In most cases this means posting executable code which demonstrates your problem, with the emphasis being on executable. We should be able to paste this code into an editor and then run or compile it without having to write code ourselves. When you just post snippets, this usually means that we will not run your code, as we do not have the time to invent all the code around it. Ignoring this also comes with the substantial risk that you do not post the code which contains your actual mistake/problem.
- Sparseness: Your problems should be sparse, or in other words you should spend some time on boiling down more complex problems. When you, for example, are writing a plugin with which one can create trees with physics and all sorts of fancy things, and you run into a problem, you should spend time on removing as many fancy things as possible, so that we have an easier time helping you. Code examples should only very rarely have more than one thousand lines of code.
- Illustrate/Contrast: Images and videos illustrating a problem are not required but can help in complex cases. But illustration goes beyond images and videos, it is also about what you would expect. When there is a feature which returns the value
[0, 2, 3, 4]and you think that is a bug, telling us that you think that
[0, 2, 3, 4]is buggy output might not be enough. Tell us why you think this is buggy and contrast it with what you would consider correct,
[0, 2, 4, 6]for example. This also applies to all other questions. When you want to do task X, tell us exactly what you currently can do, and then contrast it with what you want to do and by that illustrating the missing parts.
When you are not at liberty to share your code/project publicly, you can also send it to us via
Below you can find an exemplary posting which illustrates all four points. The example highlights the core problem in the first sentence, builds a contrast between, and has a short code example which is executable on its own.
is it possible that the method
c4d.utils.Neighbor.GetPointOneRingPoints()is (currently) bugged?
The documentation states that it will return "the points that are attached through one edge to the given point". The problem occurs on points which are either edge or corner cases of a non-closed surface. Below is a simple example to illustrate the problem. The orange points are the inputs for the method, the green points are the output, and red points are points not included in the output - but I would expect them to be included:
- An edge case. We get the two green points but not the red one.
- A default case. Everything is fine here, we get four points.
- A corner case. We only get the green point but not the red one.
One can reproduce the behavior in the console on a similar topology (and different point IDs) with the following code:
>>> from c4d import utils >>> nbr = utils.Neighbor() >>> nbr.Init(op) True >>> nbr.GetPointOneRingPoints(26) #edge case [52, 27] >>> nbr.GetPointOneRingPoints(39) #default case [65, 38, 40, 13] >>> nbr.GetPointOneRingPoints(25) #corner case 
Reporting Bugs & Crashes
When you do not have only a question but also think you have found either a bug in our API or there is a pesky bug in your code, it is important to be as precise as possible when describing the bug, while keeping things sparse. Let us assume that we want to document the fictional issue that the built-in Cube Object will generate a pyramid as its geometry once its Segments.X parameter takes the value
Always accompany crash reports and bugs with precise information regarding the Cinema 4D and OS version you are using. When you report viewport drawing related crashes, please also report your GPU and its driver version.
Fig. I: The Cube object behaves weirdly once its Segements.X parameter is set to the value 42. The Cube object is here a tangible stand-in for a plugin you might develop or an API feature in one of our APIs.
When you think you have found a bug, you must describe it in the following form.
# A mandatory brief description of the essence of the problem, must be less than 500 characters. Short description # An optional illustration of the problem. [Image] # A mandatory step-by-step list to reproduce the problem. Be precise here! Reproduction * Step 1 * ... * Step N # A mandatory list of outcomes that are the result of the reproduction steps. Put here things you consider 'wrong'. Result * Result 1 * ... * Result N # An optional list of Cinema 4D versions where you have tested the problem/bug. OK means there is no problem. # NOK means "NOT OK", i.e., there is a problem. Versions * [OK/NOK] Version 1 * ... * [OK/NOK] Version N
For our cube object example, a bug report could look like this:
The Cube Object generates pyramid-like geometry when the Segments.X parameter of the Cube object is set to the value 42. Reproduction: 1. Open Cinema 4D in the Model layout. 2. Add the Cube object from the object palette. 3. Set the *Segments.X* parameter of the Cube object to 42. Result: 1. The Cube object resembles a pyramid object. 2. Changing the *Segments.X* parameter has no effect anymore. Versions: OK 2023.2, Windows 10 NOK 2024.0, Windows 11
Important points are:
- Do not write essays in the problem short description: We usually will not read large walls of text. In complex cases you can follow up the short description with a detailed description, but most of your work should go into sufficiently describing the problem in one sentence.
- Rather provide precise reproduction steps: Bugs often occur in a very specific context and things you might consider irrelevant are not. In this case, the precise context is the Model layout and creating the object from the object palette rather than from the menu. Your efforts in precision should go into this category.
- Observe Results: Bugs often have more than one effect, try to observe and describe as many side effects as possible. In this case, not only the geometry output is bugged, but also the triggering parameter once the bug has been triggered.
- Include Scenes: Include an example scene when possible and sensible.
the Maxon SDK Group
This topic deliberately has been left open for on-topic questions. Due to the informative nature of this topic, it will be strictly moderated.