RE: Re[2]: Survey - how would you do this?

[Brent McPherson]

In general most games draw all their own custom UI on top of the graphics 
library so the platform-specific code footprint would be much less than in an 
application like Softimage which is built on top of the native UI toolkit. e.g. 
games are typically implemented in a single OpenGL/DirectX window.

In terms of emulation technology you are not going to get any better than 
Mainwin since it was developed directly from the Windows source code and is 
natively compiled. I doubt any other emulation library would achieve the 
required level of compatibility to run Softimage. The only viable solution IMO 
is to use virtualization technology to run windows on your Mac or dual-boot etc.

Cheers.
--
Brent

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Angus Davidson
Sent: 17 February 2014 11:51
To: softimage@listproc.autodesk.com
Subject: Re: Re[2]: Survey - how would you do this?

Hi Brent

Very well explained thank you. I do agree that because of the overall 
crappiness of Windows COM has got a bad rep. Unfortunately its very hard for 
most people to know where one begins and the other ends and in the end the 
overall perception is the one that sticks.

On a slightly unrelated note I was patching my wifes GuildWars 2 and instead of 
downloading the whole data file I just copied it from my mac install to her 
windows one. Seems that GW2 is pretty much running in emulation mode using 
Transgaming Cider.  For those of you who may have played GW2 know its very 
graphics intensive and I comfortable get 45-60fps on max settings.

Anyone know if the way Softimage is put together would preclude it from coming 
to the Mac using this type of technology rather then rewriting it ?

Kind regards

Angus



From: Brent McPherson 
mailto:brent.mcpher...@autodesk.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Monday 17 February 2014 at 1:06 PM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: RE: Re[2]: Survey - how would you do this?

On the subject of Windows I have an interesting perspective because prior to 
1998 I worked at Alias.

At that time Alias believed that Windows would be the dominant platform going 
forward and there was a lot of talk about using Mainwin (or one of the other 
Windows emulation frameworks available at the time) on IRIX to ease the burden 
of cross-platform development. The only saving grace was that Maya was designed 
to be cross-platform so even if we had switched to say Mainwin it wouldn't have 
locked the product into a single platform. I am saying this because in 1998 
computing was dominated by Windows/Microsoft and the decisions made by 
Softimage made perfect sense. (and I could imagine making similar decisions if 
Maya's development had started a few years later when Windows PCs took over 
from workstations)

COM is a different thing and it is a shame it has become synonymous with 
Windows. Rather COM is a set of rules and conventions designed to support 
interface-based programing in C++ since the language does not have direct 
support for this built-in. OOP got one thing fundamentally wrong in that it was 
overly concerned with code reuse through inheritance. Inheritance in retrospect 
turned out to be a bad thing because it mixes the two (unrelated) concepts of 
interface and implementation. The end result is usually code that is harder to 
maintain and change since changes in low-level classes have a tendency to 
ripple outwards to many parts of the system. (something we call 
"tight-coupling" in the programming world)

The reality is that most code in a large application is not reusable and reuse 
generally only happens with low-level libraries that are carefully crafted and 
designed to be reusable. A COM interface is a black box designed to separate 
interface from implementation and different objects can implement the same 
interface in different ways or masquerade as other objects using the magic of 
interfaces. This helps limit the scope of changes in the system and gives 
developers more flexibility at the application level. An interesting example 
that comes to mind is the quaternion fcurves in Softimage which are COM objects 
that masquerade as regular fcurves. As a result very little code needed to be 
modified to display or interact with them since most of the system *sees* them 
as regular fcurves.

So in summary Windows bad, COM good. ;-)
--
Brent

From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Emilio Hernandez
Sent: 14 February 2014 17:17
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Re[2]: Survey - how would 

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

that's based on WINE for OSX.  you can go ahead and try it yourself.

On Monday, February 17, 2014, Angus Davidson 
wrote:

>  Hi Brent
>
>  Very well explained thank you. I do agree that because of the overall
> crappiness of Windows COM has got a bad rep. Unfortunately its very hard
> for most people to know where one begins and the other ends and in the end
> the overall perception is the one that sticks.
>
>  On a slightly unrelated note I was patching my wifes GuildWars 2 and
> instead of downloading the whole data file I just copied it from my mac
> install to her windows one. Seems that GW2 is pretty much running in
> emulation mode using Transgaming Cider.  For those of you who may have
> played GW2 know its very graphics intensive and I comfortable get 45-60fps
> on max settings.
>
>  Anyone know if the way Softimage is put together would preclude it from
> coming to the Mac using this type of technology rather then rewriting it ?
>
>  Kind regards
>
>  Angus
>
>
>

Re: Re[2]: Survey - how would you do this?

[Angus Davidson]

Hi Brent

Very well explained thank you. I do agree that because of the overall 
crappiness of Windows COM has got a bad rep. Unfortunately its very hard for 
most people to know where one begins and the other ends and in the end the 
overall perception is the one that sticks.

On a slightly unrelated note I was patching my wifes GuildWars 2 and instead of 
downloading the whole data file I just copied it from my mac install to her 
windows one. Seems that GW2 is pretty much running in emulation mode using 
Transgaming Cider.  For those of you who may have played GW2 know its very 
graphics intensive and I comfortable get 45-60fps on max settings.

Anyone know if the way Softimage is put together would preclude it from coming 
to the Mac using this type of technology rather then rewriting it ?

Kind regards

Angus



From: Brent McPherson 
mailto:brent.mcpher...@autodesk.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Monday 17 February 2014 at 1:06 PM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: RE: Re[2]: Survey - how would you do this?

On the subject of Windows I have an interesting perspective because prior to 
1998 I worked at Alias.

At that time Alias believed that Windows would be the dominant platform going 
forward and there was a lot of talk about using Mainwin (or one of the other 
Windows emulation frameworks available at the time) on IRIX to ease the burden 
of cross-platform development. The only saving grace was that Maya was designed 
to be cross-platform so even if we had switched to say Mainwin it wouldn't have 
locked the product into a single platform. I am saying this because in 1998 
computing was dominated by Windows/Microsoft and the decisions made by 
Softimage made perfect sense. (and I could imagine making similar decisions if 
Maya's development had started a few years later when Windows PCs took over 
from workstations)

COM is a different thing and it is a shame it has become synonymous with 
Windows. Rather COM is a set of rules and conventions designed to support 
interface-based programing in C++ since the language does not have direct 
support for this built-in. OOP got one thing fundamentally wrong in that it was 
overly concerned with code reuse through inheritance. Inheritance in retrospect 
turned out to be a bad thing because it mixes the two (unrelated) concepts of 
interface and implementation. The end result is usually code that is harder to 
maintain and change since changes in low-level classes have a tendency to 
ripple outwards to many parts of the system. (something we call 
"tight-coupling" in the programming world)

The reality is that most code in a large application is not reusable and reuse 
generally only happens with low-level libraries that are carefully crafted and 
designed to be reusable. A COM interface is a black box designed to separate 
interface from implementation and different objects can implement the same 
interface in different ways or masquerade as other objects using the magic of 
interfaces. This helps limit the scope of changes in the system and gives 
developers more flexibility at the application level. An interesting example 
that comes to mind is the quaternion fcurves in Softimage which are COM objects 
that masquerade as regular fcurves. As a result very little code needed to be 
modified to display or interact with them since most of the system *sees* them 
as regular fcurves.

So in summary Windows bad, COM good. ;-)
--
Brent

From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Emilio Hernandez
Sent: 14 February 2014 17:17
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Re[2]: Survey - how would you do this?

It is really a shame that Autodesk when bought Softimage, instead of starting 
the migration from the COM/OLE platform, just took the guts outs of Softimage.  
The Dev team. To insert it in Maya, which, IMHO is sitll basically the same 
from those days.  I have not seen any "super development" of Maya as it would 
be expected by such corporate strategy...  If by now, Maya had the 
functionality, beauty, elegance, design, and workflow of Softimage,  the story 
would be different.
I am married to Softimage until "death tear us appart".

Maybe it is not Softimage's days the only ones that are counted...
Autodesk has been loosing market lately, and has been unsuccesful of driving 
the "small" but solid Softimage user base to Maya.  And when the time comes, my 
perception is that the mayority of us, at least in the film/vfx industry is 
looking to other platforms rather than Maya.  They betted

RE: Re[2]: Survey - how would you do this?

[Brent McPherson]

On the subject of Windows I have an interesting perspective because prior to 
1998 I worked at Alias.

At that time Alias believed that Windows would be the dominant platform going 
forward and there was a lot of talk about using Mainwin (or one of the other 
Windows emulation frameworks available at the time) on IRIX to ease the burden 
of cross-platform development. The only saving grace was that Maya was designed 
to be cross-platform so even if we had switched to say Mainwin it wouldn't have 
locked the product into a single platform. I am saying this because in 1998 
computing was dominated by Windows/Microsoft and the decisions made by 
Softimage made perfect sense. (and I could imagine making similar decisions if 
Maya's development had started a few years later when Windows PCs took over 
from workstations)

COM is a different thing and it is a shame it has become synonymous with 
Windows. Rather COM is a set of rules and conventions designed to support 
interface-based programing in C++ since the language does not have direct 
support for this built-in. OOP got one thing fundamentally wrong in that it was 
overly concerned with code reuse through inheritance. Inheritance in retrospect 
turned out to be a bad thing because it mixes the two (unrelated) concepts of 
interface and implementation. The end result is usually code that is harder to 
maintain and change since changes in low-level classes have a tendency to 
ripple outwards to many parts of the system. (something we call 
"tight-coupling" in the programming world)

The reality is that most code in a large application is not reusable and reuse 
generally only happens with low-level libraries that are carefully crafted and 
designed to be reusable. A COM interface is a black box designed to separate 
interface from implementation and different objects can implement the same 
interface in different ways or masquerade as other objects using the magic of 
interfaces. This helps limit the scope of changes in the system and gives 
developers more flexibility at the application level. An interesting example 
that comes to mind is the quaternion fcurves in Softimage which are COM objects 
that masquerade as regular fcurves. As a result very little code needed to be 
modified to display or interact with them since most of the system *sees* them 
as regular fcurves.

So in summary Windows bad, COM good. ;-)
--
Brent

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Emilio Hernandez
Sent: 14 February 2014 17:17
To: softimage@listproc.autodesk.com
Subject: Re: Re[2]: Survey - how would you do this?

It is really a shame that Autodesk when bought Softimage, instead of starting 
the migration from the COM/OLE platform, just took the guts outs of Softimage.  
The Dev team. To insert it in Maya, which, IMHO is sitll basically the same 
from those days.  I have not seen any "super development" of Maya as it would 
be expected by such corporate strategy...  If by now, Maya had the 
functionality, beauty, elegance, design, and workflow of Softimage,  the story 
would be different.
I am married to Softimage until "death tear us appart".

Maybe it is not Softimage's days the only ones that are counted...
Autodesk has been loosing market lately, and has been unsuccesful of driving 
the "small" but solid Softimage user base to Maya.  And when the time comes, my 
perception is that the mayority of us, at least in the film/vfx industry is 
looking to other platforms rather than Maya.  They betted to the wrong horse, 
again imho.  Maybe I am wrong.  But only time will tell.



[http://img694.imageshack.us/img694/8965/erojamailpleca.jpg]

2014-02-14 10:15 GMT-06:00 Angus Davidson 
mailto:angus.david...@wits.ac.za>>:

For historical perspective, you need to know that we were owned by
Microsoft in 1998, and there was no indication that SGI or the Mac
would come back from the dead.  The company began to consider the Film
industry as "legacy" and that games would be the future.  The product
was named after the name of the game exchange format to subtly suggest
that.  Max also had taken the Windows NT jump, with huge success.
Well Microsoft hasnt gotten any better at predicting tech since.  Smart phones, 
tablets, pretty much anything internet based ;)=


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 

Re[4]: Survey - how would you do this?

[Eugen Sares]

Good to hear - both that they are planning a stack, and that you might
not need it... ; )
I do need it quite often, though. Doing corrections on the modeling in
the scene is just part of the workflow.

I see Modo as my escape route, in the years to come, should Autodesk
continue to hold us on such a tight leash - needlessly, or out of
dubious reasons.
Of course that remains to be validated, but at least Modo seems to have
a 'bright future'.
Softimage still has great potential, but the heap of all the things that
need attention doesn't seem to get much smaller as it seems.


-- Originalnachricht --
Von: "Angus Davidson" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 15.02.2014 07:32:16
Betreff: RE: Re[2]: Survey - how would you do this?


To me it isnt a deal breaker as the things I would need to change (for
example if the client wanted more rocks , or a bigger circumference on
the asteroid belt ) are still there and can be edited on the fly. If
you drill down on your objects in the list on the right hand side you
now get a very wide array of things to play with.  I havent so far come
up with something where I found I was missing the functionality of
Softimage stack. In most cases it was just poking around what was there
to find out where to modify things.

As far as I know its on the todo list for 801. How they find middle
ground between what they have now and something like what we have in
softimage remains to be seen.

I think its mostly that folks are just very set in their ways and tend
to cling to things rather then do things a different way.  The folks I
know that have switched  from Softimage to Modo full-time complained at
first but are now just as efficient and flexible as before.





From: Eugen Sares [sof...@mail.sprit.org]
Sent: 14 February 2014 11:46 PM
To:softimage@listproc.autodesk.com
Subject: Re[2]: Survey - how would you do this?

Last time I looked Modo did not have an operator graph / modifier stack
or sorts. Linear workflow, so to speak. Isn't that a dealbreaker,
really?
Or is it me being used to that so much I can't imagine going without?
Any news on the subject? Is The Foundry planning for anything? (Not
talking about deformers)


-- Originalnachricht --
Von: "Angus Davidson" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 14.02.2014 22:32:43
Betreff: RE: Survey - how would you do this?


Hi Ben

I take your point on COM. Do you know if the Mac / Linux versions use
Com wrappers or recreate the functionality in a different way.

Must admit I was blown away by the redshift alpha. Unfortunately I
dont have regular access to the GPUs that really make it shine.

I think a lot depends on what happens with the 2015 release of
Softimage. (which should be soonish). A lot of folks felt very burned
by what they got last year, and have very grudgingly paid their subs
for this year. If its not a very solid affirmation of Softimage
getting the love it deserves people are not going to pay top dollar
for very little in return again. The VFX economy is not in great
shape. People just cant be taking those kind of chances going forward.
Once that happens Softimage is effectively dead as a product from a
sales point of view. Personally I hope Autodesk finally realizes how
stupid they are being and actually puts the right number of resources
to work on Softimage. Realistically I suspect I have more chance of
getting a mac version ;(

Autodesk mishandling of Softimage is not likely to move many people to
Maya. Once trust is broken with a company it tends to include their
whole offering. so they will need to go somewhere. Once that happens
the renderer companies will follow.

I am a bit more optimistic about external renderer's finding their way
to Modo, Octane and  Thea are already there or on their way. Once Modo
market share increases it will become more attractive to plug your
renderer into. Personally Arnold for me would be awesome as I have
access to far more CPU rendering power.





From: Ben Rogall [xsi_l...@shaders.moederogall.com]
Sent: 14 February 2014 10:41 PM
To:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Hi Angus

Yep, I just wanted to make the point that someone was able to do that
on top of COM. I'm fond of Modo too, especially for modeling and the
Luxology people seem really reasonable. I was doing some rendering in
Modo too, but then Redshift came along.

On 2/14/2014 11:57 AM, Angus Davidson wrote:

Hi Ben

The big difference is Modo is also successfully cross platform, and
in active development. When the time comes to move on they will be in
a position to do so.

Something Softimage currently lacks.  Which is something Autodesk
will regret down the line.


-

RE: Survey - how would you do this?

[Angus Davidson]

Hi Matt

Huge fan of the look and feel of Wildstar.  Havent had a MMO with an 
exceptional cartoony style since Wow. Everyone in between has always tried the 
same formula so its refreshing to see.

Good luck




From: Matt Lind [ml...@carbinestudios.com]
Sent: 14 February 2014 11:53 PM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

Watch the video here:   http://www.wildstar-online.com/en/news/#page1

At various times you’ll see asteroid belts of various radius, density, and 
orbital speed.  We needed to create a dense asteroid belt for a closeup.

We don’t do photo-real.  The emotional effect from shape and movement is more 
important as the game is largely based on a comic book style.  Take a peek at 
the screenshots and other media for more examples.

>From a technical point of view, since this asteroid belt must perform in a 
>real time environment, must be optimal in use of resources.  The challenge was 
>this asteroid belt had to be created by a junior artist with no technical 
>skills and done in rapid fashion unsupervised.  The question is how do you 
>instruct such a person to create the asteroid belt to get the task done 
>quickly (< 30 minutes), effectively, and with minimal risk against immediate 
>and long term objectives related to pipeline.


Matt





From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 12:19 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Sorry, thats what I meant, if you are still curious as to seeing some more 
different approaches.

Also, just wanted to clarify about the orbits of the asteroids. is it like 
Saturn ring or Asteroid belt as am sure you mentioned planets.

if it is a ring then definitely a bitmap approach until close up  then still 
bitmaps as they are only micrometer > meter and you could squeeze a lot more 
smaller clumps onto a bitmap versus geometrydoes your engine do cloud 
gridss and can fly through them?  I  imagine an asteroid ring would be similar.

On 14 February 2014 20:01, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
It was solved even before I sent out the first message.  I was just curious how 
other people would solve the same problem given the circumstances.


Matt




From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM

To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

 Emilio wrote "they simply took a pristine and talented dev team who understood 
the artists, and plugged them into The Matrix"

ahem.  that will be *some*, but not all of the talented dev.  am guessing some 
chose not to go work for the 'matrix' . some were then fired apparently in 
rounds of 'must make more profit for shareholders'

can we get back to asteroids. Matt, has it been solved and we can end this 
thread or you still looking for some differnt ideas?





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: Re[2]: Survey - how would you do this?

[Angus Davidson]

To me it isnt a deal breaker as the things I would need to change (for example 
if the client wanted more rocks , or a bigger circumference on the asteroid 
belt ) are still there and can be edited on the fly. If you drill down on your 
objects in the list on the right hand side you now get a very wide array of 
things to play with.  I havent so far come up with something where I found I 
was missing the functionality of Softimage stack. In most cases it was just 
poking around what was there to find out where to modify things.

As far as I know its on the todo list for 801. How they find middle ground 
between what they have now and something like what we have in softimage remains 
to be seen.

I think its mostly that folks are just very set in their ways and tend to cling 
to things rather then do things a different way.  The folks I know that have 
switched  from Softimage to Modo full-time complained at first but are now just 
as efficient and flexible as before.





From: Eugen Sares [sof...@mail.sprit.org]
Sent: 14 February 2014 11:46 PM
To: softimage@listproc.autodesk.com
Subject: Re[2]: Survey - how would you do this?

Last time I looked Modo did not have an operator graph / modifier stack or 
sorts. Linear workflow, so to speak. Isn't that a dealbreaker, really?
Or is it me being used to that so much I can't imagine going without?
Any news on the subject? Is The Foundry planning for anything? (Not talking 
about deformers)


-- Originalnachricht --
Von: "Angus Davidson" 
mailto:angus.david...@wits.ac.za>>
An: "softimage@listproc.autodesk.com" 
mailto:softimage@listproc.autodesk.com>>
Gesendet: 14.02.2014 22:32:43
Betreff: RE: Survey - how would you do this?

Hi Ben

I take your point on COM. Do you know if the Mac / Linux versions use Com 
wrappers or recreate the functionality in a different way.

Must admit I was blown away by the redshift alpha. Unfortunately I dont have 
regular access to the GPUs that really make it shine.

I think a lot depends on what happens with the 2015 release of Softimage. 
(which should be soonish). A lot of folks felt very burned by what they got 
last year, and have very grudgingly paid their subs for this year. If its not a 
very solid affirmation of Softimage getting the love it deserves people are not 
going to pay top dollar for very little in return again. The VFX economy is not 
in great shape. People just cant be taking those kind of chances going forward. 
Once that happens Softimage is effectively dead as a product from a sales point 
of view. Personally I hope Autodesk finally realizes how stupid they are being 
and actually puts the right number of resources to work on Softimage. 
Realistically I suspect I have more chance of getting a mac version ;(

Autodesk mishandling of Softimage is not likely to move many people to Maya. 
Once trust is broken with a company it tends to include their whole offering. 
so they will need to go somewhere. Once that happens the renderer companies 
will follow.

I am a bit more optimistic about external renderer's finding their way to Modo, 
Octane and  Thea are already there or on their way. Once Modo market share 
increases it will become more attractive to plug your renderer into. Personally 
Arnold for me would be awesome as I have access to far more CPU rendering power.





From: Ben Rogall 
[xsi_l...@shaders.moederogall.com<mailto:xsi_l...@shaders.moederogall.com>]
Sent: 14 February 2014 10:41 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

Hi Angus

Yep, I just wanted to make the point that someone was able to do that on top of 
COM. I'm fond of Modo too, especially for modeling and the Luxology people seem 
really reasonable. I was doing some rendering in Modo too, but then Redshift 
came along.

On 2/14/2014 11:57 AM, Angus Davidson wrote:
Hi Ben

The big difference is Modo is also successfully cross platform, and in active 
development. When the time comes to move on they will be in a position to do so.

Something Softimage currently lacks.  Which is something Autodesk will regret 
down the line.



From: Ben Rogall 
[xsi_l...@shaders.moederogall.com<mailto:xsi_l...@shaders.moederogall.com>]
Sent: 14 February 2014 07:45 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its SDK, the COM 
roots are more visible than with Softimage. However most everything is nicely 
wrapped in C++ classes so you don't usually have to deal with the low level 
nuts and bolts of COM.

Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t find a way off 
of it (which is unlikely 

RE: Survey - how would you do this?

[Matt Lind]

The video is just a style reference.

The final movement is done in the Softimage scene, placement is done in a world 
editor.  Rocks cannot collide with anything.

Operators, such as deformations (other than envelopes), do not transfer into 
the engine.  Animation is plotted per frame.  Eg; a position constrained object 
will have global transforms plotted and constraint removed when exported.
Animation is heavy data, but is filtered for cases where values do not change 
over multiple frames (FCurve is horizontal).

Keep that in mind when deciding how to use resources such as number of 
polygons, keys, textures, materials, etc…


Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 3:22 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

haha I said radius, I meant circumference :) but yes if your junior knows 
the length of the circumference of the belt then they can make nicely designed 
and spread out patches which can then be deformed by curve at the correct speed,

On 14 February 2014 23:16, Rob Chapman 
mailto:tekano@gmail.com>> wrote:
ah I see! well then I would just instruct said junior to crank out as many 
individual styled asteroids as low poly as possible in the style and format 
desired.  get primitive>dodecohedron, randomize points and subdivide some 
impact craters etc.

 and to visualize (assuming final movement & placement is done in-engine) 
duplicate or instantiate as many as needed. from your video looks like 
hundreds. use the multiselect and r(min,max) in the transform panel to get them 
into a rough rectangular patch in one axis and to the length of the radius of 
the intended asteroid belt to be.  this way a good distribution of amounts and 
sizes can be ascertained straightaway.

again the r(min,max) can be used to keyframe rotations of individual asteroids 
like Manny demonstrated.

then under a null these can be deformed by a curve representing the belt and 
keyframing the translation along curve.

simples!   less than half hour easy

On 14 February 2014 21:53, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Watch the video here:   http://www.wildstar-online.com/en/news/#page1

At various times you’ll see asteroid belts of various radius, density, and 
orbital speed.  We needed to create a dense asteroid belt for a closeup.

We don’t do photo-real.  The emotional effect from shape and movement is more 
important as the game is largely based on a comic book style.  Take a peek at 
the screenshots and other media for more examples.

From a technical point of view, since this asteroid belt must perform in a real 
time environment, must be optimal in use of resources.  The challenge was this 
asteroid belt had to be created by a junior artist with no technical skills and 
done in rapid fashion unsupervised.  The question is how do you instruct such a 
person to create the asteroid belt to get the task done quickly (< 30 minutes), 
effectively, and with minimal risk against immediate and long term objectives 
related to pipeline.


Matt





From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 12:19 PM

To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

Sorry, thats what I meant, if you are still curious as to seeing some more 
different approaches.

Also, just wanted to clarify about the orbits of the asteroids. is it like 
Saturn ring or Asteroid belt as am sure you mentioned planets.

if it is a ring then definitely a bitmap approach until close up  then still 
bitmaps as they are only micrometer > meter and you could squeeze a lot more 
smaller clumps onto a bitmap versus geometrydoes your engine do cloud 
gridss and can fly through them?  I  imagine an asteroid ring would be similar.

On 14 February 2014 20:01, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
It was solved even before I sent out the first message.  I was just curious how 
other people would solve the same problem given the circumstances.


Matt




From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM

To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

 Emilio wrote "they simply took a pristine and talented dev team who understood 
the artists, and plugged them into The Matrix"

ahem.  that will be *some*, but not all of the talented d

Re: Survey - how would you do this?

[Rob Chapman]

haha I said radius, I meant circumference :) but yes if your junior
knows the length of the circumference of the belt then they can make nicely
designed and spread out patches which can then be deformed by curve at the
correct speed,


On 14 February 2014 23:16, Rob Chapman  wrote:

> ah I see! well then I would just instruct said junior to crank out as many
> individual styled asteroids as low poly as possible in the style and format
> desired.  get primitive>dodecohedron, randomize points and subdivide some
> impact craters etc.
>
>  and to visualize (assuming final movement & placement is done in-engine)
> duplicate or instantiate as many as needed. from your video looks like
> hundreds. use the multiselect and r(min,max) in the transform panel to get
> them into a rough rectangular patch in one axis and to the length of the
> radius of the intended asteroid belt to be.  this way a good distribution
> of amounts and sizes can be ascertained straightaway.
>
> again the r(min,max) can be used to keyframe rotations of individual
> asteroids like Manny demonstrated.
>
> then under a null these can be deformed by a curve representing the belt
> and keyframing the translation along curve.
>
> simples!   less than half hour easy
>
>
> On 14 February 2014 21:53, Matt Lind  wrote:
>
>> Watch the video here:   http://www.wildstar-online.com/en/news/#page1
>>
>>
>>
>> At various times you’ll see asteroid belts of various radius, density,
>> and orbital speed.  We needed to create a dense asteroid belt for a closeup.
>>
>>
>>
>> We don’t do photo-real.  The emotional effect from shape and movement is
>> more important as the game is largely based on a comic book style.  Take a
>> peek at the screenshots and other media for more examples.
>>
>>
>>
>> From a technical point of view, since this asteroid belt must perform in
>> a real time environment, must be optimal in use of resources.  The
>> challenge was this asteroid belt had to be created by a junior artist with
>> no technical skills and done in rapid fashion unsupervised.  The question
>> is how do you instruct such a person to create the asteroid belt to get the
>> task done quickly (< 30 minutes), effectively, and with minimal risk
>> against immediate and long term objectives related to pipeline.
>>
>>
>>
>>
>>
>> Matt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman
>> *Sent:* Friday, February 14, 2014 12:19 PM
>>
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: Survey - how would you do this?
>>
>>
>>
>> Sorry, thats what I meant, if you are still curious as to seeing some
>> more different approaches.
>>
>>
>>
>> Also, just wanted to clarify about the orbits of the asteroids. is it
>> like Saturn ring or Asteroid belt as am sure you mentioned planets.
>>
>>
>>
>> if it is a ring then definitely a bitmap approach until close up  then
>> still bitmaps as they are only micrometer > meter and you could squeeze a
>> lot more smaller clumps onto a bitmap versus geometrydoes your engine
>> do cloud gridss and can fly through them?  I  imagine an asteroid ring
>> would be similar.
>>
>>
>>
>> On 14 February 2014 20:01, Matt Lind  wrote:
>>
>> It was solved even before I sent out the first message.  I was just
>> curious how other people would solve the same problem given the
>> circumstances.
>>
>>
>>
>>
>>
>> Matt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman
>> *Sent:* Friday, February 14, 2014 11:57 AM
>>
>>
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: Survey - how would you do this?
>>
>>
>>
>>  Emilio wrote "they simply took a pristine and talented dev team who
>> understood the artists, and plugged them into The Matrix"
>>
>>
>>
>> ahem.  that will be *some*, but not all of the talented dev.  am guessing
>> some chose not to go work for the 'matrix' . some were then fired
>> apparently in rounds of 'must make more profit for shareholders'
>>
>>
>>
>> can we get back to asteroids. Matt, has it been solved and we can end
>> this thread or you still looking for some differnt ideas?
>>
>>
>>
>>
>>
>
>

Re: Survey - how would you do this?

[Rob Chapman]

ah I see! well then I would just instruct said junior to crank out as many
individual styled asteroids as low poly as possible in the style and format
desired.  get primitive>dodecohedron, randomize points and subdivide some
impact craters etc.

 and to visualize (assuming final movement & placement is done in-engine)
duplicate or instantiate as many as needed. from your video looks like
hundreds. use the multiselect and r(min,max) in the transform panel to get
them into a rough rectangular patch in one axis and to the length of the
radius of the intended asteroid belt to be.  this way a good distribution
of amounts and sizes can be ascertained straightaway.

again the r(min,max) can be used to keyframe rotations of individual
asteroids like Manny demonstrated.

then under a null these can be deformed by a curve representing the belt
and keyframing the translation along curve.

simples!   less than half hour easy


On 14 February 2014 21:53, Matt Lind  wrote:

> Watch the video here:   http://www.wildstar-online.com/en/news/#page1
>
>
>
> At various times you’ll see asteroid belts of various radius, density, and
> orbital speed.  We needed to create a dense asteroid belt for a closeup.
>
>
>
> We don’t do photo-real.  The emotional effect from shape and movement is
> more important as the game is largely based on a comic book style.  Take a
> peek at the screenshots and other media for more examples.
>
>
>
> From a technical point of view, since this asteroid belt must perform in a
> real time environment, must be optimal in use of resources.  The challenge
> was this asteroid belt had to be created by a junior artist with no
> technical skills and done in rapid fashion unsupervised.  The question is
> how do you instruct such a person to create the asteroid belt to get the
> task done quickly (< 30 minutes), effectively, and with minimal risk
> against immediate and long term objectives related to pipeline.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman
> *Sent:* Friday, February 14, 2014 12:19 PM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>
>
> Sorry, thats what I meant, if you are still curious as to seeing some more
> different approaches.
>
>
>
> Also, just wanted to clarify about the orbits of the asteroids. is it like
> Saturn ring or Asteroid belt as am sure you mentioned planets.
>
>
>
> if it is a ring then definitely a bitmap approach until close up  then
> still bitmaps as they are only micrometer > meter and you could squeeze a
> lot more smaller clumps onto a bitmap versus geometrydoes your engine
> do cloud gridss and can fly through them?  I  imagine an asteroid ring
> would be similar.
>
>
>
> On 14 February 2014 20:01, Matt Lind  wrote:
>
> It was solved even before I sent out the first message.  I was just
> curious how other people would solve the same problem given the
> circumstances.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman
> *Sent:* Friday, February 14, 2014 11:57 AM
>
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>
>
>  Emilio wrote "they simply took a pristine and talented dev team who
> understood the artists, and plugged them into The Matrix"
>
>
>
> ahem.  that will be *some*, but not all of the talented dev.  am guessing
> some chose not to go work for the 'matrix' . some were then fired
> apparently in rounds of 'must make more profit for shareholders'
>
>
>
> can we get back to asteroids. Matt, has it been solved and we can end this
> thread or you still looking for some differnt ideas?
>
>
>
>
>

Re: Re[2]: Survey - how would you do this?

[Emilio Hernandez]

Cool work!  Congrats!





2014-02-14 16:22 GMT-06:00 Eugen Sares :

>  Great stuff, Matt! I don't play myself (anymore), but I like the looks
> and the humor. Much success with your game!
> Doesn't those assets look somehow... softimage-ish...?
>
>
> -- Originalnachricht --
> Von: "Matt Lind" 
> An: "softimage@listproc.autodesk.com" 
> Gesendet: 14.02.2014 22:53:50
> Betreff: RE: Survey - how would you do this?
>
>
>  Watch the video here:   http://www.wildstar-online.com/en/news/#page1
>
>
>
> At various times you'll see asteroid belts of various radius, density, and
> orbital speed.  We needed to create a dense asteroid belt for a closeup.
>
>
>
> We don't do photo-real.  The emotional effect from shape and movement is
> more important as the game is largely based on a comic book style.  Take a
> peek at the screenshots and other media for more examples.
>
>
>
> From a technical point of view, since this asteroid belt must perform in a
> real time environment, must be optimal in use of resources.  The challenge
> was this asteroid belt had to be created by a junior artist with no
> technical skills and done in rapid fashion unsupervised.  The question is
> how do you instruct such a person to create the asteroid belt to get the
> task done quickly (< 30 minutes), effectively, and with minimal risk
> against immediate and long term objectives related to pipeline.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc..autodesk.com]
> *On Behalf Of *Rob Chapman
>
> *Sent:* Friday, February 14, 2014 12:19 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>
>
> Sorry, thats what I meant, if you are still curious as to seeing some more
> different approaches.
>
>
>
> Also, just wanted to clarify about the orbits of the asteroids. is it like
> Saturn ring or Asteroid belt as am sure you mentioned planets.
>
>
>
> if it is a ring then definitely a bitmap approach until close up  then
> still bitmaps as they are only micrometer > meter and you could squeeze a
> lot more smaller clumps onto a bitmap versus geometrydoes your engine
> do cloud gridss and can fly through them?  I  imagine an asteroid ring
> would be similar.
>
>
>
> On 14 February 2014 20:01, Matt Lind  wrote:
>
> It was solved even before I sent out the first message.  I was just
> curious how other people would solve the same problem given the
> circumstances.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman
> *Sent:* Friday, February 14, 2014 11:57 AM
>
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>
>
>  Emilio wrote "they simply took a pristine and talented dev team who
> understood the artists, and plugged them into The Matrix"
>
>
>
> ahem.  that will be *some*, but not all of the talented dev.  am guessing
> some chose not to go work for the 'matrix' . some were then fired
> apparently in rounds of 'must make more profit for shareholders'
>
>
>
> can we get back to asteroids. Matt, has it been solved and we can end this
> thread or you still looking for some differnt ideas?
>
>
>
>
>
>
>
> --
><http://www.avast.com/>
>
> Diese E-Mail ist frei von Viren und Malware, denn der avast! 
> Antivirus<http://www.avast.com/>Schutz ist aktiv.
>
>

