Not sure how much ram you have, but my ram is the max for my machine: 16Gb.
Ok. That will take about an hour and 15 minutes. (Ed: Actually 2hrs20min.)
I have 16GB too, but remember that the usable size can be far less if you have many programs open - or multiple Rhino instances.
On further investigation to find one, I think I have found the cause of the unrecoverable crashes. It happens when I attempt to open a file which has previously been edited without Va (so the Va objects are blocks in the file) and I choose to run the Va plug-ins when given the option to do so. If I choose not to, the projects I have tested open and begin the essential-before-editing Raytrace rendering. I can then activate the Va plug-ins in Options. After that, from what I can tell without waiting a half-hour for that to stop, the rendering will continue and I assume the project will be stable after that. If you’d still like one of those files, please let me know. I assume it’s a conflict between Va attempting to reconcile itself with these loading
blocks and the load of the Raytrace rendering.
Yes, I’m savvy enough to know to shut down everything else except watching resource use with task manager and GPU-Z while the rendering runs. Often I have a few tabs open in Chrome to view the forum, but otherwise nothing else is running. Maybe we can assume that the difference between our machines is a slightly higher spec. graphics card and no bitmaps nor bumpmaps for your system to contend with.
By the way, when I’m rendering a Capture-To-File View this morning (at 2500 passes), I’m noticing that task manager tells me Rhino isn’t responding. But rendering progress is shown on the progress bar. I haven’t noticed if the "not responding’ message has been present with lower-pass rendering yesterday. I expect so.
During today’s progressing 2500 pass rendering, the Raytrace view mode doesn’t display in the viewport, by the way. It shows the last Rendered View though the display tab still shows Raytraced selected.
Enric, it’s probably worth mentioning that the only issue I was experiencing with Va and Raytrace (until I changed the glass material) was the low-transmission characteristic of the default window glass material. After I changed the glass material though, even changing it back to that default material did not keep the glass from matching the opaque material specified ‘bylayer’ for the opaque window elements.
I decided to see go back to see how workable the low transmissivity of the default Va glass assignment would be if I just added many more lights, but that gets tricky (though not impossible): please see my report in the immediately preceding post about what happens when I open a project with former Va blocks in it and activate Tibidabo and Va on open.
I don’t have VA, but it does sound like it is impacting the functioning of Raytraced to some degree. So in that sense I don’t need such a file, as we won’t have the same situation to test.
I’ll let the VA people investigate, if they need clarifications they can always ask internally (:
As long as the progress bar shows activity I wouldn’t worry about that.
It is normal that VisualARQ tries to audit the document if it contains VisualARQ data and it has been modified without VisualARQ being loaded. VisualARQ needs to make sure all information is still correct, like layers/linetypes/materials used in style attributes, surfaces that walls are extended to, etc.
But this process should be very fast, unless some VisualARQ geometry needs to be updated, but it shouldn’t take as much as half and hour, and in any case it shouldn’t crash, so there must be a bug in VisualARQ. We have recently fixed a bug in VisualARQ 2.3 (will be released very soon) when VisualARQ detects many new materials in the document. Maybe this bug is related.
Can you please send me one of these models to firstname.lastname@example.org?
I’ll send you a dropbox link.
To clarify: When this issue crops up, the file does not begin rendering. It displays a black viewport and can never be worked with. It’s a premanent crash. Only if Va is NOT chosen to load at the start does the file begins rendering for half an hour (in the case of this project) before anything can happen. That delay happens without Va being loaded and is a Rhino issue happening on opening a file which was saved in Raytraced View Mode.
The 2500 pass render, long as it is, yields pretty good results. I set FilterGlossy to .75 and both Clamp options to 1.5. Between RR and Rayt the results are quite comparable, by the way. The only significance difference is that the bumpy reflective tin frame in the upper right of the image goes very dark grey and unreflective in the Rayt mode, btw. Maybe from the clamping.
I think I have what I need now thanks- a sense of how to manage this sort of thins in Rayt. The big issue for me is Va’s incompatibility for now.
By the way, in both renderers I have to blast about 24 lights at an intensity of 100 to get what appears to be bright sun beams into that room. And a corresponding amount of diffuse light has to be pumped through each window to balance with it.
Make sure the surface normals (
Dir command) are pointing outward.
I will check when the current render is finished, but wouldn’t Rhino Render show them dark as well if they’re ponting in?
Ed: Yes, they’re pointing outward.
Can you post a screenshot of the material settings? Or tell me the name of the material, then I can check here, too.
Not sure I understand what you are after without a visual aid.
RR Render below (the settings above were created for this result, to resemble a shiny hammered tin frame) It’s in the dark corner but it still looks like bumpy reflective tin. This is what I was after:
Raytrace (it’s too dark):
To Get this Raytraced Beam of Sunlight at Sunset:
It takes this many sunlamps:
Only once I had the ‘key’ sunlight at approximately the right value (with all the directional lights at max intensity), with no other light sources, did I add diffuse light and fill to fill in all the shadows. (It’s tempting to wonder if it is the colour that’s dimming the lights, but for sunlight entering the room in the middle of the day in pure white, it took almost as many lights.) After that I still had to add lights to get the bright beam I was after. It’s okay - a person just has to keep copying a light in place until there’s enough light. it just seems strange that a single light source can’t go bright enough to register a result in the built-in renderer. It takes quite a few lights for the Rhino Render too. The Render View Mode of this scene looks like it’s on the surface of the sun.
I guess this takes us right back to the very first post in this thread, to which the answer might be “yes, the light sources are dim in relation to what’s required to simulate sunlight entering a room. Just keep adding them.” Or maybe I should be starting with the ambient light and then adding the sunbeam. I believe that’s how I did it for the RR render, but that took around this many lights to create a sun beam, too.
I’d be happy to learn a better technique with these renderers if there’s one you can recommend…
The material you have there to simulate (battered) metal isn’t a good choice for
Raytraced. I created a better metal based on the Rhino Metal material with a better bump map:
BatteredTin.rmtl (86 KB)
The bump map you used in your original doesn’t really work well, since it is really just a diffuse map.
Further, here is a trick to allow stronger sun from the default calculated version so that you don’t have to use that many helper suns. Add a button to your toolbar, draw a simple bitmap icon for it with the tool offered
and have a left-click and a right-click action. For the left-click use the command
_RhinoCycles_SetAdvancedOptions _SunlightFactor=30 _Enter for the right-click use
_RhinoCycles_SetAdvancedOptions _SunlightFactor=3.2 _Enter
If you want to experiment with the strong sun left-click on the button, then start
Raytraced. To go back to the default strength (3.2 factor) right-click on the button.
Here is a quick render with sun factor set to 30 (but 10 may already be enough strength increase) and the new material in use on the frame:
I’ve been able to open the file without any problem in VisualARQ 2.2.3 and Rhino 6.8 (both are the latest public versions). The file is opened as fast with or without VisualARQ loaded, and the Raytraced viewport starts after the file is opened. The only issue is that some materials on VisualARQ objects are not correct when VisualARQ is loaded, because of the known issues between VisualARQ and the Raytraced display mode.
Did you try saving them and reopening in Raytrace View Mode? That’s when I have problems. OTOH, I have found several files which weren’t opening yesterday morning were opening yesterday afternoon, so this may remain a mystery.
Thanks. Made an alias too for sun strength.
I hope most materials can do duty in both renderers.
I think the material I posted will work fine also in Rhino Render.