Re: Color at Vertices from Clusters

[Matt Lind]

I tested my code and it works just fine here.  Please make sure it is 
installed correctly and functioning.  If there are any errors in the script 
log, post them here (other than "invalid selection" which is a user error).


Since you're dealing with vertex colors, make sure your viewport's display 
options are set to display them.  Sometimes they are overridden by materials 
or turned off completely.  An easy way to check is set shade mode to 
'constant'.


Vertex colors are also subservient to materials.  Each material can only 
display a single vertex color property at a time and you must assign the 
vertex color property to the material before it will appear in the viewport. 
For trivial cases such as single material with single vertex color property, 
Softimage will figure it out automatically.  However, if the object has 
multiple materials or multiple vertex color properties, you must select each 
material (in the scene explorer), open it's PPG, navigate to the "OpenGL" 
tab, and manually assign the vertex color property to the material via the 
dropdown menu at the bottom of the PPG.  If your object has multiple 
materials, you'll need to repeat this process for each material on the 
object  (Yes, it's a complete pain-in-the-ass and a gripe of many game 
developers).  Multi-selection PPGs don't always work for this and has proven 
to be flakey.


Finally, make sure you have assigned a color to your polygon cluster.  By 
default they'll render as grey or green.  Test on a simple grid if necessary 
by manually creating polygon clusters and assigning colors to them.  Then 
run the tool to verify the colors are written to the vertex color property.


If all the above is done correctly, you should only need to select the 
polygon mesh object(s), run my tool, and voila!



Matt



Date: Wed, 5 Aug 2015 01:18:51 -0300
From: Francisco Criado 
Subject: Re: Color at Vertices from Clusters
To: "softimage@listproc.autodesk.com"


Hi guys!


thank you all for the different aproaches. Matt tried your Java script with 
and nothing happens, have any idea what may be?

Francois, i will try your script tonight and let you know how it goes :)
Thanks for everything guys.

F.

-Original Message- 
From: softimage-requ...@listproc.autodesk.com

Sent: Tuesday, August 04, 2015 3:50 PM
To: softimage@listproc.autodesk.com
Subject: Softimage Digest, Vol 81, Issue 5

Send Softimage mailing list submissions to
softimage@listproc.autodesk.com

To subscribe or unsubscribe via the World Wide Web, visit
http://listproc.autodesk.com/mailman/listinfo/softimage
or, via email, send a message with subject or body 'help' to
softimage-requ...@listproc.autodesk.com

You can reach the person managing the list at
softimage-ow...@listproc.autodesk.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Softimage digest..."


Today's Topics:

  1. Re: Color at Vertices from Clusters (Matt Lind)


--

Message: 1
Date: Tue, 4 Aug 2015 15:50:45 -0700
From: "Matt Lind" 
Subject: Re: Color at Vertices from Clusters
To: 
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Here's a variation of a tool I used in games production.

Works with multi-selections and will apply the color found in the polygon 
cluster?s PPG.  This allows you to choose your colors at will and as often 
as you like.  Just copy n? paste this code into a file called 
?ML_VertexColorFromPolygonCluster.js? and drop into the ?plugins? folder of 
any workgroup to start using.  Will appear in Model/Animate/Render > [Get] 
Property > Map Paint Tools > ML VertexColor from PolygonCluster.  Can also 
be called from scripting.


You don?t want to use rendermap because it?ll have precision errors and 
result in color bleed in some tight spots or when there are polygon islands.



Matt



//---start of script 
(JScript)---

//
// ML_VertexColorFromPolygonCluster()
//
// Transfers color from polygons in polygon cluster to vertex color property 
using cluster color.

//

//===
// Constants()
//===
function Constants()
{
   this.PRG= "ML_VertexColorFromPolygonCluster";
   this.MENU_LABEL = "ML VertexColor from PolygonCluster";
}

//===
// XSILoadPlugin() - Registers plugin with XSI
//
//===
function XSILoadPlugin( oPluginRegistrar )
{
   var oConstants = new Constants();

   oPluginRegistrar.Author = "Matt Lind";
   oPluginRegistrar.Name   = oConstants.PRG;
   oPluginRegistrar.Email  

Re: Color at Vertices from Clusters

[Francisco Criado]

Hi guys!

thank you all for the different aproaches. Matt tried your Java script with
and nothing happens, have any idea what may be?
Francois, i will try your script tonight and let you know how it goes :)
Thanks for everything guys.

F.

Re[2]: OT: Jurassic World, Mad Max, Avengers Ultron ... money

[Mathieu Leclaire]

That's well said. I'm going to keep that link and bring it up each time I have 
this argument again. Thanks for sharing.


-Original Message-
From: "Pierre Schiller" 
To: softimage@listproc.autodesk.com
Date: 08/05/15 11:04
Subject: Re: OT: Jurassic World, Mad Max, Avengers Ultron ... money

