I rendered an image today (V7 WIP), it took over 30 minutes to complete (see screenshot). I then ran ViewCaptureToFile from the perspective view in Render display mode, I got a superior image in less than a few seconds using this method ?? Also using the render window some of objects rendered incorrectly (the leaves are a mess) ?? This was using V7WIP on a 16" MBP. Final images output attached too.
can you post the file and your textures?
Kyle, thanks for chipping in, appreciated . Files too large to upload here on Discourse, have bunged them in GoogleDrive folder, link below. Some of the assets in the scene are from Quixel Megascans, and the textures, so high quality and quite heavy, saying the the files are only 150mb, so not huge. There is a V6 & V7 version in there, the above was from V7 WIP. I tried a ViewCaptureToFile with the V6 file, with Raytraced display mode and transparent background, it took around 10minutes and the output I got was a blank white image ??? 🤷:weary:
Please Click To Access Files
your plant material has a huge displacement value on it… shut off the displacement channel completely and it renders fine-
view capture to file here completes in 7 seconds. (transparent background)
this is a render with the plant displacement fixed.
please run systeminfo in rhino and post the result here.
Turned off displacement, ran View Capture to File, Raytraced, was taking forever , system info attached. This was using v7 WIP yes ? Question if I may Kyle, is there a quick way to identify if there is a huge texture/displacement/bump map causing an issue in a file ?
Milezee System Info.txt (6.5 KB)
Did you use Mac Rhino for your test? Thanks.
Just opening the v7 chair takes a bit over 5GB of RAM. Using _Render after opening bumps that memory usage to 12.7GB. Maybe not the fastest on my macbook pro, as I have only the CPU to render on ~3 minutes for 8 samples (the denoiser will be so useful here once it is publicly available). Resolution with just opening and rendering is 1846x1368. Considering the swapping, the usage of a dual-core CPU I’d say that is pretty much expected and quite an achievement.
If you then switch to Raytraced, you’ll get another huge memory hit, and doing a ViewCaptureTo* gives another big hit. I didn’t test, but I wouldn’t be suprised if that went up to 17-18GB of RAM usage.
Now, I understand the craze for 4K and larger textures. But you have to understand that such usage comes with a cost: memory usage.
Take for instance your orange. It is in your render the tiniest item, you hardly will ever be able to see the details on it. 4k textures is pure waste for that. Same goes for all the smaller items. All the 4k textures are pretty much a waste of resources in all possible manners.
Compare for instance with the lady texture. That is only 262x798 pixels. Yet the lady appears nicely detailed in the render.
I would suggest using much smaller textures. Use of 4k and up is necessary only for close-up shots, or where the object surface is a considerable amount of the final image.
A final word on displacement: for it to work properly you need a dense mesh. Displacement works by displacing the vertices of the geometry. Test for yourself: add a simple plane. Add a PBR material with a texture in the displacement channel - use 2d checker with black and white for clearest effect. You’ll see nothing useful happens. Now make sure your simple plane gets meshed as dense as possible. You’ll find that more geometry equals better displacement according the displacement texture.
takes mine about 10 minutes and the picture image has a black plane around it. Just ran another without transparent background, again around 10 minutes for 100 samples and it gave me a blank white image ?? 🤷🤷:thinking:
Not sure why you’re seeing these problems, but I wouldn’t be surprised if the heavy textures are partly to blame here.
Are you using the GPU or the CPU as your rendering device?
Anyway, on my Macbook pro I get this for _Render with the Rhino Render, which I recommend over ViewCaptureTo* due to memory pressure and OpenGL usage. The _Render window sidesteps both. Attached a 3-sample render of your file with transparent background. That should render just fine, but maybe using ViewCaptureTo* is interfering with proper realization of the transparency channel in OpenGL.
In V6 the GPU (Radeon Pro), in V7 the CPU , same result, the picture image shows a black plane around it if I use View Capture To File with transparent background
Especially in v7 I’d use _Render over _ViewCaptureToFile - both should work, but this file is heavier than necessary due to the textures. It means a lot of extra work for the GPU, and if you max out its VRAM then Things can happen.
_ViewCaptureToFile (and Clipboard) both go through OpenGL. _Render skips all that and you get just Cycles goodness.
Uhmmmm , how comes it looks right on your machine ??
I used _Render, and not _ViewCaptureToFile?
yeh works slightly better using that method in V7, black plane gone, very confusing though tbh.
I just tried Render in V6, this is what it gave me 🤷🤷🤷:man_facepalming:
Rhino Render in v6 is a different engine than Rhino Render in v7
yep I understand that, but why would the Rendered output look like its half finished in V6 render? It doesn’t make sense 🤷🤷
Its actually better if I just take a screenshot of the perspective viewport in render display mode , surely that’s not right ??