Re: ADSK going Subscription only?

2014-10-03 Thread Tim Leydecker

Subscription (e.g. updates and bugfixes) isn´t bad in itself,
what worries me is the stealing away from providing support for a specific 
release
to forcing the client into a subscription model that has nothing to do with a
specific release but instead has the potential to be re-labeled as the 
equivalent to
subscribing to a service. You don´t own a specific software, you pay for the 
service
of being granted access to using a range of software.

Or more simply put for comparison, you don´t get to marry your very own special 
wife,
you are expected to pay just to spend time with "a woman"...

Cat in a bag.

Very nice model for the vendor not so nice for the client.

Cheers,

tim






On 03.10.2014 00:08, Matt Lind wrote:

This has been discussed quite for a while, so it should be news.

The one piece of information in the article that is not entirely true is the 
assumption customers stay on older versions of software only because they can.

Reality is many stay on older versions because productions with longer 
timelines need to freeze on a version to ensure no regressions creep into the 
pipeline during the critical
part of the schedule.  R+D in production is at a premium and they cannot be 
spending oodles of time fixing the same stuff again and again.  Many other 
studios have no R+D at all,
they’re on thinner ice with thin profit margins and breakneck schedules just to 
keep the doors open.  As the saying goes, “In the heat of battle, the best 
weapon is a familiar one”.

Another reason which applies in general – Autodesk really hasn’t given any 
incentive to upgrade as the feature improvements have been fairly minimal but 
problems have been all too
frequent.   Why would a customer invest money to upgrade a product which makes 
life more difficult?

Matt

*From:*softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *pedro santos
*Sent:* Thursday, October 02, 2014 2:55 PM
*To:* Softimage Mailing List
*Subject:* ADSK going Subscription only?

Solid Info? o_O


http://www.studiodaily.com/2014/10/autodesk-plans-to-go-subscription-only-over-next-one-to-two-years/?utm_source=feedly&utm_reader=feedly&utm_medium=rss&utm_campaign=autodesk-plans-to-go-subscription-only-over-next-one-to-two-years

Cheers


--



http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif



Pedro Alpiarça dos Santos
Animator  3DModeler  Illustrator

http://probiner.x10.mx/




Re: ADSK going Subscription only?

2014-10-03 Thread Sebastien Sterling
To be implemented over the next 2 years... well i guess we now know when
Bifrost will be completed :P

On 3 October 2014 08:52, Tim Leydecker  wrote:

> Subscription (e.g. updates and bugfixes) isn´t bad in itself,
> what worries me is the stealing away from providing support for a specific
> release
> to forcing the client into a subscription model that has nothing to do
> with a
> specific release but instead has the potential to be re-labeled as the
> equivalent to
> subscribing to a service. You don´t own a specific software, you pay for
> the service
> of being granted access to using a range of software.
>
> Or more simply put for comparison, you don´t get to marry your very own
> special wife,
> you are expected to pay just to spend time with "a woman"...
>
> Cat in a bag.
>
> Very nice model for the vendor not so nice for the client.
>
> Cheers,
>
> tim
>
>
>
>
>
>
> On 03.10.2014 00:08, Matt Lind wrote:
>
>> This has been discussed quite for a while, so it should be news.
>>
>> The one piece of information in the article that is not entirely true is
>> the assumption customers stay on older versions of software only because
>> they can.
>>
>> Reality is many stay on older versions because productions with longer
>> timelines need to freeze on a version to ensure no regressions creep into
>> the pipeline during the critical
>> part of the schedule.  R+D in production is at a premium and they cannot
>> be spending oodles of time fixing the same stuff again and again.  Many
>> other studios have no R+D at all,
>> they’re on thinner ice with thin profit margins and breakneck schedules
>> just to keep the doors open.  As the saying goes, “In the heat of battle,
>> the best weapon is a familiar one”.
>>
>> Another reason which applies in general – Autodesk really hasn’t given
>> any incentive to upgrade as the feature improvements have been fairly
>> minimal but problems have been all too
>> frequent.   Why would a customer invest money to upgrade a product which
>> makes life more difficult?
>>
>> Matt
>>
>> *From:*softimage-boun...@listproc.autodesk.com [mailto:softimage-bounces@
>> listproc.autodesk.com] *On Behalf Of *pedro santos
>> *Sent:* Thursday, October 02, 2014 2:55 PM
>> *To:* Softimage Mailing List
>> *Subject:* ADSK going Subscription only?
>>
>> Solid Info? o_O
>>
>>
>> http://www.studiodaily.com/2014/10/autodesk-plans-to-go-
>> subscription-only-over-next-one-to-two-years/?utm_source=
>> feedly&utm_reader=feedly&utm_medium=rss&utm_campaign=
>> autodesk-plans-to-go-subscription-only-over-next-one-to-two-years
>>
>> Cheers
>>
>>
>> --
>>
>> 
>> 
>> 
>>
>> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif
>>
>>
>>
>> Pedro Alpiarça dos Santos
>> Animator  3DModeler  Illustrator
>>
>>> http://probiner.x10.mx/

>>>
>>


Re: Spam:Re: ADSK going Subscription only?

2014-10-03 Thread Angus Davidson
By that definition Adobe and Autodesk are effectively digital Pimps.
Charming

On 2014/10/03, 9:52 AM, "Tim Leydecker"  wrote:

>Subscription (e.g. updates and bugfixes) isn´t bad in itself,
>what worries me is the stealing away from providing support for a
>specific release
>to forcing the client into a subscription model that has nothing to do
>with a
>specific release but instead has the potential to be re-labeled as the
>equivalent to
>subscribing to a service. You don´t own a specific software, you pay for
>the service
>of being granted access to using a range of software.
>
>Or more simply put for comparison, you don´t get to marry your very own
>special wife,
>you are expected to pay just to spend time with "a woman"...
>
>Cat in a bag.
>
>Very nice model for the vendor not so nice for the client.
>
>Cheers,
>
>tim
>
>
>
>
>
>
>On 03.10.2014 00:08, Matt Lind wrote:
>> This has been discussed quite for a while, so it should be news.
>>
>> The one piece of information in the article that is not entirely true
>>is the assumption customers stay on older versions of software only
>>because they can.
>>
>> Reality is many stay on older versions because productions with longer
>>timelines need to freeze on a version to ensure no regressions creep
>>into the pipeline during the critical
>> part of the schedule.  R+D in production is at a premium and they
>>cannot be spending oodles of time fixing the same stuff again and again.
>> Many other studios have no R+D at all,
>> they¹re on thinner ice with thin profit margins and breakneck schedules
>>just to keep the doors open.  As the saying goes, ³In the heat of
>>battle, the best weapon is a familiar one².
>>
>> Another reason which applies in general ­ Autodesk really hasn¹t given
>>any incentive to upgrade as the feature improvements have been fairly
>>minimal but problems have been all too
>> frequent.   Why would a customer invest money to upgrade a product
>>which makes life more difficult?
>>
>> Matt
>>
>> *From:*softimage-boun...@listproc.autodesk.com
>>[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *pedro
>>santos
>> *Sent:* Thursday, October 02, 2014 2:55 PM
>> *To:* Softimage Mailing List
>> *Subject:* ADSK going Subscription only?
>>
>> Solid Info? o_O
>>
>>
>> 
>>http://www.studiodaily.com/2014/10/autodesk-plans-to-go-subscription-only
>>-over-next-one-to-two-years/?utm_source=feedly&utm_reader=feedly&utm_medi
>>um=rss&utm_campaign=autodesk-plans-to-go-subscription-only-over-next-one-
>>to-two-years
>>
>> Cheers
>>
>>
>> --
>>
>> 
>>-
>>-
>>--
>>
>> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif
>>
>>  
>>
>> Pedro Alpiarça dos Santos
>> Animator  3DModeler  Illustrator
http://probiner.x10.mx/
>>

 

This communication is 
intended for the addressee only. It is confidential. If you have received this 
communication in error, please notify us immediately and destroy the original 
message. You may not copy or disseminate this communication without the 
permission of the University. Only authorised signatories are competent to 
enter into agreements on behalf of the University and recipients are thus 
advised that the content of this message may not be legally binding on the 
University and may contain the personal views and opinions of the author, which 
are not necessarily the views and opinions of The University of the 
Witwatersrand, Johannesburg. All agreements between the University and 
outsiders are subject to South African Law unless the University agrees in 
writing to the contrary. 






Re: Glasswoks Lycra

2014-10-03 Thread Florian Juri
Thanks very much guys, we're glad you like the job!

Some have been scratching their heads about how we've achieved the
extrusion effect and creation of UVs, and Manny, you've cracked it already!

After a lot of R&D and smoking heads we've 'settled' with the most simple
technique, which seemed to work best to achieve the effect the Director was
after, and it also turned out to be robust and fast.

For the majority of cloth elements we've used the following workflow:

After having accurately tracked characters and the camera we've:

- drawn spline curves on a static copy of the character's mesh to define
the areas the cloth should be 'emitted' from.
- we then sampled points on these curves, reinterpreted the locations on
the animated characters, and
- for every frame of a shot added strand positions, effectively creating
strand trail point clouds for the whole length of a shot, for every piece
of garment
- the strands were then converted into splines and
- lofted. So for a lot of shots we already head the UVs for free. For quite
a few shots, because of the nature of the dancers' movements we needed to
re-do the UVs though.

So we ended up with an extruded mesh (one edge loop per frame, or
subdivided if more detail was needed) which represented the dancer's
movement in 3D space over time.
Using ICE we've triggered vertices at the right time to start simulating
(using a Verlet setup) and hid/deleted all polygons 'in front' of a dancer.

For some shots to help joining characters and garment, additional pieces
were simulated using nCloth or Marvelous Designer.

That's it, nothing too fancy. :)

cheers,
Florian

On Thu, Oct 2, 2014 at 10:09 PM, Jason S  wrote:

>  Don't know how it was extruded, but the integration with actors' very
> dynamic movements is excellent!
> don't know exactly where real cloth starts or ends! :]
>
>
> On 10/02/14 16:56, Steven Caron wrote:
>
> if they are generating the data from strands then they know the start and
> end, as long as they know the vertical start and end it wouldn't be very
> hard to generate the the UVs along with the mesh.
>
> On Thu, Oct 2, 2014 at 1:53 PM, Manny Papamanos <
> manny.papama...@autodesk.com> wrote:
>
>> The long extruded element may already be generated as a whole piece,
>> and then is 'masked' off.
>> Would definitely be easier if it were patch/nurbs  based.
>>
>>
>>
>> Manny Papamanos
>> Product Support Specialist
>> Americas Frontline Technical Support
>> Customer Service and Support
>>
>> From: softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] On Behalf Of adrian wyer
>> Sent: Thursday, October 02, 2014 6:46 AM
>> To: softimage@listproc.autodesk.com
>> Subject: RE: Glasswoks Lycra
>>
>> any idea how the UVs were created?
>>
>> a
>>
>>
>


Re: Glasswoks Lycra

2014-10-03 Thread Florian Juri
oh and I forgot to mention: without Redshift we'd be still rendering!



On Fri, Oct 3, 2014 at 11:32 AM, Florian Juri 
wrote:

> Thanks very much guys, we're glad you like the job!
>
> Some have been scratching their heads about how we've achieved the
> extrusion effect and creation of UVs, and Manny, you've cracked it already!
>
> After a lot of R&D and smoking heads we've 'settled' with the most simple
> technique, which seemed to work best to achieve the effect the Director was
> after, and it also turned out to be robust and fast.
>
> For the majority of cloth elements we've used the following workflow:
>
> After having accurately tracked characters and the camera we've:
>
> - drawn spline curves on a static copy of the character's mesh to define
> the areas the cloth should be 'emitted' from.
> - we then sampled points on these curves, reinterpreted the locations on
> the animated characters, and
> - for every frame of a shot added strand positions, effectively creating
> strand trail point clouds for the whole length of a shot, for every piece
> of garment
> - the strands were then converted into splines and
> - lofted. So for a lot of shots we already head the UVs for free. For
> quite a few shots, because of the nature of the dancers' movements we
> needed to re-do the UVs though.
>
> So we ended up with an extruded mesh (one edge loop per frame, or
> subdivided if more detail was needed) which represented the dancer's
> movement in 3D space over time.
> Using ICE we've triggered vertices at the right time to start simulating
> (using a Verlet setup) and hid/deleted all polygons 'in front' of a dancer.
>
> For some shots to help joining characters and garment, additional pieces
> were simulated using nCloth or Marvelous Designer.
>
> That's it, nothing too fancy. :)
>
> cheers,
> Florian
>
> On Thu, Oct 2, 2014 at 10:09 PM, Jason S  wrote:
>
>>  Don't know how it was extruded, but the integration with actors' very
>> dynamic movements is excellent!
>> don't know exactly where real cloth starts or ends! :]
>>
>>
>> On 10/02/14 16:56, Steven Caron wrote:
>>
>> if they are generating the data from strands then they know the start and
>> end, as long as they know the vertical start and end it wouldn't be very
>> hard to generate the the UVs along with the mesh.
>>
>> On Thu, Oct 2, 2014 at 1:53 PM, Manny Papamanos <
>> manny.papama...@autodesk.com> wrote:
>>
>>> The long extruded element may already be generated as a whole piece,
>>> and then is 'masked' off.
>>> Would definitely be easier if it were patch/nurbs  based.
>>>
>>>
>>>
>>> Manny Papamanos
>>> Product Support Specialist
>>> Americas Frontline Technical Support
>>> Customer Service and Support
>>>
>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] On Behalf Of adrian wyer
>>> Sent: Thursday, October 02, 2014 6:46 AM
>>> To: softimage@listproc.autodesk.com
>>> Subject: RE: Glasswoks Lycra
>>>
>>> any idea how the UVs were created?
>>>
>>> a
>>>
>>>
>>
>


Re: Glasswoks Lycra

2014-10-03 Thread Sebastien Sterling
A wee making of would be nice :)

On 3 October 2014 11:34, Florian Juri  wrote:

> oh and I forgot to mention: without Redshift we'd be still rendering!
>
>
>
> On Fri, Oct 3, 2014 at 11:32 AM, Florian Juri  > wrote:
>
>> Thanks very much guys, we're glad you like the job!
>>
>> Some have been scratching their heads about how we've achieved the
>> extrusion effect and creation of UVs, and Manny, you've cracked it already!
>>
>> After a lot of R&D and smoking heads we've 'settled' with the most simple
>> technique, which seemed to work best to achieve the effect the Director was
>> after, and it also turned out to be robust and fast.
>>
>> For the majority of cloth elements we've used the following workflow:
>>
>> After having accurately tracked characters and the camera we've:
>>
>> - drawn spline curves on a static copy of the character's mesh to define
>> the areas the cloth should be 'emitted' from.
>> - we then sampled points on these curves, reinterpreted the locations on
>> the animated characters, and
>> - for every frame of a shot added strand positions, effectively creating
>> strand trail point clouds for the whole length of a shot, for every piece
>> of garment
>> - the strands were then converted into splines and
>> - lofted. So for a lot of shots we already head the UVs for free. For
>> quite a few shots, because of the nature of the dancers' movements we
>> needed to re-do the UVs though.
>>
>> So we ended up with an extruded mesh (one edge loop per frame, or
>> subdivided if more detail was needed) which represented the dancer's
>> movement in 3D space over time.
>> Using ICE we've triggered vertices at the right time to start simulating
>> (using a Verlet setup) and hid/deleted all polygons 'in front' of a dancer.
>>
>> For some shots to help joining characters and garment, additional pieces
>> were simulated using nCloth or Marvelous Designer.
>>
>> That's it, nothing too fancy. :)
>>
>> cheers,
>> Florian
>>
>> On Thu, Oct 2, 2014 at 10:09 PM, Jason S  wrote:
>>
>>>  Don't know how it was extruded, but the integration with actors' very
>>> dynamic movements is excellent!
>>> don't know exactly where real cloth starts or ends! :]
>>>
>>>
>>> On 10/02/14 16:56, Steven Caron wrote:
>>>
>>> if they are generating the data from strands then they know the start
>>> and end, as long as they know the vertical start and end it wouldn't be
>>> very hard to generate the the UVs along with the mesh.
>>>
>>> On Thu, Oct 2, 2014 at 1:53 PM, Manny Papamanos <
>>> manny.papama...@autodesk.com> wrote:
>>>
 The long extruded element may already be generated as a whole piece,
 and then is 'masked' off.
 Would definitely be easier if it were patch/nurbs  based.



 Manny Papamanos
 Product Support Specialist
 Americas Frontline Technical Support
 Customer Service and Support

 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of adrian wyer
 Sent: Thursday, October 02, 2014 6:46 AM
 To: softimage@listproc.autodesk.com
 Subject: RE: Glasswoks Lycra

 any idea how the UVs were created?

 a


>>>
>>
>


Re: Drawable Facial Rig

2014-10-03 Thread David Rivera
I remembered GEAR for facial rigging but the GEAR site doesn´t have it to 
download...
Anyone knows how is it going for Jeremie and GEAR in facial rig?

 
David Rivera
3D Compositor/Animator
LinkedIN
Behance
VFX Reel


On Thursday, October 2, 2014 1:42 AM, Nicolas Esposito <3dv...@gmail.com> wrote:
 


Wow! this is impressive RnD!
+1 for Fabric to come up with something better then this :-)


2014-10-02 6:42 GMT+02:00 Eugene Flormata :

amazing! i hope fabric engine takes note for this
>
>
>On Wed, Oct 1, 2014 at 2:56 PM, Ed Schiffer  wrote:
>
>I've never seen a drawing facil rig before, I think this is quite unique! ::
>>
>>http://lesterbanks.com/2014/10/drawable-facial-rig-will-amaze/
>>
>>
>>-- 
>>www.edschiffer.com 
>

Re: Glasswoks Lycra

2014-10-03 Thread Alastair Hearsum
We're going to try and get one out. You know how it is when you are 
straight on to the next thing though.


Alastair Hearsum
Head of 3d
GLASSWORKS
Facebook 
 Twitter 
 Vimeo 
 Instagram 


See our latest work _here_. 
33/34 Great Pulteney Street
London
W1F 9NP
T +44 (0)20 7434 1182
glassworks.co.uk 
Glassworks Terms and Conditions of Sale can be found at glassworks.co.uk
(Company registered in England with number 04759979. Registered office 
25 Harley Street, London, W1G 9BR. VAT registration number: 86729)

Please consider the environment before you print this email.
DISCLAIMER: This e-mail and attachments are strictly privileged, private 
and confidential and are intended solely for the stated recipient(s). 
Any views or opinions presented are solely those of the author and do 
not necessarily represent those of the Company. If you are not the 
intended recipient, be advised that you have received this e-mail in 
error and that any use, dissemination, forwarding, printing, or copying 
of this e-mail is strictly prohibited. If this transmission is received 
in error please kindly return it to the sender and delete this message 
from your system.

On 03/10/2014 14:45, Sebastien Sterling wrote:

A wee making of would be nice :)

On 3 October 2014 11:34, Florian Juri > wrote:


oh and I forgot to mention: without Redshift we'd be still rendering!



On Fri, Oct 3, 2014 at 11:32 AM, Florian Juri
mailto:florian.j...@googlemail.com>>
wrote:

Thanks very much guys, we're glad you like the job!

Some have been scratching their heads about how we've achieved
the extrusion effect and creation of UVs, and Manny, you've
cracked it already!

After a lot of R&D and smoking heads we've 'settled' with the
most simple technique, which seemed to work best to achieve
the effect the Director was after, and it also turned out to
be robust and fast.

For the majority of cloth elements we've used the following
workflow:

After having accurately tracked characters and the camera we've:

- drawn spline curves on a static copy of the character's mesh
to define the areas the cloth should be 'emitted' from.
- we then sampled points on these curves, reinterpreted the
locations on the animated characters, and
- for every frame of a shot added strand positions,
effectively creating strand trail point clouds for the whole
length of a shot, for every piece of garment
- the strands were then converted into splines and
- lofted. So for a lot of shots we already head the UVs for
free. For quite a few shots, because of the nature of the
dancers' movements we needed to re-do the UVs though.

So we ended up with an extruded mesh (one edge loop per frame,
or subdivided if more detail was needed) which represented the
dancer's movement in 3D space over time.
Using ICE we've triggered vertices at the right time to start
simulating (using a Verlet setup) and hid/deleted all polygons
'in front' of a dancer.

For some shots to help joining characters and garment,
additional pieces were simulated using nCloth or Marvelous
Designer.

That's it, nothing too fancy. :)

cheers,
Florian

On Thu, Oct 2, 2014 at 10:09 PM, Jason S
mailto:jasonsta...@gmail.com>> wrote:

Don't know how it was extruded, but the integration with
actors' very dynamic movements is excellent!
don't know exactly where real cloth starts or ends! :]


On 10/02/14 16:56, Steven Caron wrote:

if they are generating the data from strands then they
know the start and end, as long as they know the vertical
start and end it wouldn't be very hard to generate the
the UVs along with the mesh.

On Thu, Oct 2, 2014 at 1:53 PM, Manny Papamanos
mailto:manny.papama...@autodesk.com>> wrote:

The long extruded element may already be generated as
a whole piece,
and then is 'masked' off.
Would definitely be easier if it were patch/nurbs  based.



Manny Papamanos
Product Support Specialist
Americas Frontline Technical Support
Customer Service and Support

From: softimage-boun...@listproc.autodesk.com

[mailto:softimage-boun...@listproc.autodesk.com


Re: Glasswoks Lycra

2014-10-03 Thread Sebastien Sterling
i'm sure, i meant even a viewport capture, just to see the verious bits in
the viewport, and yes of course i understand you guys gota make tracks ;)

On 3 October 2014 18:13, Alastair Hearsum  wrote:

>  We're going to try and get one out. You know how it is when you are
> straight on to the next thing though.
>
>  Alastair Hearsum
> Head of 3d
> [image: GLASSWORKS]
>  [image: Facebook]
>  [image:
> Twitter]  [image: Vimeo]
>  [image: Instagram]
> 
>  See our latest work *here*. 
>  33/34 Great Pulteney Street
> London
> W1F 9NP
> T +44 (0)20 7434 1182
> glassworks.co.uk 
>  Glassworks Terms and Conditions of Sale can be found at glassworks.co.uk
>  (Company registered in England with number 04759979. Registered office 25
> Harley Street, London, W1G 9BR. VAT registration number: 86729)
>  Please consider the environment before you print this email.
>  DISCLAIMER: This e-mail and attachments are strictly privileged, private
> and confidential and are intended solely for the stated recipient(s). Any
> views or opinions presented are solely those of the author and do not
> necessarily represent those of the Company. If you are not the intended
> recipient, be advised that you have received this e-mail in error and that
> any use, dissemination, forwarding, printing, or copying of this e-mail is
> strictly prohibited. If this transmission is received in error please
> kindly return it to the sender and delete this message from your system.
>  On 03/10/2014 14:45, Sebastien Sterling wrote:
>
> A wee making of would be nice :)
>
> On 3 October 2014 11:34, Florian Juri  wrote:
>
>> oh and I forgot to mention: without Redshift we'd be still rendering!
>>
>>
>>
>> On Fri, Oct 3, 2014 at 11:32 AM, Florian Juri <
>> florian.j...@googlemail.com> wrote:
>>
>>> Thanks very much guys, we're glad you like the job!
>>>
>>> Some have been scratching their heads about how we've achieved the
>>> extrusion effect and creation of UVs, and Manny, you've cracked it already!
>>>
>>> After a lot of R&D and smoking heads we've 'settled' with the most
>>> simple technique, which seemed to work best to achieve the effect the
>>> Director was after, and it also turned out to be robust and fast.
>>>
>>> For the majority of cloth elements we've used the following workflow:
>>>
>>> After having accurately tracked characters and the camera we've:
>>>
>>> - drawn spline curves on a static copy of the character's mesh to define
>>> the areas the cloth should be 'emitted' from.
>>> - we then sampled points on these curves, reinterpreted the locations on
>>> the animated characters, and
>>> - for every frame of a shot added strand positions, effectively creating
>>> strand trail point clouds for the whole length of a shot, for every piece
>>> of garment
>>> - the strands were then converted into splines and
>>> - lofted. So for a lot of shots we already head the UVs for free. For
>>> quite a few shots, because of the nature of the dancers' movements we
>>> needed to re-do the UVs though.
>>>
>>> So we ended up with an extruded mesh (one edge loop per frame, or
>>> subdivided if more detail was needed) which represented the dancer's
>>> movement in 3D space over time.
>>> Using ICE we've triggered vertices at the right time to start simulating
>>> (using a Verlet setup) and hid/deleted all polygons 'in front' of a dancer.
>>>
>>> For some shots to help joining characters and garment, additional pieces
>>> were simulated using nCloth or Marvelous Designer.
>>>
>>> That's it, nothing too fancy. :)
>>>
>>> cheers,
>>> Florian
>>>
>>> On Thu, Oct 2, 2014 at 10:09 PM, Jason S  wrote:
>>>
  Don't know how it was extruded, but the integration with actors' very
 dynamic movements is excellent!
 don't know exactly where real cloth starts or ends! :]


 On 10/02/14 16:56, Steven Caron wrote:

 if they are generating the data from strands then they know the start
 and end, as long as they know the vertical start and end it wouldn't be
 very hard to generate the the UVs along with the mesh.

 On Thu, Oct 2, 2014 at 1:53 PM, Manny Papamanos <
 manny.papama...@autodesk.com> wrote:

> The long extruded element may already be generated as a whole piece,
> and then is 'masked' off.
> Would definitely be easier if it were patch/nurbs  based.
>
>
>
> Manny Papamanos
> Product Support Specialist
> Americas Frontline Technical Support
> Customer Service and Support
>
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of adrian wyer
> Sent: Thursday, October 02, 2014 6:46 AM
> To: softimage@listproc.autodesk.com
> Subject: RE: Glassw

Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
Why is that?  I didn't see anything in that spot any renderer couldn't
handle without issue.  Was there some specific reason redshift excelled
beyond some extra gpu power?



On Fri, Oct 3, 2014 at 3:34 AM, Florian Juri 
wrote:

> oh and I forgot to mention: without Redshift we'd be still rendering!
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Mirko Jankovic
sheer power and speed of Redshift is something you need to see first hand
really :) they will oproably explain better but... Redshift for a lot of
people was game changer

On Fri, Oct 3, 2014 at 7:53 PM, Simon van de Lagemaat <
si...@theembassyvfx.com> wrote:

> Why is that?  I didn't see anything in that spot any renderer couldn't
> handle without issue.  Was there some specific reason redshift excelled
> beyond some extra gpu power?
>
>
>
> On Fri, Oct 3, 2014 at 3:34 AM, Florian Juri 
> wrote:
>
>> oh and I forgot to mention: without Redshift we'd be still rendering!
>>
>>
>>


Re: Glasswoks Lycra

2014-10-03 Thread Steven Caron
that extra GPU power is a dramatic increase in speed though.

On Fri, Oct 3, 2014 at 10:53 AM, Simon van de Lagemaat <
si...@theembassyvfx.com> wrote:

> Why is that?  I didn't see anything in that spot any renderer couldn't
> handle without issue.  Was there some specific reason redshift excelled
> beyond some extra gpu power?
>
>
>
> On Fri, Oct 3, 2014 at 3:34 AM, Florian Juri 
> wrote:
>
>> oh and I forgot to mention: without Redshift we'd be still rendering!
>>
>>
>>


Re: Glasswoks Lycra

2014-10-03 Thread Emilio Hernandez
I will add quality and clean renders to the speed and power.

No fireflies, unexpected noise, etc.

Besides for me it is not only about the rendering. Maybe if you have a
super render farm, you can just send the job and forget about unitl it is
done.  But when working in texturing, shading, and lighting, Redshift is a
joy to work with, and a hell of a time saver.



---
Emilio Hernández   VFX & 3D animation.


Re: Glasswoks Lycra

2014-10-03 Thread Steven Caron
hey emilio

which rendering engines do you use?

On Fri, Oct 3, 2014 at 11:09 AM, Emilio Hernandez  wrote:

> I will add quality and clean renders to the speed and power.
>
> No fireflies, unexpected noise, etc.
>
> Besides for me it is not only about the rendering. Maybe if you have a
> super render farm, you can just send the job and forget about unitl it is
> done.  But when working in texturing, shading, and lighting, Redshift is a
> joy to work with, and a hell of a time saver.
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Tim Crowson

It really is. Even on very complex scenes.
-Tim

On 10/3/2014 1:06 PM, Steven Caron wrote:

that extra GPU power is a dramatic increase in speed though.

On Fri, Oct 3, 2014 at 10:53 AM, Simon van de Lagemaat 
mailto:si...@theembassyvfx.com>> wrote:


Why is that?  I didn't see anything in that spot any renderer
couldn't handle without issue.  Was there some specific reason
redshift excelled beyond some extra gpu power?



On Fri, Oct 3, 2014 at 3:34 AM, Florian Juri
mailto:florian.j...@googlemail.com>>
wrote:

oh and I forgot to mention: without Redshift we'd be still
rendering!





--
Signature


Re: Glasswoks Lycra

2014-10-03 Thread Rob Chapman
Not having to kick ass or rewind a frame for evey render region preview is
a huge time saver on its own..
On 3 Oct 2014 19:12, "Steven Caron"  wrote:

> hey emilio
>
> which rendering engines do you use?
>
> On Fri, Oct 3, 2014 at 11:09 AM, Emilio Hernandez 
> wrote:
>
>> I will add quality and clean renders to the speed and power.
>>
>> No fireflies, unexpected noise, etc.
>>
>> Besides for me it is not only about the rendering. Maybe if you have a
>> super render farm, you can just send the job and forget about unitl it is
>> done.  But when working in texturing, shading, and lighting, Redshift is a
>> joy to work with, and a hell of a time saver.
>>
>>
>


Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
At the cost of a smaller fast memory pool?  From what I understand Redshift
slows down significantly when it starts using off board RAM?  I know this
is one of the main reasons many other renderers haven't gone to the GPU yet
since cards with decent amounts of memory are still priced far too high.

