[Bf-cycles] realtime preview

Mohamed Sakr 3dsakr at gmail.com
Mon Apr 18 07:36:31 CEST 2016


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160418/7cba7720/attachment.htm 


More information about the Bf-cycles mailing list