wouldn't you want to use it with multi threaded render be sure all threads get shut down? this is just a guess as i have no experience with the abort callback on a custom renderer, but i think halfdan wrote the example and i personally think he is a pretty smart dood.
s On Tue, May 1, 2012 at 4:25 PM, Nicolas Burtnyk <[email protected]>wrote: > Yeah that's the doc page that got me worried/confused. > > The critical section indeed seems completely unnecessary as well. > > Thanks for your help. > > > On Tue, May 1, 2012 at 4:16 PM, Ben Houston <[email protected]> wrote: > >> I assume you are referring to this: >> >> >> http://softimage.wiki.softimage.com/sdkdocs/cb_Renderer_Abort.htm#Rzmcb_Renderer_Abort >> >> Currently we are not locking and unlocking the scene, but may be we >> should be. I will look into that. I guess if the user modifies the >> scene during our data query, they could get inconsistent results, but >> it is just a preview so I am not sure that is the end of the world >> unless it causes a crash. I must admit I am not that clear on what >> scene locks are. >> >> I think the critical section around a boolean is unnecessary >> personally. A boolean is already atomic generally and you don't need >> perfect synchronization for an abort process. >> >> -ben >> >> On Tue, May 1, 2012 at 7:10 PM, Nicolas Burtnyk <[email protected]> >> wrote: >> > That part I get. I guess I'm confused by some of the statements in the >> docs >> > about calling UnlockScene before checking the abort flag and by the >> example >> > code which seems to use a simple abort flag in some cases and a Win32 >> Event >> > in others. >> > >> > >> > On Tue, May 1, 2012 at 3:56 PM, Ben Houston <[email protected]> wrote: >> >> >> >> A very easy way of using it would be to set a global boolean >> >> somewhere, such as "bool gAbortRequested" on start of render to >> >> "false". Then check it periodically on your render thread. When >> >> abort is called just set gAbordRender to "true" and eventually your >> >> renderer thread will check that variable, notice it is "true" and >> >> stop. It does take a bit of engineering to make sure it can stop >> >> without memory leaks. >> >> -ben >> >> >> >> On Tue, May 1, 2012 at 6:52 PM, Nicolas Burtnyk < >> [email protected]> >> >> wrote: >> >> > Understood - so given that I should use it, how do I use it properly? >> >> > >> >> > >> >> > On Tue, May 1, 2012 at 3:48 PM, Ben Houston <[email protected]> >> wrote: >> >> >> >> >> >> You can technically ignore it, but if your render is long, user's >> will >> >> >> get annoyed with it and complain. Thus for the best user >> experience, >> >> >> you want to pay attention to it. >> >> >> -ben >> >> >> >> >> >> On Tue, May 1, 2012 at 6:15 PM, Nicolas Burtnyk >> >> >> <[email protected]> >> >> >> wrote: >> >> >> > Hey guys, >> >> >> > >> >> >> > Does anyone have any experience with the Custom Render Abort >> >> >> > callback? >> >> >> > I'm confused by some statements and the example code in the docs. >> >> >> > >> >> >> > The docs say that in response to the abort callback we should halt >> >> >> > further >> >> >> > processing as soon as possible and return CStatus::Abort from the >> >> >> > Process >> >> >> > callback. >> >> >> > What is an acceptable "as soon as possible"? Obviously we can't >> check >> >> >> > whether the abort flag is set for every line of code. >> >> >> > Are there functions that will fail or hang if used after Abort has >> >> >> > been >> >> >> > called? Anything else we should be aware of here? For instance is >> it >> >> >> > technically legal (albeit not nice to the user) to ignore the >> Abort >> >> >> > callback >> >> >> > and just keep on extracting data and sending fragments to Soft? >> >> >> > >> >> >> > Also, I'm confused by this statement in the docs on the Abort >> >> >> > callback: >> >> >> > "The >> >> >> > optimal way of doing this is to unlock the scene graph first, and >> >> >> > then >> >> >> > check >> >> >> > whether the flag has been set, in which case it should stop >> >> >> > immediately, >> >> >> > otherwise then lock the scene graph again and carry on." What is >> the >> >> >> > purpose >> >> >> > of unlocking the scene graph prior to checking the abort flag? Why >> >> >> > not >> >> >> > just >> >> >> > unlock if we find that the abort flag has been set? >> >> >> > >> >> >> > Finally, in the ColorRenderer example in the docs, why is the >> abort >> >> >> > check >> >> >> > that's done after sending each new fragment waiting on an event >> >> >> > rather >> >> >> > than >> >> >> > simply calling isAborted()? >> >> >> > Why the distinction here? >> >> >> > >> >> >> > Thanks! >> >> >> > >> >> >> > -Nicolas >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Best regards, >> >> >> Ben Houston >> >> >> Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom >> >> >> http://Exocortex.com - Passionate CG Software Professionals. >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Ben Houston >> >> Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom >> >> http://Exocortex.com - Passionate CG Software Professionals. >> >> >> > >> >> >> >> -- >> Best regards, >> Ben Houston >> Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom >> http://Exocortex.com - Passionate CG Software Professionals. >> >> >