How is Redshift with overall memory usage?  i.e. what is the memory
footprint per polygon etc.  Also it's biased correct?  I
become nauseous when someone mentions that word, is their approach better
than other IC approaches?  Similar pitfalls?

I may try it this weekend on my 780gtx (only 3GB onboard) at home since
it's been getting good PR here.  With the type of memory heavy rendering we
do for film and the efficient platform agnostic pipeline friendly workflow
we have with Arnold I don't see it being useful outside some smaller
commercial jobs but I'd like to get a taste of the speed and interactivity.
I suppose if we were a 5 person shop again something like RS would be a
godsend.

On Fri, Oct 3, 2014 at 11:06 AM, Steven Caron  wrote:

> that extra GPU power is a dramatic increase in speed though.
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Emilio Hernandez
Since Redshift appeared, mostly I used Mental Ray since Softimage 3D 3.5

I used Maxwell, Arnold, 3Delight, Fury and I was in the beta testers of
V-ray.  But when finally Redshift came out in its Alpha stage, and I was
able to participate in the group. I knew this was the render engine I was
expecting for Softimage.

I was working in a 5 seconds lenght product shot for Kellogg's that with my
hardware resources, it would have been impossible to deliver on time with
the quality the client was expecting.

So, straight after download and installed Redshift, I gave it a try.
Straight from the beggining, I felt at home with Redshift, setup the scene
in a breeze, made a couple of tests and hit render.

The final render came out without any problem and incredibly fast without
any flickering, fireflies, noise, etc.   Since then, I am using Redshift
99%  Except for particle volumes.

Cheers!


---
Emilio Hernández   VFX & 3D animation.

2014-10-03 13:11 GMT-05:00 Steven Caron :

> hey emilio
>
> which rendering engines do you use?
>
> On Fri, Oct 3, 2014 at 11:09 AM, Emilio Hernandez 
> wrote:
>
>> I will add quality and clean renders to the speed and power.
>>
>> No fireflies, unexpected noise, etc.
>>
>> Besides for me it is not only about the rendering. Maybe if you have a
>> super render farm, you can just send the job and forget about unitl it is
>> done.  But when working in texturing, shading, and lighting, Redshift is a
>> joy to work with, and a hell of a time saver.
>>
>>
>


Re: Glasswoks Lycra

2014-10-03 Thread Ed Manning
Ditto.  total gamechanger. Redshift is literally the only thing that kept
me from closing up shop. I had priced out new multicore render nodes, and
licenses for VRay and Arnold, as well as testing Arion, Octane and more
obscure options, and the numbers just didn't make sense.  I was going to
just not be able to continue doing the type of remote work my clients
expect on the schedules they need, and make enough money for it to be worth
doing.

For example, I'm just putting 2 new render machines online - they're refurb
Dell workstations that cost $450 each, with an additional 16GB RAM, ($190
each), an auxiliary drive bay power supply ($25!) and 2 GTX 780s
($850/pair).  So each render node's hardware was about $1500, the Redshift
license is $500, and I get much better performance from each node than I
see from brand-new $10K 20-core CPU render boxes.


Re: Glasswoks Lycra

2014-10-03 Thread Emilio Hernandez
Forgot to mention the amazing Redshift support.  Those guys really rock!

---
Emilio Hernández   VFX & 3D animation.

2014-10-03 13:43 GMT-05:00 Ed Manning :

> Ditto.  total gamechanger. Redshift is literally the only thing that kept
> me from closing up shop. I had priced out new multicore render nodes, and
> licenses for VRay and Arnold, as well as testing Arion, Octane and more
> obscure options, and the numbers just didn't make sense.  I was going to
> just not be able to continue doing the type of remote work my clients
> expect on the schedules they need, and make enough money for it to be worth
> doing.
>
> For example, I'm just putting 2 new render machines online - they're
> refurb Dell workstations that cost $450 each, with an additional 16GB RAM,
> ($190 each), an auxiliary drive bay power supply ($25!) and 2 GTX 780s
> ($850/pair).  So each render node's hardware was about $1500, the Redshift
> license is $500, and I get much better performance from each node than I
> see from brand-new $10K 20-core CPU render boxes.
>
>
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Sebastien Sterling
Octane is an un-biased GPU renderer, i wonder how it stacks

they way i understand bias and unbies

is it, that

unbias, computer goes through the whole gamut of possible calculations to
find the right result per ray traced.

Bias, you get to clamp the calculations to a more probable outcome, so the
ray calculation won't bother with "everything" just the specific bracket
you want to work in, which speeds up things, but sacrifices certainty in
accuracy?

is that right ?

or is that brute force ?



On 3 October 2014 19:34, Simon van de Lagemaat 
wrote:

> At the cost of a smaller fast memory pool?  From what I understand
> Redshift slows down significantly when it starts using off board RAM?  I
> know this is one of the main reasons many other renderers haven't gone to
> the GPU yet since cards with decent amounts of memory are still priced far
> too high.
>
> How is Redshift with overall memory usage?  i.e. what is the memory
> footprint per polygon etc.  Also it's biased correct?  I
> become nauseous when someone mentions that word, is their approach better
> than other IC approaches?  Similar pitfalls?
>
> I may try it this weekend on my 780gtx (only 3GB onboard) at home since
> it's been getting good PR here.  With the type of memory heavy rendering we
> do for film and the efficient platform agnostic pipeline friendly workflow
> we have with Arnold I don't see it being useful outside some smaller
> commercial jobs but I'd like to get a taste of the speed and interactivity.
> I suppose if we were a 5 person shop again something like RS would be a
> godsend.
>
> On Fri, Oct 3, 2014 at 11:06 AM, Steven Caron  wrote:
>
>> that extra GPU power is a dramatic increase in speed though.
>>
>>
>>


Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
So SLI seems to be the most cost efficient method i.e. double the power per
physical box...  nice thing is you can probably upgrade those GPU's across
a few generations without upgrading the rest of the system since the PCI
specs don't change much and power draw tends to decrease with newer cards.

I mean, it's not cheap but I'll assume the dollar per flops ratio is way
higher.

On Fri, Oct 3, 2014 at 11:43 AM, Ed Manning  wrote:

> Ditto.  total gamechanger. Redshift is literally the only thing that kept
> me from closing up shop. I had priced out new multicore render nodes, and
> licenses for VRay and Arnold, as well as testing Arion, Octane and more
> obscure options, and the numbers just didn't make sense.  I was going to
> just not be able to continue doing the type of remote work my clients
> expect on the schedules they need, and make enough money for it to be worth
> doing.
>
> For example, I'm just putting 2 new render machines online - they're
> refurb Dell workstations that cost $450 each, with an additional 16GB RAM,
> ($190 each), an auxiliary drive bay power supply ($25!) and 2 GTX 780s
> ($850/pair).  So each render node's hardware was about $1500, the Redshift
> license is $500, and I get much better performance from each node than I
> see from brand-new $10K 20-core CPU render boxes.
>
>
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Tim Crowson
1) it slows down the most when sending geometry out of core, and frankly 
even that ain't all that bad. 'Significantly' is relative here when it's 
already that fast.
2) There is currently a hard-coded 4GB cap on on-board geo cache, to try 
and balance performance in these early stages. So even if your card has 
6+, it will send geo out of core if hits 4GB. The devs have talked about 
upping this though, especially with bigger cards coming along.
3) I can't recall the exact numbers, but they're able to fit roughly 
110-120M unique triangles in 4GB, that geo being simple geo with a 
single UV mesh.
4) Biased man I'm not gonna split hairs on this. If that's a big 
deal for you it's a big deal for you. Seems like the sort of thing 
Archviz people would care about more than VFX or Animation folks. 
Redshift does have a hearty Monte-Carlo-only mode that I am partial too 
though
5) I lit and rendered all 75 of my shots on Yellowday 
 in about 30 days on 12 multi-GPU 
