Topics created by Filip

@ferdinand said in GvNodeMaster::Execute() returns error:

Since you do your own stuff, this could for example fail in the DL_TERMINAL node you implemented in addition to some of the init stuff going wrong.

I have confirmed that the error seems to come from my own GvOperatorData()-plugins (shader nodes). When I delete all my own nodes in the graph and only use the build in c4d xpresso nodes, then GvNodeMaster updates correctly. I will look into this, but now I know where to look! We can mark this as solved for now.

"I can of course also just have a look at it, but I will not be able to run your project to see and tell you why it fails exactly"
At this stage, I was just looking for general feedback on how and when the Execute() function was supposed to work correctly, i.e., if it needed to be called in a special context or similar. This is also why I did not post detailed code initially. I don´t fully agree that detailed code is always needed to discuss an issue, even if it of course sometimes helps in clarifying things! Anyway, thanks a lot for the good support, it is really helpful and I appreciate the availability of this forum - it really helps!

Best regards
/Filip

"PS: There are also the copy buffer methods on GvNodeMaster if you want to preserve connections, copy multiple nodes at once etc.:"
-That looks like it might be exactly what I need! Thanks a lot!

Hello @Filip ,

without further questions or postings, we will consider this topic as solved by Friday, the 11th of august 2023 and flag it accordingly.

Thank you for your understanding,
Maxon SDK Group

Great, thanks a lot for looking into this and for the detailed explanations!

Now I know better what my options are! I am marking this thread as "solved".

Best regards
Filip Malmberg

Hi @Filip,

okay, thank you for the clarification.

Cheers,
Ferdinand

@r_gigante said in SDK for node based materials, status?:

With regard to your question, we confirm that at the moment there are no news concerning this topic but, again, we are aware of the relevance of the request and it will be delivered accordingly to our product development plan.

Thanks!
On a related note: Is there any statement from MAXON on the future of the old xpresso-style node system?

We are looking to implement a node-system in our plugin, and since API for the new node system is not out yet we may consider using the legacy xpresso API instead. On the other hand, it would not be a good idea to invest resources in this if that part of the SDK might be deprecated and replaced with the new node system.

I realize that you may not be able to provide much info on the roadmap here, but any information that you can give would be super helpful for making this decision!
Cheers
/Filip

Thanks for confirming that this approach looks correct!
"never use NULL to check your pointers against to or to assign it to your pointers: rather prefer using nullptr cause while the first comes from a define the second is a built-in pointer type."
-Thanks, noted!

"with regard to the last implementation, why not using:"
-Because we only want to check the next object (obj=obj->GetNext()) if "inCache" is true. Otherwise, the function would not only check the object passed to the function and its cache, but also all subsequent objects on the same level of the hierarchy.

@r_gigante Thanks for confirming. We will try to reverse engineer the filenames based on that data.

Cheers
/Filip

Hello,

That's a more wide discussion about how to code. We can say that as long as it compile and your plugin is working, your code is fine.

Cinema 4D is provided for both Windows and OSX, so differences can be introduces. Using our datatype guaranty (unless a bug) that your code will work the same on both OS. (of course there's always exception, don't jump on them 😉 )
Same goes for external librairies.

Another example is our thread/job system, some external librairies can interfere with cinema4D in a badly way.

Cheers,
Manuel

"I warmly recommend cloning the whole document on a temp doc"
Thanks, I'll try working on a clone. I had the impression that the document passed to the videopost was already a clone of the original document, but perhaps this is not the case for viewport rendering?

"With regard to your issue, I'm a bit confused by the need you have to call BaseDocument::AnimateObject() or BaseDocument::ExecutePasses() when the VIDEOPOSTCALL in VideoPostData::Execute() is VIDEOPOSTCALL::INNER. Actually when you're in this step, you can already access and query the VolumeData to retrieve all the relevant information about the scene elements (like RayObject, RayLight and so on)."

-We have some good reasons for working with the basedocument directly, rather than the data provided from the VolumeData.

"Consider that this approach is sub-optimal since you're going to double the resources used to store the current document."
-OK. This should be fine for our purposes. Our plugin actually provides custom rendering commands, that are the preferred way of rendering with the plugin. The videopost functionality is added as more of a convenience in our case, to make the plugin work nicely with things like viewport rendering, material preview etc.

/Filip

@m_magalhaes said in Safety of GetCache() after ExecutePasses()?:

The scene will be update and you can retrieves the caches.

Great, thanks!

/Filip

@m_magalhaes

"when you are using RenderDocument, you can set the RENDERFLAGS, so it can be virtually "anything""
-Yes, that makes sense. Thanks.

"Can i ask you why you need to know if a render have been started using the RenderDocument() function ?"
-In a custom renderer, I am exploring the possibility of sometimes (depending on user selected options) sending the rendered images to an external image viewer (not the c4d picture viewer). In this case, if RenderDocument() is called, we would still want to render to the c4d bitmap to make sure RenderDocument() correctly returns an image.

Anyway, as I said, this was a bit of a long shot. Since this appears not to be possible, I will explore other options.

Thanks!
/Filip

Hi again,
It turns out that the issue was not related to Cinema 4d itself, but was caused by how I handled the connection to the 3rd party library. You can mark this as solved.

Best regards
/Filip