Well, in this case the double is being passed to an external library (the renderer) right after this code, and the library expects a double.

Now, here comes a friendly rant: I have read the code style guide you linked to, but I'm actually not quite sure how to interpret it or what to think of it. To me it appears to be a mix of things that could potentially be important, and things that are just internal stylistic recommendations. And it makes no distinction between the two.

Take these three examples:

-"Always start a new line after the for statement."'
-"Do not write to global structures from a thread."
-"Do not use external libraries (e.g STL or BOOST) unless absolutely necessary".

The first one is clearly just a preference from MAXON (and I don't see why I should follow it if I prefer to structure my code in another way...). The second one seems to be a serious warning, and it sounds likely that violating this rule could cause a bug. For the third one, I have no idea. Maybe it is just a suggestion as well, and maybe linking my plugin with STL or BOOST could cause bugs. The docs do not say.

The recommendation for using MAXON datatypes also kind of falls into this category: I can't tell from the docs if it is just a style recommendation from MAXON, or something that could actually have an effect on my code.

To me, the code guide would be much more useful if it only listed things that are actual rules (or at least clearly separated rules and important advice from purely stylistic recommendations).

Cheers
/Filip

Hi again,
Thanks for your input! I have found the solution now:

The issue was not the camera field of view, but how I calculated the bounds of the viewplane (image plane). C4d fits the aspect ratio of the final render resolution into the size of the viewport in a specific way, that I reverse engineered. Here is the code for my solution, in case anyone else has the same problem:

double f=double(resolution[1])/double(resolution[0]);
double f2 =double(renderdata_resolution[1])/double(renderdata_resolution[0]);
double c = f2 / f;

double screen_window[4];
screen_window[0] = -1*c;
screen_window[1]=-f*c;
screen_window[2] = 1*c;
screen_window[3]=f*c;

In the above code, "resolution" is the resolution, in pixels, of the viewport and "renderdata_resolution" is the resolution we would have if rendering to the picture viewer.

/Filip

Hi!
In my renderer plugin, I use the following code to get the camera FOV:

Float aperture = camera->GetAperture();
Float focus = camera->GetFocus();
float horizontal_fov = (float)RadToDeg(2 * ATan(0.5*aperture / focus));

This matches perfectly when rendering to the picture viewer, but when I render to the viewport there is a slight mismatch in the camera FOV.

Any suggestions on how to get the correct camera field of view for viewport rendering?

(I should add that I am determining render resolution by the size of the buffers obtained in the renderer videopost, like this:

VPBuffer* colorBuf = vps->render->GetBuffer(VPBUFFER_RGBA, NOTOK);

maxon::Int32 const xres = colorBuf->GetInfo(VPGETINFO::XRESOLUTION);
maxon::Int32 const yres = colorBuf->GetInfo(VPGETINFO::YRESOLUTION);

)

"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

Hi!
I am writing a custom renderer, implemented as a videopost plugin. In the execute() function of the videpost, during VIDEOPOSTCALL::INNER, I traverse the document obtained from vps->doc to extract the scene information (geometry, shaders, lights, etc. ) that gets sent to the API of the renderer.

All works fine when I render to the picture viewer, but when I try to do viewport rendering I get crashes.

During the traversal, I do in some cases perform some operations on the parsed document, such as AnimateDocument(), ExecutePasses() etc. I am thinking that one of these might be the culprit. So, here is my somewhat vague question: Are there any operations that are forbidden to perform on vps->doc during viewport rendering? (But are allowed during picture viewer rendering)

Thanks!
/Filip

@s_bach OK, thanks!

@s_bach said in Node Editor API for R21?:

Hello,

your assessment is correct. The Cinema 4D R21 SDK does not provide an API to edit node materials.

best wishes,
Sebastian

Are there possibly any functions for traversing existing node graphs?

/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 all!
I am implementing a recursive traversal of a scene, visiting all real and virtual objects in the hierarchy, closely following the recursive function outlined in the documentation of BaseObject::GetCache().

The docs also say this about safety: "Use the above routine only if the caches are already built. It is for instance not safe to use it in a command plugin since the user can have stopped the scene redraw and the building of caches."

Is it safe to call this routine if I have built the caches myself using ExecutePasses(), even if called from a command plugin?

/Filip