Glad to hear that it might be simply handled. I hope it is before too long - integration between Va and Rhino is important to a user like me.
I think the potential for the pair is enormous.
Iâm working around Va limitations. To get back to accomplishing a Raytrace render:
From much experimentation trying to save a Raytraced render, Iâm not clear on the procedure and limitations of using View>Capture to do so:
-
Most of the time I succeed only in saving a blank image about 30k in size after View>CaptureToFile displays a render progress bar for what seems enough time to re-render an already-rendered Raytraced Viewport. (This means waiting out render times twice: If I attempt View>CaptureToFile on a Raytrace View in progress, I get a crash.) Despite many attempts, I have only successfully saved one image. The result matched the pixel dimension of the displayed view port. Iâm not sure what settings are necessary to accomplish that as I havenât succeeded again.
-
Is it possible to generate and save a Raytraced render that exceeds the pixel dimensions of the displayed viewport? Itâs possible to set (in Options) a âdpiâ of less than one, and to choose (in View>CaptureToFile) output pixel dimensions exceeding those of the viewport. Every effort to accomplish this has failed.
-
The âpreserve viewport proportionsâ checkbox in View>Capture doesnât lock the proportions of the two width and height input fields.
The problem you see here is a known bug for which no fix has been figured out yet. Iâm confident that Raytraced does do its thing as it should, but somehow the final step inside Rhino fails.
You should be able to get (gamma-uncorrected) images out by using TestSaveDebugImagesToggle once, then doing a capture with the resolution you desire. You should be able to find a file called RC_modal_renderer.png in the folder %TEMP% \McNeel\Rhino\V6 (copy&paste this line into the address bar of file explorer:
Here is how it looks like with the test command (which you need to run only once, it is a toggle):
Thanks Nathan. Yikes. Raytrace is doing a great and fast job of rendering, but⌠I hope itâs not too out of line to suggest that how it works and what the issues are could really use some documentation. Maybe that exists in some location Iâm not aware of, but without it I have spent a lot of time rendering and re-rendering with varying settings - thinking I must be missing something until you cleared up one thing after another.
In addition to your post above about capture, I found this, which confirms my suspicions about how to actually make CaptureToFile work, but only for a resoilution </= to the render windowâs.:
[Holo
Dec '17
viewcapturetofile and then use the viewport resolution and an iteration that is equal to or lower than the current one for the viewport.]
Also - it appears that the user has to wait out Raytrace render time twice in order to capture a render. Once to complete a render to the viewport before CaptureToFile can be sucessfully run, and again as part of the Capture process. Please let me know if thereâs some way around that. Fast as Raytrace is, these renders are still taking up to an hour each.
it wasnât at %TEMP% \McNeel\Rhino\V6
But I searched for the file name and found it in C:\Users\djhg\AppData\Local\Temp
Maybe this is because I used âcaptureToFileâ
This is part of the problem solved. But you can save me a lot more experimentation if you can explain the relationship between the OPtions>advanced>raytrace[etc] settings and those in the Capture settings window:
Sometimes the Capture Window opens with default settings needing adjustment, in which caseâŚ
- Inputting the fields in the latter is so unresponsive as to be unworkable, as the render is already attempting to render the view port. ED: The viewport render may have to be paused to do this.
- Locking the proportions displays unexpected results. ED: The viewport render may to be paused to do this also.
- The input fields seem unresponsive to any selections in the âscaleâ field, and needing to know how this relates to whatever dpi is set in Options seems particularly important.
And yet sometimes the Capture panel opens up with pixel dimension settings which appear to match the dpi setting in options as it relates to the pixel dimensions of the viewport window. Lately thatâs been the case, but itâs a fluke. I donât know how I accomplished it (but because I did, I donât have to deal with the three issues above - for now.)
Also
(Ed: Some of the below is addressed a post i have discovered about fireflies here: Raytraced/render . My project has quite a few reflective objects and bright light sources so Iâm now trying clamping and filter glossy. However I still have crashing if I attempt to change the vIew mode as per the next post.)
-
I think the saved rendered png is too speckly to be the image resolution I chose. Despite all the GPU processing time I think itâs simply upressed the viewport resolution image. (This might explain why the 3D processing module of the GPU was inactive for the Capture process.) (Ed: I tried rerendering/capturing again with the default dpi setting of 1 - dpi was set to .6 for the below - but the same speckles result.)
-
The viewport resolution render has been looking too speckly too. It looks like the sort of noise one gets in the lower-intensive AO settings.
Something must be off with the Raytraced Render, because A Rhino Render of the same scene at the same reolution looks like this:
Since advised 6 days ago (iâ;ve been at this every day alomst full time since then) to use Raytraced because itâs better at this than Render, Iâm hoping you can help me get it right.
btw, the ViewCaptureToClipboardâs resolution input fields were inaccessible. I can only set them in ViewCaptureToFile.
Before I attempted to generate a render of a higher resolution than the viewport display, I somehow saved the below render at a resolution matching the viewport. A segement of this rendering is below.
I thought the higher resolution renders shown at the start of this post would smooth out continuous tones, but itâs made them worse.
Having a handle on the speckles issue from some more research on the forum, I am discovering that the crashing issue can be circumvented if I wait a half hour immediately after opening a file - which was saved in Raytrace view mode - for a Raytrace Render to complete in the Viewport before changing the View Mode.
Because for this project that takes half an hour, Iâm hoping thereâs a way around it.
Ed: Actually several incrementally saved versions (including one I need) of this project actually do a âsoftâ crash on opening in Raytraced View Mode. (Black Viewport that crashes with an attempted View Mode crash, and doesnât render at all.) My video driver is up to date.
I would suggest to use the non-dialog versions of the commands _ViewCaptureToFile and _ViewCaptureToClipboard â -_ViewCaptureToFile and -_ViewCaptureToClipboard. You wonât get annoying waits for update of the thumbnail, especially taxing on large models as yours.
You donât need higher-resolution renders from Raytraced, but rather more samples. In the dialog versions of the commands you need to change the number of passes:
That will give more samples and over time give smoother results. For your room model Iâd go for at least 2500, maybe even more.
For the viewport you can also change the number of passes in the bottom right corner by clicking on it, enter a new number and confirm by pressing enter
Your project is indeed a bigger one, but it doesnât take 30 minutes on my machine. Depending on the available memory (RAM) you may run into the case where Windows is starting to put you data into the swap, after which everything will just slow down to a crawl.
I have received your crashdumps, and I have investigated them. As mentioned earlier I know the location it happens, I just donât know yet how it happens, and I donât see how it is possible it happens like that. For some reason in your case the render engine is still alive while its thread has terminated and exited - which seems impossible, since the thread shouldnât terminate until the render engine has closed down. I keep chipping away on the problem, though. Until then Iâm afraid youâll have to be patient when opening a version of the file with Raytraced as a saved viewport mode.
Thanks, but unfortunately the projects that crash with a black viewport never recover. The crash is permanent. So to clarify: some projects saved in raytrace mode open in a state of rendering and require the render to complete before anything can happen. Other projects saved in Raytrace mode open with a black Viewport and never render/recover.
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.)
Can you please share one of those files that never recover for you? Please do so again at Rhino - Upload to Support with nathan@mcneel.com as the recipient.
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.
Hi @djhg,
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 visualarq@asuni.com?
Regards,
Enric
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.
-Pascal
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.