It is probably because it is 01:50 in the night here in Finland, but I don’t get what you mean here. Can you post a cropped part of the rendering with Raytraced viewport that shows what you mean?
This was done in Cycles. All the lights are the same, cut-and-pasted. Some are have highlighted surfaces; others don’t. I think that Cycle’s doesn’t think that these need the last surface pass.
It appears that Rhino 6’s stock (non-Cycles) raytracer doesn’t suffer from the glass sorting issue; the viewports do. Did you get a chance look at the fine I sent? Or get some rest?
Note: White bar on left was caused by poster’s mistake.
I haven’t figured out why you see that much darkening of the emissive lights.
But for rendering purposes in your model there are quite many objects that can and should be blocked and instanced. That’ll take memory pressure down, and make conversion of the model for Raytraced faster.
Well, I can block the lights the vertical pillars, the windows, and some of the ceiling metal, but given my experience on another project. I don’t expect a huge performance gain.
Still, this project is texture-heavy and it has a lot of surface area. It also needed more point lights than I would have liked for the indirect lighting in the interior. Blocking it may have more of an effect, in this one. As an experiment, I will try it.
I appreciate you looking into this. And you have most of what I am working on. It’s almost done, now. The "can’t use environment maps because they go fullbright " bug is harsh. So, is the rending problems in the preview.
Also, you have many light objects, and those make it hard in Rendered mode - which is what you see prior to the first Raytraced result, and when manipulating the view in Raytraced you see actually really poor performance because of the OpenGL drawing. As a test you can turn off the light primitives, switch to Raytraced, and then rotate the view. Especially with UseFastDraw in the advanced settings turned to true the response is much improved.
If you feel you want more contribution of indirect lighting then you can up the diffuse bounce count. By default it is at 2, but 4 already gives much more light from indirect bounces.
Hi, I wanted even for the indirect lighting. In the real original diner, they used florescents.
I am still having transparant sorting issues in OpenGL views. The separator is glass.
I’ll let @jeff investigate the OpenGL transparency problem you’re seeing.
Going back on my original suggestion to do block instances, I think that actually what makes more sense is to extract render meshes for some of your complex objects and join them together when they are all assigned the same material.
For instance under the roof lids you have some intricate objects, many of them. It makes conversion already much faster if you extract the render meshes and join them into one:
The same really with any part that has repetition in and are currently represented by many objects. If they are assigned the same material just extract render mesh and join them into one object. Move your original objects to a separate layer that you hide - in case you need to tweak the geometry later…
The same I’d do for the seats: cushions where possible extracted render meshes and joined together into one, etc. For Raytraced it will make a huge difference when the amount of separate objects is decreased clearly.
I’ve been working hard to I blocked most of the repetitive, things except for those. I will do those too, and snip the edges so they don’t interfere with linear trim. I just need a break for a while.
When I block them, I will lower the mesh quite far, as they only need one triangle–per triangle. Though, I don’t want to start messing around with separate meshes in this drawing because it greatly increases that needs to be done, as well as negating the purpose of working with NURBS.
Thank you for looking into the transparency issue.
Understood.
That is why I suggested to keep the original NURBS geometry on hidden layers.
I am merely giving hints to make everything more performant in Raytraced, you are free to ignore everything I say 
Ignoring everything you say isn’t going to help : )
Anyway, this is what I have blocked so far. I am going back through lowering the meshes just before the round stuff gets really pointy.
Fortunately, almost everything is there. It needs work on textures and lighting.
At some point, I could upload a version of what I have. I’ve done optimizations such as the second image. Since I took that screenshot, I’ve replaced almost any polysurfaces I could with extrusions, and then blocked those.
When you are ready with your model please upload again at rhino3d.com/upload?to=nathan@mcneel.com if you want me to look again.
For the interior you probably can do some more cases of simple spheres with Cycles emissive set to hidden to add more light to your scene without impacting OGL drawing.
Thank you. I will upload it after the roof trim is been low-poly meshed, trimmed, and blocked.
The problem with the interior lights, is that their surface isn’t lit. The emission light casting seems to work fine. The problem is: some emissive surfaces are dark because they are behind glass. Since, I blocked them, I think that none of them work, and the blocks are snapped to the original places.
It wold be a small nightmare, but perhaps the windows could be removed and then their surface photoshopped in, after.
The light globes are made from revolved surfaces. I wonder if that might be the trouble. I will try to make them using cylinders, filleted spheres with their tops trimmed.
(Pascal, I did check the dir, and they are good, closed polysurfaces.)
Using blocks for everything slowed down the prepare for realtime retracing by a large amount, perhaps a 3x slowdown. I am not pleased.
Am I correct in guessing you blocked a small bit, then copied that small bit many times? This is why I later on also said that it would be good to make larger mesh objects out of them as well.
Indeed many, many small objects is also going to slow down the conversion.
In my tests I had meshed the lights and windows as well, those worked just fine. The windows I had meshed, then joined into one big window mesh.
Since you’re doing now a drawing for rendering only, I’d really go for as much mesh-based, joined where possible, blocked where useful - keeping the original geometry on hidden layers as much as possible. That is what one would do for big render projects (intricate scenes or animations) as well. It is then not about what is absolutely correct by the number, but what looks correct.
But I can help more when I see your file 
I will send the updated file, when I get home. Last night, while it was switching to rendering mode, I just crashed out Rhino, and went to sleep.
After a while, you may find that one type of everything is well enough to keep track of. I don’t mind specifying custom meshes from things, as long as they are with the NURBs.
In this case, this is only a visualization. It’s not the core of what I use Rhino for, but others use it for this purpose, such as the new Blade Runner movie.
For users, it might be handy if there was show-triangles toggle, so we can see what it has to deal with.
But, no, I absolutely do not want to manage separate meshes and geometry. One of Rhino’s strengths is that we aren’t supposed to have to deal with micromanaging triangle meshes–especially on a project as small as this. There’s only about 1,000 objects in this, and my adoptive 12FPS degradation is kicking in the OpenGl views. Well, at least it works.
[Back in the day, I used to make 5,000 objects a month, with drawings which often had 15,000 objects. Granted the roofing metal is a bit much, but people are using Grasshopper for buildings.]
On the roofing metal, I was unable to get the triangle count any lower, and it still look what it’s supposed to look at with the mesher. I admire the art (deco) that went into these buildings.
And that’s what I working to emulate. It still needs a background, and some texture work. I have 5 hours into making a single brick texture, and it still needs about 3 more hours to even it out, and replace the bricks that cannot be used. The others textures go quick.
And that’s what I am leaning toward.
I am so excited about the surface lighting, but I might have to change it back, but I understand that it is an experimental feature.
BTW, there is an inefficiency/issue that Cycles renders it’s first viewport first pass without applying mapping. It’s possible that it was missed, but at these speeds, it can be noticed.
-
The OpenGl render has a transparency bug.
-
Environment maps cannot be applied to a materials without the material going fullbright. It’s broken. The materials no environment on it. That’s why there is a big billboard behind the camera. I like the idea of a global environment, but we should be able to load a environments on materials, as well.
-
There is a great discrepancy between any of the rendered modes and Ratraced, as far as gamma and mapping.
-
There are minor mapping issues in Rendered mode.
-
We really need Raytraced/Cycles to be more responsive in navigating the camera on medium and large files. We don’t need many pixels to do it, but the computer shouldn’t hang for a minute after budging the camera.
There are some changes that could done to help the Raytraced mode be more responsive.
-
If the timer can be updated, the GUI could instead be read, but it’s not. Three or four seconds pass raytracing passes–with no GUI input.
-
For anything but the smallest projects, While the menu-bar is open, the raytracer should halt. Why would I need it to continue, when I am likely to change what it’s doing?
I’m not sure I understand this - what timer are we talking about?
Do you mean to say that the Rhino UI should suspend Raytraced working while a menu is opened? And either resume if nothing changed the scene, or restart?
edit: btw, I downloaded Diner 126 scene, but haven’t had time to properly look into it yet.
There’s a little timer that states how long the Raytracer is working on the scene, found at the bottom of the Viewport when Raytracing is enabled.
Yes, indeed, I would like it to suspend while menus, such as the “File” menu is clicked on, and the viewport menu, too. I would like it to suspend while I have a mouse button down in the viewport, so I can pan and rotate the scene. It would be totally okay, if when it can’t handle what has to be done, that it shows a wirefame, so I can pan, and then I let go, and then it restarts…you know, in realtime.
Somehow, it knows if a material event happens, such as changing the reflectivity, but being able to pan and rotate the camera would be easier than changing modes, moving the camera, and then changing back.
~
I did an experiment, and rebuilt the interior lights to make as many surfaces as I could without revolved surfaces, but that didn’t fix the bug where the interior light’s surface is not lit if it is behind glass.
Lastly, I am not completely convinced that that “Throttle” Cycles user setting actually does anything.