boxes. The toughest shots' frame times averaged 45min/f, with most in 
the 5-15m range, and several far faster than that. The densest shots 
here used about 8-9GB total, IIRC.
6) As always, everything is relative to your business and what the needs 
of your production are. No news there.


-Tim


On 10/3/2014 1:34 PM, Simon van de Lagemaat wrote:
At the cost of a smaller fast memory pool?  From what I understand 
Redshift slows down significantly when it starts using off board RAM?  
I know this is one of the main reasons many other renderers haven't 
gone to the GPU yet since cards with decent amounts of memory are 
still priced far too high.


How is Redshift with overall memory usage?  i.e. what is the memory 
footprint per polygon etc.  Also it's biased correct?  I 
become nauseous when someone mentions that word, is their approach 
better than other IC approaches?  Similar pitfalls?


I may try it this weekend on my 780gtx (only 3GB onboard) at home 
since it's been getting good PR here.  With the type of memory heavy 
rendering we do for film and the efficient platform agnostic pipeline 
friendly workflow we have with Arnold I don't see it being useful 
outside some smaller commercial jobs but I'd like to get a taste of 
the speed and interactivity. I suppose if we were a 5 person shop 
again something like RS would be a godsend.


On Fri, Oct 3, 2014 at 11:06 AM, Steven Caron > wrote:


that extra GPU power is a dramatic increase in speed though.




--
Signature



Re: Glasswoks Lycra

2014-10-03 Thread Tim Crowson
What's really awesome is that these cards are not only getting better, 
but cheaper too. The 900 series was just released and packs a punch for 
not a whole lot of money. Redshift excells with these so-called 'gaming' 
cards.


-Tim


On 10/3/2014 1:52 PM, Simon van de Lagemaat wrote:
So SLI seems to be the most cost efficient method i.e. double the 
power per physical box...  nice thing is you can probably upgrade 
those GPU's across a few generations without upgrading the rest of the 
system since the PCI specs don't change much and power draw tends to 
decrease with newer cards.


I mean, it's not cheap but I'll assume the dollar per flops ratio is 
way higher.


On Fri, Oct 3, 2014 at 11:43 AM, Ed Manning > wrote:


Ditto.  total gamechanger. Redshift is literally the only thing
that kept me from closing up shop. I had priced out new multicore
render nodes, and licenses for VRay and Arnold, as well as testing
Arion, Octane and more obscure options, and the numbers just
didn't make sense.  I was going to just not be able to continue
doing the type of remote work my clients expect on the schedules
they need, and make enough money for it to be worth doing.

For example, I'm just putting 2 new render machines online -
they're refurb Dell workstations that cost $450 each, with an
additional 16GB RAM, ($190 each), an auxiliary drive bay power
supply ($25!) and 2 GTX 780s ($850/pair).  So each render node's
hardware was about $1500, the Redshift license is $500, and I get
much better performance from each node than I see from brand-new
$10K 20-core CPU render boxes.







--
Signature




Re: Glasswoks Lycra

2014-10-03 Thread Steven Caron
let's not get 'pokey' here, apples and oranges. unless you have
'progressive' on in redshift, it is re exporting the data each time. in
sitoa you just turn scene rebuild mode to 'always' and it is the same
thing. my findings were i couldn't use 'progressive' similar to how sitoa
does... so, apples and oranges.

back to how awesome redshift is and how much talent glassworks' has...

On Fri, Oct 3, 2014 at 11:34 AM, Rob Chapman  wrote:

> Not having to kick ass or rewind a frame for evey render region preview is
> a huge time saver on its own..
> On 3 Oct 2014 19:12, "Steven Caron"  wrote:
>
>> hey emilio
>>
>> which rendering engines do you use?
>>
>>


Re: Glasswoks Lycra

2014-10-03 Thread Steven Caron
i meant... which rendering engines do you use in redshift :P

On Fri, Oct 3, 2014 at 11:42 AM, Emilio Hernandez  wrote:

> Since Redshift appeared, mostly I used Mental Ray since Softimage 3D 3.5
>
> I used Maxwell, Arnold, 3Delight, Fury and I was in the beta testers of
> V-ray.  But when finally Redshift came out in its Alpha stage, and I was
> able to participate in the group. I knew this was the render engine I was
> expecting for Softimage.
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Tim Crowson

I know you asked Emilio, but I'll answer for my part: BF+BF or BF+IPC.
-Tim

On 10/3/2014 2:08 PM, Steven Caron wrote:

i meant... which rendering engines do you use in redshift :P

On Fri, Oct 3, 2014 at 11:42 AM, Emilio Hernandez > wrote:


Since Redshift appeared, mostly I used Mental Ray since Softimage
3D 3.5

I used Maxwell, Arnold, 3Delight, Fury and I was in the beta
testers of V-ray.  But when finally Redshift came out in its Alpha
stage, and I was able to participate in the group. I knew this was
the render engine I was expecting for Softimage.




--
Signature


Re: Glasswoks Lycra

2014-10-03 Thread Steven Caron
their memory footprint is very similar to arnold. ie. cost per triangle and
the attributes associated to it redshift guys have done a great job with
their 'out of core' performance.

redshift has brute force modes, you can get it to behave like arnold just
like you can get vray to behave like arnold.

On Fri, Oct 3, 2014 at 11:34 AM, Simon van de Lagemaat <
si...@theembassyvfx.com> wrote:

> At the cost of a smaller fast memory pool?  From what I understand
> Redshift slows down significantly when it starts using off board RAM?  I
> know this is one of the main reasons many other renderers haven't gone to
> the GPU yet since cards with decent amounts of memory are still priced far
> too high.
>
> How is Redshift with overall memory usage?  i.e. what is the memory
> footprint per polygon etc.  Also it's biased correct?  I
> become nauseous when someone mentions that word, is their approach better
> than other IC approaches?  Similar pitfalls?
>
> I may try it this weekend on my 780gtx (only 3GB onboard) at home since
> it's been getting good PR here.  With the type of memory heavy rendering we
> do for film and the efficient platform agnostic pipeline friendly workflow
> we have with Arnold I don't see it being useful outside some smaller
> commercial jobs but I'd like to get a taste of the speed and interactivity.
> I suppose if we were a 5 person shop again something like RS would be a
> godsend.
>
> On Fri, Oct 3, 2014 at 11:06 AM, Steven Caron  wrote:
>
>> that extra GPU power is a dramatic increase in speed though.
>>
>>
>>


Re: Glasswoks Lycra

2014-10-03 Thread Emilio Hernandez
Haha.

Regularly I use as the Primary Brute Force, and for the secondary IPC.

Cheers!

---
Emilio Hernández   VFX & 3D animation.

2014-10-03 14:08 GMT-05:00 Steven Caron :

> i meant... which rendering engines do you use in redshift :P
>
> On Fri, Oct 3, 2014 at 11:42 AM, Emilio Hernandez 
> wrote:
>
>> Since Redshift appeared, mostly I used Mental Ray since Softimage 3D 3.5
>>
>> I used Maxwell, Arnold, 3Delight, Fury and I was in the beta testers of
>> V-ray.  But when finally Redshift came out in its Alpha stage, and I was
>> able to participate in the group. I knew this was the render engine I was
>> expecting for Softimage.
>>
>>
>>