So, hey here´s a "good morning" link. Told you this doesn´t end. What are your 
thoughts about this video?
YT: Why CG Sucks (Except It Doesn't)

https://www.youtube.com/watch?v=bL6hp8BKB24


On Mon, Jul 27, 2015 at 7:55 PM, Fabian Schnuer Gohde  wrote:
All very true. More than any fancy shading boohaa, believability within the 
laws of physical (even when stretched) is key for me to be willing to keep 
suspending my disbelief in an obviously ridiculous scenario. 

I'll go ahead and believe any outlandish magic/tech/gadget/superpower but the 
thing that takes me out of movies faster than anything is if you have 
non-superman characters survive impossible g-forces. Transformers has a bunch 
of stuff in there with characters getting yanked out of the air or scooped up a 
second before hitting the ground and all I can do is count the number of times 
they should have had their bones shattered and necks snapped.


Another pet peeve that is the lack of smoke when structures get blown up. 
Hasn't anyone watched a building coming down on discovery channel?


-F

On 27 July 2015 at 17:46, Maurice Patel  wrote:
Very well put. This is my feeling too.
Take Kurosawa. He uses movement so perfectly - it is not necessarily realistic 
in that it is heavily staged but it is 100% believable as natural. If directors 
paid as much attention to movement then a large part of this problem could be 
moot. With so many people involved in the CG production it is hard to fault the 
artists (they can make improvements but cannot save a badly directed movie), it 
really does fall on the director to make sure (s)he is getting the right 
performance, whether its real or CG, and that requires flawless planning, 
coordination and a vision of what the end result should be. It can't really be 
delegated.
maurice

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Saturday, July 25, 2015 5:00 PM
To: softimage@listproc.autodesk.com
Subject: Re: OT: Jurassic World, Mad Max, Avengers Ultron ... money



I can go on, but the problem is everybody is trying to tell stories through FX 
rather than having the FX support the story.  So much emphasis is put on the 
'look' that it fails to consider the more important element - motion.







--
Portfolio 2013
Cinema & TV production
Video Reel

Re: OT: Jurassic World, Mad Max, Avengers Ultron ... money

[Pierre Schiller]

So, hey here´s a "good morning" link. Told you this doesn´t end. What are
your thoughts about this video?
YT: Why CG Sucks (Except It Doesn't)

https://www.youtube.com/watch?v=bL6hp8BKB24

On Mon, Jul 27, 2015 at 7:55 PM, Fabian Schnuer Gohde 
wrote:

> All very true. More than any fancy shading boohaa, believability within
> the laws of physical (even when stretched) is key for me to be willing to
> keep suspending my disbelief in an obviously ridiculous scenario.
>
> I'll go ahead and believe any outlandish magic/tech/gadget/superpower but
> the thing that takes me out of movies faster than anything is if you have
> non-superman characters survive impossible g-forces. Transformers has a
> bunch of stuff in there with characters getting yanked out of the air or
> scooped up a second before hitting the ground and all I can do is count the
> number of times they should have had their bones shattered and necks
> snapped.
>
> Another pet peeve that is the lack of smoke when structures get blown up.
> Hasn't anyone watched a building coming down on discovery channel?
>
> -F
>
> On 27 July 2015 at 17:46, Maurice Patel 
> wrote:
>
>> Very well put. This is my feeling too.
>> Take Kurosawa. He uses movement so perfectly - it is not necessarily
>> realistic in that it is heavily staged but it is 100% believable as
>> natural. If directors paid as much attention to movement then a large part
>> of this problem could be moot. With so many people involved in the CG
>> production it is hard to fault the artists (they can make improvements but
>> cannot save a badly directed movie), it really does fall on the director to
>> make sure (s)he is getting the right performance, whether its real or CG,
>> and that requires flawless planning, coordination and a vision of what the
>> end result should be. It can't really be delegated.
>> maurice
>>
>> -Original Message-
>> From: softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
>> Sent: Saturday, July 25, 2015 5:00 PM
>> To: softimage@listproc.autodesk.com
>> Subject: Re: OT: Jurassic World, Mad Max, Avengers Ultron ... money
>>
>>
>> I can go on, but the problem is everybody is trying to tell stories
>> through FX rather than having the FX support the story.  So much emphasis
>> is put on the 'look' that it fails to consider the more important element -
>> motion.
>>
>>
>


-- 
Portfolio 2013 
Cinema & TV production
Video Reel 

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Mirko Jankovic]

agree. 980ti is just a bit above 2 970s price wise, performance wise it
realyl dpends on scenes you are working on. but I plan to upgrade my 4x970
with 980ti as soon as possible, even if it means replacing 1 by  1

On Wed, Aug 5, 2015 at 3:36 PM, Matt Morris  wrote:

> The 970 is the most cost efficient only with scenes that fit into its
> memory - which using redshift is limited to 3.5Gb because of the internal
> memory architecture. I'd recommend looking at gpus with 6Gb or higher. The
> 980ti is a great card for the money, and the extra vram will help
> performance even on small scenes as you can utilise memory optimisation
> settings. Because you're limited to 4 gpus (risers don't work too well and
> limited by number and speed of pci-e lanes as mirko said) you want to make
> the most of that space. Per card electricity usage and heat output isn't
> that much more for the 980ti.
>
> On 5 August 2015 at 14:04, Tim Leydecker  wrote:
>
>> Thanks for the clarification, Dan.
>>
>> I think I mixed this up with the download section of the forum for
>> customers?
>>
>> Whatever, good that the registered user forum is accessible to interested
>> parties.
>>
>> Cheers,
>>
>> tim
>>
>> P.S: For Hair, Shave&Haircut is supported (I don´t have personal
>> experience with it).
>>
>>
>> Am 05.08.2015 um 14:17 schrieb Dan Yargici:
>>
>> "you may find it helpful to register in the Redshift3D.com forums, afaik
>> you´ll need to have
>> at least one registered license to get access to the "Registered users
>> only" forum area."
>>
>> Just to clear this up.  I'm pretty sure you don't need to have a license
>> to access the Registered Users section of the Redshift forums.
>>
>> DAN
>>
>>
>> On Wed, Aug 5, 2015 at 2:58 PM, Rob Chapman  wrote:
>>
>>> A lot of good and informed points by all, just wanted to add, this guy
>>> here, Sven, at 
>>> http://www.render4you.de/renderfarm.html recently became the first
>>> official Redshift GPU render farm and have used him already on a few jobs
>>> with very tight deadlines.  Essentially he has a rack of 7x Tesla K40st -
>>> so 1 node is the equivalent of a 6x single 980gtx which I find is pretty
>>> cost effective solution of adding a decent online GPU render node, that
>>> works with hardly any setup if you have a redshift scene ready to go
>>>
>>> best
>>>
>>> Rob
>>>
>>> On 5 August 2015 at 11:56, Tim Leydecker < 
>>> bauero...@gmx.de> wrote:
>>>
 Hi Morten,

 you may find it helpful to register in the Redshift3D.com forums, afaik
 you´ll need to have
 at least one registered license to get access to the "Registered users
 only" forum area.

 There´s a few threads there about Hardware, multiple GPU systems and
 some user cases
 of testing single gpu vs. multi gpu rendering plus some Developer info
 about roadmaps and such.

 Personally, I´m a big fan of Redshift 3D.

 Still, here´s a few things to consider you may find useful:

 - Compared to Arnold, there is no HtoA or C4DtoA equivalent, e.g. no
 direct C4D or Houdini support
 - Compared to Arnold, rendering Yeti is not yet supported in Redshift3D
 - it´s looked at, no ETA.
 - Maya Fluids, Volumerendering, FumeFX e.g. Fire&Smoke&Dust&such isn´t
 in Redshift3D sofar

 - Multitasking, compared to CPU based multitasking and task switching
 (e.g. switching between
   rendering in Maya, Softimage while simultaneously comping in Nuke and
 painting Textures in Photoshop
   or Mari) may pose GPU specific limitations with multiple applications
 fighting for a very limited GPU VRAM.
  Redshift3D can utilize system RAM for VRAM but there can be headache
 when other, "dumber" apps go ahead
  and just block VRAM for their caching. It´s well worth running a good
 few hard tests in typical workflow scenarios.
  Maya, Substance Painter/Designer, Nuke, Photoshop, they all offer one
 type or another of GPU caching or GPU
  acceleration option. My personal feeling is, such stuff never gets
 tested in real-world, multiple-applications-running scenarios.

 At a glance, it would sound easy enough to have separate, dedicated
 GPUs run headless for rendering and reserving one GPU
 for viewport display and other apps but to be honest, all this stuff is
 so new, even thought it´s great, it´s still pushing grown
 legacy workflows and boundaries and in doing so, it may sometimes hurt.

 My very personal suggestion is:

 - a starter kit is just one GPU, optimally a Titan X with 12GB VRAM.
 - step 2, adding a second GPU, running headless, reserved for rendering
 - step 3, adding a third GPU, comparing speed to step 2
 - step 4, price/performance balancing, comparing a 1-2-3 GPU GTX970
 render rig with the above

 Could be you find out you like to run 1 Titan X for viewport display
 and multi-apps, and 2 GT

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Matt Morris]

