The value of 'porgress' during the use of RenderDocument() is greater than 1.0
-
Hi,
I used the example code from c4d.documents.RendeDocument() in the document, which indicates that the values returned by progress are between 0-1.0. However, in my actual use, there may be some values greater than 1.0

This is my code, using Viewport Render with a frame range of 1001-1100
""" Copyright: MAXON Computer GmbH Author: Maxime Adam Description: - Render the current document with a progress hook to get notified about the current rendering progress. Class/method highlighted: - c4d.bitmaps.MultipassBitmap - c4d.documents.RenderDocument() """ import c4d def PythonCallBack(progress, progress_type): """Function passed in RenderDocument. It will be called automatically by Cinema 4D with the current render progress. Args: progress (float): The percent of the progress for the current step progress_type (c4d.RENDERPROGRESSTYPE): The Main part of the current rendering step """ print(progress) def main(): # Retrieves the current active render settings rd = doc.GetActiveRenderData() # Creates a Multi Pass Bitmaps that will store the render result bmp = c4d.bitmaps.MultipassBitmap(int(rd[c4d.RDATA_XRES]), int(rd[c4d.RDATA_YRES]), c4d.COLORMODE_RGB) if bmp is None: raise RuntimeError("Failed to create the bitmap.") # Adds an alpha channel bmp.AddChannel(True, True) # Renders the document if c4d.documents.RenderDocument(doc, rd.GetDataInstance(), bmp,c4d.RENDERFLAGS_EXTERNAL, prog=PythonCallBack, wprog=None) != c4d.RENDERRESULT_OK: raise RuntimeError("Failed to render the temporary document.") # Displays the render in the Picture Viewer #c4d.bitmaps.ShowBitmap(bmp) if __name__ == "__main__": main()Thanks for any help!
-
Hey @chuanzhen,
Thank you for reaching out to us. I will have a look at this problem, at the latest by the end of next week (31/10). We are aware that
RendeDocumentkeeps regressing, because there are a lot of render technology changes happening behind the scenes in the Cinema in the last releases.Hopefully, this is just a smaller bug, or a user error. But this could also be a more complicated thing. I will let you know at the latest by the end of next week.
Cheers,
Ferdinand -
FYI: I have not forgotten you. Will get to your topic tomorrow, hopefully

-
-
Hey @chuanzhen,
So, first of all, please excuse the delay. And thank you for the exemplary problem description, I almost booked this under "cannot reproduce" but you really hit the nail on the head with the conditions.
There is currently a bug in how the viewport renderer handles sending data to the progress hook. But this only happens when rendering a document from another frame than its starting frame. I am not yet 100% certain, but I am pretty sure this is a bug in the progress hook itself and not the viewport renderer. So, the bug could also appear in other contexts where a specific function of the progress hook is used. But so far the viewport renderer is the only renderer with which I could reproduce this.
There is not really anything you can do as a user, because there is a concrete bug. But the viewport renderer calls the progress hook twice each frame: Once with the correct progress, and once with a progress that is shifted by
renderFrameRange/documentFrameRangepercent. With some internal code knowledge we can simply say by the call index if the given progress is correct or not. But please understand that this is very much a hack.I will probably fix this, but I cannot fix this retroactively in 2025. This workaround could be useful for you but it is also a bit risky.
I have moved this into bugs.
Cheers,
Ferdinand"""Provides a workaround to get correct progress values when rendering a document with the viewport renderer. This workaround is specific to the case of this thread (viewport renderer + start frame other than the first frame). I know what causes the bug, but I am not yet sure if it is the viewport renderer which feeds the thing with wrong data, or of the thing itself is buggy. THIS IS A HACK USE AT YOUR OWN RISK! DO NOT REMOVE THIS WARNING. See: https://developers.maxon.net/forum/topic/16341 """ import c4d import mxutils doc: c4d.documents.BaseDocument # What basically happens for the preview renderer, is that it calls the progress hook twice for each # frame. The second call happens just two lines after the first call. Each first call provides # "correct" data, while the second does not. However, the first call is only made when RDATA_FASTAFX # is set to false in the render data (is the case by default). The workaround is then simply to build # history data so that we can know if the current call is an even (correct) or odd (incorrect) call. PROGRESS_STACK: list[float] = [] def PythonCallBack(progress, progress_type): """ """ # Just some stuff I used for debugging which only works in 2026 and above. # symbol: str = mxutils.g_c4d_symbol_translation_cache.Get(progress_type, "RENDERPROGRESSTYPE_")[0] # with open("/Users/f_hoppe/Documents/temp/render_progress.txt", "a") as f: # f.write(f"{symbol}: {progress:.2f}%\n") PROGRESS_STACK.append(progress) if len(PROGRESS_STACK) % 2 == 0: # Even call: correct data print(f"Render Progress: {progress:.2f}%") else: # Odd call: incorrect data, ignore, this is the same context as the previous one. pass def main() -> None: """ """ # c4d.ClearPythonConsole() rd = doc.GetActiveRenderData() rd[c4d.RDATA_FASTAFX] = False # REALLY make sure that RDATA_FASTAFX is disabled bmp = c4d.bitmaps.MultipassBitmap(int(rd[c4d.RDATA_XRES]), int(rd[c4d.RDATA_YRES]), c4d.COLORMODE_RGB) if bmp is None: raise RuntimeError("Failed to create the bitmap.") bmp.AddChannel(True, True) if c4d.documents.RenderDocument(doc, rd.GetDataInstance(), bmp, c4d.RENDERFLAGS_EXTERNAL, prog=PythonCallBack, ) != c4d.RENDERRESULT_OK: raise RuntimeError("Failed to render the temporary document.") if __name__ == "__main__": main() -
I have moved this into bugs.
-
F ferdinand moved this topic from Cinema 4D SDK