Re: Muscle system. Free/

2014-10-03 Thread David Rivera
YES!

 
David Rivera
3D Compositor/Animator
LinkedIN
Behance
VFX Reel


On Wednesday, September 24, 2014 4:27 AM, Jordi Bares  
wrote:
 


Another reason to keep using XSI… wow… thanks 


Jordi Bares
jordiba...@gmail.com

On 24 Sep 2014, at 09:31, Max Evgrafov  wrote:

https://vimeo.com/106103487
>
>
>plug https://www.dropbox.com/s/ptwaw35rfz2mutf/VorleXMuscleSystem2PRO.zip?dl=0
>
>doc 
>https://www.dropbox.com/s/lx2fv87vvq91gzd/VorleXShapeKeyCreationTechnique.doc?dl=0
>
>
>-- 
>Евграфов Максим.(Summatr)
>https://vimeo.com/user3098735/videos  
>---
>Хорошего Вам настроения !!! :-)

Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
I suppose there's also no density processing tax that Intel likes to levy
on the xeon silicone along with the shitty extra dollars for ecc ram and
server class motherboards.  They really aren't growing any positive karma
with that.

On Fri, Oct 3, 2014 at 12:07 PM, Tim Crowson  wrote:

>  What's really awesome is that these cards are not only getting better,
> but cheaper too. The 900 series was just released and packs a punch for not
> a whole lot of money. Redshift excells with these so-called 'gaming' cards.
>
> -Tim
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
Ya sorry I totally derailed this thread... the work was amazing!!!

On Fri, Oct 3, 2014 at 12:07 PM, Steven Caron  wrote:

>
>
> back to how awesome redshift is and how much talent glassworks' has...
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Steven Caron
haha, thanks. that is what i figured.. most people using vray do something
similar with their brute force + light cache


On Fri, Oct 3, 2014 at 12:13 PM, Emilio Hernandez  wrote:

> Haha.
>
> Regularly I use as the Primary Brute Force, and for the secondary IPC.
>
> Cheers!
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
With Modo we almost always ended up using brute force because the IC
methods were just far to skittish no matter how much you dialed things up.
I think since then they've implemented some hybrid approach as well.

I still think the future is bidirectional with beastly hardware dealing
with any noise but for now I'm curious to try out RS.  Seems like the raw
speed is over riding any other concerns especially on smaller jobs.

On Fri, Oct 3, 2014 at 12:20 PM, Steven Caron  wrote:

> haha, thanks. that is what i figured.. most people using vray do something
> similar with their brute force + light cache
>
>
>


Re: Muscle system. Free/

2014-10-03 Thread Michael Clarke
THANK  YOU. MAX.

Can’t wait to give this a try.



Michael Clarke Design
Blue C Studios
713-927-9835

On Oct 3, 2014, at 2:15 PM, David Rivera  wrote:

> YES!
>  
> David Rivera
> 3D Compositor/Animator
> LinkedIN
> Behance
> VFX Reel
> 
> 
> On Wednesday, September 24, 2014 4:27 AM, Jordi Bares  
> wrote:
> 
> 
> Another reason to keep using XSI… wow… thanks 
> 
> Jordi Bares
> jordiba...@gmail.com
> 
> On 24 Sep 2014, at 09:31, Max Evgrafov  wrote:
> 
>> https://vimeo.com/106103487
>> 
>> plug 
>> https://www.dropbox.com/s/ptwaw35rfz2mutf/VorleXMuscleSystem2PRO.zip?dl=0
>> 
>> doc 
>> https://www.dropbox.com/s/lx2fv87vvq91gzd/VorleXShapeKeyCreationTechnique.doc?dl=0
>> 
>> -- 
>> Евграфов Максим.(Summatr)
>> https://vimeo.com/user3098735/videos  
>> ---
>> Хорошего Вам настроения !!! :-)
> 
> 
> 



Re: Glasswoks Lycra

2014-10-03 Thread Ed Manning
On Fri, Oct 3, 2014 at 2:52 PM, Simon van de Lagemaat <
si...@theembassyvfx.com> wrote:

> So SLI seems to be the most cost efficient method i.e. double the power
> per physical box...  nice thing is you can probably upgrade those GPU's
> across a few generations without upgrading the rest of the system since the
> PCI specs don't change much and power draw tends to decrease with newer
> cards.
>
> I mean, it's not cheap but I'll assume the dollar per flops ratio is way
> higher.
>

Actually, SLI doesn't enter into it -- Redshift doesn't use it, and if your
cards are wired up with an SLI bridge, you need to disable it in the nVidia
settings.


Re: Glasswoks Lycra

2014-10-03 Thread Simon van de Lagemaat
But still distributing one frame across two cards right?

On Fri, Oct 3, 2014 at 12:46 PM, Ed Manning  wrote:

>
>
> Actually, SLI doesn't enter into it -- Redshift doesn't use it, and if
> your cards are wired up with an SLI bridge, you need to disable it in the
> nVidia settings.
>
>
>


Re: Glasswoks Lycra

2014-10-03 Thread Rob Chapman
ah I see and no I do not use progressive mode as am just wanting a preview
whilst tweaking stuff so yes to see any changes made one will have to
resubmit the scene. honestly did not know about the auto update in Arnold
will switch it on next time I'm contrasting and comparing, thanks for the
tip.




On 3 October 2014 20:07, Steven Caron  wrote:

> let's not get 'pokey' here, apples and oranges. unless you have
> 'progressive' on in redshift, it is re exporting the data each time. in
> sitoa you just turn scene rebuild mode to 'always' and it is the same
> thing. my findings were i couldn't use 'progressive' similar to how sitoa
> does... so, apples and oranges.
>
> back to how awesome redshift is and how much talent glassworks' has...
>
> On Fri, Oct 3, 2014 at 11:34 AM, Rob Chapman  wrote:
>


Re: Glasswoks Lycra

2014-10-03 Thread Ed Manning
On Fri, Oct 3, 2014 at 3:49 PM, Simon van de Lagemaat <
si...@theembassyvfx.com> wrote:

> But still distributing one frame across two cards right?
>
> yes.  IIR, the docs say up to 8 cards per host.  though there is a decline
in returns, so I think most people don't go over 3.


Re: Glasswoks Lycra

2014-10-03 Thread ola.mad...@digitalcontext.se
Yes, there seems to be a decline at 3 cards. But another great thing about 
redshift is that you can render multiple tasks simultaneously so card 1 & 2 
render frame 1 and card 3 & 4 render frame 2, etc. this is fully supported with 
Deadline (don't know about royal render, but I think someone said it was 
supported as well). 

Cheers
Ola


> 3 okt 2014 kl. 21:54 skrev Ed Manning :
> 
>> On Fri, Oct 3, 2014 at 3:49 PM, Simon van de Lagemaat 
>>  wrote:
>> But still distributing one frame across two cards right?
> yes.  IIR, the docs say up to 8 cards per host.  though there is a decline in 
> returns, so I think most people don't go over 3. 


Re: Glasswoks Lycra

2014-10-03 Thread Mirko Jankovic
yes that is exactly what I'm doing.
4 titans using all together when tweaking everything pulling  speed from
them, and then in most of cases sending to Deadline with 4 of them each
rendering 1 frame or 2 by 2.
Really good support in Deadline for that .

On Fri, Oct 3, 2014 at 11:50 PM, ola.mad...@digitalcontext.se <
ola.mad...@digitalcontext.se> wrote:

> Yes, there seems to be a decline at 3 cards. But another great thing about
> redshift is that you can render multiple tasks simultaneously so card 1 & 2
> render frame 1 and card 3 & 4 render frame 2, etc. this is fully supported
> with Deadline (don't know about royal render, but I think someone said it
> was supported as well).
>
> Cheers
> Ola
>
>
> 3 okt 2014 kl. 21:54 skrev Ed Manning :
>
> On Fri, Oct 3, 2014 at 3:49 PM, Simon van de Lagemaat <
> si...@theembassyvfx.com> wrote:
>
>> But still distributing one frame across two cards right?
>>
>> yes.  IIR, the docs say up to 8 cards per host.  though there is a
> decline in returns, so I think most people don't go over 3.
>
>


Re: Glasswoks Lycra

2014-10-03 Thread ola.mad...@digitalcontext.se
Yes, it's a really sweet setup. And it still only requires one license per 
machine even if you run separate tasks on each card. 

We're using a mixtures of Titans, 780ti and tesla cards and I can only second 
what everyone else is saying. It's ridiculous fast. 

O



> 3 okt 2014 kl. 23:57 skrev Mirko Jankovic :
> 
> yes that is exactly what I'm doing. 
> 4 titans using all together when tweaking everything pulling  speed from 
> them, and then in most of cases sending to Deadline with 4 of them each 
> rendering 1 frame or 2 by 2.
> Really good support in Deadline for that . 
> 
>> On Fri, Oct 3, 2014 at 11:50 PM, ola.mad...@digitalcontext.se 
>>  wrote:
>> Yes, there seems to be a decline at 3 cards. But another great thing about 
>> redshift is that you can render multiple tasks simultaneously so card 1 & 2 
>> render frame 1 and card 3 & 4 render frame 2, etc. this is fully supported 
>> with Deadline (don't know about royal render, but I think someone said it 
>> was supported as well). 
>> 
>> Cheers
>> Ola
>> 
>> 
>>> 3 okt 2014 kl. 21:54 skrev Ed Manning :
>>> 
 On Fri, Oct 3, 2014 at 3:49 PM, Simon van de Lagemaat 
  wrote:
 But still distributing one frame across two cards right?
>>> yes.  IIR, the docs say up to 8 cards per host.  though there is a decline 
>>> in returns, so I think most people don't go over 3. 
> 


Re: Glasswoks Lycra

2014-10-03 Thread Jason S

  
  
Once I tried the classroom, but with
  literally everything everywhere displaced at a level of less than
  a pixel.. a blurry reflection scene material , many many area
  lights and with a wild camera move, to make motion blurred very
  dense displaced geo  all over the frame (with 1st bouce brute
  force GI) , to make the most nightmareish sampling task as
  possible,
  and rendered a 1080p frame in 14 min (to get where noise was at an
  acceptable amount) (.. and I was floored! :]
  (non-tweaked to death settings took 2h)
  
  Would have taken several -hours- if not days with anything else!
  
  Made like a full screen of (mostly noise free) fine-fine trail
  lines (under little redshift logos :] )
  
  
  
  On 10/03/14 18:44, ola.mad...@digitalcontext.se wrote:


  
  Yes, it's a really sweet setup. And it still only requires
one license per machine even if you run separate tasks on each
card. 
  
  
  We're using a mixtures of Titans, 780ti and tesla cards and I
can only second what everyone else is saying. It's ridiculous
fast. 
  
  
  O
  

  
  
3 okt 2014 kl. 23:57 skrev Mirko Jankovic :

  
  

  yes that is exactly what I'm doing. 
4 titans using all together when tweaking everything
  pulling  speed from them, and then in most of cases
  sending to Deadline with 4 of them each rendering 1 frame
  or 2 by 2.
Really good support in Deadline for that . 
  
  
On Fri, Oct 3, 2014 at 11:50 PM, ola.mad...@digitalcontext.se
  
  wrote:
  

  Yes, there seems to be a decline at 3 cards. But
another great thing about redshift is that you can
render multiple tasks simultaneously so card 1 &
2 render frame 1 and card 3 & 4 render frame 2,
etc. this is fully supported with Deadline (don't
know about royal render, but I think someone said it
was supported as well). 
  
  
  Cheers
  Ola

  
  
3 okt 2014 kl. 21:54 skrev Ed Manning :

  
  

  

  
On Fri, Oct 3, 2014
  at 3:49 PM, Simon van de Lagemaat 
  wrote:
  
But still distributing
  one frame across two cards right?

  
  

  
  
  yes.  IIR, the docs say up to 8 cards
per host.  though there is a decline in
returns, so I think most people don't go
over 3. 

  

  

  
  


  

  


  



Re: Glasswoks Lycra

2014-10-03 Thread Jason S

  
  
Redshift is a noise cruncher :]
  
  (and soft is a production cruncher :] )
  
  On 10/03/14 20:11, Jason S wrote:


  
  Once I tried the classroom, but with
literally everything everywhere displaced at a level of less
than a pixel.. a blurry reflection scene material , many many
area lights and with a wild camera move, to make motion blurred
very dense displaced geo  all over the frame (with 1st bouce
brute force GI) , to make the most nightmareish sampling task as
possible,
and rendered a 1080p frame in 14 min (to get where noise was at
an acceptable amount) (.. and I was floored! :]
(non-tweaked to death settings took 2h)

Would have taken several -hours- if not days with anything else!

Made like a full screen of (mostly noise free) fine-fine trail
lines (under little redshift logos :] )



On 10/03/14 18:44, ola.mad...@digitalcontext.se
wrote:
  
  

Yes, it's a really sweet setup. And it still only requires
  one license per machine even if you run separate tasks on each
  card. 


We're using a mixtures of Titans, 780ti and tesla cards and
  I can only second what everyone else is saying. It's
  ridiculous fast. 


O

  


  3 okt 2014 kl. 23:57 skrev Mirko Jankovic :
  


  
yes that is exactly what I'm doing. 
  4 titans using all together when tweaking everything
pulling  speed from them, and then in most of cases
sending to Deadline with 4 of them each rendering 1
frame or 2 by 2.
  Really good support in Deadline for that . 


  On Fri, Oct 3, 2014 at 11:50 PM,
ola.mad...@digitalcontext.se

wrote:

  
Yes, there seems to be a decline at 3 cards.
  But another great thing about redshift is that you
  can render multiple tasks simultaneously so card 1
  & 2 render frame 1 and card 3 & 4 render
  frame 2, etc. this is fully supported with
  Deadline (don't know about royal render, but I
  think someone said it was supported as well). 


Cheers
Ola
  


  3 okt 2014 kl. 21:54 skrev Ed Manning :
  


  

  

  On Fri, Oct 3,
2014 at 3:49 PM, Simon van de Lagemaat 
wrote:

  But still distributing
one frame across two cards right?
  


  


yes.  IIR, the docs say up to 8
  cards per host.  though there is a
  decline in returns, so I think most
  people don't go over 3. 
  

  

  


  
  

  

  
  


  



Procedural Animation for Blender

2014-10-03 Thread Paulo Cesar Duarte
Very nice: https://www.youtube.com/watch?v=l-2UG4dklD0

Looks something similar to MoGraph in Cinema 4d.


Cheers.
Paulo Duarte

-- 
paulo-duarte.com


Re: Procedural Animation for Blender

2014-10-03 Thread Sebastien Sterling
Sigh, wish blender had a better less cluttered UI.

On 4 October 2014 05:35, Paulo Cesar Duarte  wrote:

> Very nice: https://www.youtube.com/watch?v=l-2UG4dklD0
>
> Looks something similar to MoGraph in Cinema 4d.
>
>
> Cheers.
> Paulo Duarte
>
> --
> paulo-duarte.com
>