The 970 is the most cost efficient only with scenes that fit into its
memory - which using redshift is limited to 3.5Gb because of the internal
memory architecture. I'd recommend looking at gpus with 6Gb or higher. The
980ti is a great card for the money, and the extra vram will help
performance even on small scenes as you can utilise memory optimisation
settings. Because you're limited to 4 gpus (risers don't work too well and
limited by number and speed of pci-e lanes as mirko said) you want to make
the most of that space. Per card electricity usage and heat output isn't
that much more for the 980ti.

On 5 August 2015 at 14:04, Tim Leydecker  wrote:

> Thanks for the clarification, Dan.
>
> I think I mixed this up with the download section of the forum for
> customers?
>
> Whatever, good that the registered user forum is accessible to interested
> parties.
>
> Cheers,
>
> tim
>
> P.S: For Hair, Shave&Haircut is supported (I don´t have personal
> experience with it).
>
>
> Am 05.08.2015 um 14:17 schrieb Dan Yargici:
>
> "you may find it helpful to register in the Redshift3D.com forums, afaik
> you´ll need to have
> at least one registered license to get access to the "Registered users
> only" forum area."
>
> Just to clear this up.  I'm pretty sure you don't need to have a license
> to access the Registered Users section of the Redshift forums.
>
> DAN
>
>
> On Wed, Aug 5, 2015 at 2:58 PM, Rob Chapman  wrote:
>
>> A lot of good and informed points by all, just wanted to add, this guy
>> here, Sven, at 
>> http://www.render4you.de/renderfarm.html recently became the first
>> official Redshift GPU render farm and have used him already on a few jobs
>> with very tight deadlines.  Essentially he has a rack of 7x Tesla K40st -
>> so 1 node is the equivalent of a 6x single 980gtx which I find is pretty
>> cost effective solution of adding a decent online GPU render node, that
>> works with hardly any setup if you have a redshift scene ready to go
>>
>> best
>>
>> Rob
>>
>> On 5 August 2015 at 11:56, Tim Leydecker < 
>> bauero...@gmx.de> wrote:
>>
>>> Hi Morten,
>>>
>>> you may find it helpful to register in the Redshift3D.com forums, afaik
>>> you´ll need to have
>>> at least one registered license to get access to the "Registered users
>>> only" forum area.
>>>
>>> There´s a few threads there about Hardware, multiple GPU systems and
>>> some user cases
>>> of testing single gpu vs. multi gpu rendering plus some Developer info
>>> about roadmaps and such.
>>>
>>> Personally, I´m a big fan of Redshift 3D.
>>>
>>> Still, here´s a few things to consider you may find useful:
>>>
>>> - Compared to Arnold, there is no HtoA or C4DtoA equivalent, e.g. no
>>> direct C4D or Houdini support
>>> - Compared to Arnold, rendering Yeti is not yet supported in Redshift3D
>>> - it´s looked at, no ETA.
>>> - Maya Fluids, Volumerendering, FumeFX e.g. Fire&Smoke&Dust&such isn´t
>>> in Redshift3D sofar
>>>
>>> - Multitasking, compared to CPU based multitasking and task switching
>>> (e.g. switching between
>>>   rendering in Maya, Softimage while simultaneously comping in Nuke and
>>> painting Textures in Photoshop
>>>   or Mari) may pose GPU specific limitations with multiple applications
>>> fighting for a very limited GPU VRAM.
>>>  Redshift3D can utilize system RAM for VRAM but there can be headache
>>> when other, "dumber" apps go ahead
>>>  and just block VRAM for their caching. It´s well worth running a good
>>> few hard tests in typical workflow scenarios.
>>>  Maya, Substance Painter/Designer, Nuke, Photoshop, they all offer one
>>> type or another of GPU caching or GPU
>>>  acceleration option. My personal feeling is, such stuff never gets
>>> tested in real-world, multiple-applications-running scenarios.
>>>
>>> At a glance, it would sound easy enough to have separate, dedicated GPUs
>>> run headless for rendering and reserving one GPU
>>> for viewport display and other apps but to be honest, all this stuff is
>>> so new, even thought it´s great, it´s still pushing grown
>>> legacy workflows and boundaries and in doing so, it may sometimes hurt.
>>>
>>> My very personal suggestion is:
>>>
>>> - a starter kit is just one GPU, optimally a Titan X with 12GB VRAM.
>>> - step 2, adding a second GPU, running headless, reserved for rendering
>>> - step 3, adding a third GPU, comparing speed to step 2
>>> - step 4, price/performance balancing, comparing a 1-2-3 GPU GTX970
>>> render rig with the above
>>>
>>> Could be you find out you like to run 1 Titan X for viewport display and
>>> multi-apps, and 2 GTX970 for a render job.
>>>
>>>
>>> Another thing.
>>>
>>> Multi-socket CPU boards and PCIe slots. It seems easier to get solid
>>> single socket CPU boards with lot´s of PCIe slots.
>>>
>>> Again, from my personal experience running a current generation dual
>>> socket Xeon rig, it is annoying how many CPU
>>> cycles I see wasted away in idle in most of my daily chores, except for
>>> pur

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Tim Leydecker]