Re[2]: Survey - how would you do this?

[Eugen Sares]

Great stuff, Matt! I don't play myself (anymore), but I like the looks
and the humor. Much success with your game!
Doesn't those assets look somehow... softimage-ish...?


-- Originalnachricht --
Von: "Matt Lind" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 14.02.2014 22:53:50
Betreff: RE: Survey - how would you do this?


Watch the video here:   http://www.wildstar-online.com/en/news/#page1



At various times you’ll see asteroid belts of various radius, density,
and orbital speed.  We needed to create a dense asteroid belt for a
closeup.



We don’t do photo-real.  The emotional effect from shape and movement
is more important as the game is largely based on a comic book style.
Take a peek at the screenshots and other media for more examples.



From a technical point of view, since this asteroid belt must perform
in a real time environment, must be optimal in use of resources.  The
challenge was this asteroid belt had to be created by a junior artist
with no technical skills and done in rapid fashion unsupervised.  The
question is how do you instruct such a person to create the asteroid
belt to get the task done quickly (< 30 minutes), effectively, and with
minimal risk against immediate and long term objectives related to
pipeline.





Matt











From:softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob
Chapman
Sent: Friday, February 14, 2014 12:19 PM
To:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?



Sorry, thats what I meant, if you are still curious as to seeing some
more different approaches.



Also, just wanted to clarify about the orbits of the asteroids. is it
like Saturn ring or Asteroid belt as am sure you mentioned planets.



if it is a ring then definitely a bitmap approach until close up  then
still bitmaps as they are only micrometer > meter and you could squeeze
a lot more smaller clumps onto a bitmap versus geometrydoes your
engine do cloud gridss and can fly through them?  I  imagine an
asteroid ring would be similar.



On 14 February 2014 20:01, Matt Lind  wrote:

It was solved even before I sent out the first message.  I was just
curious how other people would solve the same problem given the
circumstances.





Matt









From:softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob
Chapman
Sent: Friday, February 14, 2014 11:57 AM


To:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?



 Emilio wrote "they simply took a pristine and talented dev team who
understood the artists, and plugged them into The Matrix"



ahem.  that will be *some*, but not all of the talented dev.  am
guessing some chose not to go work for the 'matrix' . some were then
fired apparently in rounds of 'must make more profit for shareholders'



can we get back to asteroids. Matt, has it been solved and we can end
this thread or you still looking for some differnt ideas?







---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com

Re: Survey - how would you do this?

[Ben Rogall]

Well, yes it is missing and it is a big deal. But if I'm creating a 
static object I do really like the Modo workflow. Hopefully that will be 
addressed but I haven't heard anything. The new MeshFusion plugin does 
have a live graph for boolean modeling.


On 2/14/2014 3:46 PM, Eugen Sares wrote:
Last time I looked Modo did not have an operator graph / modifier 
stack or sorts. Linear workflow, so to speak. Isn't that a 
dealbreaker, really?

Or is it me being used to that so much I can't imagine going without?
Any news on the subject? Is The Foundry planning for anything? (Not 
talking about deformers)

-- Originalnachricht --
Von: "Angus Davidson" <mailto:angus.david...@wits.ac.za>>
An: "softimage@listproc.autodesk.com" <mailto:softimage@listproc.autodesk.com>>

Gesendet: 14.02.2014 22:32:43
Betreff: RE: Survey - how would you do this?

Hi Ben

I take your point on COM. Do you know if the Mac / Linux versions use 
Com wrappers or recreate the functionality in a different way.


Must admit I was blown away by the redshift alpha. Unfortunately I 
dont have regular access to the GPUs that really make it shine.


I think a lot depends on what happens with the 2015 release of 
Softimage. (which should be soonish). A lot of folks felt very burned 
by what they got last year, and have very grudgingly paid their subs 
for this year. If its not a very solid affirmation of Softimage 
getting the love it deserves people are not going to pay top dollar 
for very little in return again. The VFX economy is not in great 
shape. People just cant be taking those kind of chances going 
forward. Once that happens Softimage is effectively dead as a product 
from a sales point of view. Personally I hope Autodesk finally 
realizes how stupid they are being and actually puts the right number 
of resources to work on Softimage. Realistically I suspect I have 
more chance of getting a mac version ;(


Autodesk mishandling of Softimage is not likely to move many people 
to Maya. Once trust is broken with a company it tends to include 
their whole offering. so they will need to go somewhere. Once that 
happens the renderer companies will follow.


I am a bit more optimistic about external renderer's finding their 
way to Modo, Octane and  Thea are already there or on their way. Once 
Modo market share increases it will become more attractive to plug 
your renderer into. Personally Arnold for me would be awesome as I 
have access to far more CPU rendering power.






*From:* Ben Rogall [xsi_l...@shaders.moederogall.com 
<mailto:xsi_l...@shaders.moederogall.com>]

*Sent:* 14 February 2014 10:41 PM
*To:* softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>

*Subject:* Re: Survey - how would you do this?

Hi Angus

Yep, I just wanted to make the point that someone was able to do that 
on top of COM. I'm fond of Modo too, especially for modeling and the 
Luxology people seem really reasonable. I was doing some rendering in 
Modo too, but then Redshift came along.


On 2/14/2014 11:57 AM, Angus Davidson wrote:

Hi Ben

The big difference is Modo is also successfully cross platform, and 
in active development. When the time comes to move on they will be 
in a position to do so.


Something Softimage currently lacks.  Which is something Autodesk 
will regret down the line.




*From:* Ben Rogall [xsi_l...@shaders.moederogall.com]
*Sent:* 14 February 2014 07:45 PM
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its 
SDK, the COM roots are more visible than with Softimage. However 
most everything is nicely wrapped in C++ classes so you don't 
usually have to deal with the low level nuts and bolts of COM.


Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t 
find a way off of it (which is unlikely given the very small dev 
team) COM doesn’t scale the way new 3d apps require. To many 
 bottlenecks.


Jumping into Modo for my first attempt at particles. Managed to get 
the following after my allotted 5 minutes


pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a 
more random rock ;)






From: Guillaume Laforge <mailto:guillaume..laforge...@gmail.com>>
Reply-To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
<mailto:softimage@listproc.autodesk.com>>

Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
<mailto:softimage@listproc.autodesk.com>>

Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty

Re: Survey - how would you do this?

[Ben Rogall]

As far as I know it's COM based for all three. There is very little that 
needs to be changed to compile a plugin for Mac vs Windows.


As a freelancer, I'm in the opposite situation regarding renderers. It's 
so easy to upgrade or add gpu's with Redshift and get great improvements 
in render power.


Ben


On 2/14/2014 3:32 PM, Angus Davidson wrote:

Hi Ben

I take your point on COM. Do you know if the Mac / Linux versions use 
Com wrappers or recreate the functionality in a different way.


Must admit I was blown away by the redshift alpha. Unfortunately I 
dont have regular access to the GPUs that really make it shine.


I think a lot depends on what happens with the 2015 release of 
Softimage. (which should be soonish). A lot of folks felt very burned 
by what they got last year, and have very grudgingly paid their subs 
for this year. If its not a very solid affirmation of Softimage 
getting the love it deserves people are not going to pay top dollar 
for very little in return again. The VFX economy is not in great 
shape. People just cant be taking those kind of chances going forward. 
Once that happens Softimage is effectively dead as a product from a 
sales point of view. Personally I hope Autodesk finally realizes how 
stupid they are being and actually puts the right number of resources 
to work on Softimage. Realistically I suspect I have more chance of 
getting a mac version ;(


Autodesk mishandling of Softimage is not likely to move many people to 
Maya. Once trust is broken with a company it tends to include their 
whole offering. so they will need to go somewhere. Once that happens 
the renderer companies will follow.


I am a bit more optimistic about external renderer's finding their way 
to Modo, Octane and  Thea are already there or on their way. Once Modo 
market share increases it will become more attractive to plug your 
renderer into. Personally Arnold for me would be awesome as I have 
access to far more CPU rendering power.






*From:* Ben Rogall [xsi_l...@shaders.moederogall.com]
*Sent:* 14 February 2014 10:41 PM
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Survey - how would you do this?

Hi Angus

Yep, I just wanted to make the point that someone was able to do that 
on top of COM. I'm fond of Modo too, especially for modeling and the 
Luxology people seem really reasonable. I was doing some rendering in 
Modo too, but then Redshift came along.


On 2/14/2014 11:57 AM, Angus Davidson wrote:

Hi Ben

The big difference is Modo is also successfully cross platform, and 
in active development. When the time comes to move on they will be in 
a position to do so.


Something Softimage currently lacks.  Which is something Autodesk 
will regret down the line.




*From:* Ben Rogall [xsi_l...@shaders.moederogall.com]
*Sent:* 14 February 2014 07:45 PM
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its 
SDK, the COM roots are more visible than with Softimage. However most 
everything is nicely wrapped in C++ classes so you don't usually have 
to deal with the low level nuts and bolts of COM.


Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t 
find a way off of it (which is unlikely given the very small dev 
team) COM doesn’t scale the way new 3d apps require. To many 
 bottlenecks.


Jumping into Modo for my first attempt at particles. Managed to get 
the following after my allotted 5 minutes


pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a 
more random rock ;)






From: Guillaume Laforge <mailto:guillaume.laforge...@gmail.com>>
Reply-To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
<mailto:softimage@listproc.autodesk.com>>

Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
<mailto:softimage@listproc.autodesk.com>>

Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so 
is using COM too. How it works on Linux has been explain on this 
list many time (almost as often as people asking how to 
install Softimage successfully  on Linux).


I have nothing against COM in theory, except that it is hard to find 
good programmers mastering this interface those days. It is an old 
tech and Softimage is built on it. Easy to get the picture no ?




On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson 
mailto:angus.david...@wits.ac.za>> wrote:


How does the linux version get around all of the MFC / Com+
dependencies ? Would be great if we could get the  linux versi

RE: Survey - how would you do this?

[Matt Lind]

Watch the video here:   http://www.wildstar-online.com/en/news/#page1

At various times you’ll see asteroid belts of various radius, density, and 
orbital speed.  We needed to create a dense asteroid belt for a closeup.

We don’t do photo-real.  The emotional effect from shape and movement is more 
important as the game is largely based on a comic book style.  Take a peek at 
the screenshots and other media for more examples.

From a technical point of view, since this asteroid belt must perform in a real 
time environment, must be optimal in use of resources.  The challenge was this 
asteroid belt had to be created by a junior artist with no technical skills and 
done in rapid fashion unsupervised.  The question is how do you instruct such a 
person to create the asteroid belt to get the task done quickly (< 30 minutes), 
effectively, and with minimal risk against immediate and long term objectives 
related to pipeline.


Matt





From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 12:19 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Sorry, thats what I meant, if you are still curious as to seeing some more 
different approaches.

Also, just wanted to clarify about the orbits of the asteroids. is it like 
Saturn ring or Asteroid belt as am sure you mentioned planets.

if it is a ring then definitely a bitmap approach until close up  then still 
bitmaps as they are only micrometer > meter and you could squeeze a lot more 
smaller clumps onto a bitmap versus geometrydoes your engine do cloud 
gridss and can fly through them?  I  imagine an asteroid ring would be similar.

On 14 February 2014 20:01, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
It was solved even before I sent out the first message.  I was just curious how 
other people would solve the same problem given the circumstances.


Matt




From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM

To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

 Emilio wrote "they simply took a pristine and talented dev team who understood 
the artists, and plugged them into The Matrix"

ahem.  that will be *some*, but not all of the talented dev.  am guessing some 
chose not to go work for the 'matrix' . some were then fired apparently in 
rounds of 'must make more profit for shareholders'

can we get back to asteroids. Matt, has it been solved and we can end this 
thread or you still looking for some differnt ideas?

Re[2]: Survey - how would you do this?

[Eugen Sares]

Last time I looked Modo did not have an operator graph / modifier stack
or sorts. Linear workflow, so to speak. Isn't that a dealbreaker,
really?
Or is it me being used to that so much I can't imagine going without?
Any news on the subject? Is The Foundry planning for anything? (Not
talking about deformers)


-- Originalnachricht --
Von: "Angus Davidson" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 14.02.2014 22:32:43
Betreff: RE: Survey - how would you do this?


Hi Ben

I take your point on COM. Do you know if the Mac / Linux versions use
Com wrappers or recreate the functionality in a different way.

Must admit I was blown away by the redshift alpha. Unfortunately I dont
have regular access to the GPUs that really make it shine.

I think a lot depends on what happens with the 2015 release of
Softimage. (which should be soonish). A lot of folks felt very burned
by what they got last year, and have very grudgingly paid their subs
for this year. If its not a very solid affirmation of Softimage getting
the love it deserves people are not going to pay top dollar for very
little in return again. The VFX economy is not in great shape. People
just cant be taking those kind of chances going forward. Once that
happens Softimage is effectively dead as a product from a sales point
of view. Personally I hope Autodesk finally realizes how stupid they
are being and actually puts the right number of resources to work on
Softimage. Realistically I suspect I have more chance of getting a mac
version ;(

Autodesk mishandling of Softimage is not likely to move many people to
Maya. Once trust is broken with a company it tends to include their
whole offering. so they will need to go somewhere. Once that happens
the renderer companies will follow.

I am a bit more optimistic about external renderer's finding their way
to Modo, Octane and  Thea are already there or on their way. Once Modo
market share increases it will become more attractive to plug your
renderer into. Personally Arnold for me would be awesome as I have
access to far more CPU rendering power.





From: Ben Rogall [xsi_l...@shaders.moederogall.com]
Sent: 14 February 2014 10:41 PM
To:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Hi Angus

Yep, I just wanted to make the point that someone was able to do that
on top of COM. I'm fond of Modo too, especially for modeling and the
Luxology people seem really reasonable. I was doing some rendering in
Modo too, but then Redshift came along.

On 2/14/2014 11:57 AM, Angus Davidson wrote:

Hi Ben

The big difference is Modo is also successfully cross platform, and in
active development. When the time comes to move on they will be in a
position to do so.

Something Softimage currently lacks.  Which is something Autodesk will
regret down the line.



From: Ben Rogall [xsi_l...@shaders.moederogall.com]
Sent: 14 February 2014 07:45 PM
To:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its SDK,
the COM roots are more visible than with Softimage. However most
everything is nicely wrapped in C++ classes so you don't usually have
to deal with the low level nuts and bolts of COM.

Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:

Unfortunately  it will be Softimages achilles heel if they don’t find
a way off of it (which is unlikely given the very small dev team) COM
doesn’t scale the way new 3d apps require. To many  bottlenecks.

Jumping into Modo for my first attempt at particles. Managed to get
the following after my allotted 5 minutes

pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a
more random rock ;)





From: Guillaume Laforge 
Reply-To: "softimage@listproc.autodesk.com"

Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com"

Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so
is using COM too. How it works on Linux has been explain on this list
many time (almost as often as people asking how to install Softimage
successfully  on Linux).

I have nothing against COM in theory, except that it is hard to find
good programmers mastering this interface those days. It is an old
tech and Softimage is built on it. Easy to get the picture no ?



On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson
 wrote:

How does the linux version get around all of the MFC / Com+
dependencies ? Would be great if we could get the  linux version to
be used as the compile base. In theory then a more open windows
version and even a mac version would be possible ;)

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this wa

RE: Survey - how would you do this?

[Angus Davidson]

Hi Ben

I take your point on COM. Do you know if the Mac / Linux versions use Com 
wrappers or recreate the functionality in a different way.

Must admit I was blown away by the redshift alpha. Unfortunately I dont have 
regular access to the GPUs that really make it shine.

I think a lot depends on what happens with the 2015 release of Softimage. 
(which should be soonish). A lot of folks felt very burned by what they got 
last year, and have very grudgingly paid their subs for this year. If its not a 
very solid affirmation of Softimage getting the love it deserves people are not 
going to pay top dollar for very little in return again. The VFX economy is not 
in great shape. People just cant be taking those kind of chances going forward. 
Once that happens Softimage is effectively dead as a product from a sales point 
of view. Personally I hope Autodesk finally realizes how stupid they are being 
and actually puts the right number of resources to work on Softimage. 
Realistically I suspect I have more chance of getting a mac version ;(

Autodesk mishandling of Softimage is not likely to move many people to Maya. 
Once trust is broken with a company it tends to include their whole offering. 
so they will need to go somewhere. Once that happens the renderer companies 
will follow.

I am a bit more optimistic about external renderer's finding their way to Modo, 
Octane and  Thea are already there or on their way. Once Modo market share 
increases it will become more attractive to plug your renderer into. Personally 
Arnold for me would be awesome as I have access to far more CPU rendering power.





From: Ben Rogall [xsi_l...@shaders.moederogall.com]
Sent: 14 February 2014 10:41 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Hi Angus

Yep, I just wanted to make the point that someone was able to do that on top of 
COM. I'm fond of Modo too, especially for modeling and the Luxology people seem 
really reasonable. I was doing some rendering in Modo too, but then Redshift 
came along.

On 2/14/2014 11:57 AM, Angus Davidson wrote:
Hi Ben

The big difference is Modo is also successfully cross platform, and in active 
development. When the time comes to move on they will be in a position to do so.

Something Softimage currently lacks.  Which is something Autodesk will regret 
down the line.



From: Ben Rogall 
[xsi_l...@shaders.moederogall.com<mailto:xsi_l...@shaders.moederogall.com>]
Sent: 14 February 2014 07:45 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its SDK, the COM 
roots are more visible than with Softimage. However most everything is nicely 
wrapped in C++ classes so you don't usually have to deal with the low level 
nuts and bolts of COM.

Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t find a way off 
of it (which is unlikely given the very small dev team) COM doesn’t scale the 
way new 3d apps require. To many  bottlenecks.

Jumping into Modo for my first attempt at particles. Managed to get the 
following after my allotted 5 minutes

pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a more random 
rock ;)





From: Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so is using 
COM too. How it works on Linux has been explain on this list many time (almost 
as often as people asking how to install Softimage successfully  on Linux).

I have nothing against COM in theory, except that it is hard to find good 
programmers mastering this interface those days. It is an old tech and 
Softimage is built on it. Easy to get the picture no ?



On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson 
mailto:angus.david...@wits.ac.za>> wrote:
How does the linux version get around all of the MFC / Com+ dependencies ? 
Would be great if we could get the  linux version to be used as the compile 
base. In theory then a more open windows version and even a mac version would 
be possible ;)

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this was from a long time back. FBX , was buggy and 
Alembic wasnt yet an option. We came up with an exporter that allowed a decent 
to and fro between 3D app and Games engine.

Similar to how the obj exporter work

Re: Survey - how would you do this?

[Sebastien Sterling]

Does anyone know how open modo is ? i guess that will be the next step for
luxologic/foundery, to open it out, and make pipe integration a priority.


On 14 February 2014 21:41, Ben Rogall wrote:

