[Bf-cycles] realtime preview

Mon Apr 18 10:15:53 CEST 2016

It's just a deadlock. You can open up your debugger and check the thread
the application it's locked on then see who might be holding that lock.

On 18 April 2016 at 07:36, Mohamed Sakr <3dsakr at gmail.com> wrote:

> Hi,
>
> sorry for opening this up again.
> now I got an OpenGL context.
>
> what is the call order to update? right now what I do "and freezes
> everything":
> 1- try lock scene mutex
> 2- update scene
> 3- unlock
> 4- session reset
>
> I also tried pause and unpause, but the same result "everything freezes".
> any idea?
>
> cheers,
> Mohamed Sakr
>
> On Thu, Nov 12, 2015 at 6:31 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:
>
>> yea, there is no ogl context to work on.., thanks a lot for clarification
>> :)
>>
>> On Thu, Nov 12, 2015 at 3:44 PM, Nathan Letwory <nathan at mcneel.com>
>> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> On 12/11/2015 14:58, Mohamed Sakr wrote:
>>> > Hi Nathan,
>>> >
>>> > thanks a lot! :) there are 2 things that I need to understand: 1-
>>> > if I change the scene data "so the scene is always there" ,
>>> > cancel/restart the session performance penalty is ok? (I'm forced
>>> > to background = true)
>>>
>>> There is indeed a performance penalty. I suppose I should make a
>>> screencast tomorrow when at the desk so you can compare what the
>>> performance difference is. It wasn't that bad, but now that I managed
>>> to get background=false working properly I have to say that it does
>>> feel really nice.
>>>
>>> What is the reason you can't render using background=false? No access
>>> to a good ogl context? This used to be the case for me too, but once I
>>> managed to get the ogl drawing to work (session->draw()) it made also
>>> scene updating much more simple.
>>>
>>> > 2-
>>> > https://github.com/mcneel/RhinoCycles/blob/5a04498c14779533395bbb59b64
>>> 9e33dec4e0f0d/RenderEngines/ViewportRenderEngine.cs#L200-L202
>>> >
>>> >
>>> I kinda don't understand how do we wait here? assuming you call
>>> > everything from a separate thread, the main thread will handle
>>> > messages and the separate thread will be locked in rendering?
>>>
>>> The Renderer() function gets started in a separate thread indeed.
>>> Based on the status of the ChangeQueue (custom implementation in
>>> ChangeDatabase.cs) will, in this old case of background=true
>>> rendering, cancel the session, which will allow the session rendering
>>> thread to join back into the rendering loop of Renderer().
>>>
>>> As said, it works, and it isn't all that too bad, but esp. for larger
>>> scenes there will be a noticable pause for the cancel, data upload and
>>> restart.
>>>
>>> /Nathan
>>>
>>> >
>>> > cheers, Mohamed Sakr
>>> >
>>> > On Thu, Nov 12, 2015 at 2:31 PM, Nathan Letwory <nathan at mcneel.com
>>> > <mailto:nathan at mcneel.com>> wrote:
>>> >
>>> > And hi again,
>>> >
>>> > I wanted to illustrate what I'm doing with some links into the
>>> > source of RhinoCycles. It might help see how it could be done. (And
>>> > I'm assuming here I understood Cycles session management properly
>>> > ;)
>>> >
>>> > Links interspersed in message below.
>>> >
>>> > On 12/11/2015 14:19, Nathan Letwory wrote:
>>> >> Hi,
>>> >
>>> >> On 12/11/2015 13:55, Mohamed Sakr wrote:
>>> >>> Hi,
>>> >
>>> >>> this crashes at some point, any ideas about the general logic
>>> >>> here? note that I'm working with background = true
>>> >
>>> >> With my work on RhinoCycles integration I have found that
>>> >> modifying a running render session with background=true isn't
>>> >> very easy to do. You'll have to first cancel the running session,
>>> >> push your changes, then reset and restart.
>>> >
>>> > Not so long ago I was still using background-rendering in
>>> > RhinoCycles. The update and render cycle look like this:
>>> >
>>> > https://github.com/mcneel/RhinoCycles/blob/5a04498c14779533395bbb59b64
>>> 9e33dec4e0f0d/RenderEngines/ViewportRenderEngine.cs#L150
>>> <https://github.com/mcneel/RhinoCycles/blob/5a04498c14779533395bbb59b649e33dec4e0f0d/RenderEngines/ViewportRenderEngine.cs#L150>
>>> >
>>> >  This worked together with a check for changes (and possible
>>> > upload) here:
>>> >
>>> > https://github.com/mcneel/RhinoCycles/blob/5a04498c14779533395bbb59b64
>>> 9e33dec4e0f0d/RenderEngine.cs#L150
>>> <https://github.com/mcneel/RhinoCycles/blob/5a04498c14779533395bbb59b649e33dec4e0f0d/RenderEngine.cs#L150>
>>> >
>>> >  - From CheckFlushQueue() you can see that I cancel the session
>>> > before starting upload to Cycles.
>>> >
>>> >> If you render with background=false you can first pause the
>>> >> session, then lock, update, reset and unpause.
>>> >
>>> > Simple start for the render session in RhinoCycles happens here:
>>> >
>>> >
>>> >
>>> > https://github.com/mcneel/RhinoCycles/blob/master/RenderEngines/Viewpo
>>> rtRenderEngine.cs#L153
>>> <https://github.com/mcneel/RhinoCycles/blob/master/RenderEngines/ViewportRenderEngine.cs#L153>
>>> >
>>> >
>>> >
>>> >
>>> > Up until this basic session, scene and their parameters have been
>>> > created and connected.
>>> >
>>> >
>>> >
>>> > CheckFlushQueue() checks if there are any changes in the
>>> > changequeue, which at this point will be true. Synchronize() will
>>> > pause the session, push the data, reset and unpause.
>>> >
>>> >
>>> >
>>> > Similarly, while the interactive render session is running I
>>> > periodically check for new changes, which I do in the class
>>> > governing that:
>>> > https://github.com/mcneel/RhinoCycles/blob/master/Viewport/RenderedVie
>>> wport.cs
>>> >
>>> >
>>> , more specifically in the UiUpdate() function here
>>> > https://github.com/mcneel/RhinoCycles/blob/master/Viewport/RenderedVie
>>> wport.cs#L125
>>> <https://github.com/mcneel/RhinoCycles/blob/master/Viewport/RenderedViewport.cs#L125>
>>> >
>>> >
>>> >
>>> > Hopefully this helped.
>>> >
>>> > /Nathan
>>> >
>>> >
>>> >
>>> >
>>> >>> cheers, Mohamed Sakr
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________ Bf-cycles mailing
>>> > list Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>>> > http://lists.blender.org/mailman/listinfo/bf-cycles
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________ Bf-cycles mailing
>>> > list Bf-cycles at blender.org
>>> > http://lists.blender.org/mailman/listinfo/bf-cycles
>>> >
>>>
>>> - --
>>> Nathan Letwory
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJWRJegAAoJEKtfN7KsE0Tt/GUIAI/CcPe+OMShNHuh3snxWCi3
>>> 2tLmG1Fq/7vjHUY7GiAqrYcYXlCc6uze2kQZgLFqdMGMqIiPCfRs5wcgwE0ImJWL
>>> UHsKTXKwsBLHCNxeJFswAGniUzIg4w/2KR8mm6iB76DlUANoLO2WIIHXaPXk4hX9
>>> 7SmvlUXjF6xGs+P9ZVbXyqTCgGRfYP+DmPOx2RxQMpXBti6Lrepsj4NjciVKnSB3
>>> jhCl7B7wdy/68vwIfQ+lp5V7CxpHtlHcjqS1KLUV9dkRhIaIUStU1Qwd+A0zvc7R
>>> 7Yjj2hml1joCCKgd5ZjfzXArZwHspQXHBJdnpG3+XaHEKSD3HiMRhpjs3361fHM=
>>> =9lj0
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> Bf-cycles mailing list
>>> Bf-cycles at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>>
>>
>>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160418/d5f6309e/attachment.htm 