Tweet
The RenderGlobalContext::time variable provided via the system notifications NOTIFY_PRE_RENDERFRAME and NOTIFY_POST_RENDERFRAME as a notification parameter is always wrong.
Bug 1 - wrong unit of measure:
The provided TimeValue should be in the standard 3ds max time unit of ticks (1/4800 of a second) but it is a frame number. For example in a 30 fps animation where each frame has a duration of 160 ticks (4800/30). The frame number 1 should have time=160 and frame 2 time=320 (V-Ray GPU sets it to 1 and 2).
To correct the value it needs to be multiplied by GetCOREInterface()->GetTicksPerFrame(). However, because of the next bug this is not a solution.
Bug 2 - wrong value outside the active time segment:
If the rendered frame is outside the active time segment (possible when specifying a Range of Frames or specific Frames to be rendered ) in 3ds max then the provided time value is wrong. It seems to be the current time of the time slider in frames (wrong unit). For example when the active time segment is 1 to 100 and rendering the range 120 to 150 then time is set to whatever position the time slider is at when starting the render. Same problem when specifying specific frame numbers to render.
Bug 3:
This a closely related bug. The value RenderGlobalContext::frameDur (frame duration as float) is also wrong. It should be in frames it appears but it is in Ticks. (Scanline has this value at 1.0 but V-RAY GPU sets it to 160.0 for a 30 fps animation.)
MAXScript bug and demonstration:
For frame 1 of a 30fps animation:
I use the time value in my plugin (psd-manager 5) to calculate the correct frame number to append to a filename via 3ds max function BMMCreateNumberedFilename. So the consequence of a wrong time value is quite severe. Using GetCOREInterface::GetTime() is not a way to get the correct time, because this will not report correct results outside the active time segment. I have a complicated workaround by counting frames and parsing all other time related values set in the Render Setup dialog Time output section - but this still fails when calling the renderer programmatically e.g. via scripting. This should be fixed in Next and 5.
Regards,
Daniel
- affects V-Ray 5 GPU and Next GPU (I tested mainly using 5.00.06 build 30453 on max 2021), did not test version 3 (because it doesn't have the callback)
- also affects MAXScript callback #postRenderFrame where time is also a provided parameter
- V-RAY CPU always provides the correct values (same as all other renderers I tested, Scanline, Arnold, RedShift, FStorm )
Bug 1 - wrong unit of measure:
The provided TimeValue should be in the standard 3ds max time unit of ticks (1/4800 of a second) but it is a frame number. For example in a 30 fps animation where each frame has a duration of 160 ticks (4800/30). The frame number 1 should have time=160 and frame 2 time=320 (V-Ray GPU sets it to 1 and 2).
To correct the value it needs to be multiplied by GetCOREInterface()->GetTicksPerFrame(). However, because of the next bug this is not a solution.
Bug 2 - wrong value outside the active time segment:
If the rendered frame is outside the active time segment (possible when specifying a Range of Frames or specific Frames to be rendered ) in 3ds max then the provided time value is wrong. It seems to be the current time of the time slider in frames (wrong unit). For example when the active time segment is 1 to 100 and rendering the range 120 to 150 then time is set to whatever position the time slider is at when starting the render. Same problem when specifying specific frame numbers to render.
Bug 3:
This a closely related bug. The value RenderGlobalContext::frameDur (frame duration as float) is also wrong. It should be in frames it appears but it is in Ticks. (Scanline has this value at 1.0 but V-RAY GPU sets it to 160.0 for a 30 fps animation.)
MAXScript bug and demonstration:
Code:
-- prints the time value of the just rendered frame to the listener -- time is parameter 13 in the array sent along the render notification callbacks.removeScripts id:#test callbacks.addScript #postRenderFrame "print(\"Frame time: \" + (callbacks.notificationParam())[13] as string)" id:#test
- VRay GPU will print "Frame time: 0.00625f" (which is 1/160)
- Scanline/VRay... will print "Frame time: 1f"
I use the time value in my plugin (psd-manager 5) to calculate the correct frame number to append to a filename via 3ds max function BMMCreateNumberedFilename. So the consequence of a wrong time value is quite severe. Using GetCOREInterface::GetTime() is not a way to get the correct time, because this will not report correct results outside the active time segment. I have a complicated workaround by counting frames and parsing all other time related values set in the Render Setup dialog Time output section - but this still fails when calling the renderer programmatically e.g. via scripting. This should be fixed in Next and 5.
Regards,
Daniel
Comment