>  Hi Angus
>
> Yep, I just wanted to make the point that someone was able to do that on
> top of COM. I'm fond of Modo too, especially for modeling and the Luxology
> people seem really reasonable. I was doing some rendering in Modo too, but
> then Redshift came along.
>
>
> On 2/14/2014 11:57 AM, Angus Davidson wrote:
>
> Hi Ben
>
>  The big difference is Modo is also successfully cross platform, and in
> active development. When the time comes to move on they will be in a
> position to do so.
>
>  Something Softimage currently lacks.  Which is something Autodesk will
> regret down the line.
>
>
>  --
> *From:* Ben Rogall [xsi_l...@shaders.moederogall.com]
> *Sent:* 14 February 2014 07:45 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>  As a matter of fact, Modo is COM based. When programming with its SDK,
> the COM roots are more visible than with Softimage. However most everything
> is nicely wrapped in C++ classes so you don't usually have to deal with the
> low level nuts and bolts of COM.
>
> Ben
>
> On 2/14/2014 7:42 AM, Angus Davidson wrote:
>
> Unfortunately  it will be Softimages achilles heel if they don't find a
> way off of it (which is unlikely given the very small dev team) COM doesn't
> scale the way new 3d apps require. To many  bottlenecks.
>
>  Jumping into Modo for my first attempt at particles. Managed to get the
> following after my allotted 5 minutes
>
>  pic.twitter.com/EDOKamNkkn
>
>  Just used a plain cube as a poly source. Need to update that with a more
> random rock ;)
>
>
>
>
>
>   From: Guillaume Laforge 
> Reply-To: "softimage@listproc.autodesk.com" <
> softimage@listproc.autodesk.com>
> Date: Friday 14 February 2014 at 2:06 PM
> To: "softimage@listproc.autodesk.com" 
> Subject: Re: Survey - how would you do this?
>
>   Softimage code in Linux is pretty much the same as on Windows and so is
> using COM too. How it works on Linux has been explain on this list many
> time (almost as often as people asking how to
> install Softimage successfully  on Linux).
>
>  I have nothing against COM in theory, except that it is hard to find
> good programmers mastering this interface those days. It is an old tech and
> Softimage is built on it. Easy to get the picture no ?
>
>
>
> On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson <
> angus.david...@wits.ac.za> wrote:
>
>> How does the linux version get around all of the MFC / Com+ dependencies
>> ? Would be great if we could get the  linux version to be used as the
>> compile base. In theory then a more open windows version and even a mac
>> version would be possible ;)
>>
>> On the plus side at least you have moved to a decent laptop now ;)
>>
>> My only experience in this was from a long time back. FBX , was buggy and
>> Alembic wasnt yet an option. We came up with an exporter that allowed a
>> decent to and fro between 3D app and Games engine.
>>
>> Similar to how the obj exporter worked it was text based and had a
>> separate include file for geometry, materials,bones animation etc. This
>> allowed it to be be easy to use for version control , and also allowed us
>> to reuse animations etc  across more then one model. Admittedly things were
>> a lot simpler then .
>>
>> Havent looked at Modo for creating the asteroid belt.  will try have a
>> look this weekend.
>>
>> 
>> From: Luc-Eric Rousseau [luceri...@gmail.com]
>> Sent: 14 February 2014 04:26 AM
>> To: softimage@listproc.autodesk.com
>> Subject: Re: Survey - how would you do this?
>>
>>  imagine if we made such jokes every time the Fabric came to pimp their
>> stuff here. ;)
>>
>> If there is going to be a discussion about creating custom tools for
>> artists, sweeping statements about DCCs, and name dropping like Pixar,
>> it's in everyone's interest to be informed about the maya side of the
>> story.  On my side, as Maya UI team lead, pyside (python+qt) is part
>> of the day-to-day.  Something I could have never imagine on Softimage.
>> I'd always have to write everything in C++/MFC to do anything.  I've
>> also dumped my PC for a Macbook Pro.
>>
>>
>> On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
>>  wrote:
>> > Don't forget to

Re: Survey - how would you do this?

[Ben Rogall]

Hi Angus

Yep, I just wanted to make the point that someone was able to do that on 
top of COM. I'm fond of Modo too, especially for modeling and the 
Luxology people seem really reasonable. I was doing some rendering in 
Modo too, but then Redshift came along.


On 2/14/2014 11:57 AM, Angus Davidson wrote:

Hi Ben

The big difference is Modo is also successfully cross platform, and in 
active development. When the time comes to move on they will be in a 
position to do so.


Something Softimage currently lacks.  Which is something Autodesk will 
regret down the line.




*From:* Ben Rogall [xsi_l...@shaders.moederogall.com]
*Sent:* 14 February 2014 07:45 PM
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its SDK, 
the COM roots are more visible than with Softimage. However most 
everything is nicely wrapped in C++ classes so you don't usually have 
to deal with the low level nuts and bolts of COM.


Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t find 
a way off of it (which is unlikely given the very small dev team) COM 
doesn’t scale the way new 3d apps require. To many  bottlenecks.


Jumping into Modo for my first attempt at particles. Managed to get 
the following after my allotted 5 minutes


pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a 
more random rock ;)






From: Guillaume Laforge <mailto:guillaume.laforge...@gmail.com>>
Reply-To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
<mailto:softimage@listproc.autodesk.com>>

Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
<mailto:softimage@listproc.autodesk.com>>

Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so 
is using COM too. How it works on Linux has been explain on this list 
many time (almost as often as people asking how to 
install Softimage successfully  on Linux).


I have nothing against COM in theory, except that it is hard to find 
good programmers mastering this interface those days. It is an old 
tech and Softimage is built on it. Easy to get the picture no ?




On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson 
mailto:angus.david...@wits.ac.za>> wrote:


How does the linux version get around all of the MFC / Com+
dependencies ? Would be great if we could get the  linux version
to be used as the compile base. In theory then a more open
windows version and even a mac version would be possible ;)

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this was from a long time back. FBX , was
buggy and Alembic wasnt yet an option. We came up with an
exporter that allowed a decent to and fro between 3D app and
Games engine.

Similar to how the obj exporter worked it was text based and had
a separate include file for geometry, materials,bones animation
etc. This allowed it to be be easy to use for version control ,
and also allowed us to reuse animations etc  across more then one
model. Admittedly things were a lot simpler then .

Havent looked at Modo for creating the asteroid belt.  will try
have a look this weekend.


From: Luc-Eric Rousseau [luceri...@gmail.com
<mailto:luceri...@gmail.com>]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.com
    <mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

imagine if we made such jokes every time the Fabric came to pimp
their
stuff here. ;)

If there is going to be a discussion about creating custom tools for
artists, sweeping statements about DCCs, and name dropping like
Pixar,
it's in everyone's interest to be informed about the maya side of the
story.  On my side, as Maya UI team lead, pyside (python+qt) is part
of the day-to-day.  Something I could have never imagine on
Softimage.
I'd always have to write everything in C++/MFC to do anything.  I've
also dumped my PC for a Macbook Pro.


On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
mailto:guillaume.laforge...@gmail.com>> wrote:
> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron mailto:car...@gmail.com>> wrote:
>>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
>> mai

Re: Survey - how would you do this?

[Rob Chapman]

Sorry, thats what I meant, if you are still curious as to seeing some more
different approaches.

Also, just wanted to clarify about the orbits of the asteroids. is it like
Saturn ring or Asteroid belt as am sure you mentioned planets.

if it is a ring then definitely a bitmap approach until close up  then
still bitmaps as they are only micrometer > meter and you could squeeze a
lot more smaller clumps onto a bitmap versus geometrydoes your engine
do cloud gridss and can fly through them?  I  imagine an asteroid ring
would be similar.


On 14 February 2014 20:01, Matt Lind  wrote:

> It was solved even before I sent out the first message.  I was just
> curious how other people would solve the same problem given the
> circumstances.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman
> *Sent:* Friday, February 14, 2014 11:57 AM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>
>
>  Emilio wrote "they simply took a pristine and talented dev team who
> understood the artists, and plugged them into The Matrix"
>
>
>
> ahem.  that will be *some*, but not all of the talented dev.  am guessing
> some chose not to go work for the 'matrix' . some were then fired
> apparently in rounds of 'must make more profit for shareholders'
>
>
>
> can we get back to asteroids. Matt, has it been solved and we can end this
> thread or you still looking for some differnt ideas?
>
>
>

RE: Survey - how would you do this?

[Matt Lind]

It was solved even before I sent out the first message.  I was just curious how 
other people would solve the same problem given the circumstances.


Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

 Emilio wrote "they simply took a pristine and talented dev team who understood 
the artists, and plugged them into The Matrix"

ahem.  that will be *some*, but not all of the talented dev.  am guessing some 
chose not to go work for the 'matrix' . some were then fired apparently in 
rounds of 'must make more profit for shareholders'

can we get back to asteroids. Matt, has it been solved and we can end this 
thread or you still looking for some differnt ideas?

Re: Survey - how would you do this?

[Rob Chapman]

 Emilio wrote "they simply took a pristine and talented dev team who
understood the artists, and plugged them into The Matrix"

ahem.  that will be *some*, but not all of the talented dev.  am guessing
some chose not to go work for the 'matrix' . some were then fired
apparently in rounds of 'must make more profit for shareholders'

can we get back to asteroids. Matt, has it been solved and we can end this
thread or you still looking for some differnt ideas?

Re: Survey - how would you do this?

[Emilio Hernandez]

Absolutley.

The Foundry has been doing things the way it should be.

A 3d dedicated app was the only missing link in their film/vfx chain.  And
with Modo, they closed the round trip.

I can see Nuke displaying a Modo scene interactively doing all the
lighiting, rendering and compositing, beeing send to Hiero to be dispalyed
with the rest of the feature.

Something that Softimage started a long time ago when DS was capable of
reading a Softimage scene... and 15 years later, finally The Foundry
discovered the black thread.

Something that Autodesk and had in his hands.

With all that technology and amazing dev teams.  Instead of after acquiring
Softimage and say "Hey lets create something new that will have the best of
both worlds", they simply took a pristine and talented dev team who
understood the artists, and plugged them into The Matrix.






2014-02-14 11:57 GMT-06:00 Angus Davidson :

>  Hi Ben
>
>  The big difference is Modo is also successfully cross platform, and in
> active development. When the time comes to move on they will be in a
> position to do so.
>
>  Something Softimage currently lacks.  Which is something Autodesk will
> regret down the line.
>
>
>  --
> *From:* Ben Rogall [xsi_l...@shaders.moederogall.com]
> *Sent:* 14 February 2014 07:45 PM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>   As a matter of fact, Modo is COM based. When programming with its SDK,
> the COM roots are more visible than with Softimage. However most everything
> is nicely wrapped in C++ classes so you don't usually have to deal with the
> low level nuts and bolts of COM.
>
> Ben
>
> On 2/14/2014 7:42 AM, Angus Davidson wrote:
>
> Unfortunately  it will be Softimages achilles heel if they don't find a
> way off of it (which is unlikely given the very small dev team) COM doesn't
> scale the way new 3d apps require. To many  bottlenecks.
>
>  Jumping into Modo for my first attempt at particles. Managed to get the
> following after my allotted 5 minutes
>
>  pic.twitter.com/EDOKamNkkn
>
>  Just used a plain cube as a poly source. Need to update that with a more
> random rock ;)
>
>
>
>
>
>   From: Guillaume Laforge 
> Reply-To: "softimage@listproc.autodesk.com" <
> softimage@listproc.autodesk.com>
> Date: Friday 14 February 2014 at 2:06 PM
> To: "softimage@listproc.autodesk.com" 
> Subject: Re: Survey - how would you do this?
>
>   Softimage code in Linux is pretty much the same as on Windows and so is
> using COM too. How it works on Linux has been explain on this list many
> time (almost as often as people asking how to
> install Softimage successfully  on Linux).
>
>  I have nothing against COM in theory, except that it is hard to find
> good programmers mastering this interface those days. It is an old tech and
> Softimage is built on it. Easy to get the picture no ?
>
>
>
> On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson <
> angus.david...@wits.ac.za> wrote:
>
>> How does the linux version get around all of the MFC / Com+ dependencies
>> ? Would be great if we could get the  linux version to be used as the
>> compile base. In theory then a more open windows version and even a mac
>> version would be possible ;)
>>
>> On the plus side at least you have moved to a decent laptop now ;)
>>
>> My only experience in this was from a long time back. FBX , was buggy and
>> Alembic wasnt yet an option. We came up with an exporter that allowed a
>> decent to and fro between 3D app and Games engine.
>>
>> Similar to how the obj exporter worked it was text based and had a
>> separate include file for geometry, materials,bones animation etc. This
>> allowed it to be be easy to use for version control , and also allowed us
>> to reuse animations etc  across more then one model. Admittedly things were
>> a lot simpler then .
>>
>> Havent looked at Modo for creating the asteroid belt.  will try have a
>> look this weekend.
>>
>> 
>> From: Luc-Eric Rousseau [luceri...@gmail.com]
>> Sent: 14 February 2014 04:26 AM
>> To: softimage@listproc.autodesk.com
>> Subject: Re: Survey - how would you do this?
>>
>>  imagine if we made such jokes every time the Fabric came to pimp their
>> stuff here. ;)
>>
>> If there is going to be a discussion about creating custom tools for
>> artists, sweeping statements about DCCs, and name dropping like Pixar,
>> it's in everyone's interest to be informed about the maya side of the
>> story.  On my side, as Maya UI team

RE: Survey - how would you do this?

[Angus Davidson]

Hi Ben

The big difference is Modo is also successfully cross platform, and in active 
development. When the time comes to move on they will be in a position to do so.

Something Softimage currently lacks.  Which is something Autodesk will regret 
down the line.



From: Ben Rogall [xsi_l...@shaders.moederogall.com]
Sent: 14 February 2014 07:45 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

As a matter of fact, Modo is COM based. When programming with its SDK, the COM 
roots are more visible than with Softimage. However most everything is nicely 
wrapped in C++ classes so you don't usually have to deal with the low level 
nuts and bolts of COM.

Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t find a way off 
of it (which is unlikely given the very small dev team) COM doesn’t scale the 
way new 3d apps require. To many  bottlenecks.

Jumping into Modo for my first attempt at particles. Managed to get the 
following after my allotted 5 minutes

pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a more random 
rock ;)





From: Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so is using 
COM too. How it works on Linux has been explain on this list many time (almost 
as often as people asking how to install Softimage successfully  on Linux).

I have nothing against COM in theory, except that it is hard to find good 
programmers mastering this interface those days. It is an old tech and 
Softimage is built on it. Easy to get the picture no ?



On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson 
mailto:angus.david...@wits.ac.za>> wrote:
How does the linux version get around all of the MFC / Com+ dependencies ? 
Would be great if we could get the  linux version to be used as the compile 
base. In theory then a more open windows version and even a mac version would 
be possible ;)

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this was from a long time back. FBX , was buggy and 
Alembic wasnt yet an option. We came up with an exporter that allowed a decent 
to and fro between 3D app and Games engine.

Similar to how the obj exporter worked it was text based and had a separate 
include file for geometry, materials,bones animation etc. This allowed it to be 
be easy to use for version control , and also allowed us to reuse animations 
etc  across more then one model. Admittedly things were a lot simpler then .

Havent looked at Modo for creating the asteroid belt.  will try have a look 
this weekend.


From: Luc-Eric Rousseau [luceri...@gmail.com<mailto:luceri...@gmail.com>]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

imagine if we made such jokes every time the Fabric came to pimp their
stuff here. ;)

If there is going to be a discussion about creating custom tools for
artists, sweeping statements about DCCs, and name dropping like Pixar,
it's in everyone's interest to be informed about the maya side of the
story.  On my side, as Maya UI team lead, pyside (python+qt) is part
of the day-to-day.  Something I could have never imagine on Softimage.
I'd always have to write everything in C++/MFC to do anything.  I've
also dumped my PC for a Macbook Pro.


On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
mailto:guillaume.laforge...@gmail.com>> wrote:
> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron 
> mailto:car...@gmail.com>> wrote:
>>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
>> mailto:guillaume.laforge...@gmail.com>> 
>> wrote:
>>>
>>> I've got the feeling that someone is trying to sell us some Autodesk
>>> products here.
>>> Can I have a special discount if I print this thread and bring it to my
>>> reseller ?
>>>
>
=


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 
permis

Re: Re[2]: Survey - how would you do this?

[Emilio Hernandez]

Hey Siew, thanks for tip.  Transfer attributes didn't worked.  I took the
mesh UV it in Softimage and back to Maya due to Maya's crappy UV tools.

I took a look at the Diamond Tools.  Nice add on for Maya just to get
modeling, and UV unfolding kind of Softimage "old technology" out of the
box behavior for an additional $200 bucks...

And Mirko just touch the main point here.

Luc-Eric what happened in that transition when you guys were ripped off
from Softimage?  Seems like you suffered a brain wash.  I don't care about
the name of the software.  But at this point I would expect a 3d software
from Autodesk with the beauty of Softimage and the developer, progamming
capability of Maya.  But sadly that is not the case.

Instead we have from Autodesk a Frankenstein and a dying king locked in a
tower.






2014-02-14 11:25 GMT-06:00 Mirko Jankovic :

> well from what I can see and also understand from Luc-Eric Maya is
> great... for developers and programmers but crap for artist.
> SI on the other hand is love at first sight for Artist but not so for
> developers.
> S... should 3d art application be for programmers and developers or to
> make life easy for artist?
>
>
>
> On Fri, Feb 14, 2014 at 6:16 PM, Emilio Hernandez wrote:
>
>> It is really a shame that Autodesk when bought Softimage, instead of
>> starting the migration from the COM/OLE platform, just took the guts outs
>> of Softimage.  The Dev team. To insert it in Maya, which, IMHO is sitll
>> basically the same from those days.  I have not seen any "super
>> development" of Maya as it would be expected by such corporate strategy...
>> If by now, Maya had the functionality, beauty, elegance, design, and
>> workflow of Softimage,  the story would be different.
>>
>> I am married to Softimage until "death tear us appart".
>>
>> Maybe it is not Softimage's days the only ones that are counted...
>>
>> Autodesk has been loosing market lately, and has been unsuccesful of
>> driving the "small" but solid Softimage user base to Maya.  And when the
>> time comes, my perception is that the mayority of us, at least in the
>> film/vfx industry is looking to other platforms rather than Maya.  They
>> betted to the wrong horse, again imho.  Maybe I am wrong.  But only time
>> will tell.
>>
>>
>>
>>
>>
>>
>>
>> 2014-02-14 10:15 GMT-06:00 Angus Davidson :
>>
>>
>>> For historical perspective, you need to know that we were owned by
>>> Microsoft in 1998, and there was no indication that SGI or the Mac
>>> would come back from the dead.  The company began to consider the Film
>>> industry as "legacy" and that games would be the future.  The product
>>> was named after the name of the game exchange format to subtly suggest
>>> that.  Max also had taken the Windows NT jump, with huge success.
>>>
>>> Well Microsoft hasnt gotten any better at predicting tech since.  Smart
>>> phones, tablets, pretty much anything internet based ;)=
>>> >> style="width:100%;">
>>> 
>>> >> face="arial,sans-serif" size="1" color="#99">>> style="font-size:11px;">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: Survey - how would you do this?

[Ben Rogall]

As a matter of fact, Modo is COM based. When programming with its SDK, 
the COM roots are more visible than with Softimage. However most 
everything is nicely wrapped in C++ classes so you don't usually have to 
deal with the low level nuts and bolts of COM.


Ben

On 2/14/2014 7:42 AM, Angus Davidson wrote:
Unfortunately  it will be Softimages achilles heel if they don’t find 
a way off of it (which is unlikely given the very small dev team) COM 
doesn’t scale the way new 3d apps require. To many  bottlenecks.


Jumping into Modo for my first attempt at particles. Managed to get 
the following after my allotted 5 minutes


pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a 
more random rock ;)






From: Guillaume Laforge <mailto:guillaume.laforge...@gmail.com>>
Reply-To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>

Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com 
<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>

Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so 
is using COM too. How it works on Linux has been explain on this list 
many time (almost as often as people asking how to 
install Softimage successfully  on Linux).


I have nothing against COM in theory, except that it is hard to find 
good programmers mastering this interface those days. It is an old 
tech and Softimage is built on it. Easy to get the picture no ?




On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson 
mailto:angus.david...@wits.ac.za>> wrote:


How does the linux version get around all of the MFC / Com+
dependencies ? Would be great if we could get the  linux version
to be used as the compile base. In theory then a more open windows
version and even a mac version would be possible ;)

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this was from a long time back. FBX , was
buggy and Alembic wasnt yet an option. We came up with an exporter
that allowed a decent to and fro between 3D app and Games engine.

Similar to how the obj exporter worked it was text based and had a
separate include file for geometry, materials,bones animation etc.
This allowed it to be be easy to use for version control , and
also allowed us to reuse animations etc  across more then one
model. Admittedly things were a lot simpler then .

Havent looked at Modo for creating the asteroid belt.  will try
have a look this weekend.


From: Luc-Eric Rousseau [luceri...@gmail.com
<mailto:luceri...@gmail.com>]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.com
    <mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

imagine if we made such jokes every time the Fabric came to pimp their
stuff here. ;)

If there is going to be a discussion about creating custom tools for
artists, sweeping statements about DCCs, and name dropping like Pixar,
it's in everyone's interest to be informed about the maya side of the
story.  On my side, as Maya UI team lead, pyside (python+qt) is part
of the day-to-day.  Something I could have never imagine on Softimage.
I'd always have to write everything in C++/MFC to do anything.  I've
also dumped my PC for a Macbook Pro.


On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
mailto:guillaume.laforge...@gmail.com>> wrote:
> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron mailto:car...@gmail.com>> wrote:
>>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
>> mailto:guillaume.laforge...@gmail.com>> wrote:
>>>
>>> I've got the feeling that someone is trying to sell us some
Autodesk
>>> products here.
>>> Can I have a special discount if I print this thread and bring
it to my
>>> reseller ?
>>>
>
=


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 

FW: Re[2]: Survey - how would you do this?

[Angus Davidson]

Have a look at

http://www.thefoundry.co.uk/products/modo/learn/

Specifically the getting started videos for animation and particles. It  really 
shows how they are trying to make the tools artist friendly.

There is definitely a place for the more technical approach and I would go as 
far as saying Softimage in a lot of tech areas has Maya beat. More so then 
anyone in AD cares to admit.





From: Mirko Jankovic [mirkoj.anima...@gmail.com]
Sent: 14 February 2014 07:25 PM
To: softimage@listproc.autodesk.com
Subject: Re: Re[2]: Survey - how would you do this?

well from what I can see and also understand from Luc-Eric Maya is great... for 
developers and programmers but crap for artist.
SI on the other hand is love at first sight for Artist but not so for 
developers.
S... should 3d art application be for programmers and developers or to make 
life easy for artist?





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: Re[2]: Survey - how would you do this?

[Mirko Jankovic]

well from what I can see and also understand from Luc-Eric Maya is great...
for developers and programmers but crap for artist.
SI on the other hand is love at first sight for Artist but not so for
developers.
S... should 3d art application be for programmers and developers or to
make life easy for artist?



On Fri, Feb 14, 2014 at 6:16 PM, Emilio Hernandez  wrote:

> It is really a shame that Autodesk when bought Softimage, instead of
> starting the migration from the COM/OLE platform, just took the guts outs
> of Softimage.  The Dev team. To insert it in Maya, which, IMHO is sitll
> basically the same from those days.  I have not seen any "super
> development" of Maya as it would be expected by such corporate strategy...
> If by now, Maya had the functionality, beauty, elegance, design, and
> workflow of Softimage,  the story would be different.
>
> I am married to Softimage until "death tear us appart".
>
> Maybe it is not Softimage's days the only ones that are counted...
>
> Autodesk has been loosing market lately, and has been unsuccesful of
> driving the "small" but solid Softimage user base to Maya.  And when the
> time comes, my perception is that the mayority of us, at least in the
> film/vfx industry is looking to other platforms rather than Maya.  They
> betted to the wrong horse, again imho.  Maybe I am wrong.  But only time
> will tell.
>
>
>
>
>
>
>
> 2014-02-14 10:15 GMT-06:00 Angus Davidson :
>
>
>> For historical perspective, you need to know that we were owned by
>> Microsoft in 1998, and there was no indication that SGI or the Mac
>> would come back from the dead.  The company began to consider the Film
>> industry as "legacy" and that games would be the future.  The product
>> was named after the name of the game exchange format to subtly suggest
>> that.  Max also had taken the Windows NT jump, with huge success.
>>
>> Well Microsoft hasnt gotten any better at predicting tech since.  Smart
>> phones, tablets, pretty much anything internet based ;)=
>> > style="width:100%;">
>> 
>> > face="arial,sans-serif" size="1" color="#99">> style="font-size:11px;">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: Re[2]: Survey - how would you do this?

[Emilio Hernandez]

It is really a shame that Autodesk when bought Softimage, instead of
starting the migration from the COM/OLE platform, just took the guts outs
of Softimage.  The Dev team. To insert it in Maya, which, IMHO is sitll
basically the same from those days.  I have not seen any "super
development" of Maya as it would be expected by such corporate strategy...
If by now, Maya had the functionality, beauty, elegance, design, and
workflow of Softimage,  the story would be different.

I am married to Softimage until "death tear us appart".

Maybe it is not Softimage's days the only ones that are counted...

Autodesk has been loosing market lately, and has been unsuccesful of
driving the "small" but solid Softimage user base to Maya.  And when the
time comes, my perception is that the mayority of us, at least in the
film/vfx industry is looking to other platforms rather than Maya.  They
betted to the wrong horse, again imho.  Maybe I am wrong.  But only time
will tell.







2014-02-14 10:15 GMT-06:00 Angus Davidson :

>
> For historical perspective, you need to know that we were owned by
> Microsoft in 1998, and there was no indication that SGI or the Mac
> would come back from the dead.  The company began to consider the Film
> industry as "legacy" and that games would be the future.  The product
> was named after the name of the game exchange format to subtly suggest
> that.  Max also had taken the Windows NT jump, with huge success.
>
> Well Microsoft hasnt gotten any better at predicting tech since.  Smart
> phones, tablets, pretty much anything internet based ;)=
>  style="width:100%;">
> 
>  size="1" color="#99">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: Survey - how would you do this?

[Siew Yi Liang]

(sneaks in)

   And speaking of constrains.   To constrain to a point on a mesh in
   Maya, you need to have UV's!  and watch out.  If you constrain
   to a point that in the UV is in two different coordinates... ciao...
   BTW if you need to constraint to a point on a mesh in Maya, you can
   use clusters without the mesh needing to have UVs.


http://www.terencejacobson.com/hyperRealMeshParent.mel

That script is an example, really nice for getting things like the 
'doritos' effect in Maya without doing too much under-the-hood stuff.
However if you do not require the clusters to deform in parallel with 
other deformers (skinClusters, blendshapes what have you) then the 
relative attribute in the cluster should allow for most types of 
object-to-point-on-mesh constraints. And yes, the default point-to-poly 
constraint is rubbish. :P


As far as transferrring UVs go...did the Transfer Attributes tool not 
work out? I know it's not really as flexible as GATOR, but usually for 
99% of cases where topology is identical it should work out fine. 
However I use Diamant Tools regularly when I need to project details/UVs 
from mesh to mesh where the topology isn't the same for whatever reason.


Hopefully that helps out if you need to tackle these specific problems 
again!


(sneaks out)

Yours sincerely,
Siew Yi Liang

On 2/13/2014 8:15 PM, Emilio Hernandez wrote:
Sorry to jump into this masters discution, but don't we have PyQT in 
Softimage also?


And now that Luc-Eric jumped in...

Ok, Maya is more customizable, and better for Devs to integrate it 
into a pipeline and bla, bla, bla. Because out of the box sorry but... 
p


I am a novel in Maya and I am using it because I need to, not because 
I am convinced of using it. And the more I use it, the more I love 
Softimage.


I couldn't find a way to transfer a simple UV  from one mesh to 
another.  So I went and dug into Creative Crash to find a script...


A script for this, a script for that.  The only thing I want to thank 
Maya is that I started scripting again...  Thank god I have two 
monitors to have the script editor open with I don't know how many 
tabs.  Or why not.  I can have a lot of buttons clogging more my 
workspace with nice Maya icons.  I don't have time to start getting 
"creative" to draw an icon for each additional script I write to do a 
simple task...


