Translated scene data is NOT always more efficient than the raw scene data. It’s often quite the opposite.
The data structures for the scene represented in the DCC application are often more complex because they must support user interaction and editing of the data. Renderers often don’t need to do that as they’re on the publish end of the spectrum and only need the data that has to be displayed on the screen or written to the resulting file (eg: an image). However, that is not to say the DCC scene data is larger or less efficient than the rendered data. A few examples: hair, NURBS surfaces, volumic raymarching. With hair, the DCC will often display guide hairs as curves, or some other manipulator for the user to interact with. The data structure to link all the parts will be much more complex than the renderer’s data structure which is only slightly more complex than a bucket of triangle strips. However, the amount of memory required to store the hair information in the DCC is significantly less as only curve control points, positions of the guides and some other meta data need be stored. That’s not much physical data. The renderer, on the other hand, must expand all that data into raw triangle strips, or whatever it chooses to draw the hairs. It takes a lot more memory to store the vertex and edge connection data for dense triangle strips for millions of hairs than it does to store the controls points and other basic data for guide hairs in a DCC to represent the same information. NURBS. The data structure to create a NURBS surface in a DCC isn’t very large in the grand scheme of things as it’s mostly control point positions and a few pieces of metadata such as weights, edge flags, multiplicity, etc... What kills it is the math to make the nice shapes and interact with other surfaces such as when blending or trimming which must be recomputed any time the data is modified. When a NURBS surface is pushed into a renderer for display, the surface is tessellated into a dense polygon mesh and often significantly more dense (to preserve curvature smoothness) than as seen in the DCC. Again, while the data structure in the renderer is simpler than in the DCC, it contains more physical data. Volumic raymarching. This one can kill a raytracer fairly easily as it’s recursive in nature. In the DCC you’ll likely get a bounding box representing the data in the scene, but in the renderer the shaders kick into overdrive and sample the interior of the bounding box ad nauseum to rasterize the voxels. This requires tree data structures in some cases to hold the intermediate data until the result is reached. Those tree data structures can grow quite large, sometimes exceeding available memory of the computer. There are many more examples. The moral is DCC data structures are usually more complex but (often) hold less data, while renderer data structures are leaner but often have to hold more physical data. Renderer data may also scale based on the output resolution. Higher resolution images will incur more cost for render data structures if the rendering technique is view dependent, for example, as rendering will continue until some measureable visual criteria is met. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Kubicek Sent: Tuesday, May 20, 2014 5:18 AM To: softimage@listproc.autodesk.com Subject: Re: OT: Graphic card for optimous performance with Redshift When you render on the CPU directly from your DCC app, you have your scene in mem twice. Once in e.g. Soft, and once translated into what the renderer can render, both are stored in RAM, hence the memory consumption appears relatively high. In case of Redshift, video memory on the card (VRAM) is used for storing translated, renderable scene data, as long as it fits in. Translated scene data is usually a lot more efficient to store than the actual, raw scene, which has a lot of metadata, construction history, etc, that is not needed for rendering. Hence, a scene consuming 10gb in RAM is usually easily renderable on a 6gb card, depending on how much additional unique and procedural geometry you create at render time (e.g. subd, displacement, hair). There was a thread in the Redshift forum regarding actual triangle numbers storable in certain amounts of Vram. I can't find that thread now, but I believe it was around 100mio unique triangles in 6gb of Vram? no, vram only gets used by the card it's built in. but 6 gb vram is quite a lot and can't be compared to cpu ram. Means, if your scene uses like 15gb in Vray that doesn't mean 6gb is not enough for the scene in Redshift. Christian On 20.05.2014 11:48, Cristobal Infante wrote: If you have two 6gb cards, does Redshift consider this as 12gb of RAM or only 6gb? On 20 May 2014 10:32, Stefan Kubicek <s...@tidbit-images.com<mailto:s...@tidbit-images.com>> wrote: Last time I checked they were more expensive than two separate titans. What about the titan z series? Are they out yet? They could probably pack quite a punch :) On Tue, May 20, 2014 at 9:35 AM, Stefan Kubicek <s...@tidbit-images.com<mailto:s...@tidbit-images.com>> wrote: I second that, the 780 with 6gb (~2300 cores vs ~2800 of the Titan) is currently the biggest bang for the buck. Make sure to get the one that adheres to NVidias reference cooling design to get rid of the heat at the rear instead of injecting it into the pc housing, as the other, cheaper one from EVGA does. hey, the titan black is very fast, but considering the benchmarks (http://www.videocardbenchmark.net/high_end_gpus.html) the 780 isn't lame either, and the 6gb version is close to half the price of a titan. so if you want a bargain that's still fast, I would go for the 780 6gb. Christian On 19.05.2014 18:46, David Rivera wrote: Hi, now that Redshift is officially out and running smoothly, I´d like to ask you guys what Graphic Cards for best GPU performance would be optimum for an I7 stream core? I´m taking a look at: EVGA EVGA GeForce GTX TITAN SuperClocked 6GB GDDR5 384bit, Dual-Link DVI-I, DVI-D, HDMI,DP, SLI Ready Graphics Card Graphics Cards 06G-P4-2791-KR<http://www.amazon.com/EVGA-SuperClocked-Dual-Link-Graphics-06G-P4-2791-KR/dp/B00BL8BX7O/ref=sr_1_2?ie=UTF8&qid=1400517384&sr=8-2&keywords=nvidia+titan> But if I recall, there were some threads that were posted about the performance of the Quadro K4000 vs Titan. I can afford something of 1k cost ($1000) but before buying I would like to ask if there´s a better (cheaper) option? Like you all guys know, I´d like to take these considerations with softimage and later on the year transition fully to Modo 801. So what are your thoughts / recommendations? Thanks for sharing. David. [http://ecx.images-amazon.com/images/I/71phIxf42XL._SL1500_.jpg]<http://www.amazon.com/EVGA-SuperClocked-Dual-Link-Graphics-06G-P4-2791-KR/dp/B00BL8BX7O/ref=sr_1_2?ie=UTF8&qid=1400517384&sr=8-2&keywords=nvidia+titan> EVGA EVGA GeForce GTX TITAN SuperClocked 6GB...<http://www.amazon.com/EVGA-SuperClocked-Dual-Link-Graphics-06G-P4-2791-KR/dp/B00BL8BX7O/ref=sr_1_2?ie=UTF8&qid=1400517384&sr=8-2&keywords=nvidia+titan> Amazon.com: EVGA EVGA GeForce GTX TITAN SuperClocked 6GB GDDR5 384bit, Dual-Link DVI-I, DVI-D, HDMI,DP, SLI Ready Graphics Card Graphics Cards ... View on www.amazon.com<http://www.amazon.com/EVGA-SuperClocked-Dual-Link-Graphics-06G-P4-2791-KR/dp/B00BL8BX7O/ref=sr_1_2?ie=UTF8&qid=1400517384&sr=8-2&keywords=nvidia+titan> Preview by Yahoo David Rivera 3D Compositor/Animator LinkedIN<http://ec.linkedin.com/in/3dcinetv> Behance<https://www.behance.net/3dcinetv> VFX Reel<https://vimeo.com/70551635> -- [http://www.keyvis.at/wp-content/gallery/aboutUs/keyvisLogoMail.png] ----------------------------------------------------- Stefan Kubicek ste...@keyvis.at<mailto:%22ste...@keyvis.at%22+%3cste...@keyvis.at%3E> ----------------------------------------------------- Alfred Feierfeilstraße 3 A-2380 Perchtoldsdorf bei Wien Phone: +43 (0) 699 12614231<tel:%2B43%20%280%29%20699%2012614231> www.keyvis.at<http://www.keyvis.at> This email and its attachments are confidential and for the recipient only -- [http://www.keyvis.at/wp-content/gallery/aboutUs/keyvisLogoMail.png] ----------------------------------------------------- Stefan Kubicek ste...@keyvis.at<mailto:%22ste...@keyvis.at%22+%3cste...@keyvis.at%3E> ----------------------------------------------------- Alfred Feierfeilstraße 3 A-2380 Perchtoldsdorf bei Wien Phone: +43 (0) 699 12614231<tel:%2B43%20%280%29%20699%2012614231> www.keyvis.at<http://www.keyvis.at> This email and its attachments are confidential and for the recipient only -- [http://www.keyvis.at/wp-content/gallery/aboutUs/keyvisLogoMail.png] ----------------------------------------------------- Stefan Kubicek ste...@keyvis.at<mailto:%22ste...@keyvis.at%22%20%3cste...@keyvis.at%3e> ----------------------------------------------------- Alfred Feierfeilstraße 3 A-2380 Perchtoldsdorf bei Wien Phone: +43 (0) 699 12614231 www.keyvis.at<http://www.keyvis.at> This email and its attachments are confidential and for the recipient only