Thanks for the clarification, Dan.

I think I mixed this up with the download section of the forum for 
customers?


Whatever, good that the registered user forum is accessible to 
interested parties.


Cheers,

tim

P.S: For Hair, Shave&Haircut is supported (I don´t have personal 
experience with it).


Am 05.08.2015 um 14:17 schrieb Dan Yargici:
"you may find it helpful to register in the Redshift3D.com forums, 
afaik you´ll need to have
at least one registered license to get access to the "Registered users 
only" forum area."


Just to clear this up.  I'm pretty sure you don't need to have a 
license to access the Registered Users section of the Redshift forums.


DAN


On Wed, Aug 5, 2015 at 2:58 PM, Rob Chapman > wrote:


A lot of good and informed points by all, just wanted to add, this
guy here, Sven, at http://www.render4you.de/renderfarm.html
recently became the first official Redshift GPU render farm and
have used him already on a few jobs with very tight deadlines. 
Essentially he has a rack of 7x Tesla K40st - so 1 node is the

equivalent of a 6x single 980gtx which I find is pretty cost
effective solution of adding a decent online GPU render node, that
works with hardly any setup if you have a redshift scene ready to go

best

Rob

On 5 August 2015 at 11:56, Tim Leydecker mailto:bauero...@gmx.de>> wrote:

Hi Morten,

you may find it helpful to register in the Redshift3D.com
forums, afaik you´ll need to have
at least one registered license to get access to the
"Registered users only" forum area.

There´s a few threads there about Hardware, multiple GPU
systems and some user cases
of testing single gpu vs. multi gpu rendering plus some
Developer info about roadmaps and such.

Personally, I´m a big fan of Redshift 3D.

Still, here´s a few things to consider you may find useful:

- Compared to Arnold, there is no HtoA or C4DtoA equivalent,
e.g. no direct C4D or Houdini support
- Compared to Arnold, rendering Yeti is not yet supported in
Redshift3D - it´s looked at, no ETA.
- Maya Fluids, Volumerendering, FumeFX e.g.
Fire&Smoke&Dust&such isn´t in Redshift3D sofar

- Multitasking, compared to CPU based multitasking and task
switching (e.g. switching between
  rendering in Maya, Softimage while simultaneously comping in
Nuke and painting Textures in Photoshop
  or Mari) may pose GPU specific limitations with multiple
applications fighting for a very limited GPU VRAM.
 Redshift3D can utilize system RAM for VRAM but there can be
headache when other, "dumber" apps go ahead
 and just block VRAM for their caching. It´s well worth
running a good few hard tests in typical workflow scenarios.
 Maya, Substance Painter/Designer, Nuke, Photoshop, they all
offer one type or another of GPU caching or GPU
 acceleration option. My personal feeling is, such stuff never
gets tested in real-world, multiple-applications-running
scenarios.