And speaking of constrains.   To constrain to a point on a mesh in 
Maya, you need to have UV's!  and watch out.  If you constrain to 
a point that in the UV is in two different coordinates... ciao...


So yes maybe when you have an army of Devs scripting and scripting. 
You can have awsome custom tools...


But when you have a small studio or you are freelance, for me Maya is 
"no go".


So instead of spreading the word on how "good is Maya" compared to 
"Softimage" to try to convince us to switch platforms, because Maya is 
"more customizable".  We want a descent upgrade of Softimage.  Not 
only a "super camera switcher".


What is the fear of Autodesk?

That if you guys start making real improvements on Softimage the Maya 
"industry standard" farce will fall?


Sorry but I am really pissed off of how Autodesk is handling 
Softimage.  The best thing you can do is put it on sale so that people 
who really cares, will take Softimage to the next level instead of 
burying it in Asia.


But this will hardly happen.  Softimage in some other hands will be a 
very strong contender to Maya






















2014-02-13 20:49 GMT-06:00 Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>>:


Btw, would love to see how to build such asteroid belt in Modo ;)


On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind
mailto:ml...@carbinestudios.com>> wrote:

Below:


-Original Message-
From: softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>
[mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>] On Behalf Of
Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind
mailto:ml...@carbinestudios.com>>
wrote:
>>>   Allows us to define our own primitives, data structures,
and treats those data structures as first class citizens in
the API.

>yeah, with only experience with Softimage's SDK one might
think that's
>something special.   But it's a common thing to do with Maya.

[Matt]
I was paraphrasing a comment made by one of our engineers.
 Although I have run into 

RE: Re[2]: Survey - how would you do this?

[Angus Davidson]

For historical perspective, you need to know that we were owned by
Microsoft in 1998, and there was no indication that SGI or the Mac
would come back from the dead.  The company began to consider the Film
industry as "legacy" and that games would be the future.  The product
was named after the name of the game exchange format to subtly suggest
that.  Max also had taken the Windows NT jump, with huge success.

Well Microsoft hasnt gotten any better at predicting tech since.  Smart phones, 
tablets, pretty much anything internet based ;)=
 

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: Re[2]: Survey - how would you do this?

[Angus Davidson]

Part of the problem I have found with most windows SDKs it that even though 
they are laid out in nice separated layers in order to get things to actually 
work you need to hot wire between so many layers that in the end your wound up 
tighter then a lump of coal trying to be a diamond. 

Unfortunately Mac OS X wasn't around then and most other Unixes were unfriendly 
to the point of being sadistic.

Personally I would have preferred if instead of releasing ICE when they did  
they had rather spent that time on rebuilding SI using components that would 
have been cross platform. It also would have kept Softimage off Autodesks radar 
for a bit longer. Once it was in Autodesks's domain there would never be the 
will / money /dev time to get that type of task done. 

That and it kills every time when I install Softimage (in my job I do that a 
lot) and you install Composite when theres a perfectly good compositor built in 
(if it had been developed)

Unfortunately that's not a developers fault its a managements fault. Softimage 
is the app where great tech goes to die. To me that is inexcusable. 





From: Eugen Sares [sof...@mail.sprit.org]
Sent: 14 February 2014 04:17 PM
To: softimage@listproc.autodesk.com
Subject: Re[2]: Survey - how would you do this?

While we are at it, out of interest:
could you elaborate a bit what the part of Softimage is that is married
so tightly to Windows? UI, event handling, whatever...?
Is Soft not laid out in a way so that higher functional levels sit atop
'abstract' lower level ones, so you could make changes down there
comparatively easy?
Thanks!
Eugen


-- Originalnachricht --
Von: "Luc-Eric Rousseau" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 14.02.2014 15:10:38
Betreff: Re: Survey - how would you do this?

>>  Unfortunately it will be Softimages achilles heel if they don't find
>>a way off of it (which is unlikely given the very small dev team)
>>  COM doesn't scale the way new 3d apps require. To many bottlenecks.
>>
>
>It's moot, but COM is fine, it's no more or less scalable than C++.
>Firefox is entirely built with a cross platform clone of COM, called
>XPCOM. The problem is that we made XSI only for a Windows NT-only
>future. The mainwin decision was meant to be something temporary until
>SGI died out. It's not just COM, it's a 100% windows sdk app.
>
>On Fri, Feb 14, 2014 at 8:42 AM, Angus Davidson
> wrote:
>>>  Jumping into Modo for my first attempt at particles. Managed to get
>>>the following after my allotted 5 minutes
>>
>>  pic.twitter.com/EDOKamNkkn
>>
>>  Just used a plain cube as a poly source. Need to update that with a
>>more random rock ;)
>>


---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com


=
 

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: Re[2]: Survey - how would you do this?

[Luc-Eric Rousseau]

On Fri, Feb 14, 2014 at 9:17 AM, Eugen Sares  wrote:
> While we are at it, out of interest:
> could you elaborate a bit what the part of Softimage is that is married so
> tightly to Windows? UI, event handling, whatever...?
> Is Soft not laid out in a way so that higher functional levels sit atop
> 'abstract' lower level ones, so you could make changes down there
> comparatively easy?

that would have been nice, but there is no platform abstraction layer
in XSI.  The only bits of code that are cross platform are the ones
that needed to work in a mental ray shader, and some odd bits from
Softimage|3D. Every little thing in XSI is a COM object for example
geometries, parameters, or fcurves.  We did abstract things, in
beautiful ways that allow everything to work with everything else and
be browsed and built elegantly, but not the OS itself. The dev
environment was assumed to be windows, and the programming model
COM/OLE.  The softimage source code is very high quality, but married
to windows.

For historical perspective, you need to know that we were owned by
Microsoft in 1998, and there was no indication that SGI or the Mac
would come back from the dead.  The company began to consider the Film
industry as "legacy" and that games would be the future.  The product
was named after the name of the game exchange format to subtly suggest
that.  Max also had taken the Windows NT jump, with huge success.

Re: Survey - how would you do this?

[Eric Thivierge]

Instead of bashing people / other products you may want to spend more 
time welcoming the other technologies and applauding the technology they 
are coming up with. You'll be doing less damage to how you and AD is 
perceived.


Super unprofessional.

Eric T.

On 2/14/2014 7:09 AM, Luc-Eric Rousseau wrote:
You're a bit of a special case in the "bias" departement, imho, given 
that you were fire from Autodesk. 

Re[2]: Survey - how would you do this?

[Eugen Sares]

While we are at it, out of interest:
could you elaborate a bit what the part of Softimage is that is married 
so tightly to Windows? UI, event handling, whatever...?
Is Soft not laid out in a way so that higher functional levels sit atop 
'abstract' lower level ones, so you could make changes down there 
comparatively easy?

Thanks!
Eugen


-- Originalnachricht --
Von: "Luc-Eric Rousseau" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 14.02.2014 15:10:38
Betreff: Re: Survey - how would you do this?

 Unfortunately it will be Softimages achilles heel if they don't find 
a way off of it (which is unlikely given the very small dev team)

 COM doesn't scale the way new 3d apps require. To many bottlenecks.



It's moot, but COM is fine, it's no more or less scalable than C++.
Firefox is entirely built with a cross platform clone of COM, called
XPCOM. The problem is that we made XSI only for a Windows NT-only
future. The mainwin decision was meant to be something temporary until
SGI died out. It's not just COM, it's a 100% windows sdk app.

On Fri, Feb 14, 2014 at 8:42 AM, Angus Davidson
 wrote:
 Jumping into Modo for my first attempt at particles. Managed to get 
the following after my allotted 5 minutes


 pic.twitter.com/EDOKamNkkn

 Just used a plain cube as a poly source. Need to update that with a 
more random rock ;)





---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

> Unfortunately  it will be Softimages achilles heel if they don't find a way 
> off of it (which is unlikely given the very small dev team)
> COM doesn't scale the way new 3d apps require. To many  bottlenecks.
>

It's moot, but COM is fine, it's no more or less scalable than C++.
Firefox is entirely built with a cross platform clone of COM, called
XPCOM. The problem is that we made XSI only for a Windows NT-only
future. The mainwin decision was meant to be something temporary until
SGI died out.  It's not just COM, it's a 100% windows sdk app.

On Fri, Feb 14, 2014 at 8:42 AM, Angus Davidson
 wrote:
>> Jumping into Modo for my first attempt at particles. Managed to get the 
>> following after my allotted 5 minutes
>
> pic.twitter.com/EDOKamNkkn
>
> Just used a plain cube as a poly source. Need to update that with a more 
> random rock ;)
>

Re: Survey - how would you do this?

[Angus Davidson]

Unfortunately  it will be Softimages achilles heel if they don’t find a way off 
of it (which is unlikely given the very small dev team) COM doesn’t scale the 
way new 3d apps require. To many  bottlenecks.

Jumping into Modo for my first attempt at particles. Managed to get the 
following after my allotted 5 minutes

pic.twitter.com/EDOKamNkkn

Just used a plain cube as a poly source. Need to update that with a more random 
rock ;)





From: Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Friday 14 February 2014 at 2:06 PM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: Re: Survey - how would you do this?

Softimage code in Linux is pretty much the same as on Windows and so is using 
COM too. How it works on Linux has been explain on this list many time (almost 
as often as people asking how to install Softimage successfully  on Linux).

I have nothing against COM in theory, except that it is hard to find good 
programmers mastering this interface those days. It is an old tech and 
Softimage is built on it. Easy to get the picture no ?



On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson 
mailto:angus.david...@wits.ac.za>> wrote:
How does the linux version get around all of the MFC / Com+ dependencies ? 
Would be great if we could get the  linux version to be used as the compile 
base. In theory then a more open windows version and even a mac version would 
be possible ;)

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this was from a long time back. FBX , was buggy and 
Alembic wasnt yet an option. We came up with an exporter that allowed a decent 
to and fro between 3D app and Games engine.

Similar to how the obj exporter worked it was text based and had a separate 
include file for geometry, materials,bones animation etc. This allowed it to be 
be easy to use for version control , and also allowed us to reuse animations 
etc  across more then one model. Admittedly things were a lot simpler then .

Havent looked at Modo for creating the asteroid belt.  will try have a look 
this weekend.


From: Luc-Eric Rousseau [luceri...@gmail.com<mailto:luceri...@gmail.com>]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

imagine if we made such jokes every time the Fabric came to pimp their
stuff here. ;)

If there is going to be a discussion about creating custom tools for
artists, sweeping statements about DCCs, and name dropping like Pixar,
it's in everyone's interest to be informed about the maya side of the
story.  On my side, as Maya UI team lead, pyside (python+qt) is part
of the day-to-day.  Something I could have never imagine on Softimage.
I'd always have to write everything in C++/MFC to do anything.  I've
also dumped my PC for a Macbook Pro.


On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
mailto:guillaume.laforge...@gmail.com>> wrote:
> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron 
> mailto:car...@gmail.com>> wrote:
>>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
>> mailto:guillaume.laforge...@gmail.com>> 
>> wrote:
>>>
>>> I've got the feeling that someone is trying to sell us some Autodesk
>>> products here.
>>> Can I have a special discount if I print this thread and bring it to my
>>> reseller ?
>>>
>
=


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. 








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 

Re: Survey - how would you do this?

[Helge Mathee]

You are not doing yourself a favor, Luc-Eric.
Quite an unprofessional cheap shot.

On 14.02.2014 13:09, Luc-Eric Rousseau wrote:

On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
 wrote:

Luc-Eric, you can try as you want, but you are inside AD, so you are biased
as much as me when I was speaking about Softimage as an Autodesk employee or
speaking about Creation Platform as a Fabric employee.

I'm sure you not saying you were making dishonest pro-fabric posts
when you were getting paychecks from Fabric. Anyways, I'm stating
verifiable facts, not making board statements about something being
"better"

Everyone is biased to the things they know best, clients or employees.

You're a bit of a special case in the "bias" departement, imho, given
that you were fire from Autodesk.

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

On Thu, Feb 13, 2014 at 11:15 PM, Emilio Hernandez  wrote:
>
> Sorry to jump into this masters discution, but don't we have PyQT in 
> Softimage also?

You can download a plugin, but it's never going to be a built-in
feature you can assume is there and working. But most importantly, the
Maya UI is native Qt, so you have access to it all through PySide,
intermix Mel and Pyside.  There are no boundaries between Maya UI and
QT and PySide.

>  couldn't find a way to transfer a simple UV  from one mesh to another.  So I 
> went and dug into Creative Crash to find a script...

This is off topic, but what was wrong with Mesh->Transfer Attrbutes?

Re: Survey - how would you do this?

[Guillaume Laforge]

And about your comparaison with Fabric. You just forget that it is a small
team of human crafting their product. How can you compare that to
Bifrost/Whatever AD projects and speak about those theoretical futur
products on your own ! I just don't get the point on bashing a startup when
working in a large company. Are you scared by what they are doing maybe ?

I will stop the flames here.


On Fri, Feb 14, 2014 at 7:20 AM, Guillaume Laforge <
guillaume.laforge...@gmail.com> wrote:

> > You're a bit of a special case in the "bias" departement, imho, given
> that you were fire from Autodesk.
>
> Your last sentence is really rude Luc-Eric.
> Btw I still don't know why they fired me :). They just told me they needed
> to fire peoples...
> My guess was that I was not good in C++ COM ;).
>
>
>
>
>
>
> On Fri, Feb 14, 2014 at 7:09 AM, Luc-Eric Rousseau wrote:
>
>> On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
>>  wrote:
>> > Luc-Eric, you can try as you want, but you are inside AD, so you are
>> biased
>> > as much as me when I was speaking about Softimage as an Autodesk
>> employee or
>> > speaking about Creation Platform as a Fabric employee.
>>
>> I'm sure you not saying you were making dishonest pro-fabric posts
>> when you were getting paychecks from Fabric. Anyways, I'm stating
>> verifiable facts, not making board statements about something being
>> "better"
>>
>> Everyone is biased to the things they know best, clients or employees.
>>
>> You're a bit of a special case in the "bias" departement, imho, given
>> that you were fire from Autodesk.
>>
>
>

Re: Survey - how would you do this?

[Guillaume Laforge]

> You're a bit of a special case in the "bias" departement, imho, given
that you were fire from Autodesk.

Your last sentence is really rude Luc-Eric.
Btw I still don't know why they fired me :). They just told me they needed
to fire peoples...
My guess was that I was not good in C++ COM ;).






On Fri, Feb 14, 2014 at 7:09 AM, Luc-Eric Rousseau wrote:

> On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
>  wrote:
> > Luc-Eric, you can try as you want, but you are inside AD, so you are
> biased
> > as much as me when I was speaking about Softimage as an Autodesk
> employee or
> > speaking about Creation Platform as a Fabric employee.
>
> I'm sure you not saying you were making dishonest pro-fabric posts
> when you were getting paychecks from Fabric. Anyways, I'm stating
> verifiable facts, not making board statements about something being
> "better"
>
> Everyone is biased to the things they know best, clients or employees.
>
> You're a bit of a special case in the "bias" departement, imho, given
> that you were fire from Autodesk.
>

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
 wrote:
> Luc-Eric, you can try as you want, but you are inside AD, so you are biased
> as much as me when I was speaking about Softimage as an Autodesk employee or
> speaking about Creation Platform as a Fabric employee.

I'm sure you not saying you were making dishonest pro-fabric posts
when you were getting paychecks from Fabric. Anyways, I'm stating
verifiable facts, not making board statements about something being
"better"

Everyone is biased to the things they know best, clients or employees.

You're a bit of a special case in the "bias" departement, imho, given
that you were fire from Autodesk.

Re: Survey - how would you do this?

[Guillaume Laforge]

Softimage code in Linux is pretty much the same as on Windows and so is
using COM too. How it works on Linux has been explain on this list many
time (almost as often as people asking how to
install Softimage successfully  on Linux).

I have nothing against COM in theory, except that it is hard to find good
programmers mastering this interface those days. It is an old tech and
Softimage is built on it. Easy to get the picture no ?



On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson
wrote:

> How does the linux version get around all of the MFC / Com+ dependencies ?
> Would be great if we could get the  linux version to be used as the compile
> base. In theory then a more open windows version and even a mac version
> would be possible ;)
>
> On the plus side at least you have moved to a decent laptop now ;)
>
> My only experience in this was from a long time back. FBX , was buggy and
> Alembic wasnt yet an option. We came up with an exporter that allowed a
> decent to and fro between 3D app and Games engine.
>
> Similar to how the obj exporter worked it was text based and had a
> separate include file for geometry, materials,bones animation etc. This
> allowed it to be be easy to use for version control , and also allowed us
> to reuse animations etc  across more then one model. Admittedly things were
> a lot simpler then .
>
> Havent looked at Modo for creating the asteroid belt.  will try have a
> look this weekend.
>
> 
> From: Luc-Eric Rousseau [luceri...@gmail.com]
> Sent: 14 February 2014 04:26 AM
> To: softimage@listproc.autodesk.com
> Subject: Re: Survey - how would you do this?
>
> imagine if we made such jokes every time the Fabric came to pimp their
> stuff here. ;)
>
> If there is going to be a discussion about creating custom tools for
> artists, sweeping statements about DCCs, and name dropping like Pixar,
> it's in everyone's interest to be informed about the maya side of the
> story.  On my side, as Maya UI team lead, pyside (python+qt) is part
> of the day-to-day.  Something I could have never imagine on Softimage.
> I'd always have to write everything in C++/MFC to do anything.  I've
> also dumped my PC for a Macbook Pro.
>
>
> On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
>  wrote:
> > Don't forget to print the threads/coupons Steven !
> >
> >
> > On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:
> >>
> >> ya, i get that feeling too ;)
> >>
> >> its magical
> >>
> >>
> >> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
> >>  wrote:
> >>>
> >>> I've got the feeling that someone is trying to sell us some Autodesk
> >>> products here.
> >>> Can I have a special discount if I print this thread and bring it to my
> >>> reseller ?
> >>>
> >
> =
>  style="width:100%;">
> 
>  size="1" color="#99">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: Survey - how would you do this?

[Angus Davidson]

Just had an image of a horse with an embedded wacom. Yup that’s going to be 
hard to unsee.



From: Mirko Jankovic 
mailto:mirkoj.anima...@gmail.com>>
Reply-To: 
"softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Date: Friday 14 February 2014 at 8:11 AM
To: "softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>" 
mailto:softimage@listproc.autodesk.com>>
Subject: Re: Survey - how would you do this?

really nice, first jump into thread Luc-Eric and question is like oh ditch SI 
what do you wanna use next (*cough* Maya *cough*)
But as someone else mentioned... there is old saying...
"Every gypsy brags about his horse"
not sure how it sounds in English but should get across...


On Fri, Feb 14, 2014 at 4:42 AM, Sebastien Sterling 
mailto:sebastien.sterl...@gmail.com>> wrote:
You can do it in cinema4D ! with the asteroid belt deformer, its right next to 
the popcorn deformer and the flap your arms like a bird deformer !


On 14 February 2014 03:49, Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>> wrote:
Btw, would love to see how to build such asteroid belt in Modo ;)


On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Below:


-Original Message-
From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?

On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
>>>   Allows us to define our own primitives, data structures, and treats those 
>>> data structures as first class citizens in the API.

>yeah, with only experience with Softimage's SDK one might think that's
>something special.   But it's a common thing to do with Maya.

[Matt]
I was paraphrasing a comment made by one of our engineers.  Although I have run 
into the issue myself more than once.


>sure, Fabric requires no work at all to make it usable for artist..
>it's magical. (Does not really answer the questions about your uv editing, 
>retopology, and reduction  problems, though)

[Matt]
Never claimed it did.  Only said it's closer in paradigm to what we need, and 
it still needs to mature for us to give it a serious look.  What it does offer 
is the ability to take control of the situation and develop what we need 
without re-inventing the wheel from scratch every time.



>About authoring stuff that would not be obviously better authored directly in 
>the game engine:
>there are a lot of custom authoring tools out there where the tool is actually 
>the Maya running in library mode.
>You have no way of knowing this if all you see is a video of it on the >web, 
>the maya UI is not there at all,
>it looks like it was a custom tool written from scratch.  Maya in library mode 
>takes no licenses.  All of this is simply
> inconceivable from a Softimage point of view, and it was a factor in getting 
> kicked out of the bigger places.

[Matt]
The point of editing in the game engine is changes to the engine are 
immediately available to the artist creating content.  What they see is what 
they get, and with real time feedback.  A large portion of any artists' day is 
spent waiting for files to export from the DCC and collate into the engine.  In 
some cases many minutes per export/collate. That is not iteration friendly and 
problematic for engineers as they have another set of code to maintain and keep 
in sync.   Having a Maya backend in library mode doesn't solve this problem.

One problem we continually face is the ability to see an asset in the context 
of the game with proper lighting, fx, and other game specific data in the 
authoring stages.  An artist needs to see how a reflective surface will look in 
a particular zone of a world.  You cannot easily replicate that in a commercial 
DCC.  Likewise, it's not simple to recreate the DCC's editing power for 
creating raw assets.  The process of moving towards the engine has to start 
somewhere.  Right now many games have level editors, texture paging editors, 
and so on.  Those tools need to come together and start incorporating raw 3D 
data into the mix where it can be more easily edited.  That's the next 
generation of tools. Most engines already define how animation works and 
exposing transform manipulators and FCurve editors wouldn't be too much of a 
stretch beyond what's already in the system (in comparison to doing the same 
for modeling, texturing, etc...).  The DCC shouldn&#

Re: Survey - how would you do this?

[Mirko Jankovic]

really nice, first jump into thread Luc-Eric and question is like oh ditch
SI what do you wanna use next (*cough* Maya *cough*)
But as someone else mentioned... there is old saying...
"Every gypsy brags about his horse"
not sure how it sounds in English but should get across...


On Fri, Feb 14, 2014 at 4:42 AM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> You can do it in cinema4D ! with the asteroid belt deformer, its right
> next to the popcorn deformer and the flap your arms like a bird deformer !
>
>
> On 14 February 2014 03:49, Guillaume Laforge <
> guillaume.laforge...@gmail.com> wrote:
>
>> Btw, would love to see how to build such asteroid belt in Modo ;)
>>
>>
>> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>>
>>> Below:
>>>
>>>
>>> -Original Message-
>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>> Sent: Thursday, February 13, 2014 5:26 PM
>>> To: softimage@listproc.autodesk.com
>>> Subject: Re: Survey - how would you do this?
>>>
>>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>>> wrote:
>>> >>>   Allows us to define our own primitives, data structures, and
>>> treats those data structures as first class citizens in the API.
>>>
>>> >yeah, with only experience with Softimage's SDK one might think that's
>>> >something special.   But it's a common thing to do with Maya.
>>>
>>> [Matt]
>>> I was paraphrasing a comment made by one of our engineers.  Although I
>>> have run into the issue myself more than once.
>>>
>>>
>>> >sure, Fabric requires no work at all to make it usable for artist..
>>> >it's magical. (Does not really answer the questions about your uv
>>> editing, retopology, and reduction  problems, though)
>>>
>>> [Matt]
>>> Never claimed it did.  Only said it's closer in paradigm to what we
>>> need, and it still needs to mature for us to give it a serious look.  What
>>> it does offer is the ability to take control of the situation and develop
>>> what we need without re-inventing the wheel from scratch every time.
>>>
>>>
>>>
>>> >About authoring stuff that would not be obviously better authored
>>> directly in the game engine:
>>> >there are a lot of custom authoring tools out there where the tool is
>>> actually the Maya running in library mode.
>>> >You have no way of knowing this if all you see is a video of it on the
>>> >web, the maya UI is not there at all,
>>> >it looks like it was a custom tool written from scratch.  Maya in
>>> library mode takes no licenses.  All of this is simply
>>> > inconceivable from a Softimage point of view, and it was a factor in
>>> getting kicked out of the bigger places.
>>>
>>> [Matt]
>>> The point of editing in the game engine is changes to the engine are
>>> immediately available to the artist creating content.  What they see is
>>> what they get, and with real time feedback.  A large portion of any
>>> artists' day is spent waiting for files to export from the DCC and collate
>>> into the engine.  In some cases many minutes per export/collate. That is
>>> not iteration friendly and problematic for engineers as they have another
>>> set of code to maintain and keep in sync.   Having a Maya backend in
>>> library mode doesn't solve this problem.
>>>
>>> One problem we continually face is the ability to see an asset in the
>>> context of the game with proper lighting, fx, and other game specific data
>>> in the authoring stages.  An artist needs to see how a reflective surface
>>> will look in a particular zone of a world.  You cannot easily replicate
>>> that in a commercial DCC.  Likewise, it's not simple to recreate the DCC's
>>> editing power for creating raw assets.  The process of moving towards the
>>> engine has to start somewhere.  Right now many games have level editors,
>>> texture paging editors, and so on.  Those tools need to come together and
>>> start incorporating raw 3D data into the mix where it can be more easily
>>> edited.  That's the next generation of tools. Most engines already define
>>> how animation works and exposing transform manipulators and FCurve editors
>>> wouldn't be too much of a stretch beyond what's already in the syste

RE: Survey - how would you do this?

[Marc Brinkley]

Don't get me wrong...its not like I am very excited to use it either. I knew 
coming here my days of hands on SI work was over. But honestly, my career over 
the last 8 years has veered away from hands on content creation so I really 
don't use any DCC these days...however my team does use Maya as the main tool 
exactly because it is so customizable. Along with Modo and a handful of SI 
users too!

But, just because Maya is so customizable doesn't mean that it makes life 
easier. From my point of view, this place built their entire workflow and 
toolset on Maya and we are paying a deep cost because of that in time, money 
and sanity. Most people don't see it that way. But having used other DCCs and 
other engines this pain was completely self-inflicted.

The burn rate on building out Maya tools and the overhead we are paying to just 
support and bug fix our own tools is crazy. I would have rather spent that 
money on other tools, workflows and even building our own editor. Then at least 
we would have had all the control in the world.

This is why doing it all in the DCC doesn't make sense to me.

To Graham's point, yes I have seen one too many devs with eyes bigger than 
their stomach think they can build the next great engine and editor. Not too 
many places can actually afford to do that or even do it right. Though I have 
been lucky to work at places that can or at least be smart enough to just buy a 
license of UE3\4.

Meh 2 cents to the pile.

Back to my excel and powerpoint.

:)

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron
Sent: Thursday, February 13, 2014 6:01 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

sarcasm aside, i am not surprised people use maya for game dev.. i know very 
well how customizable it is, and envy it plenty. its just not... exciting to me.

On Thu, Feb 13, 2014 at 5:56 PM, Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>> wrote:
Don't forget to print the threads/coupons Steven !

On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron 
mailto:car...@gmail.com>> wrote:
ya, i get that feeling too ;)

its magical

On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>> wrote:
I've got the feeling that someone is trying to sell us some Autodesk products 
here.
Can I have a special discount if I print this thread and bring it to my 
reseller ?

RE: Survey - how would you do this?

[Angus Davidson]

How does the linux version get around all of the MFC / Com+ dependencies ? 
Would be great if we could get the  linux version to be used as the compile 
base. In theory then a more open windows version and even a mac version would 
be possible ;) 

