Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Thanks for your answer Animator89.Redshift deals with large scenes better than most CPU-based renderers on the market. The rest of them? Not so much. OTOY are working on an out-of-core architecture for Octane, but I'm a little bit sceptical, because Octane renders pixels in a random order which means even more random access to texture and geometry, which puts even more stress on the PCIe bandwidth and slows things down. Redshift can render in bucket mode, which helps a bit even with path tracing.
I was thinking in that posibility because I saw some nice images from octane and redshift. But I realy dont know if in the present the Gpu renderers are capable to execute big scenes like others based on cpu. The vram limit of gpu maybe dont permit to realize this archviz scenes?
maybe another shortage in VFB is render history with an comparison tool (like nuke) to see differences between current render and previous renders .Looks almost exactly like the MODO render window. Not a bad thing though.
So their out-of-core streaming enables pretty much unlimited texture amount ? Did it also bypass the texture amount limit CUDA previously had (and which still seems to be case for Octane or not?)Basically, yes. In a simple test I just did, using a 2k by 1k HDRI resulted in a whopping 556 kB memory on the GPU used for textures. It's obviously only loading the parts it needs. It doesn't have a "max number of texture" like Octane. Presumably performance might suffer if you have thousands upon thousands of images, but there is no set limit as far as I know.
16mil. polies for 3GB vram is nice, but 16mil. is still nothing. How does it go around displacement ?In the same simple test I mentioned earlier, I rendered 38 million (unique) triangles on a card with 1.6 gigs of free memory. Out of the 1.6 gigs available to Redshift, the texture cache used up 128 megs, and various other things accounted for a bit more. In the end, there was 1.2 gigs available for geometry, and it used 1.1 gigs for 38 million triangles. It stands to reason that if you had a 6 gigabyte card used just for rendering (to save from Windows' overhead), you could fit about 190 million triangles before worrying about going out of core.
How does it go around displacement ?Displacements are generated on the CPU and resulting triangles are streamed to the GPU as needed, same as with regular geometry. It doesn't do texture-space displacement rendering, as far as I know (like V-Ray's 2D displacement effect).
I have to see how the Redshift memory cycling works, but I am pretty sure it's still at performance cost, and you can't just go for lowest memory possible without setbacks (780ti by default has 3GB that's not a miracle).There is a performance hit to going out of core (using more VRAM than what's available). How big a hit you'll take depends on numerous factors. First of all, images aren't as problematic as geometry. In fact, Redshift defaults to a GPU texture cache of just 128 megs. It simply will not use more than that for image maps, no matter how many you have. Streaming them from VRAM is apparently really fast, so image usage is basically not a problem.
Xeons have artificial margins...but they need to be compared to GPUs which are likewise. TeslaK40/QuadroK6000, while identical in performance to 780, cost 4000 euros each but bring 12GB Vram to the table.
The cost between "production-ready" high-end station based on pure CPU or GPU, are equally expensive, but GPUs actually scale in price even steeper. GPUs are NOT therefore any cheaper.
In fact you can go for Octa-CPU IvyBridge Xeon single-machine amounting to 256 cores for about 40 000 euros. For the same price, nVidia offers their Octa-Kepler based boxes which are about 50 000 euros each. I would say performance would be very similar in practical terms.
Power requirements as Rawalanche wrote also applies: Average IvyB (non-WS) Xeons is 120W, Kepler nVidia 240W. So in average, double the heat, noise and electricity, although this might not so much matter in grand scale both schemes cost :- ).
OR just use displacement instead bumpYes, that works too because it actually generates additional polygons, instead of just changing the normals. But you can still get this problem with displacements, if your displacement subdivision rate is too coarse.
Notice that I didn't say mental ray could produce as good results in less time, merely that it could produce good results -- good in this case meaning good enough. That was kind of my point. Corona is great if you need really great quality. If you only need decent quality, it might not be the best choice.Many engines, even mental ray, and definitely V-Ray, can be tweaked to produce good results in less render time than Corona would typically take. But the main advantage of Corona is that it gives you quality that competes with the best of what unbiased rendering has to offer, with a feature set that you typically only get in classical biased rendering, performance that isn't too far behind (and sometimes ahead), and a workflow that is better than either. That's a pretty cool thing. Don't get lost in the whole "rendertime" issue.
Vray yes, but mental ray no. No matter how you tweak mental ray, it will always provide either vastly inferior, or extremely long rendering results.
http://furryball.aaa-studio.eu/aboutFurryBall/compare.htmlUgh, don't get me started on Furryball. I emailed them my MODO version of that classroom, you know. Vastly better quality than any of the images on their comparison page, and it took less than five minutes on a run-of-the-mill i7. Ten minutes on my quad-core laptop. They didn't want to post it, though, because "only Maya plugins" -- despite the fact that MODO is available as a plugin for Maya via moma. If they can include Maxwell, which is also an export-to-standalone-based plugin, surely the same setup for MODO is also valid. Bah!
nuff said.