At a glance, it would sound easy enough to have separate,
dedicated GPUs run headless for rendering and reserving one GPU
for viewport display and other apps but to be honest, all this
stuff is so new, even thought it´s great, it´s still pushing grown
legacy workflows and boundaries and in doing so, it may
sometimes hurt.

My very personal suggestion is:

- a starter kit is just one GPU, optimally a Titan X with 12GB
VRAM.
- step 2, adding a second GPU, running headless, reserved for
rendering
- step 3, adding a third GPU, comparing speed to step 2
- step 4, price/performance balancing, comparing a 1-2-3 GPU
GTX970 render rig with the above

Could be you find out you like to run 1 Titan X for viewport
display and multi-apps, and 2 GTX970 for a render job.


Another thing.

Multi-socket CPU boards and PCIe slots. It seems easier to get
solid single socket CPU boards with lot´s of PCIe slots.

Again, from my personal experience running a current
generation dual socket Xeon rig, it is annoying how many CPU
cycles I see wasted away in idle in most of my daily chores,
except for pure rendering with Arnold or the likes, I find
myself mostly having one CPU and even most of the other CPU´s
cores just not used properly by software.

I think a good sweetspot would have been to just go for one
fast, solid 6-core(budget) or 8core (current) CPU, unless of
course for a dedicated render slave...


Cheers,

tim











Am 05.08.2015 um 12:05 schrieb Morten Bartholdy:


I know several of you are using Redshift extensively 

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Dan Yargici]

"you may find it helpful to register in the Redshift3D.com forums, afaik
you´ll need to have
at least one registered license to get access to the "Registered users
only" forum area."

Just to clear this up.  I'm pretty sure you don't need to have a license to
access the Registered Users section of the Redshift forums.

DAN


On Wed, Aug 5, 2015 at 2:58 PM, Rob Chapman  wrote:

> A lot of good and informed points by all, just wanted to add, this guy
> here, Sven, at http://www.render4you.de/renderfarm.html recently became
> the first official Redshift GPU render farm and have used him already on a
> few jobs with very tight deadlines.  Essentially he has a rack of 7x Tesla
> K40st - so 1 node is the equivalent of a 6x single 980gtx which I find is
> pretty cost effective solution of adding a decent online GPU render node,
> that works with hardly any setup if you have a redshift scene ready to go
>
>
> best
>
> Rob
>
> On 5 August 2015 at 11:56, Tim Leydecker  wrote:
>
>> Hi Morten,
>>
>> you may find it helpful to register in the Redshift3D.com forums, afaik
>> you´ll need to have
>> at least one registered license to get access to the "Registered users
>> only" forum area.
>>
>> There´s a few threads there about Hardware, multiple GPU systems and some
>> user cases
>> of testing single gpu vs. multi gpu rendering plus some Developer info
>> about roadmaps and such.
>>
>> Personally, I´m a big fan of Redshift 3D.
>>
>> Still, here´s a few things to consider you may find useful:
>>
>> - Compared to Arnold, there is no HtoA or C4DtoA equivalent, e.g. no
>> direct C4D or Houdini support
>> - Compared to Arnold, rendering Yeti is not yet supported in Redshift3D -
>> it´s looked at, no ETA.
>> - Maya Fluids, Volumerendering, FumeFX e.g. Fire&Smoke&Dust&such isn´t in
>> Redshift3D sofar
>>
>> - Multitasking, compared to CPU based multitasking and task switching
>> (e.g. switching between
>>   rendering in Maya, Softimage while simultaneously comping in Nuke and
>> painting Textures in Photoshop
>>   or Mari) may pose GPU specific limitations with multiple applications
>> fighting for a very limited GPU VRAM.
>>  Redshift3D can utilize system RAM for VRAM but there can be headache
>> when other, "dumber" apps go ahead
>>  and just block VRAM for their caching. It´s well worth running a good
>> few hard tests in typical workflow scenarios.
>>  Maya, Substance Painter/Designer, Nuke, Photoshop, they all offer one
>> type or another of GPU caching or GPU
>>  acceleration option. My personal feeling is, such stuff never gets
>> tested in real-world, multiple-applications-running scenarios.
>>
>> At a glance, it would sound easy enough to have separate, dedicated GPUs
>> run headless for rendering and reserving one GPU
>> for viewport display and other apps but to be honest, all this stuff is
>> so new, even thought it´s great, it´s still pushing grown
>> legacy workflows and boundaries and in doing so, it may sometimes hurt.
>>
>> My very personal suggestion is:
>>
>> - a starter kit is just one GPU, optimally a Titan X with 12GB VRAM.
>> - step 2, adding a second GPU, running headless, reserved for rendering
>> - step 3, adding a third GPU, comparing speed to step 2
>> - step 4, price/performance balancing, comparing a 1-2-3 GPU GTX970
>> render rig with the above
>>
>> Could be you find out you like to run 1 Titan X for viewport display and
>> multi-apps, and 2 GTX970 for a render job.
>>
>>
>> Another thing.
>>
>> Multi-socket CPU boards and PCIe slots. It seems easier to get solid
>> single socket CPU boards with lot´s of PCIe slots.
>>
>> Again, from my personal experience running a current generation dual
>> socket Xeon rig, it is annoying how many CPU
>> cycles I see wasted away in idle in most of my daily chores, except for
>> pure rendering with Arnold or the likes, I find
>> myself mostly having one CPU and even most of the other CPU´s cores just
>> not used properly by software.
>>
>> I think a good sweetspot would have been to just go for one fast, solid
>> 6-core(budget) or 8core (current) CPU, unless of course for a dedicated
>> render slave...
>>
>>
>> Cheers,
>>
>> tim
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Am 05.08.2015 um 12:05 schrieb Morten Bartholdy:
>>
>> I know several of you are using Redshift extensively or only now. We are
>> looking in to expanding our permanent render license pool and are
>> considering the pros and cons of Arnold, Vray and Redshift. I believe
>> Redshift will provide the most bang for the buck, but at a cost of some
>> production functionality we are used to with Arnold and Vray. Also, it will
>> likely require an initial investment in new hardware as Redshift will not
>> run on our Pizzabox render units, so that cost has to be counted in as well.
>>
>>
>>
>> It looks like the most priceefficient Redshift setup would be to make a
>> few machines with as many GPUs in them as physically possible, but how have
>> you guys set up your Redshift renderfarms?
>>
>>
>> I am thinking

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Rob Chapman]