On the plus side at least you have moved to a decent laptop now ;)

My only experience in this was from a long time back. FBX , was buggy and 
Alembic wasnt yet an option. We came up with an exporter that allowed a decent 
to and fro between 3D app and Games engine.

Similar to how the obj exporter worked it was text based and had a separate 
include file for geometry, materials,bones animation etc. This allowed it to be 
be easy to use for version control , and also allowed us to reuse animations 
etc  across more then one model. Admittedly things were a lot simpler then .

Havent looked at Modo for creating the asteroid belt.  will try have a look 
this weekend.


From: Luc-Eric Rousseau [luceri...@gmail.com]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

imagine if we made such jokes every time the Fabric came to pimp their
stuff here. ;)

If there is going to be a discussion about creating custom tools for
artists, sweeping statements about DCCs, and name dropping like Pixar,
it's in everyone's interest to be informed about the maya side of the
story.  On my side, as Maya UI team lead, pyside (python+qt) is part
of the day-to-day.  Something I could have never imagine on Softimage.
I'd always have to write everything in C++/MFC to do anything.  I've
also dumped my PC for a Macbook Pro.


On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
 wrote:
> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:
>>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
>>  wrote:
>>>
>>> I've got the feeling that someone is trying to sell us some Autodesk
>>> products here.
>>> Can I have a special discount if I print this thread and bring it to my
>>> reseller ?
>>>
>
=
 

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: Survey - how would you do this?

[Emilio Hernandez]

Take me in and I will distract the secretary!




2014-02-13 22:23 GMT-06:00 Sebastien Sterling 
:

> Guillaume next time you are invited round AD headquarters for an event say
> you are going to the toilette and steal the deeds back for softimage.
>
> THE SPICE MUST FLOW !
>
>
> On 14 February 2014 05:15, Emilio Hernandez  wrote:
>
>> Sorry to jump into this masters discution, but don't we have PyQT in
>> Softimage also?
>>
>> And now that Luc-Eric jumped in...
>>
>> Ok, Maya is more customizable, and better for Devs to integrate it into a
>> pipeline and bla, bla, bla. Because out of the box sorry but... p
>>
>> I am a novel in Maya and I am using it because I need to, not because I
>> am convinced of using it. And the more I use it, the more I love Softimage.
>>
>> I couldn't find a way to transfer a simple UV  from one mesh to another.
>> So I went and dug into Creative Crash to find a script...
>>
>> A script for this, a script for that.  The only thing I want to thank
>> Maya is that I started scripting again...  Thank god I have two monitors to
>> have the script editor open with I don't know how many tabs.  Or why not.
>> I can have a lot of buttons clogging more my workspace with nice Maya
>> icons.  I don't have time to start getting "creative" to draw an icon for
>> each additional script I write to do a simple task...
>>
>> And speaking of constrains.   To constrain to a point on a mesh in Maya,
>> you need to have UV's!  and watch out.  If you constrain to a point
>> that in the UV is in two different coordinates... ciao...
>>
>> So yes maybe when you have an army of Devs scripting and scripting. You
>> can have awsome custom tools...
>>
>> But when you have a small studio or you are freelance, for me Maya is "no
>> go".
>>
>> So instead of spreading the word on how "good is Maya" compared to
>> "Softimage" to try to convince us to switch platforms, because Maya is
>> "more customizable".  We want a descent upgrade of Softimage.  Not only a
>> "super camera switcher".
>>
>> What is the fear of Autodesk?
>>
>> That if you guys start making real improvements on Softimage the Maya
>> "industry standard" farce will fall?
>>
>> Sorry but I am really pissed off of how Autodesk is handling Softimage.
>> The best thing you can do is put it on sale so that people who really
>> cares, will take Softimage to the next level instead of burying it in Asia.
>>
>> But this will hardly happen.  Softimage in some other hands will be a
>> very strong contender to Maya
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2014-02-13 20:49 GMT-06:00 Guillaume Laforge <
>> guillaume.laforge...@gmail.com>:
>>
>> Btw, would love to see how to build such asteroid belt in Modo ;)
>>>
>>>
>>> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>>>
>>>> Below:
>>>>
>>>>
>>>> -Original Message-
>>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>>> Sent: Thursday, February 13, 2014 5:26 PM
>>>> To: softimage@listproc.autodesk.com
>>>> Subject: Re: Survey - how would you do this?
>>>>
>>>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>>>> wrote:
>>>> >>>   Allows us to define our own primitives, data structures, and
>>>> treats those data structures as first class citizens in the API.
>>>>
>>>> >yeah, with only experience with Softimage's SDK one might think that's
>>>> >something special.   But it's a common thing to do with Maya.
>>>>
>>>> [Matt]
>>>> I was paraphrasing a comment made by one of our engineers.  Although I
>>>> have run into the issue myself more than once.
>>>>
>>>>
>>>> >sure, Fabric requires no work at all to make it usable for artist..
>>>> >it's magical. (Does not really answer the questions about your uv
>>>> editing, retopology, and reduction  problems, though)
>>>>
>>>> [Matt]
>>>> Never claimed it did.  Only said it's closer in paradigm to what we
>>>> need, and it still needs to mature for us to give 

Re: Survey - how would you do this?

[Sebastien Sterling]

Guillaume next time you are invited round AD headquarters for an event say
you are going to the toilette and steal the deeds back for softimage.

THE SPICE MUST FLOW !


On 14 February 2014 05:15, Emilio Hernandez  wrote:

> Sorry to jump into this masters discution, but don't we have PyQT in
> Softimage also?
>
> And now that Luc-Eric jumped in...
>
> Ok, Maya is more customizable, and better for Devs to integrate it into a
> pipeline and bla, bla, bla. Because out of the box sorry but... p
>
> I am a novel in Maya and I am using it because I need to, not because I am
> convinced of using it. And the more I use it, the more I love Softimage.
>
> I couldn't find a way to transfer a simple UV  from one mesh to another.
> So I went and dug into Creative Crash to find a script...
>
> A script for this, a script for that.  The only thing I want to thank Maya
> is that I started scripting again...  Thank god I have two monitors to have
> the script editor open with I don't know how many tabs.  Or why not.  I can
> have a lot of buttons clogging more my workspace with nice Maya icons.  I
> don't have time to start getting "creative" to draw an icon for each
> additional script I write to do a simple task...
>
> And speaking of constrains.   To constrain to a point on a mesh in Maya,
> you need to have UV's!  and watch out.  If you constrain to a point
> that in the UV is in two different coordinates... ciao...
>
> So yes maybe when you have an army of Devs scripting and scripting. You
> can have awsome custom tools...
>
> But when you have a small studio or you are freelance, for me Maya is "no
> go".
>
> So instead of spreading the word on how "good is Maya" compared to
> "Softimage" to try to convince us to switch platforms, because Maya is
> "more customizable".  We want a descent upgrade of Softimage.  Not only a
> "super camera switcher".
>
> What is the fear of Autodesk?
>
> That if you guys start making real improvements on Softimage the Maya
> "industry standard" farce will fall?
>
> Sorry but I am really pissed off of how Autodesk is handling Softimage.
> The best thing you can do is put it on sale so that people who really
> cares, will take Softimage to the next level instead of burying it in Asia.
>
> But this will hardly happen.  Softimage in some other hands will be a very
> strong contender to Maya
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2014-02-13 20:49 GMT-06:00 Guillaume Laforge <
> guillaume.laforge...@gmail.com>:
>
> Btw, would love to see how to build such asteroid belt in Modo ;)
>>
>>
>> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>>
>>> Below:
>>>
>>>
>>> -Original Message-
>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>> Sent: Thursday, February 13, 2014 5:26 PM
>>> To: softimage@listproc.autodesk.com
>>> Subject: Re: Survey - how would you do this?
>>>
>>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>>> wrote:
>>> >>>   Allows us to define our own primitives, data structures, and
>>> treats those data structures as first class citizens in the API.
>>>
>>> >yeah, with only experience with Softimage's SDK one might think that's
>>> >something special.   But it's a common thing to do with Maya.
>>>
>>> [Matt]
>>> I was paraphrasing a comment made by one of our engineers.  Although I
>>> have run into the issue myself more than once.
>>>
>>>
>>> >sure, Fabric requires no work at all to make it usable for artist..
>>> >it's magical. (Does not really answer the questions about your uv
>>> editing, retopology, and reduction  problems, though)
>>>
>>> [Matt]
>>> Never claimed it did.  Only said it's closer in paradigm to what we
>>> need, and it still needs to mature for us to give it a serious look.  What
>>> it does offer is the ability to take control of the situation and develop
>>> what we need without re-inventing the wheel from scratch every time.
>>>
>>>
>>>
>>> >About authoring stuff that would not be obviously better authored
>>> directly in the game engine:
>>> >there are a lot of custom authoring tools out there where the tool is
>>> actually the Maya running in library mode.
>>> >You have no way of knowing this if all you

Re: Survey - how would you do this?

[Emilio Hernandez]

Sorry to jump into this masters discution, but don't we have PyQT in
Softimage also?

And now that Luc-Eric jumped in...

Ok, Maya is more customizable, and better for Devs to integrate it into a
pipeline and bla, bla, bla. Because out of the box sorry but... p

I am a novel in Maya and I am using it because I need to, not because I am
convinced of using it. And the more I use it, the more I love Softimage.

I couldn't find a way to transfer a simple UV  from one mesh to another.
So I went and dug into Creative Crash to find a script...

A script for this, a script for that.  The only thing I want to thank Maya
is that I started scripting again...  Thank god I have two monitors to have
the script editor open with I don't know how many tabs.  Or why not.  I can
have a lot of buttons clogging more my workspace with nice Maya icons.  I
don't have time to start getting "creative" to draw an icon for each
additional script I write to do a simple task...

And speaking of constrains.   To constrain to a point on a mesh in Maya,
you need to have UV's!  and watch out.  If you constrain to a point
that in the UV is in two different coordinates... ciao...

So yes maybe when you have an army of Devs scripting and scripting. You can
have awsome custom tools...

But when you have a small studio or you are freelance, for me Maya is "no
go".

So instead of spreading the word on how "good is Maya" compared to
"Softimage" to try to convince us to switch platforms, because Maya is
"more customizable".  We want a descent upgrade of Softimage.  Not only a
"super camera switcher".

What is the fear of Autodesk?

That if you guys start making real improvements on Softimage the Maya
"industry standard" farce will fall?

Sorry but I am really pissed off of how Autodesk is handling Softimage.
The best thing you can do is put it on sale so that people who really
cares, will take Softimage to the next level instead of burying it in Asia.

But this will hardly happen.  Softimage in some other hands will be a very
strong contender to Maya





















2014-02-13 20:49 GMT-06:00 Guillaume Laforge :

> Btw, would love to see how to build such asteroid belt in Modo ;)
>
>
> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>
>> Below:
>>
>>
>> -Original Message-
>> From: softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>> Sent: Thursday, February 13, 2014 5:26 PM
>> To: softimage@listproc.autodesk.com
>> Subject: Re: Survey - how would you do this?
>>
>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>> wrote:
>> >>>   Allows us to define our own primitives, data structures, and treats
>> those data structures as first class citizens in the API.
>>
>> >yeah, with only experience with Softimage's SDK one might think that's
>> >something special.   But it's a common thing to do with Maya.
>>
>> [Matt]
>> I was paraphrasing a comment made by one of our engineers.  Although I
>> have run into the issue myself more than once.
>>
>>
>> >sure, Fabric requires no work at all to make it usable for artist..
>> >it's magical. (Does not really answer the questions about your uv
>> editing, retopology, and reduction  problems, though)
>>
>> [Matt]
>> Never claimed it did.  Only said it's closer in paradigm to what we need,
>> and it still needs to mature for us to give it a serious look.  What it
>> does offer is the ability to take control of the situation and develop what
>> we need without re-inventing the wheel from scratch every time.
>>
>>
>>
>> >About authoring stuff that would not be obviously better authored
>> directly in the game engine:
>> >there are a lot of custom authoring tools out there where the tool is
>> actually the Maya running in library mode.
>> >You have no way of knowing this if all you see is a video of it on the
>> >web, the maya UI is not there at all,
>> >it looks like it was a custom tool written from scratch.  Maya in
>> library mode takes no licenses.  All of this is simply
>> > inconceivable from a Softimage point of view, and it was a factor in
>> getting kicked out of the bigger places.
>>
>> [Matt]
>> The point of editing in the game engine is changes to the engine are
>> immediately available to the artist creating content.  What they see is
>> what they get, and with real time feedback.  A large portion of any
>> artists' day is spent waiting for files to export from the DCC and collate
>> into the engine.  In some cases many minut

Re: Survey - how would you do this?

[Sebastien Sterling]

Considering someone took the time to make a block breaker in ICE, i don't
know if we get to laugh that hard :P


On 14 February 2014 05:09, Guillaume Laforge  wrote:

> LOL
>
> Cinema4D + Asteroid sounds so Amiga (the first platform of this 3D app).
>
>
> On Thu, Feb 13, 2014 at 10:42 PM, Sebastien Sterling <
> sebastien.sterl...@gmail.com> wrote:
>
>> You can do it in cinema4D ! with the asteroid belt deformer, its right
>> next to the popcorn deformer and the flap your arms like a bird deformer !
>>
>>
>> On 14 February 2014 03:49, Guillaume Laforge <
>> guillaume.laforge...@gmail.com> wrote:
>>
>>> Btw, would love to see how to build such asteroid belt in Modo ;)
>>>
>>>
>>> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>>>
>>>> Below:
>>>>
>>>>
>>>> -Original Message-
>>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>>> Sent: Thursday, February 13, 2014 5:26 PM
>>>> To: softimage@listproc.autodesk.com
>>>> Subject: Re: Survey - how would you do this?
>>>>
>>>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>>>> wrote:
>>>> >>>   Allows us to define our own primitives, data structures, and
>>>> treats those data structures as first class citizens in the API.
>>>>
>>>> >yeah, with only experience with Softimage's SDK one might think that's
>>>> >something special.   But it's a common thing to do with Maya.
>>>>
>>>> [Matt]
>>>> I was paraphrasing a comment made by one of our engineers.  Although I
>>>> have run into the issue myself more than once.
>>>>
>>>>
>>>> >sure, Fabric requires no work at all to make it usable for artist..
>>>> >it's magical. (Does not really answer the questions about your uv
>>>> editing, retopology, and reduction  problems, though)
>>>>
>>>> [Matt]
>>>> Never claimed it did.  Only said it's closer in paradigm to what we
>>>> need, and it still needs to mature for us to give it a serious look.  What
>>>> it does offer is the ability to take control of the situation and develop
>>>> what we need without re-inventing the wheel from scratch every time.
>>>>
>>>>
>>>>
>>>> >About authoring stuff that would not be obviously better authored
>>>> directly in the game engine:
>>>> >there are a lot of custom authoring tools out there where the tool is
>>>> actually the Maya running in library mode.
>>>> >You have no way of knowing this if all you see is a video of it on the
>>>> >web, the maya UI is not there at all,
>>>> >it looks like it was a custom tool written from scratch.  Maya in
>>>> library mode takes no licenses.  All of this is simply
>>>> > inconceivable from a Softimage point of view, and it was a factor in
>>>> getting kicked out of the bigger places.
>>>>
>>>> [Matt]
>>>> The point of editing in the game engine is changes to the engine are
>>>> immediately available to the artist creating content.  What they see is
>>>> what they get, and with real time feedback.  A large portion of any
>>>> artists' day is spent waiting for files to export from the DCC and collate
>>>> into the engine.  In some cases many minutes per export/collate. That is
>>>> not iteration friendly and problematic for engineers as they have another
>>>> set of code to maintain and keep in sync.   Having a Maya backend in
>>>> library mode doesn't solve this problem.
>>>>
>>>> One problem we continually face is the ability to see an asset in the
>>>> context of the game with proper lighting, fx, and other game specific data
>>>> in the authoring stages.  An artist needs to see how a reflective surface
>>>> will look in a particular zone of a world.  You cannot easily replicate
>>>> that in a commercial DCC.  Likewise, it's not simple to recreate the DCC's
>>>> editing power for creating raw assets.  The process of moving towards the
>>>> engine has to start somewhere.  Right now many games have level editors,
>>>> texture paging editors, and so on.  Those tools need to come together and
>>>> start incorporating raw 3D data i

Re: Survey - how would you do this?

[Guillaume Laforge]

LOL

Cinema4D + Asteroid sounds so Amiga (the first platform of this 3D app).


On Thu, Feb 13, 2014 at 10:42 PM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> You can do it in cinema4D ! with the asteroid belt deformer, its right
> next to the popcorn deformer and the flap your arms like a bird deformer !
>
>
> On 14 February 2014 03:49, Guillaume Laforge <
> guillaume.laforge...@gmail.com> wrote:
>
>> Btw, would love to see how to build such asteroid belt in Modo ;)
>>
>>
>> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>>
>>> Below:
>>>
>>>
>>> -Original Message-
>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>> Sent: Thursday, February 13, 2014 5:26 PM
>>> To: softimage@listproc.autodesk.com
>>> Subject: Re: Survey - how would you do this?
>>>
>>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>>> wrote:
>>> >>>   Allows us to define our own primitives, data structures, and
>>> treats those data structures as first class citizens in the API.
>>>
>>> >yeah, with only experience with Softimage's SDK one might think that's
>>> >something special.   But it's a common thing to do with Maya.
>>>
>>> [Matt]
>>> I was paraphrasing a comment made by one of our engineers.  Although I
>>> have run into the issue myself more than once.
>>>
>>>
>>> >sure, Fabric requires no work at all to make it usable for artist..
>>> >it's magical. (Does not really answer the questions about your uv
>>> editing, retopology, and reduction  problems, though)
>>>
>>> [Matt]
>>> Never claimed it did.  Only said it's closer in paradigm to what we
>>> need, and it still needs to mature for us to give it a serious look.  What
>>> it does offer is the ability to take control of the situation and develop
>>> what we need without re-inventing the wheel from scratch every time.
>>>
>>>
>>>
>>> >About authoring stuff that would not be obviously better authored
>>> directly in the game engine:
>>> >there are a lot of custom authoring tools out there where the tool is
>>> actually the Maya running in library mode.
>>> >You have no way of knowing this if all you see is a video of it on the
>>> >web, the maya UI is not there at all,
>>> >it looks like it was a custom tool written from scratch.  Maya in
>>> library mode takes no licenses.  All of this is simply
>>> > inconceivable from a Softimage point of view, and it was a factor in
>>> getting kicked out of the bigger places.
>>>
>>> [Matt]
>>> The point of editing in the game engine is changes to the engine are
>>> immediately available to the artist creating content.  What they see is
>>> what they get, and with real time feedback.  A large portion of any
>>> artists' day is spent waiting for files to export from the DCC and collate
>>> into the engine.  In some cases many minutes per export/collate. That is
>>> not iteration friendly and problematic for engineers as they have another
>>> set of code to maintain and keep in sync.   Having a Maya backend in
>>> library mode doesn't solve this problem.
>>>
>>> One problem we continually face is the ability to see an asset in the
>>> context of the game with proper lighting, fx, and other game specific data
>>> in the authoring stages.  An artist needs to see how a reflective surface
>>> will look in a particular zone of a world.  You cannot easily replicate
>>> that in a commercial DCC.  Likewise, it's not simple to recreate the DCC's
>>> editing power for creating raw assets.  The process of moving towards the
>>> engine has to start somewhere.  Right now many games have level editors,
>>> texture paging editors, and so on.  Those tools need to come together and
>>> start incorporating raw 3D data into the mix where it can be more easily
>>> edited.  That's the next generation of tools. Most engines already define
>>> how animation works and exposing transform manipulators and FCurve editors
>>> wouldn't be too much of a stretch beyond what's already in the system (in
>>> comparison to doing the same for modeling, texturing, etc...).  The DCC
>>> shouldn't be dismissed, but the commercial vendors have to stop working
>>> like a cable 

Re: Survey - how would you do this?

[Sebastien Sterling]

... i didn't know flappy birds was a thing. Hein... it's clearly Maya
running in library mode :P


On 14 February 2014 04:43, Matt Lind  wrote:

> I still have flappy bird on my phone.  Asking $2,000 USD.
>
>
>
> Don't have asteroids anymore.
>
>
>
> Matt
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Sebastien Sterling
> *Sent:* Thursday, February 13, 2014 7:42 PM
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Survey - how would you do this?
>
>
>
> You can do it in cinema4D ! with the asteroid belt deformer, its right
> next to the popcorn deformer and the flap your arms like a bird deformer !
>
>
>
> On 14 February 2014 03:49, Guillaume Laforge <
> guillaume.laforge...@gmail.com> wrote:
>
> Btw, would love to see how to build such asteroid belt in Modo ;)
>
>
>
> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind 
> wrote:
>
> Below:
>
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
> Sent: Thursday, February 13, 2014 5:26 PM
> To: softimage@listproc.autodesk.com
> Subject: Re: Survey - how would you do this?
>
> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
> wrote:
> >>>   Allows us to define our own primitives, data structures, and treats
> those data structures as first class citizens in the API.
>
> >yeah, with only experience with Softimage's SDK one might think that's
> >something special.   But it's a common thing to do with Maya.
>
> [Matt]
> I was paraphrasing a comment made by one of our engineers.  Although I
> have run into the issue myself more than once.
>
>
>
> >sure, Fabric requires no work at all to make it usable for artist..
> >it's magical. (Does not really answer the questions about your uv
> editing, retopology, and reduction  problems, though)
>
> [Matt]
> Never claimed it did.  Only said it's closer in paradigm to what we need,
> and it still needs to mature for us to give it a serious look.  What it
> does offer is the ability to take control of the situation and develop what
> we need without re-inventing the wheel from scratch every time.
>
>
>
>
> >About authoring stuff that would not be obviously better authored
> directly in the game engine:
> >there are a lot of custom authoring tools out there where the tool is
> actually the Maya running in library mode.
> >You have no way of knowing this if all you see is a video of it on the
> >web, the maya UI is not there at all,
> >it looks like it was a custom tool written from scratch.  Maya in library
> mode takes no licenses.  All of this is simply
> > inconceivable from a Softimage point of view, and it was a factor in
> getting kicked out of the bigger places.
>
> [Matt]
> The point of editing in the game engine is changes to the engine are
> immediately available to the artist creating content.  What they see is
> what they get, and with real time feedback.  A large portion of any
> artists' day is spent waiting for files to export from the DCC and collate
> into the engine.  In some cases many minutes per export/collate. That is
> not iteration friendly and problematic for engineers as they have another
> set of code to maintain and keep in sync.   Having a Maya backend in
> library mode doesn't solve this problem.
>
> One problem we continually face is the ability to see an asset in the
> context of the game with proper lighting, fx, and other game specific data
> in the authoring stages.  An artist needs to see how a reflective surface
> will look in a particular zone of a world.  You cannot easily replicate
> that in a commercial DCC.  Likewise, it's not simple to recreate the DCC's
> editing power for creating raw assets.  The process of moving towards the
> engine has to start somewhere.  Right now many games have level editors,
> texture paging editors, and so on.  Those tools need to come together and
> start incorporating raw 3D data into the mix where it can be more easily
> edited.  That's the next generation of tools. Most engines already define
> how animation works and exposing transform manipulators and FCurve editors
> wouldn't be too much of a stretch beyond what's already in the system (in
> comparison to doing the same for modeling, texturing, etc...).  The DCC
> shouldn't be dismissed, but the commercial vendors have to stop working
> like a cable company and forcing customers to choose off their menus to get
> any signal at all.
>
>

RE: Survey - how would you do this?

[Matt Lind]

I still have flappy bird on my phone.  Asking $2,000 USD.

Don't have asteroids anymore.

Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sebastien Sterling
Sent: Thursday, February 13, 2014 7:42 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

You can do it in cinema4D ! with the asteroid belt deformer, its right next to 
the popcorn deformer and the flap your arms like a bird deformer !

On 14 February 2014 03:49, Guillaume Laforge 
mailto:guillaume.laforge...@gmail.com>> wrote:
Btw, would love to see how to build such asteroid belt in Modo ;)

On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Below:


-Original Message-
From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
>>>   Allows us to define our own primitives, data structures, and treats those 
>>> data structures as first class citizens in the API.

>yeah, with only experience with Softimage's SDK one might think that's
>something special.   But it's a common thing to do with Maya.
[Matt]
I was paraphrasing a comment made by one of our engineers.  Although I have run 
into the issue myself more than once.


>sure, Fabric requires no work at all to make it usable for artist..
>it's magical. (Does not really answer the questions about your uv editing, 
>retopology, and reduction  problems, though)
[Matt]
Never claimed it did.  Only said it's closer in paradigm to what we need, and 
it still needs to mature for us to give it a serious look.  What it does offer 
is the ability to take control of the situation and develop what we need 
without re-inventing the wheel from scratch every time.



>About authoring stuff that would not be obviously better authored directly in 
>the game engine:
>there are a lot of custom authoring tools out there where the tool is actually 
>the Maya running in library mode.
>You have no way of knowing this if all you see is a video of it on the >web, 
>the maya UI is not there at all,
>it looks like it was a custom tool written from scratch.  Maya in library mode 
>takes no licenses.  All of this is simply
> inconceivable from a Softimage point of view, and it was a factor in getting 
> kicked out of the bigger places.
[Matt]
The point of editing in the game engine is changes to the engine are 
immediately available to the artist creating content.  What they see is what 
they get, and with real time feedback.  A large portion of any artists' day is 
spent waiting for files to export from the DCC and collate into the engine.  In 
some cases many minutes per export/collate. That is not iteration friendly and 
problematic for engineers as they have another set of code to maintain and keep 
in sync.   Having a Maya backend in library mode doesn't solve this problem.

One problem we continually face is the ability to see an asset in the context 
of the game with proper lighting, fx, and other game specific data in the 
authoring stages.  An artist needs to see how a reflective surface will look in 
a particular zone of a world.  You cannot easily replicate that in a commercial 
DCC.  Likewise, it's not simple to recreate the DCC's editing power for 
creating raw assets.  The process of moving towards the engine has to start 
somewhere.  Right now many games have level editors, texture paging editors, 
and so on.  Those tools need to come together and start incorporating raw 3D 
data into the mix where it can be more easily edited.  That's the next 
generation of tools. Most engines already define how animation works and 
exposing transform manipulators and FCurve editors wouldn't be too much of a 
stretch beyond what's already in the system (in comparison to doing the same 
for modeling, texturing, etc...).  The DCC shouldn't be dismissed, but the 
commercial vendors have to stop working like a cable company and forcing 
customers to choose off their menus to get any signal at all.

>There are other stuff at Autodesk that is moving away from putting everything 
>directly in the DCC when
>it makes sense.  For example, shaderfx is a realtime shader editor that runs 
>also out of Maya.
>The Bifrost and xgen engines are also separate from Maya.
[Matt]
Does not apply to our situation.  Make sense for small to mid sized studios 
that work with commercial engines where they're limite

Re: Survey - how would you do this?

[Sebastien Sterling]

You can do it in cinema4D ! with the asteroid belt deformer, its right next
to the popcorn deformer and the flap your arms like a bird deformer !


