Closed paulmelis closed 8 months ago
It is fine to update objects (set / change parameters) even during renderFrame, but the commit()
needs to be deferred. See e.g.
apps/ospExamples/GLFWOSPRayWindow.cpp
with various async calls to addObjectToCommit
; and the commitOutstandingHandles
happens right before the next renderFrame.
The time between ospCancel
and return of ospWait
cannot be used for that, because a commit may change datastructures which are still access by a render task (until that one checks the cancel-flag), which would result in a crash.
Thanks for the info. I seem to remember that setting a data object as parameter, without the data having been committed can cause problems, even if the object on which the parameter is being set isn't committed. Is that still the case? I.e. should data objects be treated specially, or can they simply be treated the same when it comes to deferred commits (as long as the order of deferred commits is correct)? And I guess that a shared data object cannot be altered during rendering, regardless of using a deferred commit?
Looking at that example, won't certain window events, like a reshape, trigger updates on the camera
and subsequent commit()
while rendering is active?
From the manual:
The use of either ospRenderFrame or ospRenderFrameBlocking requires that all objects in the scene being rendered have been committed before rendering occurs.
I guess I'm a bit unclear to what extent "all objects in the scene" applies? Only those directly set on the World, or also all objects reachable from those, like a transfer function, or data object. Are there any general guidelines for this? For example, looking at the ospray_testing builders, like GravitySpheres, it seems they don't commit any of the data objects, plus they do fully set up a world and return it. Yet in GLFWOSPRayWindow::refreshScene()
the world
is updated using a builder and committed, while the renderer
is also updated but then added to the list of objects to commit.
Hmmm, seems there's more undocumented constraints in handling commits, e.g. #437
Unfortunately, commiting the World is indeed currently necessary if an Instance/Geometry/Volume changed (spatially).
Unfortunately, commiting the World is indeed currently necessary if an Instance/Geometry/Volume changed (spatially).
Related to this restriction, does the same hold for lights? Or is a world commit not needed if only parameters of lights are changed? Changing the world light
list obviously would force a commit.
A question regarding this section of the docs:
Does "committed before rendering occurs" leave open the case of altering and re-committing objects in the current world after rendering has started? To be more concrete, I have an interactive render loop in which
ospRenderFrame()
is repeatedly called, but somewhere during that loop the scene might need to be updated (based on user input). Since canceling the current render might take a small amount of time I'd like to alter the current world and its scene objects directly after callingospCancel()
, but before waiting onospWait(OSP_TASK_FINISHED)
, in order to minimize waiting time. But I'm not sure if that's supported and/or leads to undefined behaviour.