A lot of good and informed points by all, just wanted to add, this guy
here, Sven, at http://www.render4you.de/renderfarm.html recently became the
first official Redshift GPU render farm and have used him already on a few
jobs with very tight deadlines.  Essentially he has a rack of 7x Tesla
K40st - so 1 node is the equivalent of a 6x single 980gtx which I find is
pretty cost effective solution of adding a decent online GPU render node,
that works with hardly any setup if you have a redshift scene ready to go


best

Rob

On 5 August 2015 at 11:56, Tim Leydecker  wrote:

> Hi Morten,
>
> you may find it helpful to register in the Redshift3D.com forums, afaik
> you´ll need to have
> at least one registered license to get access to the "Registered users
> only" forum area.
>
> There´s a few threads there about Hardware, multiple GPU systems and some
> user cases
> of testing single gpu vs. multi gpu rendering plus some Developer info
> about roadmaps and such.
>
> Personally, I´m a big fan of Redshift 3D.
>
> Still, here´s a few things to consider you may find useful:
>
> - Compared to Arnold, there is no HtoA or C4DtoA equivalent, e.g. no
> direct C4D or Houdini support
> - Compared to Arnold, rendering Yeti is not yet supported in Redshift3D -
> it´s looked at, no ETA.
> - Maya Fluids, Volumerendering, FumeFX e.g. Fire&Smoke&Dust&such isn´t in
> Redshift3D sofar
>
> - Multitasking, compared to CPU based multitasking and task switching
> (e.g. switching between
>   rendering in Maya, Softimage while simultaneously comping in Nuke and
> painting Textures in Photoshop
>   or Mari) may pose GPU specific limitations with multiple applications
> fighting for a very limited GPU VRAM.
>  Redshift3D can utilize system RAM for VRAM but there can be headache when
> other, "dumber" apps go ahead
>  and just block VRAM for their caching. It´s well worth running a good few
> hard tests in typical workflow scenarios.
>  Maya, Substance Painter/Designer, Nuke, Photoshop, they all offer one
> type or another of GPU caching or GPU
>  acceleration option. My personal feeling is, such stuff never gets tested
> in real-world, multiple-applications-running scenarios.
>
> At a glance, it would sound easy enough to have separate, dedicated GPUs
> run headless for rendering and reserving one GPU
> for viewport display and other apps but to be honest, all this stuff is so
> new, even thought it´s great, it´s still pushing grown
> legacy workflows and boundaries and in doing so, it may sometimes hurt.
>
> My very personal suggestion is:
>
> - a starter kit is just one GPU, optimally a Titan X with 12GB VRAM.
> - step 2, adding a second GPU, running headless, reserved for rendering
> - step 3, adding a third GPU, comparing speed to step 2
> - step 4, price/performance balancing, comparing a 1-2-3 GPU GTX970 render
> rig with the above
>
> Could be you find out you like to run 1 Titan X for viewport display and
> multi-apps, and 2 GTX970 for a render job.
>
>
> Another thing.
>
> Multi-socket CPU boards and PCIe slots. It seems easier to get solid
> single socket CPU boards with lot´s of PCIe slots.
>
> Again, from my personal experience running a current generation dual
> socket Xeon rig, it is annoying how many CPU
> cycles I see wasted away in idle in most of my daily chores, except for
> pure rendering with Arnold or the likes, I find
> myself mostly having one CPU and even most of the other CPU´s cores just
> not used properly by software.
>
> I think a good sweetspot would have been to just go for one fast, solid
> 6-core(budget) or 8core (current) CPU, unless of course for a dedicated
> render slave...
>
>
> Cheers,
>
> tim
>
>
>
>
>
>
>
>
>
>
>
> Am 05.08.2015 um 12:05 schrieb Morten Bartholdy:
>
> I know several of you are using Redshift extensively or only now. We are
> looking in to expanding our permanent render license pool and are
> considering the pros and cons of Arnold, Vray and Redshift. I believe
> Redshift will provide the most bang for the buck, but at a cost of some
> production functionality we are used to with Arnold and Vray. Also, it will
> likely require an initial investment in new hardware as Redshift will not
> run on our Pizzabox render units, so that cost has to be counted in as well.
>
>
>
> It looks like the most priceefficient Redshift setup would be to make a
> few machines with as many GPUs in them as physically possible, but how have
> you guys set up your Redshift renderfarms?
>
>
> I am thinking a large cabinet with a huge PSU, lots of cooling, as much
> memory as possible on the motherboard and perhaps 8 GPUs in each. GTX 970
> is probably the most power per pricepoint while Titans would make sense if
> more memory for rendering is required.
>
>
> Any thoughts and pointers will be much appreciated.
>
>
>
> Morten
>
>
>
>
>

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Tim Leydecker]