On 14 February 2014 03:49, Guillaume Laforge  wrote:

> Btw, would love to see how to build such asteroid belt in Modo ;)
>
>
> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind wrote:
>
>> Below:
>>
>>
>> -Original Message-
>> From: softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>> Sent: Thursday, February 13, 2014 5:26 PM
>> To: softimage@listproc.autodesk.com
>> Subject: Re: Survey - how would you do this?
>>
>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
>> wrote:
>> >>>   Allows us to define our own primitives, data structures, and treats
>> those data structures as first class citizens in the API.
>>
>> >yeah, with only experience with Softimage's SDK one might think that's
>> >something special.   But it's a common thing to do with Maya.
>>
>> [Matt]
>> I was paraphrasing a comment made by one of our engineers.  Although I
>> have run into the issue myself more than once.
>>
>>
>> >sure, Fabric requires no work at all to make it usable for artist..
>> >it's magical. (Does not really answer the questions about your uv
>> editing, retopology, and reduction  problems, though)
>>
>> [Matt]
>> Never claimed it did.  Only said it's closer in paradigm to what we need,
>> and it still needs to mature for us to give it a serious look.  What it
>> does offer is the ability to take control of the situation and develop what
>> we need without re-inventing the wheel from scratch every time.
>>
>>
>>
>> >About authoring stuff that would not be obviously better authored
>> directly in the game engine:
>> >there are a lot of custom authoring tools out there where the tool is
>> actually the Maya running in library mode.
>> >You have no way of knowing this if all you see is a video of it on the
>> >web, the maya UI is not there at all,
>> >it looks like it was a custom tool written from scratch.  Maya in
>> library mode takes no licenses.  All of this is simply
>> > inconceivable from a Softimage point of view, and it was a factor in
>> getting kicked out of the bigger places.
>>
>> [Matt]
>> The point of editing in the game engine is changes to the engine are
>> immediately available to the artist creating content.  What they see is
>> what they get, and with real time feedback.  A large portion of any
>> artists' day is spent waiting for files to export from the DCC and collate
>> into the engine.  In some cases many minutes per export/collate. That is
>> not iteration friendly and problematic for engineers as they have another
>> set of code to maintain and keep in sync.   Having a Maya backend in
>> library mode doesn't solve this problem.
>>
>> One problem we continually face is the ability to see an asset in the
>> context of the game with proper lighting, fx, and other game specific data
>> in the authoring stages.  An artist needs to see how a reflective surface
>> will look in a particular zone of a world.  You cannot easily replicate
>> that in a commercial DCC.  Likewise, it's not simple to recreate the DCC's
>> editing power for creating raw assets.  The process of moving towards the
>> engine has to start somewhere.  Right now many games have level editors,
>> texture paging editors, and so on.  Those tools need to come together and
>> start incorporating raw 3D data into the mix where it can be more easily
>> edited.  That's the next generation of tools. Most engines already define
>> how animation works and exposing transform manipulators and FCurve editors
>> wouldn't be too much of a stretch beyond what's already in the system (in
>> comparison to doing the same for modeling, texturing, etc...).  The DCC
>> shouldn't be dismissed, but the commercial vendors have to stop working
>> like a cable company and forcing customers to choose off their menus to get
>> any signal at all.
>>
>> >There are other stuff at Autodesk that is moving away from putting
>> everything directly in the DCC when
>> >it makes sense.  For example, shaderfx is a realtime shader editor that
>> runs also out of Maya.
>> >The Bifrost and xgen engines are also separate from Maya.
>>
>> [Matt]
>> Does not apply to our situation.  Make sense for small to mid sized
>> studios that work with commercial engines where they're limited in what
>> they can modify.  Commercial tools tend to develop towards a spec, and is
>> only useful for consumers of the spec.  Once you move out of the spec, the
>> tool is less useful because it cannot always accommodate.  We built our
>> engine from scratch and in some cases don't follow the same standards as
>> the rest of the industry because we needed to do certain things more
>> efficiently whether it be how we pack data or crunch the numbers.
>>
>>
>>
>> Matt
>>
>>
>

Re: Survey - how would you do this?

[Guillaume Laforge]

Btw, would love to see how to build such asteroid belt in Modo ;)


On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind  wrote:

> Below:
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
> Sent: Thursday, February 13, 2014 5:26 PM
> To: softimage@listproc.autodesk.com
> Subject: Re: Survey - how would you do this?
>
> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
> wrote:
> >>>   Allows us to define our own primitives, data structures, and treats
> those data structures as first class citizens in the API.
>
> >yeah, with only experience with Softimage's SDK one might think that's
> >something special.   But it's a common thing to do with Maya.
>
> [Matt]
> I was paraphrasing a comment made by one of our engineers.  Although I
> have run into the issue myself more than once.
>
>
> >sure, Fabric requires no work at all to make it usable for artist..
> >it's magical. (Does not really answer the questions about your uv
> editing, retopology, and reduction  problems, though)
>
> [Matt]
> Never claimed it did.  Only said it's closer in paradigm to what we need,
> and it still needs to mature for us to give it a serious look.  What it
> does offer is the ability to take control of the situation and develop what
> we need without re-inventing the wheel from scratch every time.
>
>
>
> >About authoring stuff that would not be obviously better authored
> directly in the game engine:
> >there are a lot of custom authoring tools out there where the tool is
> actually the Maya running in library mode.
> >You have no way of knowing this if all you see is a video of it on the
> >web, the maya UI is not there at all,
> >it looks like it was a custom tool written from scratch.  Maya in library
> mode takes no licenses.  All of this is simply
> > inconceivable from a Softimage point of view, and it was a factor in
> getting kicked out of the bigger places.
>
> [Matt]
> The point of editing in the game engine is changes to the engine are
> immediately available to the artist creating content.  What they see is
> what they get, and with real time feedback.  A large portion of any
> artists' day is spent waiting for files to export from the DCC and collate
> into the engine.  In some cases many minutes per export/collate. That is
> not iteration friendly and problematic for engineers as they have another
> set of code to maintain and keep in sync.   Having a Maya backend in
> library mode doesn't solve this problem.
>
> One problem we continually face is the ability to see an asset in the
> context of the game with proper lighting, fx, and other game specific data
> in the authoring stages.  An artist needs to see how a reflective surface
> will look in a particular zone of a world.  You cannot easily replicate
> that in a commercial DCC.  Likewise, it's not simple to recreate the DCC's
> editing power for creating raw assets.  The process of moving towards the
> engine has to start somewhere.  Right now many games have level editors,
> texture paging editors, and so on.  Those tools need to come together and
> start incorporating raw 3D data into the mix where it can be more easily
> edited.  That's the next generation of tools. Most engines already define
> how animation works and exposing transform manipulators and FCurve editors
> wouldn't be too much of a stretch beyond what's already in the system (in
> comparison to doing the same for modeling, texturing, etc...).  The DCC
> shouldn't be dismissed, but the commercial vendors have to stop working
> like a cable company and forcing customers to choose off their menus to get
> any signal at all.
>
> >There are other stuff at Autodesk that is moving away from putting
> everything directly in the DCC when
> >it makes sense.  For example, shaderfx is a realtime shader editor that
> runs also out of Maya.
> >The Bifrost and xgen engines are also separate from Maya.
>
> [Matt]
> Does not apply to our situation.  Make sense for small to mid sized
> studios that work with commercial engines where they're limited in what
> they can modify.  Commercial tools tend to develop towards a spec, and is
> only useful for consumers of the spec.  Once you move out of the spec, the
> tool is less useful because it cannot always accommodate.  We built our
> engine from scratch and in some cases don't follow the same standards as
> the rest of the industry because we needed to do certain things more
> efficiently whether it be how we pack data or crunch the numbers.
>
>
>
> Matt
>
>

RE: Survey - how would you do this?

[Matt Lind]

Below:


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind  wrote:
>>>   Allows us to define our own primitives, data structures, and treats those 
>>> data structures as first class citizens in the API.

>yeah, with only experience with Softimage's SDK one might think that's
>something special.   But it's a common thing to do with Maya.

[Matt]
I was paraphrasing a comment made by one of our engineers.  Although I have run 
into the issue myself more than once.


>sure, Fabric requires no work at all to make it usable for artist..
>it's magical. (Does not really answer the questions about your uv editing, 
>retopology, and reduction  problems, though)

[Matt]
Never claimed it did.  Only said it's closer in paradigm to what we need, and 
it still needs to mature for us to give it a serious look.  What it does offer 
is the ability to take control of the situation and develop what we need 
without re-inventing the wheel from scratch every time.



>About authoring stuff that would not be obviously better authored directly in 
>the game engine:
>there are a lot of custom authoring tools out there where the tool is actually 
>the Maya running in library mode. 
>You have no way of knowing this if all you see is a video of it on the >web, 
>the maya UI is not there at all, 
>it looks like it was a custom tool written from scratch.  Maya in library mode 
>takes no licenses.  All of this is simply
> inconceivable from a Softimage point of view, and it was a factor in getting 
> kicked out of the bigger places.

[Matt]
The point of editing in the game engine is changes to the engine are 
immediately available to the artist creating content.  What they see is what 
they get, and with real time feedback.  A large portion of any artists' day is 
spent waiting for files to export from the DCC and collate into the engine.  In 
some cases many minutes per export/collate. That is not iteration friendly and 
problematic for engineers as they have another set of code to maintain and keep 
in sync.   Having a Maya backend in library mode doesn't solve this problem.  

One problem we continually face is the ability to see an asset in the context 
of the game with proper lighting, fx, and other game specific data in the 
authoring stages.  An artist needs to see how a reflective surface will look in 
a particular zone of a world.  You cannot easily replicate that in a commercial 
DCC.  Likewise, it's not simple to recreate the DCC's editing power for 
creating raw assets.  The process of moving towards the engine has to start 
somewhere.  Right now many games have level editors, texture paging editors, 
and so on.  Those tools need to come together and start incorporating raw 3D 
data into the mix where it can be more easily edited.  That's the next 
generation of tools. Most engines already define how animation works and 
exposing transform manipulators and FCurve editors wouldn't be too much of a 
stretch beyond what's already in the system (in comparison to doing the same 
for modeling, texturing, etc...).  The DCC shouldn't be dismissed, but the 
commercial vendors have to stop working like a cable company and forcing 
customers to choose off their menus to get any signal at all.

>There are other stuff at Autodesk that is moving away from putting everything 
>directly in the DCC when 
>it makes sense.  For example, shaderfx is a realtime shader editor that runs 
>also out of Maya.  
>The Bifrost and xgen engines are also separate from Maya.

[Matt]
Does not apply to our situation.  Make sense for small to mid sized studios 
that work with commercial engines where they're limited in what they can 
modify.  Commercial tools tend to develop towards a spec, and is only useful 
for consumers of the spec.  Once you move out of the spec, the tool is less 
useful because it cannot always accommodate.  We built our engine from scratch 
and in some cases don't follow the same standards as the rest of the industry 
because we needed to do certain things more efficiently whether it be how we 
pack data or crunch the numbers.



Matt

Re: Survey - how would you do this?

[Guillaume Laforge]

Luc-Eric, you can try as you want, but you are inside AD, so you are biased
as much as me when I was speaking about Softimage as an Autodesk employee
or speaking about Creation Platform as a Fabric employee.






On Thu, Feb 13, 2014 at 9:26 PM, Luc-Eric Rousseau wrote:

> imagine if we made such jokes every time the Fabric came to pimp their
> stuff here. ;)
>
> If there is going to be a discussion about creating custom tools for
> artists, sweeping statements about DCCs, and name dropping like Pixar,
> it's in everyone's interest to be informed about the maya side of the
> story.  On my side, as Maya UI team lead, pyside (python+qt) is part
> of the day-to-day.  Something I could have never imagine on Softimage.
> I'd always have to write everything in C++/MFC to do anything.  I've
> also dumped my PC for a Macbook Pro.
>
>
> On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
>  wrote:
> > Don't forget to print the threads/coupons Steven !
> >
> >
> > On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:
> >>
> >> ya, i get that feeling too ;)
> >>
> >> its magical
> >>
> >>
> >> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
> >>  wrote:
> >>>
> >>> I've got the feeling that someone is trying to sell us some Autodesk
> >>> products here.
> >>> Can I have a special discount if I print this thread and bring it to my
> >>> reseller ?
> >>>
> >
>

Re: Survey - how would you do this?

[Steven Caron]

difference is, autodesk already has our money. :)

i am fine with it actually. share how maya is better, i too think it is
important people have correct information about the subject.

On Thu, Feb 13, 2014 at 6:26 PM, Luc-Eric Rousseau wrote:

> imagine if we made such jokes every time the Fabric came to pimp their
> stuff here. ;)
>
> If there is going to be a discussion about creating custom tools for
> artists, sweeping statements about DCCs, and name dropping like Pixar,
> it's in everyone's interest to be informed about the maya side of the
> story.
>

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

imagine if we made such jokes every time the Fabric came to pimp their
stuff here. ;)

If there is going to be a discussion about creating custom tools for
artists, sweeping statements about DCCs, and name dropping like Pixar,
it's in everyone's interest to be informed about the maya side of the
story.  On my side, as Maya UI team lead, pyside (python+qt) is part
of the day-to-day.  Something I could have never imagine on Softimage.
I'd always have to write everything in C++/MFC to do anything.  I've
also dumped my PC for a Macbook Pro.


On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge
 wrote:
> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:
>>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
>>  wrote:
>>>
>>> I've got the feeling that someone is trying to sell us some Autodesk
>>> products here.
>>> Can I have a special discount if I print this thread and bring it to my
>>> reseller ?
>>>
>

Re: Survey - how would you do this?

[Guillaume Laforge]

Yeah, Maya is an API. Much better from a dev point of view I agree.




On Thu, Feb 13, 2014 at 9:01 PM, Steven Caron  wrote:

> sarcasm aside, i am not surprised people use maya for game dev.. i know
> very well how customizable it is, and envy it plenty. its just not...
> exciting to me.
>
>
> On Thu, Feb 13, 2014 at 5:56 PM, Guillaume Laforge <
> guillaume.laforge...@gmail.com> wrote:
>
>> Don't forget to print the threads/coupons Steven !
>>
>>
>> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:
>>
>>> ya, i get that feeling too ;)
>>>
>>> its magical
>>>
>>>
>>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge <
>>> guillaume.laforge...@gmail.com> wrote:
>>>
 I've got the feeling that someone is trying to sell us some Autodesk
 products here.
 Can I have a special discount if I print this thread and bring it to my
 reseller ?


>>
>

Re: Survey - how would you do this?

[Steven Caron]

sarcasm aside, i am not surprised people use maya for game dev.. i know
very well how customizable it is, and envy it plenty. its just not...
exciting to me.


On Thu, Feb 13, 2014 at 5:56 PM, Guillaume Laforge <
guillaume.laforge...@gmail.com> wrote:

> Don't forget to print the threads/coupons Steven !
>
>
> On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:
>
>> ya, i get that feeling too ;)
>>
>> its magical
>>
>>
>> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge <
>> guillaume.laforge...@gmail.com> wrote:
>>
>>> I've got the feeling that someone is trying to sell us some Autodesk
>>> products here.
>>> Can I have a special discount if I print this thread and bring it to my
>>> reseller ?
>>>
>>>
>

Re: Survey - how would you do this?

[Guillaume Laforge]

Don't forget to print the threads/coupons Steven !


On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron  wrote:

> ya, i get that feeling too ;)
>
> its magical
>
>
> On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge <
> guillaume.laforge...@gmail.com> wrote:
>
>> I've got the feeling that someone is trying to sell us some Autodesk
>> products here.
>> Can I have a special discount if I print this thread and bring it to my
>> reseller ?
>>
>>

Re: Survey - how would you do this?

[Steven Caron]

ya, i get that feeling too ;)

its magical

On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge <
guillaume.laforge...@gmail.com> wrote:

> I've got the feeling that someone is trying to sell us some Autodesk
> products here.
> Can I have a special discount if I print this thread and bring it to my
> reseller ?
>
>

Re: Survey - how would you do this?

[Guillaume Laforge]

I've got the feeling that someone is trying to sell us some Autodesk
products here.
Can I have a special discount if I print this thread and bring it to my
reseller ?

:D


On Thu, Feb 13, 2014 at 8:26 PM, Luc-Eric Rousseau wrote:

> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
> wrote:
> >   Allows us to define our own primitives, data structures, and treats
> those data structures as first class citizens in the API.
>
> yeah, with only experience with Softimage's SDK one might think that's
> something special.   But it's a common thing to do with Maya.
>
> > Not have licensing which ties the content creation product into our
> released product,
> > and is very cost effective for very large teams working across multiple
> sites.  Can
> > be set up quickly and easily and is a light install, and not require
> engineers to make
> > usable or explain to artists.  In concept, Fabric engine most closely
> fits that paradigm
>
> sure, Fabric requires no work at all to make it usable for artist..
> it's magical. (Does not really answer the questions about your uv
> editing, retopology, and reduction  problems, though)
>
> About authoring stuff that would not be obviously better authored
> directly in the game engine:
> there are a lot of custom authoring tools out there where the tool is
> actually the Maya running in library mode. You have no way of knowing
> this if all you see is a video of it on the web, the maya UI is not
> there at all, it looks like it was a custom tool written from scratch.
>  Maya in library mode takes no licenses.  All of this is simply
> inconceivable from a Softimage point of view, and it was a factor in
> getting kicked out of the bigger places.
>
> There are other stuff at Autodesk that is moving away from putting
> everything directly in the DCC when it makes sense.  For example,
> shaderfx is a realtime shader editor that runs also out of Maya.  The
> Bifrost and xgen engines are also separate from Maya.
>

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind  wrote:
>   Allows us to define our own primitives, data structures, and treats those 
> data structures as first class citizens in the API.

yeah, with only experience with Softimage's SDK one might think that's
something special.   But it's a common thing to do with Maya.

> Not have licensing which ties the content creation product into our released 
> product,
> and is very cost effective for very large teams working across multiple 
> sites.  Can
> be set up quickly and easily and is a light install, and not require 
> engineers to make
> usable or explain to artists.  In concept, Fabric engine most closely fits 
> that paradigm

sure, Fabric requires no work at all to make it usable for artist..
it's magical. (Does not really answer the questions about your uv
editing, retopology, and reduction  problems, though)

About authoring stuff that would not be obviously better authored
directly in the game engine:
there are a lot of custom authoring tools out there where the tool is
actually the Maya running in library mode. You have no way of knowing
this if all you see is a video of it on the web, the maya UI is not
there at all, it looks like it was a custom tool written from scratch.
 Maya in library mode takes no licenses.  All of this is simply
inconceivable from a Softimage point of view, and it was a factor in
getting kicked out of the bigger places.

There are other stuff at Autodesk that is moving away from putting
everything directly in the DCC when it makes sense.  For example,
shaderfx is a realtime shader editor that runs also out of Maya.  The
Bifrost and xgen engines are also separate from Maya.

Re: Survey - how would you do this?

[Bradley Gabe]

This should be a separate thread, but it's related:

I discovered a trick long ago on how to drive kinematics with ICE and have
it be quite fast, easily pushing >1000 nulls in real time. You build a
single polygon mesh with a separate square for each particle, driving each
square from the particle's SRTs with a simple ICE op. Then you create a
cluster on each square and constrain scene objects to the clusters.

I had a script that set the whole thing up, so you could select a group of
scene objects, then pick a particle cloud, and it would constrain the scene
objects in the order you selected them. This was a necessary workaround
back in the old days when Arnold wasn't working with instances, but the
tool came in handy for all kinds of situations to drive scene object
kinematics based on particle sims.

When they gave us ICE kinematics later on, the cluster constraint trick
still performed much faster and was more stable so I kept using it.

This same technique, BTW, allows you to use deformations to control SRT
movement of scene objects. Once your objects are constrained to geometry,
you can apply envelopes, lattices, or whatever other creative setups to
animate their motion.

RE: Survey - how would you do this?

[Marc Brinkley]

>> but I¹d squeeze everything I could from a DCC before pushing my data through 
>> the pipe


We are trying to do that now...you wouldn't believe the pain and suffering we 
are going through.

Oh how I long for the days of UE3. Create model and UVs, Rig and Animate, 
export to FBX...done. Then you do the hard work in your editor and engine on 
target. Of course I wouldn't dare create an MMO in UE3. Wouldn't even come 
close to scaling up.

Most of the tools we ever needed was for asset naming, checkin and export. That 
was it. 99% of it was vanilla Soft or Maya.

___
Marc Brinkley
343 Industries
Microsoft Studios
marc.brinkley [at] microsoft.com

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Graham Bell
Sent: Thursday, February 13, 2014 4:12 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?


Matt makes some valid points and to me shows some of the (even these days) 
major differences between games and film/tv pipelines.

It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty example 
of that, but that when it comes to creating games assets and pipelines, its 
perhaps not best suited to some of the requirements. It¹s not much good 
creating custom ICE nodes and compounds, but they can in effect be useless, 
unless you can reflect the tool/tech in the game engine and/or get the 
exported. Sure you can bake as many have mentioned, but that doesn¹t always 
apply in all cases. Also it creates more data that has got to be loaded in game 
and memory, and as Marc says games is so often about balancing budget to get 
things running.
Even when you have assets built to spec, you can still end up cutting back 
anywhere you can, to get the framerate. 30 fps was realistic, 60 was very often 
a dream.

Game devs are renown for building lots of proprietary tools and technology, 
some of which is justifiable, others times they¹re reinventing the wheel. But I 
think some of that is changing. Whereas in the past games would literally write 
everything, more are now buying off the shelf with middleware for some things, 
and focusing their resources on the right things. It¹s simply not always 
realistic and financially viable to write everything bespoke.

I used to be a firm believer of having a DCC as a game editor, as I¹d seen too 
many show off programmers thinking they could write their own Max/Maya and 
while I have seen some good editors, most have been poor. But I think Marc¹s 
points are very valid, I wouldn¹t take that approach now. I still think in the 
right context the DCC could work, but it depends a lot on the pipeline and the 
type of game being made. The game engine is always going to be the best place 
to view assets, as its the end result, but I¹d squeeze everything I could from 
a DCC before pushing my data through the pipe.


 

I thought Matt challenge was great and very typical of the type of thing you 
see now in mobile/casual gaming. Simple data, simple process, get it down and 
get it out.





On 13/02/2014 23:48, "Marc Brinkley"  wrote:

>Just to tack on...
>
>Coming from UE3 and Unity, I can safely say that building engine 
>dependent tools\editors into a DCC is decidedly not the way to go. If 
>you can avoid it at all costs, I would highly recommend that.
>
>It's a slippery slope. You realize that most of the infrastructure you 
>want is already in a DCC so it makes sense to use that as a 
>base...months and years later you realize that was not a good decision. :) And 
>now...
>
>My mantra over the last several years has been...the DCC is just that, 
>it creates digital content. Everything else is done in engine\editor.
>Materials, post FX, physics, VFX, Fluids, lighting, animation 
>sequencing, cameras, terrain generation, scene assembly and so on 
>should only ever be done in your engine and editor.
>
>And I got there from having tried to build the DCC into our editors. 
>Both with Soft and with Maya. Both were the wrong choice.
>
>
>My team of nearly 50+ environment artists live a daily struggle because 
>we made that choice.
>
>___
>___
>_
>Marc Brinkley
>343 Industries
>Microsoft Studios
>marc.brinkley [at] microsoft.com
>
>-Original Message-
>From: softimage-boun...@listproc.autodesk.com
>[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
>Sent: Thursday, February 13, 2014 3:16 PM
>To: softimage@listproc.autodesk.com
>Subject: RE: Survey - how would you do this?
>
>I cannot reveal what our plans are, but I can say what we need is an 
>environment that has an open and deep SDK to allow us to build tools on 

Re: Survey - how would you do this?

[Guillaume Laforge]

Just found this thread tonight. I must say I liked your idea Matt :)

Manny and Christian demos are just great. It is funny that most of us can't
think outside ICE now. As soon as something a little bit complex appear, we
jump in this node graph like zombies.

Constraints (no pun intended) are the key for creativity !

Cheers,
Guillaume

PS: I don't want to imagine how slow it would be to drive 1000 spheres
kinematics using ICE :P






On Thu, Feb 13, 2014 at 7:11 PM, Graham Bell wrote:

>
> Matt makes some valid points and to me shows some of the (even these days)
> major differences between games and film/tv pipelines.
>
> It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty
> example of that, but that when it comes to creating games assets and
> pipelines, its perhaps not best suited to some of the requirements. It¹s
> not much good creating custom ICE nodes and compounds, but they can in
> effect be useless, unless you can reflect the tool/tech in the game engine
> and/or get the exported. Sure you can bake as many have mentioned, but
> that doesn¹t always apply in all cases. Also it creates more data that has
> got to be loaded in game and memory, and as Marc says games is so often
> about balancing budget to get things running.
> Even when you have assets built to spec, you can still end up cutting back
> anywhere you can, to get the framerate. 30 fps was realistic, 60 was very
> often a dream.
>
> Game devs are renown for building lots of proprietary tools and
> technology, some of which is justifiable, others times they¹re reinventing
> the wheel. But I think some of that is changing. Whereas in the past games
> would literally write everything, more are now buying off the shelf with
> middleware for some things, and focusing their resources on the right
> things. It¹s simply not always realistic and financially viable to write
> everything bespoke.
>
> I used to be a firm believer of having a DCC as a game editor, as I¹d seen
> too many show off programmers thinking they could write their own Max/Maya
> and while I have seen some good editors, most have been poor. But I think
> Marc¹s points are very valid, I wouldn¹t take that approach now. I still
> think in the right context the DCC could work, but it depends a lot on the
> pipeline and the type of game being made. The game engine is always going
> to be the best place to view assets, as its the end result, but I¹d
> squeeze everything I could from a DCC before pushing my data through the
> pipe.
>
>
>
>
> I thought Matt challenge was great and very typical of the type of thing
> you see now in mobile/casual gaming. Simple data, simple process, get it
> down and get it out.
>
>
>
>
>
> On 13/02/2014 23:48, "Marc Brinkley"  wrote:
>
> >Just to tack on...
> >
> >Coming from UE3 and Unity, I can safely say that building engine
> >dependent tools\editors into a DCC is decidedly not the way to go. If you
> >can avoid it at all costs, I would highly recommend that.
> >
> >It's a slippery slope. You realize that most of the infrastructure you
> >want is already in a DCC so it makes sense to use that as a base...months
> >and years later you realize that was not a good decision. :) And now...
> >
> >My mantra over the last several years has been...the DCC is just that, it
> >creates digital content. Everything else is done in engine\editor.
> >Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing,
> >cameras, terrain generation, scene assembly and so on should only ever be
> >done in your engine and editor.
> >
> >And I got there from having tried to build the DCC into our editors. Both
> >with Soft and with Maya. Both were the wrong choice.
> >
> >
> >My team of nearly 50+ environment artists live a daily struggle because
> >we made that choice.
> >
> >__
> >_
> >Marc Brinkley
> >343 Industries
> >Microsoft Studios
> >marc.brinkley [at] microsoft.com
> >
> >-Original Message-
> >From: softimage-boun...@listproc.autodesk.com
> >[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
> >Sent: Thursday, February 13, 2014 3:16 PM
> >To: softimage@listproc.autodesk.com
> >Subject: RE: Survey - how would you do this?
> >
> >I cannot reveal what our plans are, but I can say what we need is an
> >environment that has an open and deep SDK to allow us to build tools on
> >our terms, and not on the application's terms, so we can make our own
> >infrastructure without having to re-invent the wheel and reduce risk

Re: Survey - how would you do this?

[Graham Bell]

Matt makes some valid points and to me shows some of the (even these days)
major differences between games and film/tv pipelines.

It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty
example of that, but that when it comes to creating games assets and
pipelines, its perhaps not best suited to some of the requirements. It¹s
not much good creating custom ICE nodes and compounds, but they can in
effect be useless, unless you can reflect the tool/tech in the game engine
and/or get the exported. Sure you can bake as many have mentioned, but
that doesn¹t always apply in all cases. Also it creates more data that has
got to be loaded in game and memory, and as Marc says games is so often
about balancing budget to get things running.
Even when you have assets built to spec, you can still end up cutting back
anywhere you can, to get the framerate. 30 fps was realistic, 60 was very
often a dream.

Game devs are renown for building lots of proprietary tools and
technology, some of which is justifiable, others times they¹re reinventing
the wheel. But I think some of that is changing. Whereas in the past games
would literally write everything, more are now buying off the shelf with
middleware for some things, and focusing their resources on the right
things. It¹s simply not always realistic and financially viable to write
everything bespoke.

I used to be a firm believer of having a DCC as a game editor, as I¹d seen
too many show off programmers thinking they could write their own Max/Maya
and while I have seen some good editors, most have been poor. But I think
Marc¹s points are very valid, I wouldn¹t take that approach now. I still
think in the right context the DCC could work, but it depends a lot on the
pipeline and the type of game being made. The game engine is always going
to be the best place to view assets, as its the end result, but I¹d
squeeze everything I could from a DCC before pushing my data through the
pipe.


 

I thought Matt challenge was great and very typical of the type of thing
you see now in mobile/casual gaming. Simple data, simple process, get it
down and get it out.





On 13/02/2014 23:48, "Marc Brinkley"  wrote:

>Just to tack on...
>
>Coming from UE3 and Unity, I can safely say that building engine
>dependent tools\editors into a DCC is decidedly not the way to go. If you
>can avoid it at all costs, I would highly recommend that.
>
>It's a slippery slope. You realize that most of the infrastructure you
>want is already in a DCC so it makes sense to use that as a base...months
>and years later you realize that was not a good decision. :) And now...
>
>My mantra over the last several years has been...the DCC is just that, it
>creates digital content. Everything else is done in engine\editor.
>Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing,
>cameras, terrain generation, scene assembly and so on should only ever be
>done in your engine and editor.
>
>And I got there from having tried to build the DCC into our editors. Both
>with Soft and with Maya. Both were the wrong choice.
>
>
>My team of nearly 50+ environment artists live a daily struggle because
>we made that choice.
>
>__
>_
>Marc Brinkley
>343 Industries
>Microsoft Studios
>marc.brinkley [at] microsoft.com
>
>-Original Message-
>From: softimage-boun...@listproc.autodesk.com
>[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
>Sent: Thursday, February 13, 2014 3:16 PM
>To: softimage@listproc.autodesk.com
>Subject: RE: Survey - how would you do this?
>
>I cannot reveal what our plans are, but I can say what we need is an
>environment that has an open and deep SDK to allow us to build tools on
>our terms, and not on the application's terms, so we can make our own
>infrastructure without having to re-invent the wheel and reduce risk from
>pipeline changes/regressions from commercial software.  Allows us to
>define our own primitives, data structures, and treats those data
>structures as first class citizens in the API.  Not have licensing which
>ties the content creation product into our released product, and is very
>cost effective for very large teams working across multiple sites.  Can
>be set up quickly and easily and is a light install, and not require
>engineers to make usable or explain to artists.  In concept, Fabric
>engine most closely fits that paradigm, but it needs to mature before we
>can give it a serious look.  I would not be surprised if we develop our
>own tools a la Pixar or the other mainstays of the industry.  The trend
>in this space is to build your creation tools into your engine so you can
>take advantage of real time feedback from iteration (a la Valve).  Since
>we built our own eng

RE: Survey - how would you do this?

[Marc Brinkley]

Just to tack on...

Coming from UE3 and Unity, I can safely say that building engine dependent 
tools\editors into a DCC is decidedly not the way to go. If you can avoid it at 
all costs, I would highly recommend that.

It's a slippery slope. You realize that most of the infrastructure you want is 
already in a DCC so it makes sense to use that as a base...months and years 
later you realize that was not a good decision. :) And now...

My mantra over the last several years has been...the DCC is just that, it 
creates digital content. Everything else is done in engine\editor. Materials, 
post FX, physics, VFX, Fluids, lighting, animation sequencing, cameras, terrain 
generation, scene assembly and so on should only ever be done in your engine 
and editor.

And I got there from having tried to build the DCC into our editors. Both with 
Soft and with Maya. Both were the wrong choice.


My team of nearly 50+ environment artists live a daily struggle because we made 
that choice.

___
Marc Brinkley
343 Industries
Microsoft Studios
marc.brinkley [at] microsoft.com

-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, February 13, 2014 3:16 PM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

I cannot reveal what our plans are, but I can say what we need is an 
environment that has an open and deep SDK to allow us to build tools on our 
terms, and not on the application's terms, so we can make our own 
infrastructure without having to re-invent the wheel and reduce risk from 
pipeline changes/regressions from commercial software.  Allows us to define our 
own primitives, data structures, and treats those data structures as first 
class citizens in the API.  Not have licensing which ties the content creation 
product into our released product, and is very cost effective for very large 
teams working across multiple sites.  Can be set up quickly and easily and is a 
light install, and not require engineers to make usable or explain to artists.  
In concept, Fabric engine most closely fits that paradigm, but it needs to 
mature before we can give it a serious look.  I would not be surprised if we 
develop our own tools a la Pixar or the other mainstays of the industry.  The 
trend in this space is to build your creation tools into your engine so you can 
take advantage of real time feedback from iteration (a la Valve).  Since we 
built our own engine from scratch, we have full control to implement such 
features on our terms.

Max, Maya, and Softimage don't cater to the MMORPG space very well.  You can 
use the products, as many have obviously demonstrated over the years, but it's 
very much shaving the corners of the square peg to fit it into the round hole.  
This has been a classic problem in games for a long time as the commercial 
software largely cater to film/video and assume games is a simpler version of 
that paradigm.   In the early days of games that was a band-aid that worked, 
but games have evolved a lot since then making the current 3D software not so 
relevant anymore.  The difference with an MMORPG is the game has larger scope, 
compared to a console or mobile game, and therefore must pull back on nifty art 
features and think more big picture of the gameplay as network bandwidth is an 
issue, and there is a very wide variety of hardware out there that must be 
accounted for - unlike a console where a particular platform is known in 
advance and likely not to change (much).  Majority of our anticipated customers 
still use older hardware running Windows XP, for example.  We have to make 
content which caters to that lowest denomination.  As tools move forward to 
accommodate those working on feats like Elysium, they tend to forget and leave 
behind those who still need that micro-architecture edit capability like us 
where pixels are still pushed one by one.

There is a reason why many games don't have interesting artwork - the tools get 
in the way.


Matt




-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 2:26 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind  wrote:
> To work around many of the issues, artists migrated to other software 
> such as Modo, Z-brush, and so on, further fracturing our pipeline 
> where work takes place, and reducing our needs to write tools in Softimage 
> for art manipulation where ICE can be a meaningful contributor.
[...]
> The bottom line is ICE is not tailored to our needs and is of very limited 
> use/benefit.
[...]
> Our primary needs are data translation (import/export), database 
> 

RE: Survey - how would you do this?

[Matt Lind]

I cannot reveal what our plans are, but I can say what we need is an 
environment that has an open and deep SDK to allow us to build tools on our 
terms, and not on the application's terms, so we can make our own 
infrastructure without having to re-invent the wheel and reduce risk from 
pipeline changes/regressions from commercial software.  Allows us to define our 
own primitives, data structures, and treats those data structures as first 
class citizens in the API.  Not have licensing which ties the content creation 
product into our released product, and is very cost effective for very large 
teams working across multiple sites.  Can be set up quickly and easily and is a 
light install, and not require engineers to make usable or explain to artists.  
In concept, Fabric engine most closely fits that paradigm, but it needs to 
mature before we can give it a serious look.  I would not be surprised if we 
develop our own tools a la Pixar or the other mainstays of the industry.  The 
trend in this space is to build your creation tools into your engine so you can 
take advantage of real time feedback from iteration (a la Valve).  Since we 
built our own engine from scratch, we have full control to implement such 
features on our terms.

Max, Maya, and Softimage don't cater to the MMORPG space very well.  You can 
use the products, as many have obviously demonstrated over the years, but it's 
very much shaving the corners of the square peg to fit it into the round hole.  
This has been a classic problem in games for a long time as the commercial 
software largely cater to film/video and assume games is a simpler version of 
that paradigm.   In the early days of games that was a band-aid that worked, 
but games have evolved a lot since then making the current 3D software not so 
relevant anymore.  The difference with an MMORPG is the game has larger scope, 
compared to a console or mobile game, and therefore must pull back on nifty art 
features and think more big picture of the gameplay as network bandwidth is an 
issue, and there is a very wide variety of hardware out there that must be 
accounted for - unlike a console where a particular platform is known in 
advance and likely not to change (much).  Majority of our anticipated customers 
still use older hardware running Windows XP, for example.  We have to make 
content which caters to that lowest denomination.  As tools move forward to 
accommodate those working on feats like Elysium, they tend to forget and leave 
behind those who still need that micro-architecture edit capability like us 
where pixels are still pushed one by one.

There is a reason why many games don't have interesting artwork - the tools get 
in the way.


Matt




-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 2:26 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind  wrote:
> To work around many of the issues, artists migrated to other software 
> such as Modo, Z-brush, and so on, further fracturing our pipeline 
> where work takes place, and reducing our needs to write tools in Softimage 
> for art manipulation where ICE can be a meaningful contributor.
[...]
> The bottom line is ICE is not tailored to our needs and is of very limited 
> use/benefit.
[...]
> Our primary needs are data translation (import/export), database 
> communications, texture unfolding/UV manipulation, modeling tools such 
> as re-topology and polygon reduction, hardware (real time) shading -- 
> All of which Softimage doesn't do very well

So do you have a plan to diminish your dependency on Softimage?
what is it, what's next?

Re: Survey - how would you do this?

[Luc-Eric Rousseau]

On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind  wrote:
> To work around many of the issues, artists migrated to other software such
> as Modo, Z-brush, and so on, further fracturing our pipeline where work takes 
> place, and reducing our needs to
> write tools in Softimage for art manipulation where ICE can be a meaningful 
> contributor.
[...]
> The bottom line is ICE is not tailored to our needs and is of very limited 
> use/benefit.
[...]
> Our primary needs are data translation (import/export), database 
> communications, texture unfolding/UV manipulation, modeling tools such
> as re-topology and polygon reduction, hardware (real time) shading -- All of 
> which Softimage doesn't do very well

So do you have a plan to diminish your dependency on Softimage?
what is it, what's next?

Re: Survey - how would you do this?

[Sergio Mucino]

  
  
Probably, but... you get the idea 
:-) 

On 13/02/2014 3:09 PM, Paul wrote:


  "I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes"

Wishful thinking I fear. 


  
On 13 Feb 2014, at 20:05, Matt Lind  wrote:

I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes

  
  




-- 
  

  

Re: Survey - how would you do this?

[Paul]

"I think that what Matt meant is that ICE is fairly young tech, and therefore, 
still prone to possible changes"

Wishful thinking I fear. 

> On 13 Feb 2014, at 20:05, Matt Lind  wrote:
> 
> I think that what Matt meant is that ICE is fairly young tech, and therefore, 
> still prone to possible changes

Re: Survey - how would you do this?

[Emilio Hernandez]

Yes I agree.  It would be nice to have an upgrade in other areas more than
ICE.  And not only a camera switcher

But I really don't expect too much for the 2015 version...

Maybe we will see only an enhanced camera switcher...






2014-02-13 13:50 GMT-06:00 :

> this didn't start out as an ICE bashing tread,
> it was about the importance of the basic toolset - which some are tied to
> for whatever reasons.
>
> Productions have been done for many years before/without ICE - it's not a
> be all end all replacement for the rest of the toolset - though I'm sure
> some FX/TD oriented people might get that impression.
>
> ICE is great and all and it's a shame to avoid using it - but the basic
> toolset is getting little development efforts while ICE sucks most
> attention to it - or so it seems at least.
> That's not a healthy outlook on the long run - as well as very frustrating
> for those using ICE sparingly or not at all.
> ...
>
>
> -Original Message- From: Eric Thivierge
> Sent: Thursday, February 13, 2014 8:22 PM
>
> To: softimage@listproc.autodesk.com
> Subject: Re: Survey - how would you do this?
>
> Fair enough, so I guess you're of the opinion that ICE is still fragile
> / unstable and not mature tool?
>
> On Thursday, February 13, 2014 2:16:02 PM, Steven Caron wrote:
>
>> after 2 service packs... arnold plugins are not available for 2014 or
>> 2014 SP1.
>>
>> On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge
>> mailto:ethivie...@hybride.com>> wrote:
>>
>> Did you just have to recompile the tools? After that everything
>> worked like before?
>>
>>
>> On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote:
>>
>> 2014... anything using ICE SDK in the array area broke.
>>
>>
>> On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge
>> mailto:ethivie...@hybride.com>
>> <mailto:ethivie...@hybride.com
>> <mailto:ethivie...@hybride.com>__>> wrote:
>>
>> When is the last time they changed ICE that it broke
>> workflows and
>> tools?
>>
>> Eric T.
>>
>>
>>
>>
>

RE: Survey - how would you do this?

[Matt Lind]

That is correct.

ICE introduces a lot of risk because it is still molding into shape.  We must 
be as risk averse as possible.


Matt



From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sergio Mucino
Sent: Thursday, February 13, 2014 8:35 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

I think that what Matt meant is that ICE is fairly young tech, and therefore, 
still prone to possible changes, whereas constraints, using his example, are 
very old tech that is pretty much not going to change... ever. I can understand 
his point, but on the flip side, I'm also aware that nothing lasts forever. But 
policies governing how assets are handled I'm sure are not Matt's to set up, so 
anyway... I'm starting to ramble, but I think I made my point. Now, back to 
your original programming :-) .
[cid:image001.gif@01CF28B3.DC597160]
On 13/02/2014 11:25 AM, Emilio Hernandez wrote:

I will drink that beer in this one with Eric.
I am not on the game side but on the film and advertising, so I only know the 
basics of a gaming engine and I found your survey challenge just to take a look 
back at the legacy tools and solve the problem, because as the rest of us I 
believe ICE is the word and the way to think how to solve a "simple" task as 
the one you describe.
I use ICE for a lot of things, not only particles fx.  And I am no erudit as 
Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc.  I will say I am an average ICE 
user more on the artist side.  And really ICE never stops surprising me.  I 
find it very stable, and I use it very often, even for very simple projects.  
And it allows me to change things as a line of shopping bags vanishing to the 
horizon in a breeze with client's request such as "No, let's make the bags 
bigger.  More bags, less bags. Can we see two rows of bags, perhpas three?..."
I can hardly imagine the 2020 release of Softimage, ICE dissapears out of 
nowhere.  For me, it is like saying the render tree will vanish.
Porting to a game engine from Softimage, is something that I can't speak a word.
But in my regular workflow ICE rules!
Cheers!

[http://img694.imageshack.us/img694/8965/erojamailpleca.jpg]

2014-02-13 8:19 GMT-06:00 Eric Thivierge 
mailto:ethivie...@hybride.com>>:
So you need to hire robots then cause all workflows involving humans are prone 
to error, you just have to reduce it as much as possible.

I'm with Brad regarding ICE. It's stable and mature for the bread and butter 
work that is done with it (an example is your asteroid task). Otherwise, how is 
real work getting done with it?

Eric T.


On 2/12/2014 6:01 PM, Matt Lind wrote:

The point is we cannot subscribe to workflows which are prone to human error.



--
<>

Re: Survey - how would you do this?

[peter_b]

this didn’t start out as an ICE bashing tread,
it was about the importance of the basic toolset - which some are tied to 
for whatever reasons.


Productions have been done for many years before/without ICE - it's not a be 
all end all replacement for the rest of the toolset - though I'm sure some 
FX/TD oriented people might get that impression.


ICE is great and all and it's a shame to avoid using it - but the basic 
toolset is getting little development efforts while ICE sucks most attention 
to it - or so it seems at least.
That's not a healthy outlook on the long run - as well as very frustrating 
for those using ICE sparingly or not at all.

...


-Original Message- 
From: Eric Thivierge

Sent: Thursday, February 13, 2014 8:22 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Fair enough, so I guess you're of the opinion that ICE is still fragile
/ unstable and not mature tool?

On Thursday, February 13, 2014 2:16:02 PM, Steven Caron wrote:

after 2 service packs... arnold plugins are not available for 2014 or
2014 SP1.

On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge
mailto:ethivie...@hybride.com>> wrote:

Did you just have to recompile the tools? After that everything
worked like before?


On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote:

2014... anything using ICE SDK in the array area broke.


On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge
mailto:ethivie...@hybride.com>
<mailto:ethivie...@hybride.com
<mailto:ethivie...@hybride.com>__>> wrote:

When is the last time they changed ICE that it broke
workflows and
tools?

Eric T.

RE: Survey - how would you do this?

[Matt Lind]

 go back and revisit tens of thousands 
of assets to make corrections.

We need full control of the ICE compound version manager.  I haven't spent much 
time on it, but in the limited time I have spent with it (a few years ago) it 
didn't seem very open.  Softimage tended to automatically prompt the user with 
a dialog each time it found a compound that was out of date.  I couldn't find a 
way to suppress it and drive it through scripting on a scene load event as 
there are times we do not want the update to happen.  That is an important 
pipeline management issue for us.

Bottom line - for most of the problems I need to solve which I've tried ICE, 
ICE has either crash and burned or come up short in feature set to support our 
needs.  Believe me, I've tried many times over many betas and releases and many 
different applications in production.  The bottom line is ICE is not tailored 
to our needs and is of very limited use/benefit.  Therefore, it's not a 
priority to get it working in our pipeline compared to the many other issues I 
must address to get our game out the door.

For sake of argument, let's pretend ICE does work and is fully mature.

The context in which we can use ICE is not the same context in which you and 
many others use it in film/video.  When you make an asset and render it, you 
can pretty much forget about it and move onto the next.  We do not have that 
luxury.  We must maintain our assets release to release in the same fashion a 
commercial application is developed.  But since art isn't code, we do not have 
the luxury of modifying classes or sub-classing code to implement updates and 
have it ripple out.  We must manually revisit assets to apply such updates.  
Since standards have evolved over time, it's not always possible to run a batch 
process to do these updates as there is no way to know which standard was in 
effect when the asset was last touched.

Operators have very limited benefit in a games pipeline as they don't translate 
into the game engine.  We have a proprietary engine which we built in-house 
from scratch.  Our principal engineer was the inventor of HLSL and one of the 
engineers behind World of Warcraft's engine, so he knows his stuff.  Our game 
engine already has its own particle system, does not support IK or other 
runtime effects coming from a content creation package (most MMORPG's don't).  
Our primary needs are data translation (import/export), database 
communications, texture unfolding/UV manipulation, modeling tools such as 
re-topology and polygon reduction, hardware (real time) shading -- All of which 
Softimage doesn't do very well.  On a simpler level- the ability to store 
colors in a palette for use in vertex color painting and sharing the palette 
between environment scenes.  The ability to paint a texture on a model in 3D.  
The ability to re-pack and relax texture UVs into a defined UV space without 
requiring the f'in Unfold operator.  The ability to resolve real time shader 
parameter names of in render passes which are overridden.  On the animation 
side, the only real benefit ICE can give is a custom constraint operator or 
perhaps a custom tail rig operator for some of our characters.  All our 
deformations must come through envelopes, but since we have hard limits on the 
number of bones we can use, there isn't enough resolution for a cloth simulator 
or deformation operator to be of use.  Each of our assets must live on its own 
in a vacuum inside a model so it can be referenced into other scenes.  That 
means no external dependencies other than texture maps.  What we really need is 
for the god damn real time shaders to function up to their name and have 
migration paths that actually work.  That is highly important and has been our 
biggest issue.

When art is generated and exported, it must be migrated into the pipeline so 
other departments can work with the data downstream in production.  Scripters, 
designers, engineers, level builders, etc...  It's not too difficult to 
introduce art into the system, but there is a lot of inertia to make 
modifications because of all the downstream dependencies.  Once an asset is 
available, you have to make the assumption it's used anywhere and everywhere 
because if you rip it out or modify it, you may break many things with a very 
large ripple effect.  Chasing down those types of problems is very difficult, 
time consuming and stressful if you do not know the cause.  For that reason, 
introducing something which is still aqueous, such as ICE, into production that 
really doesn't need it, is really not a good idea

So you tell me where I can use ICE that makes it so important to make a 
round hose fit over a square filter for something of very limited benefit?  I 
really want to hear this, Brad.


Matt











-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto

Re: Survey - how would you do this?

[Steven Caron]

i am of the opinion its not all unicorns and rainbows. i have been blocked
number of times and there are areas of ICE that are too finicky and i wont
touch (ICE Kinematics)

s

On Thu, Feb 13, 2014 at 11:22 AM, Eric Thivierge wrote:

> Fair enough, so I guess you're of the opinion that ICE is still fragile /
> unstable and not mature tool?
>
>

Re: Survey - how would you do this?

[Eric Thivierge]

Fair enough, so I guess you're of the opinion that ICE is still fragile 
/ unstable and not mature tool?


On Thursday, February 13, 2014 2:16:02 PM, Steven Caron wrote:

after 2 service packs... arnold plugins are not available for 2014 or
2014 SP1.

On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge
mailto:ethivie...@hybride.com>> wrote:

Did you just have to recompile the tools? After that everything
worked like before?


On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote:

2014... anything using ICE SDK in the array area broke.


On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge
mailto:ethivie...@hybride.com>
__>> wrote:

When is the last time they changed ICE that it broke
workflows and
tools?

Eric T.

Re: Survey - how would you do this?

[Steven Caron]

after 2 service packs... arnold plugins are not available for 2014 or 2014
SP1.

On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge wrote:

> Did you just have to recompile the tools? After that everything worked
> like before?
>
>
> On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote:
>
>> 2014... anything using ICE SDK in the array area broke.
>>
>>
>> On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge
>> mailto:ethivie...@hybride.com>> wrote:
>>
>> When is the last time they changed ICE that it broke workflows and
>> tools?
>>
>> Eric T.
>>
>>
>

Re: Survey - how would you do this?

[Eric Thivierge]

Did you just have to recompile the tools? After that everything worked 
like before?


On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote:

2014... anything using ICE SDK in the array area broke.


On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge
mailto:ethivie...@hybride.com>> wrote:

When is the last time they changed ICE that it broke workflows and
tools?

Eric T.

Re: Survey - how would you do this?

[Steven Caron]

2014... anything using ICE SDK in the array area broke.


On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge wrote:

>  When is the last time they changed ICE that it broke workflows and tools?
>
> Eric T.
>
>

Re: Survey - how would you do this?

[Eric Thivierge]

  
  
When is the last time they changed ICE that it broke workflows and
tools?

Eric T.

On 2/13/2014 11:35 AM, Sergio Mucino
  wrote:


  
  I think that what Matt meant is that ICE is fairly young tech, and
  therefore, still prone to possible changes, whereas constraints,
  using his example, are very old tech that is pretty much not going
  to change... ever. I can understand his point, but on the flip
  side, I'm also aware that nothing lasts forever. But policies
  governing how assets are handled I'm sure are not Matt's to set
  up, so anyway... I'm starting to ramble, but I think I made my
  point. Now, back to your original programming  :-) .
  


  

RE: Survey - how would you do this?

[Marc Brinkley]

We instance like crazy in games. Keeps the memory foot print down (just like 
rendering) however we still need to battle draw calls. One game I worked on had 
memory super low and we were doing great but our draw calls went through the 
roof and our frames per second went way way down. So we had to balance our 
memory and draw calls delicately to ensure we weren't over memory but were 
maintaining a consistent 30 frames per second.

God help those that run at 60 fps like Call of Duty. That's a tough business. 
That's why profiling tools are critical (like PIX on Windows).

___
Marc Brinkley
343 Industries
Microsoft Studios
marc.brinkley [at] microsoft.com

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Tuesday, February 11, 2014 12:37 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

I meant that Matt was going to say that you can't instance stuff as one 
additional restriction...
On 2/11/2014 3:28 PM, Emilio Hernandez wrote:
Well not $10 bucks but a sample scene will say yes.

https://dl.dropboxusercontent.com/u/49626349/Asteroids.scn

[http://img694.imageshack.us/img694/8965/erojamailpleca.jpg]

2014-02-11 14:19 GMT-06:00 Tim Leydecker 
mailto:bauero...@gmx.de>>:
Do it by hand.

Create null in center of Planet.

Call it Parent_Mom.

Create Volume Previz Torus Helper.

Create Asteroid in Origin.

Create Null.

Name Null Asteroid_P001.

Parent Asteroid to Asteroid_P001.

Animate Asteroid Rotation (its tumbling) in Origin.

Snap Asteroid_P001 to Torus.

Parent Asteroid_P001 to Parent_Mom.

Duplicate Asteroid_P001, resulting in Asteroid_P002.

Snap Asteroid_P002 to Torus.

Create Null, call it Parent_Spin.

Parent Parent_Mom to Parent_Spin.

Animate Rotation (Y) of Parent_Spin.

Create Null, name it Parent_Dad.

Name Planet Forever21Planet, parent Forever21 and Parent_Spin to Parent_Dad.

Duplicate Asteroid_P002 as often as you need and snap to Torus.

Duplicate Parent_Spin, rename Parent_Spin_faster. Adjust Animation to spin 
faster.

Delete any Asteroids you don´t like, offset animations where neccessary or 
desired.

Rinse, repeat.

Play.











On 11.02.2014 20:23, Matt Lind wrote:
The question:

but how do you apply the random jitter to the object positions?

Re: Survey - how would you do this?

[Sergio Mucino]

  
  
I think that what Matt meant is that ICE is fairly young tech, and
therefore, still prone to possible changes, whereas constraints,
using his example, are very old tech that is pretty much not going
to change... ever. I can understand his point, but on the flip side,
I'm also aware that nothing lasts forever. But policies governing
how assets are handled I'm sure are not Matt's to set up, so
anyway... I'm starting to ramble, but I think I made my point. Now,
back to your original programming 
:-) .

On 13/02/2014 11:25 AM, Emilio
  Hernandez wrote:


  

  

  

  


I will drink that beer in this one with Eric.

  
  I am not on the game side but on the film and
  advertising, so I only know the basics of a gaming
  engine and I found your survey challenge just to take
  a look back at the legacy tools and solve the problem,
  because as the rest of us I believe ICE is the word
  and the way to think how to solve a "simple" task as
  the one you describe.
  

