I’ve loaded the file up this morning and tried at various resolutions and they all work. I don’t know what went wrong with yesterday’s attempt.
A new issue:
If a material has texture applied to the transparency setting, the ‘global’ transparency setting for the material only effects the color texture and not the whole material.
With 0% transparency set for material:
With ~75% transparency set (showing render view as well to see the difference):
Right Mouse-Button to select is the work of the devil.
I remember when Blender was doing a drive to be come open source. Oddly, I think I contributed $1 to the drive to open it. Anyway…
There was indeed a reason why Blender was a failure as a commercial product.
I have always felt that retaining a right-mouse button to select was an is one of the most arrogant things a software creator could do, to standardize on something that’s more difficult to use, just to be different. What a horrible and stupid legacy.
I can only hope that they live a life with light switches are in upside-down, faucets that are in backwards, toilets that flush by pushing up, and car horns that activate by pulling.
1 Like
@nathanletwory another issue to do with transparency textures when rendering in Cycles. Perhaps this is related to the previous issue.
This is when using viewCaptureToFile and I’ve got the background set to transparent. As you can see on this image, the transparency texture on the leaves is being rendered as black rather than as transparent. It is worth noting that this doesn’t seem to happen when an object is behind the leaves. On the image below, there is a white object behind some of the leaves and the transparency seems to be working when the leaves are in front of that (see second image).
@robinp, can you share the color and transparency textures you use for that leave? I don’t think I need a model.
I have been finding the controls to pause a raytrace viewport very fiddly and somewhat unreliable.
Often when I click on them nothing happens but because the machine is typically so laggy when Raytrace is enabled, I never know if the click has registered or not and whether a 2nd (or 3rd or 4th etc) attempt will just undo the pausing.
This is made all the worse when using it on my MacBook Pro 13" where I have the display settings set to ‘more space’. The control becomes crazily tiny and the only UI issue I have in any app when using my machine with ‘more space’ enabled.
I really think a much more bold and robust UI would be a big improvement. I also must admit I have no idea what the pad lock does.
Just look how tiny it is, you can barely see it:
EDIT: in fact, the target is so small and so close to the edge of the viewport that more often than not, I end up with this cursor and moving the toolbar / viewport divider.
Another issue. When using viewCaptureToFile (unsure about ToClipboard), the cancel button appears to do nothing. It leaves me with the only choice being to force quit or to wait for the image to be complete.
For small HUD I logged RH-53497.
Personally, I’d have thought it would be MILES better to append the controls to the side of the viewport title.
It would be more intuitive, in that it would obviously be associated with the viewport and display style.
The buttons would be much bigger.
It wouldn’t be a full width band across the image so it would probably obscure less of the image.
I could mock it up if my suggestion isn’t clear.
The suggestion is clear, no need to do mock ups 
I think a change like that will go more to a future Rhino release. I have logged the suggestion here: RH-53502
1 Like
Moved to Serengeti Mac category
Is this specifically Mac related though? I’ve been using it on windows as well and the HUD controls are pretty much the same? I would say though that clicks are registered more reliably on windows than on the Mac version.
Pretty please with a cherry on top, please? 
(If still possible with CPU and OpenCL in concert on MacOS v6?) Apologizes if I’ve missed this write-up elsewhere - searched.
Curious to try CPU + the dual AMD Radeon FirePro D500s in a MacPro6,1 w/8-Core Intel Xeon. (Crash bait???)
Using your past recommendations of:
RhinoCycles.DpiScale - 2
RhinoCycles.Samples - 250
RhinoCycles.UseStartResolution (set to True)
RhinoCycles.UseFastDraw (set to True)
I’m getting quite usable real-time viz results on this rig - thank you! With my control file I get appropriate interactivity and a usable result in 40 sec using CPU. (250 samples) OpenCL with both cards checked gets to 250 samples in 100 seconds. Might I see an overall corresponding percentage increase by leveraging both CPU and OpenCL GPU? (Assuming such works?)
Hoping to supplant Keyshot use for in-progress design real-time viz.
Thank you, Nathan.