Let me test that with the plug-in here locally. If that were the case normally I’d expect such blackness to happen also with
Raytraced mode. Does that happen for you too?
Nathan, can your repeat this problem?
My first Idea was also to test with the raytraced mode, but that works fine. After that I tried MockingBird realtime viewport and that fails here.
I see there is a problem with that plug-in, I am investigating.
Not sure yet why it fails.
But I’ll revisit all the MockingBird examples. Thanks for the heads up!
Have you had time to find some conclusion about it?
Only that there is a lock happening in the example code. I know where, but not yet why.
Thanks for the answer and sorry for late reply. Can you tell me at which part do you see the lock, so I can check for similarity in my code?
The problem is happening with opening channel on the RenderWindow. I’ve not been able to investigate further in the past two weeks, but it is still on my list. Thanks for the reminder.
Here I don’t have the lock at opening channel, but the final error is similar.
I don’t have this error it if I don’t create a renderQueue object, otherwise I have it even if it doesn’t do anything.
In you MockingBirdViewport sample if I comment out the lines in MockingRender.cs
// cq = new MockingChangeQueue(plugInId, docSerialNumber, rhinoView);
// cq.ChangesReady += Cq_ChangesReady;
and also this
The problem disappears. ButIf I only create the renderQueue (uncomment only this):
cq = new MockingChangeQueue(plugInId, docSerialNumber, rhinoView);
The problem appears again.
I’ve been trying to figure out what is going on here, but with the sample from
I am no longer able to reproduce the hang. I realized that I was working of an old repository that is no longer in use. With the sample from above I get as one would expect. Upon switching to
MockingRealtimeMode the viewport gets properly instantiated, along with the change queue. The viewport goes from black to full white in 50 samples, and the command-line shows output as expected. I did this while using the 6.16 SRC with a debugger attached. I think that maybe the problem here is access to the command-line - in reality one should not be printing anything there, and I guess with a debugger attached there seems less potential for lockups.
So could you please test on your side by taking out all usages of RhinoApp.WriteLine() from the change queue implementation in the viewport example?
I have commented out the RhinoApp.WriteLine lines, but unfortunately I still have this full black after I start a new scene. (tested in release and debug mode too)
My Rhino is Version 6 SR 15
Do you have the same code as here?:
That is the old repository. Please use the code from
result is the same here. Can it be your newer Rhino version?
Hmm, unlikely, I was testing before also on 6.16 when I saw problems - but that was due to running my old repository code. I’m compiling a release build of the sample and test again.
@marton.parlagh before you test the plug-in please ensure it is actually loaded by checking in
Tools > Options > Plug-ins. If it isn’t right-click it and choose to load.
edit2: this plug-in doesn’t autoload when choosing the viewport mode from the drop list. Since it is a sample plug.-in I didn’t want it to autoload on Rhino startup, nor does it load when switching to the mode in a vp.
Ok, I have done the loading from pref/plugin and the result is the same.
I wait till 50 steps
switch back to wireframe
and new scene
Oooh, I have been looking at the wrong problem!
@marton.parlagh, first of appologies for getting sidetracked by looking at the wrong problem. In the end it was a small bit I had forgotten was necessary. I’ve committed and pushed a fix to the sample code:
The missing bit is cleaning up the ChangeQueue instance. That has
to be explicitly done, otherwise the display pipeline hangs like you noticed.
Ohhh, yesss - thank you!!!
Sorry it took so long. It must have been the heat… (anything above 20°C is too hot )
I hope you can make good progress now. The most complete example is of course the code for the
Raytraced mode itself…
Probably a lot to take in, but once you’ve got the basics under control using the viewport sample you’ll be able to understand better how
A post was split to a new topic: Custom RenderEnvironment not updating correctly in Raytraced