Hi there good folks of the WIP users,
(in general, but even more so specifically those awesome users who put Raytraced through the wrangler for me!)
So, again lots has happened, and I’ve been a bit lazy in keeping you all up-to-date with the current progress. I’m going to skip all the good stuff, and focus on the rough edges. I’m sure most of you will recognize the potential of this… ‘diamond’ 
Quality settings
With the latest WIP you may have noticed that the Render Quality settings don’t seem to do anything. Well, that is quite correct. At the moment a Raytraced session will always attempt to sample your great scene 10 000 times (ten thousand), with quite a good amount of bounces for all ray types. Now, with the responsiveness problems of the Rhino UI while Raytraced is running this may not be very helpful for those who suffer said responsiveness problems. Until the next WIP victims should try to restrict their usage to rendering only when really output is needed - suboptimal, but to remedy that RH-38176 is created. I should have a render options command working with the next WIP that overrides all automatic settings. Once set these should be used always. If I manage I’ll have a go at saving such settings per 3dm for the Raytraced plug-in as well, but having a working settings overriding command is priority, saving settings is a bonus.
Freezing of Rhino UI
The Raytraced viewport integration drawing has been sped up significantly, but it strongly looks like this awesome gain has exposed some nasty issue with the very low-level message pump. For some this results in dialogs not popping up in front of the Rhino main window, for others it means that the entire UI becomes unresponsive. The biggest problem is that it is hard to reproduce reliably. For instance on my dev machine I sometimes do get dialogs that open somehow behind Rhino main window - alt-tabbing brings them in front, but it is never really reliably reproducable, making this all the harder to track down and fix. But rest assured we’re looking into this with @andy. (RH-37955 and RH-38136
Sub-object material changes
Due to some confusing logic in the core that manages the so-called changequeue on which Raytraced builds its integration material changes don’t work properly. On i.e. a box with a main material and one side set to a second material changing properties of that second material don’t get propagated properly through the changequeue. This core tells Raytraced to do the wrong things, making Raytraced look like the bad guy. I have found that Raytraced is doing exactly as it is told, and I’m currently in the progress of teaching the changequeue improved logic, so it can tell Raytraced the right things to do. RH-37862
Custom materials
Due to the performance and sub-object material problems this custom material fixing keeps getting pushed further into the future. But rest assured that I am aware of this: RH-37339.
What next
I am working hard to get the issues mentioned above fixed ASAP. Once those are out of the way I’ll be working on improving the usage experience, including ‘little’ things as the HUD, plug-in settings, custom view settings, object wireframes not moving faster than the raytraced view, and so on. If you feel you must, check the never ending list of issues.
What can you do to help?
Keep using Raytraced as much as possible, reporting any issues you find. It’d be helpful if you checked the never ending list of issues to see if I anything you find has already been reported, but if you aren’t sure, just report anything you find. I’ll probably reply with links to existing issues if necessary. And please take some time to post your cool renders to our Gallery (and tag them with cycles or raytraced ) on discourse (:
Happy pixel coloring!
p.s. already big thanks for those users who already frequently provide me with feedback in private messages. Feel free to do that also in public!
edit p.p.s: Here is a list of resolved issues.