Hi Morten,

you may find it helpful to register in the Redshift3D.com forums, afaik 
you´ll need to have
at least one registered license to get access to the "Registered users 
only" forum area.


There´s a few threads there about Hardware, multiple GPU systems and 
some user cases
of testing single gpu vs. multi gpu rendering plus some Developer info 
about roadmaps and such.


Personally, I´m a big fan of Redshift 3D.

Still, here´s a few things to consider you may find useful:

- Compared to Arnold, there is no HtoA or C4DtoA equivalent, e.g. no 
direct C4D or Houdini support
- Compared to Arnold, rendering Yeti is not yet supported in Redshift3D 
- it´s looked at, no ETA.
- Maya Fluids, Volumerendering, FumeFX e.g. Fire&Smoke&Dust&such isn´t 
in Redshift3D sofar


- Multitasking, compared to CPU based multitasking and task switching 
(e.g. switching between
  rendering in Maya, Softimage while simultaneously comping in Nuke and 
painting Textures in Photoshop
  or Mari) may pose GPU specific limitations with multiple applications 
fighting for a very limited GPU VRAM.
 Redshift3D can utilize system RAM for VRAM but there can be headache 
when other, "dumber" apps go ahead
 and just block VRAM for their caching. It´s well worth running a good 
few hard tests in typical workflow scenarios.
 Maya, Substance Painter/Designer, Nuke, Photoshop, they all offer one 
type or another of GPU caching or GPU
 acceleration option. My personal feeling is, such stuff never gets 
tested in real-world, multiple-applications-running scenarios.


At a glance, it would sound easy enough to have separate, dedicated GPUs 
run headless for rendering and reserving one GPU
for viewport display and other apps but to be honest, all this stuff is 
so new, even thought it´s great, it´s still pushing grown

legacy workflows and boundaries and in doing so, it may sometimes hurt.

My very personal suggestion is:

- a starter kit is just one GPU, optimally a Titan X with 12GB VRAM.
- step 2, adding a second GPU, running headless, reserved for rendering
- step 3, adding a third GPU, comparing speed to step 2
- step 4, price/performance balancing, comparing a 1-2-3 GPU GTX970 
render rig with the above


Could be you find out you like to run 1 Titan X for viewport display and 
multi-apps, and 2 GTX970 for a render job.



Another thing.

Multi-socket CPU boards and PCIe slots. It seems easier to get solid 
single socket CPU boards with lot´s of PCIe slots.


Again, from my personal experience running a current generation dual 
socket Xeon rig, it is annoying how many CPU
cycles I see wasted away in idle in most of my daily chores, except for 
pure rendering with Arnold or the likes, I find
myself mostly having one CPU and even most of the other CPU´s cores just 
not used properly by software.


I think a good sweetspot would have been to just go for one fast, solid 
6-core(budget) or 8core (current) CPU, unless of course for a dedicated 
render slave...



Cheers,

tim










Am 05.08.2015 um 12:05 schrieb Morten Bartholdy:


I know several of you are using Redshift extensively or only now. We 
are looking in to expanding our permanent render license pool and are 
considering the pros and cons of Arnold, Vray and Redshift. I believe 
Redshift will provide the most bang for the buck, but at a cost of 
some production functionality we are used to with Arnold and Vray. 
Also, it will likely require an initial investment in new hardware as 
Redshift will not run on our Pizzabox render units, so that cost has 
to be counted in as well.


It looks like the most priceefficient Redshift setup would be to make 
a few machines with as many GPUs in them as physically possible, but 
how have you guys set up your Redshift renderfarms?



I am thinking a large cabinet with a huge PSU, lots of cooling, as 
much memory as possible on the motherboard and perhaps 8 GPUs in each. 
GTX 970 is probably the most power per pricepoint while Titans would 
make sense if more memory for rendering is required.



Any thoughts and pointers will be much appreciated.



Morten

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Mirko Jankovic]

I just mentioned that as well, btw is not SLI, SLI needs to be turned off
when rendering with Redshift but it is rendering with all cards.
But you can always send to render using 1 or 2 GPUs per frame which removes
scaling issues and give you all the power per node.

On Wed, Aug 5, 2015 at 12:51 PM, Nuno Conceicao  wrote:

> Hi
> Keep in mind SLI efficiency doesn't scale linearly, I read somewhere that
> with 2 cards efficiency is close to 90% , while with 4 is around 60%.
>
>
>
> On Wed, Aug 5, 2015 at 11:05 AM, Morten Bartholdy 
> wrote:
>
>> I know several of you are using Redshift extensively or only now. We are
>> looking in to expanding our permanent render license pool and are
>> considering the pros and cons of Arnold, Vray and Redshift. I believe
>> Redshift will provide the most bang for the buck, but at a cost of some
>> production functionality we are used to with Arnold and Vray. Also, it will
>> likely require an initial investment in new hardware as Redshift will not
>> run on our Pizzabox render units, so that cost has to be counted in as well.
>>
>>
>>
>> It looks like the most priceefficient Redshift setup would be to make a
>> few machines with as many GPUs in them as physically possible, but how have
>> you guys set up your Redshift renderfarms?
>>
>>
>> I am thinking a large cabinet with a huge PSU, lots of cooling, as much
>> memory as possible on the motherboard and perhaps 8 GPUs in each. GTX 970
>> is probably the most power per pricepoint while Titans would make sense if
>> more memory for rendering is required.
>>
>>
>> Any thoughts and pointers will be much appreciated.
>>
>>
>>
>> Morten
>>
>>
>>
>>
>

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Nuno Conceicao]

