Posts made by r_gigante

Hi Lars, thanks for reaching out to us.

At the moment the latest version of Cineware SDK is 22 and it does not come with arm64 support.

Next version is instead going to support it.

Best, Riccardo

hi @Boony2000 , these are Visual Studio Intellisense errors which you can safely ignore. If they bother you switch the filter from "Build + Intellisense" to "Build".

Cheers, R

Hi @Boony2000, thanks for reaching out to us.

From R20 to R21, as expectable, changes took place in the API which led to adapt R20 examples to be compiled against the newer API. I recommend having a look at Changes in R21 in our documentation and adapt your code or the demo examples consequently if you copied them straightly from R20.

I'm also a bit puzzled by your last reply where you stated that errors were all fixed but you confirm that warnings are still around. Can you clarify what warnings look like? Can you also provide a little bit of context in your code where the warning it's likely to take place?

Thanks, Riccardo

Hi Thomas, I'm sad to confirm that at the moment there is no updated version of ResEdit for R23.

Cheers, Riccardo

@kbar said in Plugin compiled on macOS Catalina for R23, not working on Big Sur?:

@fwilleke80 I think setting the hardened runtime when you code sign solves the timestamp issue. I don’t set a timestamp.

codesign --force --options runtime --sign 'Developer ID Application: YOURCOMPANYNAME' 'sdk/plugins/yourplugin/yourplugin.xlib'

Thanks a lot Kent, for pointing this out!
The one below is the string I use which, as said by Kent, doesn't need the timestamp because of the hardened runtime.
codesign -f -s "Developer ID Application: <YOUR DEV ID>" --options runtime <binary file>.xlib

Documentation updated accordingly

Hi @JohnThomas, thanks for reaching out us.

With regard to your question, I confirm that what you see is correct since the deformer provided data is the tessellated representation of the original spline.

Best, Riccardo

Hi @chuanzhen thanks for reaching out us.

With regard to your question, I warmly recommend also thinking of using FindUniqueID and looking at the section BaseList2D Manual::Unique ID or to make good use of BaseLink.

Finally with regard to get the object, either you traverse and compare again the unique ID or, by keeping your BaseLink list updated when add/deletion operations take place, you can look into the list and retrieve desired C4DAtom.

Cheers, R

Hi Roger, thanks for the follow up.

I'm not here to discuss performances comparisons and again if you think there's a bug to report I again suggest the user to communicate with Maxon Support but I think it's fair to compare not only settings but also the final visual appearance.
Looking at the video posted and making screenshots of the different moments I think it's clear that numbers say something but appearance on screen says something different. IMHO it looks like as Maya without AA is more under-sampled than Cinema 4D without anything, as well as Cinema 4D AA-16 looks more over-sampled than Maya AA-16.

Hi roger, thanks for reaching out to us.

With regard to your observation I confirm that the reported behaviour is indeed linear except for the first entry: to give you a measure of the constant performance scale just multiply the pixel supersampling by the fps:

• 2 * 2 * 66 = 264
• 4 * 4 * 16 = 256
• 8 * 8 * 4 = 256
• 16 * 16 * 1 = 256

Finally, if you still think of a performance drop or a bug, please report to https://www.maxon.net/support.

Best, R

Hi @blastframe, I apologize for having left this thread unanswered for such a long time and I hope it still meaningful to you getting answered.

I confirm that Cinema 4D indeed stores such information, but the BaseContainers used are not accessible from the outside and you can't modify their data.

Can you provide us an example to reproduce the lack of consistency you mentioned?

Cheers, R

Hi @JaronW you don't have to open the project file, but rather the solution file you find in C:\Custom\Maxon\SDK\plugins\projects\plugins.sln

Cheers, R

Hi @JaronW, thanks for reaching out us.

With regard to your initial idea, I inform that it's not possible to port Cinema 4D native noise function to Houdini either from the API and, mostly important, the legal point of view.
With regard to the issue you ran into, be aware that SDK belonging to a specific Cinema 4D version (let's say R21) require specific ProjectTool and you can't make the ProjectTool expecting R21 SDK to work flawlessly with R23 SDK.
Last but not least the C4DNoise class has been designed to be used only in Cinema 4D plugins.

Best, Riccardo

@rsodre can you confirm that even using 2019u3 you still have issue? Have you had any feedback from USD guys?

Cheers, R

Hi @Leo_Saramago thanks for reaching out to us.

With regard to execution priority, as you've already spotted, the scene nodes are evaluated after generator because classic Cinema items can indeed be used as entry point for the node graph. With regard instead to nodes graph execution priority, nodes are executed left-to-right, or better said, a node is evaluated when its input ports have received the needed data from the “preceding" nodes!

Hope it answers your question.
Riccardo

@ECHekman said in Compiling material nodegraph to shaders:

I take it this also means its not possible to manually convert node ourselves?

Right.

Thanks @ceen for reaching out to us.

I'll make aware Maxon ppl responsible for the animation area about your request and leave it, for the time being, to community on offering support.

Best, Riccardo

Hi @ECHekman, thanks for reaching out to us.

With regard to your question, at the moment with current API, is not possible to traverse a node-based material shader graph and consequently to convert to other convenient datasets.

As said already in other threads, it's under our radar and we hope to share soon updates on this regard.

Cheers, R

Hi @delizade, thanks for reaching out to us.

The PythonTag associated to an object is evaluated, by default, every time Cinema 4D evaluates the scene and this can happen even if the object has not changed at all.

Finally, without more details on the PythonTag code, its design and the ultimate goal, I can only think about of the simple solution of caching the last userdata value in the PythonTag's container and compare, before running your tag's business logic, it against the value found in the userdata.

Cheers, R

Hi @delizade, thanks for reaching out to us.

With regard to your question I've a few considerations to share:

• external libraries are supposed to be located either under %APPDATA%/MAXON/{cinemaversion}/python37/libs, if they are referred only to a specific Cinema version or in %APPDATA%/MAXON/python37/libs if they are supposed to be seen by all Cinema(s) installed on your machine (see here for further info);
• c4d.EventAdd() adds an event to the Cinema 4D events queue, and it's not responsible for the tag to not be executed "infinitely". Consider that a Python tag is executed every time the scene is evaluated so the behaviour your mention is consistent with the code posted.

Given said that and with regard to
@delizade said in How to use/import another script file in Python tag correctly?:

've solved the issue
c4d.EventAdd() was added end of my external function script. I removed it and used it in tag script. I think after that line python tag was triggered again.

I can't see, guessing your code I've reported below, how you stopped the PythonTag to be executed "infinitely".

import c4d
import test

def main():
    print ("test")
    customCode.myFunction(op)

Cheers, Riccardo

@fwilleke80 Thanks for the follow-up Frank! In all the previous cases I always notarized without specifying the timestamp. I'll again and in case update the guide.

Cheers, r