I use ICE for a lot of things, not only particles fx. 
And I am no erudit as Mr. Mootz, Thiago, Paul Smith, Ola
Madsen, etc.  I will say I am an average ICE user more
on the artist side.  And really ICE never stops
surprising me.  I find it very stable, and I use it very
often, even for very simple projects.  And it allows me
to change things as a line of shopping bags vanishing to
the horizon in a breeze with client's request such
as "No, let's make the bags bigger.  More bags, less
bags. Can we see two rows of bags, perhpas three?..."

  
  I can hardly imagine the 2020 release of Softimage, ICE
  dissapears out of nowhere.  For me, it is like saying the
  render tree will vanish.
  

Porting to a game engine from Softimage, is something that I
can't speak a word.

  
  But in my regular workflow ICE rules!
  

Cheers!
  
  




2014-02-13 8:19 GMT-06:00 Eric
  Thivierge :
  
So you need to hire robots then cause all workflows
involving humans are prone to error, you just have to reduce
it as much as possible.

I'm with Brad regarding ICE. It's stable and mature for the
bread and butter work that is done with it (an example is
your asteroid task). Otherwise, how is real work getting
done with it?

Eric T.

  

On 2/12/2014 6:01 PM, Matt Lind wrote:

The point is we cannot subscribe to workflows which are
prone to human error.


  

  


  


-- 
  

  

Re: Survey - how would you do this?

[Eric Thivierge]

I can see ICE disappearing like the old very clunky particle system 
that it replaced if the technology progresses and it does need to be 
replaced. I welcome it. Also, they left the old system in place for a 
few years so you could transition workflows and tool sets so it's not 
like it vanished over night.


Eric T.

On Thursday, February 13, 2014 11:25:06 AM, Emilio Hernandez wrote:


I will drink that beer in this one with Eric.

I am not on the game side but on the film and advertising, so I only
know the basics of a gaming engine and I found your survey challenge
just to take a look back at the legacy tools and solve the problem,
because as the rest of us I believe ICE is the word and the way to
think how to solve a "simple" task as the one you describe.

I use ICE for a lot of things, not only particles fx.  And I am no
erudit as Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc.  I will say
I am an average ICE user more on the artist side.  And really ICE
never stops surprising me.  I find it very stable, and I use it very
often, even for very simple projects.  And it allows me to change
things as a line of shopping bags vanishing to the horizon in a breeze
with client's request such as "No, let's make the bags bigger.
More bags, less bags. Can we see two rows of bags, perhpas three?..."

I can hardly imagine the 2020 release of Softimage, ICE dissapears out
of nowhere.  For me, it is like saying the render tree will vanish.

Porting to a game engine from Softimage, is something that I can't
speak a word.

But in my regular workflow ICE rules!

Cheers!




2014-02-13 8:19 GMT-06:00 Eric Thivierge mailto:ethivie...@hybride.com>>:

So you need to hire robots then cause all workflows involving
humans are prone to error, you just have to reduce it as much as
possible.

I'm with Brad regarding ICE. It's stable and mature for the bread
and butter work that is done with it (an example is your asteroid
task). Otherwise, how is real work getting done with it?

Eric T.


On 2/12/2014 6:01 PM, Matt Lind wrote:

The point is we cannot subscribe to workflows which are prone to
human error.

Re: Survey - how would you do this?

[Emilio Hernandez]

I will drink that beer in this one with Eric.

I am not on the game side but on the film and advertising, so I only know
the basics of a gaming engine and I found your survey challenge just to
take a look back at the legacy tools and solve the problem, because as the
rest of us I believe ICE is the word and the way to think how to solve a
"simple" task as the one you describe.

I use ICE for a lot of things, not only particles fx.  And I am no erudit
as Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc.  I will say I am an
average ICE user more on the artist side.  And really ICE never stops
surprising me.  I find it very stable, and I use it very often, even for
very simple projects.  And it allows me to change things as a line of
shopping bags vanishing to the horizon in a breeze with client's request
such as "No, let's make the bags bigger.  More bags, less bags. Can we
see two rows of bags, perhpas three?..."

I can hardly imagine the 2020 release of Softimage, ICE dissapears out of
nowhere.  For me, it is like saying the render tree will vanish.

Porting to a game engine from Softimage, is something that I can't speak a
word.

But in my regular workflow ICE rules!

Cheers!




2014-02-13 8:19 GMT-06:00 Eric Thivierge :

> So you need to hire robots then cause all workflows involving humans are
> prone to error, you just have to reduce it as much as possible.
>
> I'm with Brad regarding ICE. It's stable and mature for the bread and
> butter work that is done with it (an example is your asteroid task).
> Otherwise, how is real work getting done with it?
>
> Eric T.
>
>
> On 2/12/2014 6:01 PM, Matt Lind wrote:
>
> The point is we cannot subscribe to workflows which are prone to human
> error.
>
>
>

Re: Survey - how would you do this?

[Eric Thivierge]

So you need to hire robots then cause all workflows involving humans are 
prone to error, you just have to reduce it as much as possible.


I'm with Brad regarding ICE. It's stable and mature for the bread and 
butter work that is done with it (an example is your asteroid task). 
Otherwise, how is real work getting done with it?


Eric T.

On 2/12/2014 6:01 PM, Matt Lind wrote:

The point is we cannot subscribe to workflows which are prone to human error.

Re: Survey - how would you do this?

[Christian Gotzinger]

I don't think you can compare ICE to those other examples you described. At
this point, I think the only way for ICE to go down is for the entire
package to be discontinued. We are tiny compared to your place, but we also
need to build assets that last us for a long time. I use ICE for a lot of
these things without hesitation because I really don't see it being ripped
out or becoming unsupported at any point.

Also, I find it very stable; I've done many crazy things with it, and while
it can sometimes be slow, it does not crash pretty much ever. Granted,
kinematics is an area where I've seen some flaky behavior, but this may be
from back when they weren't officially supported as I don't need kinematics
much these days.


On Thu, Feb 13, 2014 at 12:01 AM, Matt Lind wrote:

> Part of it is circumstance, as in we only have so many resources.  For
> example, our art department is 100+, but I'm the only one in the department
> who writes code and I'm currently tasked with significantly higher priority
> issues helping out an under staffed engineering department than writing
> one-offs for every artist who needs a button.
>
> The other part is pipeline management of a large scale software
> development effort.  We have a feature film sized team working to build a
> high profile AAA title.  With an engine and tools under constant evolution,
> and life expectancy of 15+ years, you must choose methods of content
> creation which can withstand changes to the software, such as Softimage, as
> well as changes to the game itself.  An asset created today must expect to
> live for 10+ years without any further maintenance.  If given the choice
> between creating an asteroid belt using constraints vs. ICE, we'll probably
> opt for constraints because we know it's a fairly stable and mature system,
> which cannot be said for ICE.  We've been bitten many times already such as
> when we created a number of simulations back in XSI 5 using the Softimage
> particle system only for the particle system to be ripped out and replaced
> with ICE.  We can no longer open those assets in Softimage.  Same happened
> again with updates to the realtime shader APIs.  So now we must either live
> with their current state of dysfunction, or rebuild from scratch.  On
> projects of this magnitude, risk assessment has a very high priority and
> taken extremely seriously because one bad move can literally sink the
> project if the ripple effect is large enough.  While we do take measures to
> abstract data from commercial tools, we only have so much programming power
> in house to do so.
>
> The point is we cannot subscribe to workflows which are prone to human
> error.  Creating temporary data and expecting the artist to clean up after
> himself has proven to not be reliable as assets are referenced by other
> assets all the time.  If crap is left around, then anybody referencing that
> asset also inherits the crap which results in bugs in game.  In film/video
> you can sweep things under the carpet if they aren't perfect as long as the
> problem doesn't  show up on camera.  We don't have that luxury.  What you
> make has to be functional and optimal for a live game environment,
> conservative on resources, and not make any assumptions how it will be
> used.  Function has higher priority than looking pretty.
>
> There's a lot more to it, but I think you get the gist of it.
>
> Matt
>
>
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph
> G. (LARC-E1A)[LITES]
> Sent: Wednesday, February 12, 2014 10:59 AM
> To: softimage@listproc.autodesk.com
> Subject: RE: Survey - how would you do this?
>
> So cheese and monkeys aside. After 25 years as a 3D animator I've never
> worked in games. So from a serious perspective I simply  don't understand.
> It's not clear to me why you aren't able to use ICE or scripts and freeze
> those construction connections sending only the raw assets over without
>  ICE or scripting. What is it about this pipeline which makes that
> difficult?
>
> --
> Joey Ponthieux
> LaRC Information Technology Enhanced Services (LITES) Mymic Technical
> Services NASA Langley Research Center
> __
> Opinions stated here-in are strictly those of the author and do not
> represent the opinions of NASA or any other party.
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
> Sent: Wednesday, February 12, 2014 1:35 PM
> To: softimage@listproc.autodesk.com
> Subject: 

Re: Survey - how would you do this?

[Bradley Gabe]

Yup, if you were one of the NASA engineers back in Houston during the Apollo 13 
mission, the astronauts would have all died. :p

ICE not stable and mature? You're kidding, right? 

Some things are worth figuring out how to fit a round hose over a square 
filter. ICE is one of those things.




Sent from my iPhone

> On Feb 12, 2014, at 5:01 PM, Matt Lind  wrote:
> 
> Part of it is circumstance, as in we only have so many resources.  For 
> example, our art department is 100+, but I'm the only one in the department 
> who writes code and I'm currently tasked with significantly higher priority 
> issues helping out an under staffed engineering department than writing 
> one-offs for every artist who needs a button.
> 
> The other part is pipeline management of a large scale software development 
> effort.  We have a feature film sized team working to build a high profile 
> AAA title.  With an engine and tools under constant evolution, and life 
> expectancy of 15+ years, you must choose methods of content creation which 
> can withstand changes to the software, such as Softimage, as well as changes 
> to the game itself.  An asset created today must expect to live for 10+ years 
> without any further maintenance.  If given the choice between creating an 
> asteroid belt using constraints vs. ICE, we'll probably opt for constraints 
> because we know it's a fairly stable and mature system, which cannot be said 
> for ICE.  We've been bitten many times already such as when we created a 
> number of simulations back in XSI 5 using the Softimage particle system only 
> for the particle system to be ripped out and replaced with ICE.  We can no 
> longer open those assets in Softimage.  Same happened again with updates to 
> the realtime shader APIs.  So now we must either live with their current 
> state of dysfunction, or rebuild from scratch.  On projects of this 
> magnitude, risk assessment has a very high priority and taken extremely 
> seriously because one bad move can literally sink the project if the ripple 
> effect is large enough.  While we do take measures to abstract data from 
> commercial tools, we only have so much programming power in house to do so.  
> 
> The point is we cannot subscribe to workflows which are prone to human error. 
>  Creating temporary data and expecting the artist to clean up after himself 
> has proven to not be reliable as assets are referenced by other assets all 
> the time.  If crap is left around, then anybody referencing that asset also 
> inherits the crap which results in bugs in game.  In film/video you can sweep 
> things under the carpet if they aren't perfect as long as the problem doesn't 
>  show up on camera.  We don't have that luxury.  What you make has to be 
> functional and optimal for a live game environment, conservative on 
> resources, and not make any assumptions how it will be used.  Function has 
> higher priority than looking pretty.  
> 
> There's a lot more to it, but I think you get the gist of it.
> 
> Matt
> 
> 
> 
> 
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, 
> Joseph G. (LARC-E1A)[LITES]
> Sent: Wednesday, February 12, 2014 10:59 AM
> To: softimage@listproc.autodesk.com
> Subject: RE: Survey - how would you do this?
> 
> So cheese and monkeys aside. After 25 years as a 3D animator I've never 
> worked in games. So from a serious perspective I simply  don't understand. 
> It's not clear to me why you aren't able to use ICE or scripts and freeze 
> those construction connections sending only the raw assets over without  ICE 
> or scripting. What is it about this pipeline which makes that difficult?
> 
> --
> Joey Ponthieux
> LaRC Information Technology Enhanced Services (LITES) Mymic Technical 
> Services NASA Langley Research Center 
> __
> Opinions stated here-in are strictly those of the author and do not represent 
> the opinions of NASA or any other party.
> 
> 
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
> Sent: Wednesday, February 12, 2014 1:35 PM
> To: softimage@listproc.autodesk.com
> Subject: RE: Survey - how would you do this?
> 
> We'd have to add support for ICE in our exporter and pipeline management 
> tools.  We don't have resources to do that at present.
> 
> If the artist doesn't clean up after himself responsibly, it creates a lot of 
> problems.
> 
> 
> Matt
> 
> 
> 
> 
> 
> -Original Message-
>

RE: Survey - how would you do this?

[Matt Lind]

Part of it is circumstance, as in we only have so many resources.  For example, 
our art department is 100+, but I'm the only one in the department who writes 
code and I'm currently tasked with significantly higher priority issues helping 
out an under staffed engineering department than writing one-offs for every 
artist who needs a button.

The other part is pipeline management of a large scale software development 
effort.  We have a feature film sized team working to build a high profile AAA 
title.  With an engine and tools under constant evolution, and life expectancy 
of 15+ years, you must choose methods of content creation which can withstand 
changes to the software, such as Softimage, as well as changes to the game 
itself.  An asset created today must expect to live for 10+ years without any 
further maintenance.  If given the choice between creating an asteroid belt 
using constraints vs. ICE, we'll probably opt for constraints because we know 
it's a fairly stable and mature system, which cannot be said for ICE.  We've 
been bitten many times already such as when we created a number of simulations 
back in XSI 5 using the Softimage particle system only for the particle system 
to be ripped out and replaced with ICE.  We can no longer open those assets in 
Softimage.  Same happened again with updates to the realtime shader APIs.  So 
now we must either live with their current state of dysfunction, or rebuild 
from scratch.  On projects of this magnitude, risk assessment has a very high 
priority and taken extremely seriously because one bad move can literally sink 
the project if the ripple effect is large enough.  While we do take measures to 
abstract data from commercial tools, we only have so much programming power in 
house to do so.  

The point is we cannot subscribe to workflows which are prone to human error.  
Creating temporary data and expecting the artist to clean up after himself has 
proven to not be reliable as assets are referenced by other assets all the 
time.  If crap is left around, then anybody referencing that asset also 
inherits the crap which results in bugs in game.  In film/video you can sweep 
things under the carpet if they aren't perfect as long as the problem doesn't  
show up on camera.  We don't have that luxury.  What you make has to be 
functional and optimal for a live game environment, conservative on resources, 
and not make any assumptions how it will be used.  Function has higher priority 
than looking pretty.  

There's a lot more to it, but I think you get the gist of it.

Matt




-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph 
G. (LARC-E1A)[LITES]
Sent: Wednesday, February 12, 2014 10:59 AM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

So cheese and monkeys aside. After 25 years as a 3D animator I've never worked 
in games. So from a serious perspective I simply  don't understand. It's not 
clear to me why you aren't able to use ICE or scripts and freeze those 
construction connections sending only the raw assets over without  ICE or 
scripting. What is it about this pipeline which makes that difficult?

--
Joey Ponthieux
LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services 
NASA Langley Research Center __
Opinions stated here-in are strictly those of the author and do not represent 
the opinions of NASA or any other party.


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, February 12, 2014 1:35 PM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

We'd have to add support for ICE in our exporter and pipeline management tools. 
 We don't have resources to do that at present.

If the artist doesn't clean up after himself responsibly, it creates a lot of 
problems.


Matt





-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Wednesday, February 12, 2014 7:21 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind  wrote:
> The solution is 100% art driven in this case and cannot rely on game 
> engine logic or engineering resources.  If it could, there wouldn't be 
> a challenge ;-)
>
> Cannot use ICE, but you can use expressions, constraints, or animation mixer 
> to set up and plot out to explicit controls later if you prefer.
>
> A junior or staff level artist must be able to setup and complete the task 
> unsupervised in 30 minutes or less.  Must also avoid creating any bugs such 
> as leaving 

RE: Survey - how would you do this?

[Matt Lind]

You're missing the point, I don't have that time available.  Don't let my 
ability to type really fast fool you into thinking I do.

Matt



-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Wednesday, February 12, 2014 11:01 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Artists don't need to even understand that they are using ICE if you build a 
proper interface for the system. We even have MODELERS here using ICE! :P

Eric T.

Re[4]: Survey - how would you do this?

[Eugen Sares]

-- Originalnachricht --
Von: "Matt Lind" 
An: "softimage@listproc.autodesk.com" 
Gesendet: 12.02.2014 19:30:19
Betreff: RE: Re[2]: Survey - how would you do this?


As much as I’d like to see NURBS Curve improvements, I’d put it low on
the list in comparison to other things that need to be done (Such as
NURBS Surface improvements ;-D).  Seriously, fundamental tools and SDK
improvements are much needed.





Matt


Agreed, of course. We seem to be among the few who care about the
classic SDK, besides all the ICE disciples - nothing against it! If it
would be good for everything, fine, but it ain't.



Those 4 bugs I refer to are simple ones, really. One is related to
surfaces, too, btw - in JScript, you can only set Nurbs surfaces with
only one subsurface in a custom operator. In VB it works. How hard can
this be?
Another is that subcurves that you add in a custom tool cannot be
selected until you freeze (or use a strange trick - add some factory
operator, too).
I reported the same problem for polygons added in a custom op, and it
was fixed almost immediately.

Those effin' subcurves and subsurfaces... implemented so sloppy and
half-a**ed. Directive seems to say: if it's Nurbs, toss it in the
corner...













From:softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eugen
Sares
Sent: Wednesday, February 12, 2014 12:37 AM
To:softimage@listproc.autodesk.com
Subject: Re[2]: Survey - how would you do this?



-- Originalnachricht --

Von: "Matt Lind" 

An: "softimage@listproc.autodesk.com" 

Gesendet: 12.02.2014 05:37:30

Betreff: RE: Survey - how would you do this?






We don’t miss ICE as much as you’d think.  What hurts us more is the
lack of development in the fundamental tools outside of ICE such as
the texture editor, modeling, data management, animation and envelope
editing, and so on.



ICE allows you to create many arbitrary effects on a whim, but is also
locked into the way Softimage works and not the way we need to work.
ICE doesn’t really address the kinds of problems we need solved, or
issues that can’t already be solved by other means even if they aren’t
as slick.  ICE doesn’t support the data we need supported.  For
example, we’d like to make some ICE modeling tools, but since ICE
doesn’t support custom properties and other userdata in topology 
operations, any time an artist makes a topology edit to an asset, the

meta data would be lost creating bugs in our game next time the asset
is exported.



For the few areas where ICE would be useful, it either has bugs or
feature limitations making it more of a liability than a help.  That’s
why we don’t use it.  ICE needs more work to be a viable option for
us.





Matt


Amen!



I'm among those who use (and enjoy) the non-ICE part of SI (mostly),
for straightforward modeling/visualization stuff, and for a switch, it
would be cool to see the development spotlight swing over there again,
temporarily. Begging for years now to get a few measly curve related
bugs fixed...



Product politics. After all, king autodesk forbeared from having the
head of the jester, looking at all the nice ICE tricks it can play.














From:softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc..autodesk.com] On Behalf Of Sylvain
Lebeau
Sent: Tuesday, February 11, 2014 8:00 PM
To:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?



of course!!!



my god... how doest it's like to be hand cuffed?

no ice, no nothing!!



good luck Matt!

good challenge!



sly





Sylvain Lebeau // SHED
V-P/Visual effects supervisor
1410, RUE STANLEY, 11E ÉTAGE MONTRÉAL (QUÉBEC) H3A 1P8
T 514 849-1555 F 514 849-5025 WWW.SHEDMTL.COM <http://WWW.SHEDMTL.COM>




VFX Curriculum 03: Compositing Basics

mail to: s...@shedmtl.com








On Feb 11, 2014, at 10:38 PM, Matt Lind 
wrote:



This could work if normal mapping was used on the sprites, but
animated texture sequences would likely be too expensive for a slow
sequence like this.  If the asteroids moved quickly, then it could be
more doable as fewer frames would be needed.



The tricky part with the sprite solution is to keep the asteroids from
staring at the camera and flipping in an attention-grabbing way if the
camera should travel through the asteroid belt and get close to some
of the rocks.





Matt







From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sylvain
Lebeau
Sent: Tuesday, February 11, 2014 5:17 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?



Maybe it could work as well.



I think of rendering sequences of a bunch of individual rotating
asteriods with camera locked down on them, maybe 10 different ones. So
you end up with small rez little videos with a rotating asteroid in
the middle.



And use the same techni

Re: Survey - how would you do this?

[Eric Thivierge]

Artists don't need to even understand that they are using ICE if you 
build a proper interface for the system. We even have MODELERS here 
using ICE! :P


Eric T.

RE: Survey - how would you do this?

[Ponthieux, Joseph G. (LARC-E1A)[LITES]]

So cheese and monkeys aside. After 25 years as a 3D animator I've never worked 
in games. So from a serious perspective I simply  don't understand. It's not 
clear to me why you aren't able to use ICE or scripts and freeze those 
construction connections sending only the raw assets over without  ICE or 
scripting. What is it about this pipeline which makes that difficult?

--
Joey Ponthieux
LaRC Information Technology Enhanced Services (LITES)
Mymic Technical Services
NASA Langley Research Center
__
Opinions stated here-in are strictly those of the author and do not 
represent the opinions of NASA or any other party.


-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, February 12, 2014 1:35 PM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

We'd have to add support for ICE in our exporter and pipeline management tools. 
 We don't have resources to do that at present.

If the artist doesn't clean up after himself responsibly, it creates a lot of 
problems.


Matt





-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Wednesday, February 12, 2014 7:21 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind  wrote:
> The solution is 100% art driven in this case and cannot rely on game 
> engine logic or engineering resources.  If it could, there wouldn't be 
> a challenge ;-)
>
> Cannot use ICE, but you can use expressions, constraints, or animation mixer 
> to set up and plot out to explicit controls later if you prefer.
>
> A junior or staff level artist must be able to setup and complete the task 
> unsupervised in 30 minutes or less.  Must also avoid creating any bugs such 
> as leaving temporary data in the scene or methods that require such tactics.  
> Bugs that make their way into the game engine are very expensive to find, 
> fix, and QA.  Therefore, great emphasis should be placed on technique and 
> working cleanly.
>

Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? 
 Don't you have to do that for expression, anim mixer, etc?  I mean you don't 
have that in the engine either, right?

RE: Survey - how would you do this?

[Matt Lind]

You assume somebody besides me knows how to use ICE in this building.

The only reason I'm able to write on this thread now is because I'm waiting for 
queries and builds to complete.  That's about to end.

Matt



-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe
Sent: Wednesday, February 12, 2014 10:52 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

In less than the amount of time you've spent on this thread, you could have 
written a simple script to bake out ICE particle SRT's, which would not only 
help in this situation, but a million and one others. :-)

Sent from my iPhone

> On Feb 12, 2014, at 12:35 PM, Matt Lind  wrote:
> 
> We'd have to add support for ICE in our exporter and pipeline management 
> tools.  We don't have resources to do that at present.
> 
> If the artist doesn't clean up after himself responsibly, it creates a lot of 
> problems.
> 
> 
> Matt
> 
> 
> 
> 
> 
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric 
> Rousseau
> Sent: Wednesday, February 12, 2014 7:21 AM
> To: softimage@listproc.autodesk.com
> Subject: Re: Survey - how would you do this?
> 
>> On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind  wrote:
>> The solution is 100% art driven in this case and cannot rely on game 
>> engine logic or engineering resources.  If it could, there wouldn't 
>> be a challenge ;-)
>> 
>> Cannot use ICE, but you can use expressions, constraints, or animation mixer 
>> to set up and plot out to explicit controls later if you prefer.
>> 
>> A junior or staff level artist must be able to setup and complete the task 
>> unsupervised in 30 minutes or less.  Must also avoid creating any bugs such 
>> as leaving temporary data in the scene or methods that require such tactics. 
>>  Bugs that make their way into the game engine are very expensive to find, 
>> fix, and QA.  Therefore, great emphasis should be placed on technique and 
>> working cleanly.
> 
> Sorry, I missed a bit. Why couldn't you plot animation by things driven by 
> ICE?  Don't you have to do that for expression, anim mixer, etc?  I mean you 
> don't have that in the engine either, right?
> 
> 

Re: Survey - how would you do this?

[Bradley Gabe]

In less than the amount of time you've spent on this thread, you could have 
written a simple script to bake out ICE particle SRT's, which would not only 
help in this situation, but a million and one others. :-)

Sent from my iPhone

> On Feb 12, 2014, at 12:35 PM, Matt Lind  wrote:
> 
> We'd have to add support for ICE in our exporter and pipeline management 
> tools.  We don't have resources to do that at present.
> 
> If the artist doesn't clean up after himself responsibly, it creates a lot of 
> problems.
> 
> 
> Matt
> 
> 
> 
> 
> 
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com 
> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric 
> Rousseau
> Sent: Wednesday, February 12, 2014 7:21 AM
> To: softimage@listproc.autodesk.com
> Subject: Re: Survey - how would you do this?
> 
>> On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind  wrote:
>> The solution is 100% art driven in this case and cannot rely on game 
>> engine logic or engineering resources.  If it could, there wouldn't be 
>> a challenge ;-)
>> 
>> Cannot use ICE, but you can use expressions, constraints, or animation mixer 
>> to set up and plot out to explicit controls later if you prefer.
>> 
>> A junior or staff level artist must be able to setup and complete the task 
>> unsupervised in 30 minutes or less.  Must also avoid creating any bugs such 
>> as leaving temporary data in the scene or methods that require such tactics. 
>>  Bugs that make their way into the game engine are very expensive to find, 
>> fix, and QA.  Therefore, great emphasis should be placed on technique and 
>> working cleanly.
> 
> Sorry, I missed a bit. Why couldn't you plot animation by things driven by 
> ICE?  Don't you have to do that for expression, anim mixer, etc?  I mean you 
> don't have that in the engine either, right?
> 
> 

RE: Survey - how would you do this?

[Matt Lind]

We'd have to add support for ICE in our exporter and pipeline management tools. 
 We don't have resources to do that at present.

If the artist doesn't clean up after himself responsibly, it creates a lot of 
problems.


Matt





-Original Message-
From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Wednesday, February 12, 2014 7:21 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind  wrote:
> The solution is 100% art driven in this case and cannot rely on game 
> engine logic or engineering resources.  If it could, there wouldn't be 
> a challenge ;-)
>
> Cannot use ICE, but you can use expressions, constraints, or animation mixer 
> to set up and plot out to explicit controls later if you prefer.
>
> A junior or staff level artist must be able to setup and complete the task 
> unsupervised in 30 minutes or less.  Must also avoid creating any bugs such 
> as leaving temporary data in the scene or methods that require such tactics.  
> Bugs that make their way into the game engine are very expensive to find, 
> fix, and QA.  Therefore, great emphasis should be placed on technique and 
> working cleanly.
>

Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? 
 Don't you have to do that for expression, anim mixer, etc?  I mean you don't 
have that in the engine either, right?