Hi
Keep in mind SLI efficiency doesn't scale linearly, I read somewhere that
with 2 cards efficiency is close to 90% , while with 4 is around 60%.



On Wed, Aug 5, 2015 at 11:05 AM, Morten Bartholdy 
wrote:

> I know several of you are using Redshift extensively or only now. We are
> looking in to expanding our permanent render license pool and are
> considering the pros and cons of Arnold, Vray and Redshift. I believe
> Redshift will provide the most bang for the buck, but at a cost of some
> production functionality we are used to with Arnold and Vray. Also, it will
> likely require an initial investment in new hardware as Redshift will not
> run on our Pizzabox render units, so that cost has to be counted in as well.
>
>
>
> It looks like the most priceefficient Redshift setup would be to make a
> few machines with as many GPUs in them as physically possible, but how have
> you guys set up your Redshift renderfarms?
>
>
> I am thinking a large cabinet with a huge PSU, lots of cooling, as much
> memory as possible on the motherboard and perhaps 8 GPUs in each. GTX 970
> is probably the most power per pricepoint while Titans would make sense if
> more memory for rendering is required.
>
>
> Any thoughts and pointers will be much appreciated.
>
>
>
> Morten
>
>
>
>

Re: OT'ish: Redshift renderfarm with Softimage setup?

[Mirko Jankovic]

Hello,

Rigth now I've got 3 computers, 4 GPUs each, TitanX, Titan and 970
One problem when putting as many GPUs as possible like 8 for example is
limit of PCI lines that CPU supports.
For now I found that sweet spot is 4 GPUs and 5930k or similar CPUs that
have 40 PCI lines supported. Also power supply for that system is a bit
easier then for 8 GPUs.
If you wanna go with more GPUs then you should probably had to look into
dual Xeon setups as well which increases price significantly.
Depending on scenes rendering beside GPU memory it is important to
accommodate RAM as well as due to scaling of GPUs when all are rendering
same frame it goes around 2.9 scaling when rendering with 4 compared to
single GPU. But solution is simple, using Deadline or similar render
management you can assign 1 or 2 GPUs per frame, but that also runs
multiple SI instances as well so that extra RAM is always good to have.
SO far all my comps are at 32GB RAM but I am considering upgrading to 64
any time soon just to give some more breathing space when allocating single
GPU per frame ie running 4 instances at once.

Probably sounds a bit messy or something but to sum so far what I've found
is nice:
- 4 GPU per computer, reference cooling design to exhaust heat out and back
of the case,
- any 4 GPU support motherboard that can support 4x PCI3.0@x8 speed (4x16
speed is nice but didn't show much improvement in performance but price is
much higher)
- 40 PCI lanes support CPU (3930k, 4930k, 5930k or 5960x and similar
editions),
- 32+ GB RAM,
- ~1500 PSU (4x titan X I saw coming around 900W-1200W when rendering out
of the UPS, better to give some extra space ofc)
- nice good ventilated case (corsair 750d is nice example, much smaller
then 900d for example but pretty good ventilation)
and in air conditioned room there is no issues with overheating. Liquid
cooling for 4 GPU setups is rather expensive and doesn't justify the cost
in my opinion.

There is option of going with some server rack cases and putting all in
cabinet as well ofc but that depends if you are gonna use them as
workstations as well or pure rendering nodes.

As for GPUs, in most cases 970 is just a bit behind titans, but in couple
scenes where I had a some fur it was probably hitting memory limits and it
was couple times slower even at range 3-4 times slower then titans with
more ram)

On Wed, Aug 5, 2015 at 12:05 PM, Morten Bartholdy 
wrote:

> I know several of you are using Redshift extensively or only now. We are
> looking in to expanding our permanent render license pool and are
> considering the pros and cons of Arnold, Vray and Redshift. I believe
> Redshift will provide the most bang for the buck, but at a cost of some
> production functionality we are used to with Arnold and Vray. Also, it will
> likely require an initial investment in new hardware as Redshift will not
> run on our Pizzabox render units, so that cost has to be counted in as well.
>
>
>
> It looks like the most priceefficient Redshift setup would be to make a
> few machines with as many GPUs in them as physically possible, but how have
> you guys set up your Redshift renderfarms?
>
>
> I am thinking a large cabinet with a huge PSU, lots of cooling, as much
> memory as possible on the motherboard and perhaps 8 GPUs in each. GTX 970
> is probably the most power per pricepoint while Titans would make sense if
> more memory for rendering is required.
>
>
> Any thoughts and pointers will be much appreciated.
>
>
>
> Morten
>
>
>
>

OT'ish: Redshift renderfarm with Softimage setup?

[Morten Bartholdy]

I know several of you are using Redshift extensively or only now. We are
looking in to expanding our permanent render license pool and are
considering the pros and cons of Arnold, Vray and Redshift. I believe
Redshift will provide the most bang for the buck, but at a cost of some
production functionality we are used to with Arnold and Vray. Also, it will
likely require an initial investment in new hardware as Redshift will not
run on our Pizzabox render units, so that cost has to be counted in as
well.

It looks like the most priceefficient Redshift setup would be to make a few
machines with as many GPUs in them as physically possible, but how have you
guys set up your Redshift renderfarms?

I am thinking a large cabinet with a huge PSU, lots of cooling, as much
memory as possible on the motherboard and perhaps 8 GPUs in each. GTX 970
is probably the most power per pricepoint while Titans would make sense if
more memory for rendering is required.

Any thoughts and pointers will be much appreciated.


Morten