The value of 'progress' during the use of RenderDocument() is greater than 1.0

chuanzhen

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!

ferdinand

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 RendeDocument keeps 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

ferdinand

FYI: I have not forgotten you. Will get to your topic tomorrow, hopefully

chuanzhen

@ferdinand

ferdinand

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/documentFrameRange percent. 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()

ferdinand

I have moved this into bugs.

ferdinand

Hey, almost forgot: We have fixed this, an upcoming release will contain the fix . We, however, went with a fix removing the offending call instead of fixing the incorrect progress handler method (which was the issue).

So, in other words: The workaround I showed here won't work in future versions, as the number of progress calls will be halved. Before one got two calls per update when rendering with the preview renderer: One for the correctly working image progress update and one for the buggy generic progress update. We have removed the latter.

Halving the number of calls is more technically correct, since it made no sense to call the progress hook twice per update but will break any plugins that relied on that incorrect behaviour.

Cheers,
Ferdinand