Re: Survey - how would you do this?

2014-02-17 Thread 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 angus.david...@wits.ac.za
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: Survey - how would you do this?

2014-02-14 Thread 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 
mirkoj.anima...@gmail.commailto:mirkoj.anima...@gmail.com
Reply-To: 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com
Date: Friday 14 February 2014 at 8:11 AM
To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto: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 
sebastien.sterl...@gmail.commailto: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.commailto: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 
ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote:
Below:


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

On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
ml...@carbinestudios.commailto: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

Re: Survey - how would you do this?

2014-02-14 Thread 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
angus.david...@wits.ac.zawrote:

 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
 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 car...@gmail.com 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 ?
 
 
 =
 table width=100% border=0 cellspacing=0 cellpadding=0
 style=width:100%;
 tr
 td align=left style=text-align:justify;font face=arial,sans-serif
 size=1 color=#99span 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.
 /span/font/td
 /tr
 /table





Re: Survey - how would you do this?

2014-02-14 Thread Luc-Eric Rousseau
On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
guillaume.laforge...@gmail.com 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?

2014-02-14 Thread 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 luceri...@gmail.comwrote:

 On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
 guillaume.laforge...@gmail.com 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?

2014-02-14 Thread 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 luceri...@gmail.comwrote:

 On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge
 guillaume.laforge...@gmail.com 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?

2014-02-14 Thread Luc-Eric Rousseau
On Thu, Feb 13, 2014 at 11:15 PM, Emilio Hernandez emi...@e-roja.com 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?

2014-02-14 Thread 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
guillaume.laforge...@gmail.com 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?

2014-02-14 Thread 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 
guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com
Reply-To: 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com
Date: Friday 14 February 2014 at 2:06 PM
To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto: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.zamailto: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.commailto:luceri...@gmail.com]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.commailto: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
guillaume.laforge...@gmail.commailto: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 
 car...@gmail.commailto:car...@gmail.com wrote:

 ya, i get that feeling too ;)

 its magical


 On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
 guillaume.laforge...@gmail.commailto: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 ?


=
table width=100% border=0 cellspacing=0 cellpadding=0 
style=width:100%;
tr
td align=left style=text-align:justify;font face=arial,sans-serif 
size=1 color=#99span 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. /span/font/td
/tr
/table




table width=100% border=0 cellspacing=0 cellpadding=0 
style=width:100%;
tr
td align=left style=text-align:justify;font face=arial,sans

Re: Survey - how would you do this?

2014-02-14 Thread 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
angus.david...@wits.ac.za 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?

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

2014-02-14 Thread 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 
guillaume.laforge...@gmail.com 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
ml...@carbinestudios.com 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
ml...@carbinestudios.com 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

Re: Survey - how would you do this?

2014-02-14 Thread 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 guillaume.laforge...@gmail.com 
mailto:guillaume.laforge...@gmail.com
Reply-To: softimage@listproc.autodesk.com 
mailto:softimage@listproc.autodesk.com 
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 
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 
angus.david...@wits.ac.za 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
guillaume.laforge...@gmail.com
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 car...@gmail.com
mailto:car...@gmail.com wrote:

 ya, i get that feeling too ;)

 its magical


 On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
 guillaume.laforge...@gmail.com
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 ?


=
table width=100% border=0 cellspacing=0 cellpadding=0
style=width:100%;
tr
td align=left style=text-align:justify;font
face=arial,sans-serif size=1 color=#99span
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

RE: Survey - how would you do this?

2014-02-14 Thread 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 
guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com
Reply-To: 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com
Date: Friday 14 February 2014 at 2:06 PM
To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto: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.zamailto: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.commailto:luceri...@gmail.com]
Sent: 14 February 2014 04:26 AM
To: softimage@listproc.autodesk.commailto: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
guillaume.laforge...@gmail.commailto: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 
 car...@gmail.commailto:car...@gmail.com wrote:

 ya, i get that feeling too ;)

 its magical


 On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge
 guillaume.laforge...@gmail.commailto: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 ?


=
table width=100% border=0 cellspacing=0 cellpadding=0 
style=width:100%;
tr
td align=left style=text-align:justify;font face=arial,sans-serif 
size=1 color=#99span 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

Re: Survey - how would you do this?

2014-02-14 Thread 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 angus.david...@wits.ac.za:

  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 guillaume.laforge...@gmail.com
 Reply-To: softimage@listproc.autodesk.com 
 softimage@listproc.autodesk.com
 Date: Friday 14 February 2014 at 2:06 PM
 To: softimage@listproc.autodesk.com 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
 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 car...@gmail.com wrote:
 
  ya, i get that feeling too ;)
 
  its magical
 
 
  On Thu, Feb 13, 2014 at 5:32 PM

Re: Survey - how would you do this?

2014-02-14 Thread 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?

2014-02-14 Thread 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?

2014-02-14 Thread 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 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] *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?

2014-02-14 Thread 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 guillaume.laforge...@gmail.com 
mailto:guillaume.laforge...@gmail.com
Reply-To: softimage@listproc.autodesk.com 
mailto:softimage@listproc.autodesk.com 
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 
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 
angus.david...@wits.ac.za 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
guillaume.laforge...@gmail.com
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 car...@gmail.com
mailto:car...@gmail.com wrote:

 ya, i get that feeling too ;)

 its magical


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

Re: Survey - how would you do this?

2014-02-14 Thread 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 xsi_l...@shaders.moederogall.comwrote:

  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 guillaume.laforge...@gmail.com
 Reply-To: softimage@listproc.autodesk.com 
 softimage@listproc.autodesk.com
 Date: Friday 14 February 2014 at 2:06 PM
 To: softimage@listproc.autodesk.com 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
 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 car...@gmail.com 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 ?
 
 
 =
 table width=100% border=0 cellspacing=0 cellpadding=0
 style=width:100%;
 tr
 td align=left style=text-align:justify;font
 face=arial,sans

RE: Survey - how would you do this?

2014-02-14 Thread 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.commailto:xsi_l...@shaders.moederogall.com]
Sent: 14 February 2014 07:45 PM
To: softimage@listproc.autodesk.commailto: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 
guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com
Reply-To: 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com
Date: Friday 14 February 2014 at 2:06 PM
To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com 
softimage@listproc.autodesk.commailto: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.zamailto: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

RE: Survey - how would you do this?

2014-02-14 Thread 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 
ml...@carbinestudios.commailto: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.commailto:softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM

To: softimage@listproc.autodesk.commailto: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?

2014-02-14 Thread 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 guillaume.laforge...@gmail.com 
mailto:guillaume.laforge...@gmail.com
Reply-To: softimage@listproc.autodesk.com 
mailto:softimage@listproc.autodesk.com 
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 
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 
angus.david...@wits.ac.za 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

Re: Survey - how would you do this?

2014-02-14 Thread 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 primitivedodecohedron, 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 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] *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 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] *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?

2014-02-14 Thread 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 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 primitivedodecohedron, 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 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] *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 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] *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?

2014-02-14 Thread 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 
tekano@gmail.commailto: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 primitivedodecohedron, 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 
ml...@carbinestudios.commailto: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.commailto:softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 12:19 PM

To: softimage@listproc.autodesk.commailto: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 
ml...@carbinestudios.commailto: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.commailto:softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM

To: softimage@listproc.autodesk.commailto: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

RE: Survey - how would you do this?

2014-02-14 Thread 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 
ml...@carbinestudios.commailto: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.commailto:softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Rob Chapman
Sent: Friday, February 14, 2014 11:57 AM

To: softimage@listproc.autodesk.commailto: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?



table width=100% border=0 cellspacing=0 cellpadding=0 
style=width:100%;
tr
td align=left style=text-align:justify;font face=arial,sans-serif 
size=1 color=#99span 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. /span/font/td
/tr
/table


Re: Survey - how would you do this?

2014-02-13 Thread 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 ml...@carbinestudios.comwrote:

 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

Re: Survey - how would you do this?

2014-02-13 Thread 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?

2014-02-13 Thread 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 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?

2014-02-13 Thread 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 ethivie...@hybride.com
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?

2014-02-13 Thread 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 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?

2014-02-13 Thread 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 
bauero...@gmx.demailto: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?

2014-02-13 Thread 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?

2014-02-13 Thread Steven Caron
2014... anything using ICE SDK in the array area broke.


On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.comwrote:

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

 Eric T.




Re: Survey - how would you do this?

2014-02-13 Thread 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
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?

2014-02-13 Thread 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 ethivie...@hybride.comwrote:

 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
 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?

2014-02-13 Thread 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
ethivie...@hybride.com 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
ethivie...@hybride.com 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?

2014-02-13 Thread 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 ethivie...@hybride.comwrote:

 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?

2014-02-13 Thread Matt Lind
 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:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe
Sent: Wednesday, February 12, 2014 5:47 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do

Re: Survey - how would you do this?

2014-02-13 Thread 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
ethivie...@hybride.com 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
ethivie...@hybride.com 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?

2014-02-13 Thread 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 
ethivie...@hybride.commailto: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.



--
inline: image001.gif

Re: Survey - how would you do this?

2014-02-13 Thread 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 pete...@skynet.be:

 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
 ethivie...@hybride.com 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
 ethivie...@hybride.com 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?

2014-02-13 Thread 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 ml...@carbinestudios.com 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?

2014-02-13 Thread 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 ml...@carbinestudios.com 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?

2014-02-13 Thread Luc-Eric Rousseau
On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind ml...@carbinestudios.com 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?

2014-02-13 Thread 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 ml...@carbinestudios.com 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?

2014-02-13 Thread 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 ml...@carbinestudios.com 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

Re: Survey - how would you do this?

2014-02-13 Thread 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 marc.brink...@microsoft.com 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 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

Re: Survey - how would you do this?

2014-02-13 Thread 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 graham.b...@autodesk.comwrote:


 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 marc.brink...@microsoft.com 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

RE: Survey - how would you do this?

2014-02-13 Thread 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 marc.brink...@microsoft.com 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

Re: Survey - how would you do this?

2014-02-13 Thread 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?

2014-02-13 Thread Luc-Eric Rousseau
On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 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.

 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?

2014-02-13 Thread 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 luceri...@gmail.comwrote:

 On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 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.

  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?

2014-02-13 Thread 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?

2014-02-13 Thread Guillaume Laforge
Don't forget to print the threads/coupons Steven !


On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com 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?

2014-02-13 Thread 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 car...@gmail.com 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?

2014-02-13 Thread 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 car...@gmail.com 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 car...@gmail.com 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?

2014-02-13 Thread 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
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 car...@gmail.com 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?

2014-02-13 Thread 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 luceri...@gmail.comwrote:

 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?

2014-02-13 Thread 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 luceri...@gmail.comwrote:

 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
 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 car...@gmail.com 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?

2014-02-13 Thread 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 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 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?

2014-02-13 Thread 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 ml...@carbinestudios.com 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 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 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?

2014-02-13 Thread 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 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 ml...@carbinestudios.comwrote:

 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 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 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?

2014-02-13 Thread 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 
guillaume.laforge...@gmail.commailto: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 
ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote:
Below:


-Original Message-
From: 
softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com
 
[mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com]
 On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind 
ml...@carbinestudios.commailto: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 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

Re: Survey - how would you do this?

2014-02-13 Thread 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 ml...@carbinestudios.com 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 ml...@carbinestudios.com
 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 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 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

Re: Survey - how would you do this?

2014-02-13 Thread 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 ml...@carbinestudios.comwrote:

 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 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 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?

2014-02-13 Thread 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 guillaume.laforge...@gmail.com
 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 ml...@carbinestudios.comwrote:

 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 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 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

Re: Survey - how would you do this?

2014-02-13 Thread 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 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 ml...@carbinestudios.comwrote:

 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 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

Re: Survey - how would you do this?

2014-02-13 Thread 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 emi...@e-roja.com 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 ml...@carbinestudios.comwrote:

 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 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

Re: Survey - how would you do this?

2014-02-13 Thread Emilio Hernandez
Take me in and I will distract the secretary!




2014-02-13 22:23 GMT-06:00 Sebastien Sterling sebastien.sterl...@gmail.com
:

 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 emi...@e-roja.com 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 ml...@carbinestudios.comwrote:

 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 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

RE: Survey - how would you do this?

2014-02-13 Thread 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
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 car...@gmail.com 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 ?


=
table width=100% border=0 cellspacing=0 cellpadding=0 
style=width:100%; 
tr
td align=left style=text-align:justify;font face=arial,sans-serif 
size=1 color=#99span 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. /span/font/td
/tr
/table




RE: Survey - how would you do this?

2014-02-13 Thread 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 
guillaume.laforge...@gmail.commailto: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 
car...@gmail.commailto:car...@gmail.com wrote:
ya, i get that feeling too ;)

its magical

On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge 
guillaume.laforge...@gmail.commailto: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?

2014-02-13 Thread 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 ml...@carbinestudios.comwrote:

 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 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 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

Re: Survey - how would you do this?

2014-02-12 Thread Luc-Eric Rousseau
On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com 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?

2014-02-12 Thread Jeffrey Dates
Hmm..  I don't know why.. I must not understand the challenge.  How I'd do
it is:

1) duplicate your astroid(s)  ( in this case not instances for
art-direction )  # of times you want.
2) select all, and path constrain to a Circle Curve. ( roughly 40 units )
3) Multi-select their constraint, and set the length to r(0,100)
4) Then set the translation along the bias, and normal to be r(-5,5)
 you'll have to play with the values to get a proper dispersion.
5) now you have a ring of astroids randomly distributed along a torus.

You can animate the ring to get them all moving.
You can set keys using the random property...

*shrug*  I must not fully understand the problem.


On Tue, Feb 11, 2014 at 2:23 PM, Matt Lind ml...@carbinestudios.com wrote:

 An artist came to my desk yesterday asking how to do what I felt was a
 simple task, but after getting 80% through it I ran into a speed bump
 realizing it needed custom scripting or other advanced tools to fully
 resolve to satisfaction.  I had to give him a procedure that was 'good
 enough'.  This problem has multiple solutions, but I am curious how others
 would solve it:



 The problem:



 Artist must create an asteroid belt around a planet.  The asteroids are
 likely 2D sprites which must face the camera and tumble as they orbit, but
 could be 3D objects as well.  Asteroids must vary in size, shape, and
 animation speed (linear as well as rotational).  Asteroids cannot collide
 with anything.  Movement is generally slow - like a screen saver for your
 computer desktop.  Asteroid positions are jittered within the belt.



 The question:



 Dispersing objects into a ring is fairly straightforward through a number
 of techniques, but how do you apply the random jitter to the object
 positions?



 The rules:



 -  Cannot use ICE

 -  Cannot use custom scripts, custom operators, or shaders.

 -  Must only use tools out of the box that a junior or staff
 level artist would know how to use.

 -  Must be able to create the asteroid belt, from scratch to
 completion, in less than 30 minutes - and be iteration friendly to react to
 art director feedback.

 -  Ideally, the belt could be made a child of the planet in
 encompasses so it can be reoriented with respect to changes in the planet's
 size/shape/tilt/orbit.

 -  Final output must be able to exist with full integrity on its
 own in a vacuum.  Cannot not have dependencies on custom code, external
 assets, or special case logic.

 -  Asteroid belt fits within the default grid as seen in the
 scene camera.  Think torus with diameter 40 SI units, and cross section of
 roughly 3 SI Units diameter





 Ready.GO!









 Matt



Re: Survey - how would you do this?

2014-02-12 Thread Enrique Caballero
id go with what jeffrey said, but that doesnt protect against collisions.

honestly, im using ICE alot with Unity. No biggy,

If your working with a pointcloud, just take that data along with ice
kinematics, and plot the information out onto the actual assets. then
export to the game. I think you can still use ice and then just bake that
out to a game


On Wed, Feb 12, 2014 at 11:37 PM, Jeffrey Dates jda...@kungfukoi.comwrote:

 Hmm..  I don't know why.. I must not understand the challenge.  How I'd do
 it is:

 1) duplicate your astroid(s)  ( in this case not instances for
 art-direction )  # of times you want.
 2) select all, and path constrain to a Circle Curve. ( roughly 40 units )
 3) Multi-select their constraint, and set the length to r(0,100)
 4) Then set the translation along the bias, and normal to be r(-5,5)
  you'll have to play with the values to get a proper dispersion.
 5) now you have a ring of astroids randomly distributed along a torus.

 You can animate the ring to get them all moving.
 You can set keys using the random property...

 *shrug*  I must not fully understand the problem.


 On Tue, Feb 11, 2014 at 2:23 PM, Matt Lind ml...@carbinestudios.comwrote:

 An artist came to my desk yesterday asking how to do what I felt was a
 simple task, but after getting 80% through it I ran into a speed bump
 realizing it needed custom scripting or other advanced tools to fully
 resolve to satisfaction.  I had to give him a procedure that was 'good
 enough'.  This problem has multiple solutions, but I am curious how others
 would solve it:



 The problem:



 Artist must create an asteroid belt around a planet.  The asteroids are
 likely 2D sprites which must face the camera and tumble as they orbit, but
 could be 3D objects as well.  Asteroids must vary in size, shape, and
 animation speed (linear as well as rotational).  Asteroids cannot collide
 with anything.  Movement is generally slow - like a screen saver for your
 computer desktop.  Asteroid positions are jittered within the belt.



 The question:



 Dispersing objects into a ring is fairly straightforward through a number
 of techniques, but how do you apply the random jitter to the object
 positions?



 The rules:



 -  Cannot use ICE

 -  Cannot use custom scripts, custom operators, or shaders.

 -  Must only use tools out of the box that a junior or staff
 level artist would know how to use.

 -  Must be able to create the asteroid belt, from scratch to
 completion, in less than 30 minutes - and be iteration friendly to react to
 art director feedback.

 -  Ideally, the belt could be made a child of the planet in
 encompasses so it can be reoriented with respect to changes in the planet's
 size/shape/tilt/orbit.

 -  Final output must be able to exist with full integrity on its
 own in a vacuum.  Cannot not have dependencies on custom code, external
 assets, or special case logic.

 -  Asteroid belt fits within the default grid as seen in the
 scene camera.  Think torus with diameter 40 SI units, and cross section of
 roughly 3 SI Units diameter





 Ready.GO!









 Matt





RE: Survey - how would you do this?

2014-02-12 Thread 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 ml...@carbinestudios.com 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?

2014-02-12 Thread 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 ml...@carbinestudios.com 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 ml...@carbinestudios.com 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?

2014-02-12 Thread 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 ml...@carbinestudios.com 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 ml...@carbinestudios.com 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?

2014-02-12 Thread 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 ml...@carbinestudios.com 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?

2014-02-12 Thread 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?

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

2014-02-12 Thread 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 ml...@carbinestudios.com 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

Re: Survey - how would you do this?

2014-02-12 Thread 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 ml...@carbinestudios.com 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-
 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 ml...@carbinestudios.com wrote:
 The solution is 100% art driven in this case and cannot rely on game 
 engine logic

Re: Survey - how would you do this?

2014-02-11 Thread Eric Thivierge
With those restrictions, get a super fast animator to animate them by 
hand.


Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:

An artist came to my desk yesterday asking how to do what I felt was a
simple task, but after getting 80% through it I ran into a speed bump
realizing it needed custom scripting or other advanced tools to fully
resolve to satisfaction.  I had to give him a procedure that was ‘good
enough’.  This problem has multiple solutions, but I am curious how
others would solve it:

The problem:

Artist must create an asteroid belt around a planet.  The asteroids
are likely 2D sprites which must face the camera and tumble as they
orbit, but could be 3D objects as well.  Asteroids must vary in size,
shape, and animation speed (linear as well as rotational).  Asteroids
cannot collide with anything.  Movement is generally slow – like a
screen saver for your computer desktop.  Asteroid positions are
jittered within the belt.

The question:

Dispersing objects into a ring is fairly straightforward through a
number of techniques, but how do you apply the random jitter to the
object positions?

The rules:

-Cannot use ICE

-Cannot use custom scripts, custom operators, or shaders.

-Must only use tools out of the box that a junior or staff level
artist would know how to use.

-Must be able to create the asteroid belt, from scratch to completion,
in less than 30 minutes – and be iteration friendly to react to art
director feedback.

-Ideally, the belt could be made a child of the planet in encompasses
so it can be reoriented with respect to changes in the planet’s
size/shape/tilt/orbit.

-Final output must be able to exist with full integrity on its own in
a vacuum.  Cannot not have dependencies on custom code, external
assets, or special case logic.

-Asteroid belt fits within the default grid as seen in the scene
camera.  Think torus with diameter 40 SI units, and cross section of
roughly 3 SI Units diameter

Ready…..GO!

Matt





Re: Survey - how would you do this?

2014-02-11 Thread Helge Mathee

use Fabric. but I guess that's considered custom. :-)

On 2/11/2014 8:46 PM, Eric Thivierge wrote:
With those restrictions, get a super fast animator to animate them by 
hand.


Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:

An artist came to my desk yesterday asking how to do what I felt was a
simple task, but after getting 80% through it I ran into a speed bump
realizing it needed custom scripting or other advanced tools to fully
resolve to satisfaction.  I had to give him a procedure that was ‘good
enough’.  This problem has multiple solutions, but I am curious how
others would solve it:

The problem:

Artist must create an asteroid belt around a planet.  The asteroids
are likely 2D sprites which must face the camera and tumble as they
orbit, but could be 3D objects as well.  Asteroids must vary in size,
shape, and animation speed (linear as well as rotational). Asteroids
cannot collide with anything.  Movement is generally slow – like a
screen saver for your computer desktop.  Asteroid positions are
jittered within the belt.

The question:

Dispersing objects into a ring is fairly straightforward through a
number of techniques, but how do you apply the random jitter to the
object positions?

The rules:

-Cannot use ICE

-Cannot use custom scripts, custom operators, or shaders.

-Must only use tools out of the box that a junior or staff level
artist would know how to use.

-Must be able to create the asteroid belt, from scratch to completion,
in less than 30 minutes – and be iteration friendly to react to art
director feedback.

-Ideally, the belt could be made a child of the planet in encompasses
so it can be reoriented with respect to changes in the planet’s
size/shape/tilt/orbit.

-Final output must be able to exist with full integrity on its own in
a vacuum.  Cannot not have dependencies on custom code, external
assets, or special case logic.

-Asteroid belt fits within the default grid as seen in the scene
camera.  Think torus with diameter 40 SI units, and cross section of
roughly 3 SI Units diameter

Ready…..GO!

Matt







RE: Survey - how would you do this?

2014-02-11 Thread Matt Lind
You wouldn't last long in games with that attitude.


Matt




-Original Message-
From: Eric Thivierge [mailto:ethivie...@hybride.com] 
Sent: Tuesday, February 11, 2014 11:46 AM
To: softimage@listproc.autodesk.com
Cc: Matt Lind
Subject: Re: Survey - how would you do this?

With those restrictions, get a super fast animator to animate them by hand.

Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
 An artist came to my desk yesterday asking how to do what I felt was a 
 simple task, but after getting 80% through it I ran into a speed bump 
 realizing it needed custom scripting or other advanced tools to fully 
 resolve to satisfaction.  I had to give him a procedure that was ‘good 
 enough’.  This problem has multiple solutions, but I am curious how 
 others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids 
 are likely 2D sprites which must face the camera and tumble as they 
 orbit, but could be 3D objects as well.  Asteroids must vary in size, 
 shape, and animation speed (linear as well as rotational).  Asteroids 
 cannot collide with anything.  Movement is generally slow – like a 
 screen saver for your computer desktop.  Asteroid positions are 
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a 
 number of techniques, but how do you apply the random jitter to the 
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level 
 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to completion, 
 in less than 30 minutes – and be iteration friendly to react to art 
 director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses 
 so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in 
 a vacuum.  Cannot not have dependencies on custom code, external 
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of 
 roughly 3 SI Units diameter

 Ready…..GO!

 Matt





RE: Survey - how would you do this?

2014-02-11 Thread Ponthieux, Joseph G. (LARC-E1A)[LITES]
Wouldn't restricting use of ICE mean you have no access to the out of the box 
particle tools?

--
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 Eric Thivierge
Sent: Tuesday, February 11, 2014 2:46 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

With those restrictions, get a super fast animator to animate them by hand.

Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
 An artist came to my desk yesterday asking how to do what I felt was a 
 simple task, but after getting 80% through it I ran into a speed bump 
 realizing it needed custom scripting or other advanced tools to fully 
 resolve to satisfaction.  I had to give him a procedure that was ‘good 
 enough’.  This problem has multiple solutions, but I am curious how 
 others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids 
 are likely 2D sprites which must face the camera and tumble as they 
 orbit, but could be 3D objects as well.  Asteroids must vary in size, 
 shape, and animation speed (linear as well as rotational).  Asteroids 
 cannot collide with anything.  Movement is generally slow – like a 
 screen saver for your computer desktop.  Asteroid positions are 
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a 
 number of techniques, but how do you apply the random jitter to the 
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level 
 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to completion, 
 in less than 30 minutes – and be iteration friendly to react to art 
 director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses 
 so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in 
 a vacuum.  Cannot not have dependencies on custom code, external 
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of 
 roughly 3 SI Units diameter

 Ready…..GO!

 Matt





Re: Survey - how would you do this?

2014-02-11 Thread Bradley Gabe
Considering that the typical distance from one asteroid to the next is many 
thousands of kilometers,  you really shouldn't have any issues with collisions 
if you scale them properly. 

At your scale of 40 SI units for the asteroid belt, each asteroid would be well 
sub-pixel in diameter anyway, so I would create a torus to represent the belt, 
make it only very slightly opaque and call it a day. 


Sent from my iPhone

 On Feb 11, 2014, at 1:23 PM, Matt Lind ml...@carbinestudios.com wrote:
 
 An artist came to my desk yesterday asking how to do what I felt was a simple 
 task, but after getting 80% through it I ran into a speed bump realizing it 
 needed custom scripting or other advanced tools to fully resolve to 
 satisfaction.  I had to give him a procedure that was ‘good enough’.  This 
 problem has multiple solutions, but I am curious how others would solve it:
  
 The problem:
  
 Artist must create an asteroid belt around a planet.  The asteroids are 
 likely 2D sprites which must face the camera and tumble as they orbit, but 
 could be 3D objects as well.  Asteroids must vary in size, shape, and 
 animation speed (linear as well as rotational).  Asteroids cannot collide 
 with anything.  Movement is generally slow – like a screen saver for your 
 computer desktop.  Asteroid positions are jittered within the belt.
  
 The question:
  
 Dispersing objects into a ring is fairly straightforward through a number of 
 techniques, but how do you apply the random jitter to the object positions?
  
 The rules:
  
 -  Cannot use ICE
 -  Cannot use custom scripts, custom operators, or shaders.
 -  Must only use tools out of the box that a junior or staff level 
 artist would know how to use.
 -  Must be able to create the asteroid belt, from scratch to 
 completion, in less than 30 minutes – and be iteration friendly to react to 
 art director feedback.
 -  Ideally, the belt could be made a child of the planet in 
 encompasses so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.
 -  Final output must be able to exist with full integrity on its own 
 in a vacuum.  Cannot not have dependencies on custom code, external assets, 
 or special case logic.
 -  Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of roughly 
 3 SI Units diameter
  
  
 Ready…..GO!
  
  
  
  
 Matt


RE: Survey - how would you do this?

2014-02-11 Thread Matt Lind
F*ck.  Fat finger.

The rest:

We have tight restrictions for making MMORPG style games.  One of them being we 
have to think simple as there's no way to fully predict how an asset will be 
used once it's made available in the game.  Designers and scripters will pull 
whatever they can get their hands on and use them for whatever purpose they can 
think of.  Kind of the everything looks like a nail when you have a hammer 
problem.

Matt



-Original Message-
From: Matt Lind 
Sent: Tuesday, February 11, 2014 11:47 AM
To: 'Eric Thivierge'; softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

You wouldn't last long in games with that attitude.


Matt




-Original Message-
From: Eric Thivierge [mailto:ethivie...@hybride.com]
Sent: Tuesday, February 11, 2014 11:46 AM
To: softimage@listproc.autodesk.com
Cc: Matt Lind
Subject: Re: Survey - how would you do this?

With those restrictions, get a super fast animator to animate them by hand.

Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
 An artist came to my desk yesterday asking how to do what I felt was a 
 simple task, but after getting 80% through it I ran into a speed bump 
 realizing it needed custom scripting or other advanced tools to fully 
 resolve to satisfaction.  I had to give him a procedure that was ‘good 
 enough’.  This problem has multiple solutions, but I am curious how 
 others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids 
 are likely 2D sprites which must face the camera and tumble as they 
 orbit, but could be 3D objects as well.  Asteroids must vary in size, 
 shape, and animation speed (linear as well as rotational).  Asteroids 
 cannot collide with anything.  Movement is generally slow – like a 
 screen saver for your computer desktop.  Asteroid positions are 
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a 
 number of techniques, but how do you apply the random jitter to the 
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level 
 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to completion, 
 in less than 30 minutes – and be iteration friendly to react to art 
 director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses 
 so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in 
 a vacuum.  Cannot not have dependencies on custom code, external 
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of 
 roughly 3 SI Units diameter

 Ready…..GO!

 Matt





Re: Survey - how would you do this?

2014-02-11 Thread Eric Thivierge

Are all games made in an environment from what seems to be the early 90's?

And true I probably wouldn't last long in games. I like using new 
technology too much. :)


Eric T.

On 2/11/2014 2:47 PM, Matt Lind wrote:

You wouldn't last long in games with that attitude.


Matt




-Original Message-
From: Eric Thivierge [mailto:ethivie...@hybride.com]
Sent: Tuesday, February 11, 2014 11:46 AM
To: softimage@listproc.autodesk.com
Cc: Matt Lind
Subject: Re: Survey - how would you do this?

With those restrictions, get a super fast animator to animate them by hand.

Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:

An artist came to my desk yesterday asking how to do what I felt was a
simple task, but after getting 80% through it I ran into a speed bump
realizing it needed custom scripting or other advanced tools to fully
resolve to satisfaction.  I had to give him a procedure that was ‘good
enough’.  This problem has multiple solutions, but I am curious how
others would solve it:

The problem:

Artist must create an asteroid belt around a planet.  The asteroids
are likely 2D sprites which must face the camera and tumble as they
orbit, but could be 3D objects as well.  Asteroids must vary in size,
shape, and animation speed (linear as well as rotational).  Asteroids
cannot collide with anything.  Movement is generally slow – like a
screen saver for your computer desktop.  Asteroid positions are
jittered within the belt.

The question:

Dispersing objects into a ring is fairly straightforward through a
number of techniques, but how do you apply the random jitter to the
object positions?

The rules:

-Cannot use ICE

-Cannot use custom scripts, custom operators, or shaders.

-Must only use tools out of the box that a junior or staff level
artist would know how to use.

-Must be able to create the asteroid belt, from scratch to completion,
in less than 30 minutes – and be iteration friendly to react to art
director feedback.

-Ideally, the belt could be made a child of the planet in encompasses
so it can be reoriented with respect to changes in the planet’s
size/shape/tilt/orbit.

-Final output must be able to exist with full integrity on its own in
a vacuum.  Cannot not have dependencies on custom code, external
assets, or special case logic.

-Asteroid belt fits within the default grid as seen in the scene
camera.  Think torus with diameter 40 SI units, and cross section of
roughly 3 SI Units diameter

Ready…..GO!

Matt






Re: Survey - how would you do this?

2014-02-11 Thread Ed Manning
re: collision avoidance -- how big are the asteroids WRT the toroidal
volume?  the requirement for varying linear (meaning orbital I guess?)
speeds needs to be balanced against the volume of space that each sweeps
through.

the position jitter I guess I would try to do via clever parenting and use
of the randomize data entry command for transform values.


On Tue, Feb 11, 2014 at 2:46 PM, Eric Thivierge ethivie...@hybride.comwrote:

 With those restrictions, get a super fast animator to animate them by hand.

 Eric T.


 On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:

 An artist came to my desk yesterday asking how to do what I felt was a
 simple task, but after getting 80% through it I ran into a speed bump
 realizing it needed custom scripting or other advanced tools to fully
 resolve to satisfaction.  I had to give him a procedure that was 'good
 enough'.  This problem has multiple solutions, but I am curious how
 others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids
 are likely 2D sprites which must face the camera and tumble as they
 orbit, but could be 3D objects as well.  Asteroids must vary in size,
 shape, and animation speed (linear as well as rotational).  Asteroids
 cannot collide with anything.  Movement is generally slow - like a
 screen saver for your computer desktop.  Asteroid positions are
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a
 number of techniques, but how do you apply the random jitter to the
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level

 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to completion,

 in less than 30 minutes - and be iteration friendly to react to art
 director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses

 so it can be reoriented with respect to changes in the planet's
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in

 a vacuum.  Cannot not have dependencies on custom code, external
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene

 camera.  Think torus with diameter 40 SI units, and cross section of
 roughly 3 SI Units diameter

 Ready.GO!

 Matt





RE: Survey - how would you do this?

2014-02-11 Thread Matt Lind
Softimage doesn't have a particle system anymore.  ICE replaced it.

To answer your question - yes.


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: Tuesday, February 11, 2014 11:48 AM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

Wouldn't restricting use of ICE mean you have no access to the out of the box 
particle tools?

--
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 Eric Thivierge
Sent: Tuesday, February 11, 2014 2:46 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

With those restrictions, get a super fast animator to animate them by hand.

Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
 An artist came to my desk yesterday asking how to do what I felt was a 
 simple task, but after getting 80% through it I ran into a speed bump 
 realizing it needed custom scripting or other advanced tools to fully 
 resolve to satisfaction.  I had to give him a procedure that was ‘good 
 enough’.  This problem has multiple solutions, but I am curious how 
 others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids 
 are likely 2D sprites which must face the camera and tumble as they 
 orbit, but could be 3D objects as well.  Asteroids must vary in size, 
 shape, and animation speed (linear as well as rotational).  Asteroids 
 cannot collide with anything.  Movement is generally slow – like a 
 screen saver for your computer desktop.  Asteroid positions are 
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a 
 number of techniques, but how do you apply the random jitter to the 
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level 
 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to completion, 
 in less than 30 minutes – and be iteration friendly to react to art 
 director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses 
 so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in 
 a vacuum.  Cannot not have dependencies on custom code, external 
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of 
 roughly 3 SI Units diameter

 Ready…..GO!

 Matt






RE: Survey - how would you do this?

2014-02-11 Thread Ponthieux, Joseph G. (LARC-E1A)[LITES]
No ICE huh..

I know! I know! Go to the grocery store. Buy a pack of lunch meat, the 
smelliest cheese you can find, and some monkey bread. Return to work and make 
your lunch from the ingredients. Whilst everyone is running away from the smell 
of the cheese, cheat and use ICE. 

I know, I broke the spirit of the challenge. Guilty as charged. But I bet Ed 
liked the solution.

:)

--
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: Tuesday, February 11, 2014 2:54 PM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

Softimage doesn't have a particle system anymore.  ICE replaced it.

To answer your question - yes.


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: Tuesday, February 11, 2014 11:48 AM
To: softimage@listproc.autodesk.com
Subject: RE: Survey - how would you do this?

Wouldn't restricting use of ICE mean you have no access to the out of the box 
particle tools?

--
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 Eric Thivierge
Sent: Tuesday, February 11, 2014 2:46 PM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

With those restrictions, get a super fast animator to animate them by hand.

Eric T.

On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
 An artist came to my desk yesterday asking how to do what I felt was a 
 simple task, but after getting 80% through it I ran into a speed bump 
 realizing it needed custom scripting or other advanced tools to fully 
 resolve to satisfaction.  I had to give him a procedure that was ‘good 
 enough’.  This problem has multiple solutions, but I am curious how 
 others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids 
 are likely 2D sprites which must face the camera and tumble as they 
 orbit, but could be 3D objects as well.  Asteroids must vary in size, 
 shape, and animation speed (linear as well as rotational).  Asteroids 
 cannot collide with anything.  Movement is generally slow – like a 
 screen saver for your computer desktop.  Asteroid positions are 
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a 
 number of techniques, but how do you apply the random jitter to the 
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level 
 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to completion, 
 in less than 30 minutes – and be iteration friendly to react to art 
 director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses 
 so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in 
 a vacuum.  Cannot not have dependencies on custom code, external 
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of 
 roughly 3 SI Units diameter

 Ready…..GO!

 Matt







RE: Survey - how would you do this?

2014-02-11 Thread Matt Lind
The focus in games is to make software that is entertaining for our customers.  
Much of the problem solving in 3D is on the engine side.

On the content creation side, such as in Softimage, the focus is to integrate 
or mimic the engine or find ways of efficiently getting data to/from the 
engine.  The critical part is to abstract game specific data so it is not tied 
to the content creation software, and inversely abstract the content creation 
software's isms from making it into the game engine.  Do this while still 
providing an environment that artists can work quickly and efficiently.  Not as 
easy as it sounds.

The problem that is most encountered in Softimage and other 3D apps is you 
can't go low level enough to do what you need.  Softimage doesn't really 
support custom classes and data structures as first class citizens in their 
API.  Therefore, most implementations of toolsets are working around those 
limitations which often requires venturing into the dusty corners of the 
software where few people travel resulting in discovery of many bugs preventing 
you from reaching your goals.

As for making games, it taxes your brain a lot more than film/video to figure 
out how to pull off an effect or implement an idea.  Basically, your MacGyver 
skills are really put to the test.

Matt




-Original Message-
From: Eric Thivierge [mailto:ethivie...@hybride.com] 
Sent: Tuesday, February 11, 2014 11:50 AM
To: Matt Lind; softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Are all games made in an environment from what seems to be the early 90's?

And true I probably wouldn't last long in games. I like using new technology 
too much. :)

Eric T.

On 2/11/2014 2:47 PM, Matt Lind wrote:
 You wouldn't last long in games with that attitude.


 Matt




 -Original Message-
 From: Eric Thivierge [mailto:ethivie...@hybride.com]
 Sent: Tuesday, February 11, 2014 11:46 AM
 To: softimage@listproc.autodesk.com
 Cc: Matt Lind
 Subject: Re: Survey - how would you do this?

 With those restrictions, get a super fast animator to animate them by hand.

 Eric T.

 On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
 An artist came to my desk yesterday asking how to do what I felt was 
 a simple task, but after getting 80% through it I ran into a speed 
 bump realizing it needed custom scripting or other advanced tools to 
 fully resolve to satisfaction.  I had to give him a procedure that 
 was ‘good enough’.  This problem has multiple solutions, but I am 
 curious how others would solve it:

 The problem:

 Artist must create an asteroid belt around a planet.  The asteroids 
 are likely 2D sprites which must face the camera and tumble as they 
 orbit, but could be 3D objects as well.  Asteroids must vary in size, 
 shape, and animation speed (linear as well as rotational).  Asteroids 
 cannot collide with anything.  Movement is generally slow – like a 
 screen saver for your computer desktop.  Asteroid positions are 
 jittered within the belt.

 The question:

 Dispersing objects into a ring is fairly straightforward through a 
 number of techniques, but how do you apply the random jitter to the 
 object positions?

 The rules:

 -Cannot use ICE

 -Cannot use custom scripts, custom operators, or shaders.

 -Must only use tools out of the box that a junior or staff level 
 artist would know how to use.

 -Must be able to create the asteroid belt, from scratch to 
 completion, in less than 30 minutes – and be iteration friendly to 
 react to art director feedback.

 -Ideally, the belt could be made a child of the planet in encompasses 
 so it can be reoriented with respect to changes in the planet’s 
 size/shape/tilt/orbit.

 -Final output must be able to exist with full integrity on its own in 
 a vacuum.  Cannot not have dependencies on custom code, external 
 assets, or special case logic.

 -Asteroid belt fits within the default grid as seen in the scene 
 camera.  Think torus with diameter 40 SI units, and cross section of 
 roughly 3 SI Units diameter

 Ready…..GO!

 Matt






RE: Survey - how would you do this?

2014-02-11 Thread Matt Lind
I should probably mention we don’t do realism here.  Think comic book style 
with a little Anime thrown in.

Given the dimensions of the belt, asteroids could be up to 1 SI unit in 
diameter for the really large rocks.  The camera might move through this belt, 
so the fact they’re small shouldn’t be so readily dismissed.  This isn’t 
film/video where you can sweep the stuff you don’t see under the carpet.


Matt






From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe
Sent: Tuesday, February 11, 2014 11:48 AM
To: softimage@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

Considering that the typical distance from one asteroid to the next is many 
thousands of kilometers,  you really shouldn't have any issues with collisions 
if you scale them properly.

At your scale of 40 SI units for the asteroid belt, each asteroid would be well 
sub-pixel in diameter anyway, so I would create a torus to represent the belt, 
make it only very slightly opaque and call it a day.


Sent from my iPhone

On Feb 11, 2014, at 1:23 PM, Matt Lind 
ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote:
An artist came to my desk yesterday asking how to do what I felt was a simple 
task, but after getting 80% through it I ran into a speed bump realizing it 
needed custom scripting or other advanced tools to fully resolve to 
satisfaction.  I had to give him a procedure that was ‘good enough’.  This 
problem has multiple solutions, but I am curious how others would solve it:

The problem:

Artist must create an asteroid belt around a planet.  The asteroids are likely 
2D sprites which must face the camera and tumble as they orbit, but could be 3D 
objects as well.  Asteroids must vary in size, shape, and animation speed 
(linear as well as rotational).  Asteroids cannot collide with anything.  
Movement is generally slow – like a screen saver for your computer desktop.  
Asteroid positions are jittered within the belt.

The question:

Dispersing objects into a ring is fairly straightforward through a number of 
techniques, but how do you apply the random jitter to the object positions?

The rules:


-  Cannot use ICE

-  Cannot use custom scripts, custom operators, or shaders.

-  Must only use tools out of the box that a junior or staff level 
artist would know how to use.

-  Must be able to create the asteroid belt, from scratch to 
completion, in less than 30 minutes – and be iteration friendly to react to art 
director feedback.

-  Ideally, the belt could be made a child of the planet in encompasses 
so it can be reoriented with respect to changes in the planet’s 
size/shape/tilt/orbit.

-  Final output must be able to exist with full integrity on its own in 
a vacuum.  Cannot not have dependencies on custom code, external assets, or 
special case logic.

-  Asteroid belt fits within the default grid as seen in the scene 
camera.  Think torus with diameter 40 SI units, and cross section of roughly 3 
SI Units diameter


Ready…..GO!




Matt


Re: Survey - how would you do this?

2014-02-11 Thread Chris Johnson
I have to plus one on the hand animation...do a couple meteors on a circle
scale each one a litte differently. Duplicate that a number of time and
offset that. Then look for nasty collisions...done.


On Tue, Feb 11, 2014 at 3:01 PM, Matt Lind ml...@carbinestudios.com wrote:

 The focus in games is to make software that is entertaining for our
 customers.  Much of the problem solving in 3D is on the engine side.

 On the content creation side, such as in Softimage, the focus is to
 integrate or mimic the engine or find ways of efficiently getting data
 to/from the engine.  The critical part is to abstract game specific data so
 it is not tied to the content creation software, and inversely abstract the
 content creation software's isms from making it into the game engine.  Do
 this while still providing an environment that artists can work quickly and
 efficiently.  Not as easy as it sounds.

 The problem that is most encountered in Softimage and other 3D apps is you
 can't go low level enough to do what you need.  Softimage doesn't really
 support custom classes and data structures as first class citizens in their
 API.  Therefore, most implementations of toolsets are working around those
 limitations which often requires venturing into the dusty corners of the
 software where few people travel resulting in discovery of many bugs
 preventing you from reaching your goals.

 As for making games, it taxes your brain a lot more than film/video to
 figure out how to pull off an effect or implement an idea.  Basically, your
 MacGyver skills are really put to the test.

 Matt




 -Original Message-
 From: Eric Thivierge [mailto:ethivie...@hybride.com]
 Sent: Tuesday, February 11, 2014 11:50 AM
 To: Matt Lind; softimage@listproc.autodesk.com
 Subject: Re: Survey - how would you do this?

 Are all games made in an environment from what seems to be the early 90's?

 And true I probably wouldn't last long in games. I like using new
 technology too much. :)

 Eric T.

 On 2/11/2014 2:47 PM, Matt Lind wrote:
  You wouldn't last long in games with that attitude.
 
 
  Matt
 
 
 
 
  -Original Message-
  From: Eric Thivierge [mailto:ethivie...@hybride.com]
  Sent: Tuesday, February 11, 2014 11:46 AM
  To: softimage@listproc.autodesk.com
  Cc: Matt Lind
  Subject: Re: Survey - how would you do this?
 
  With those restrictions, get a super fast animator to animate them by
 hand.
 
  Eric T.
 
  On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote:
  An artist came to my desk yesterday asking how to do what I felt was
  a simple task, but after getting 80% through it I ran into a speed
  bump realizing it needed custom scripting or other advanced tools to
  fully resolve to satisfaction.  I had to give him a procedure that
  was 'good enough'.  This problem has multiple solutions, but I am
  curious how others would solve it:
 
  The problem:
 
  Artist must create an asteroid belt around a planet.  The asteroids
  are likely 2D sprites which must face the camera and tumble as they
  orbit, but could be 3D objects as well.  Asteroids must vary in size,
  shape, and animation speed (linear as well as rotational).  Asteroids
  cannot collide with anything.  Movement is generally slow - like a
  screen saver for your computer desktop.  Asteroid positions are
  jittered within the belt.
 
  The question:
 
  Dispersing objects into a ring is fairly straightforward through a
  number of techniques, but how do you apply the random jitter to the
  object positions?
 
  The rules:
 
  -Cannot use ICE
 
  -Cannot use custom scripts, custom operators, or shaders.
 
  -Must only use tools out of the box that a junior or staff level
  artist would know how to use.
 
  -Must be able to create the asteroid belt, from scratch to
  completion, in less than 30 minutes - and be iteration friendly to
  react to art director feedback.
 
  -Ideally, the belt could be made a child of the planet in encompasses
  so it can be reoriented with respect to changes in the planet's
  size/shape/tilt/orbit.
 
  -Final output must be able to exist with full integrity on its own in
  a vacuum.  Cannot not have dependencies on custom code, external
  assets, or special case logic.
 
  -Asteroid belt fits within the default grid as seen in the scene
  camera.  Think torus with diameter 40 SI units, and cross section of
  roughly 3 SI Units diameter
 
  Ready.GO!
 
  Matt
 






Re: Survey - how would you do this?

2014-02-11 Thread Emilio Hernandez
Well, a quick solution will be

1. create a group of asteroids and add the animation of the asteroids.
2. create the torus that will hold up the asteroids belt.
3. Instanciate the group of asteroids.
4. Create a object to cluster constrain of the asteroids group in dispersed
points in the torus.
5. Randomize the torus to create the jittering of the position of the
asteroids group.
6. Animate the rotation of the torus.





2014-02-11 14:06 GMT-06:00 Matt Lind ml...@carbinestudios.com:

 I should probably mention we don't do realism here.  Think comic book
 style with a little Anime thrown in.



 Given the dimensions of the belt, asteroids could be up to 1 SI unit in
 diameter for the really large rocks.  The camera might move through this
 belt, so the fact they're small shouldn't be so readily dismissed.  This
 isn't film/video where you can sweep the stuff you don't see under the
 carpet.





 Matt













 *From:* softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] *On Behalf Of *Bradley Gabe
 *Sent:* Tuesday, February 11, 2014 11:48 AM
 *To:* softimage@listproc.autodesk.com

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



 Considering that the typical distance from one asteroid to the next is
 many thousands of kilometers,  you really shouldn't have any issues with
 collisions if you scale them properly.



 At your scale of 40 SI units for the asteroid belt, each asteroid would be
 well sub-pixel in diameter anyway, so I would create a torus to represent
 the belt, make it only very slightly opaque and call it a day.



 Sent from my iPhone


 On Feb 11, 2014, at 1:23 PM, Matt Lind ml...@carbinestudios.com wrote:

 An artist came to my desk yesterday asking how to do what I felt was a
 simple task, but after getting 80% through it I ran into a speed bump
 realizing it needed custom scripting or other advanced tools to fully
 resolve to satisfaction.  I had to give him a procedure that was 'good
 enough'.  This problem has multiple solutions, but I am curious how others
 would solve it:



 The problem:



 Artist must create an asteroid belt around a planet.  The asteroids are
 likely 2D sprites which must face the camera and tumble as they orbit, but
 could be 3D objects as well.  Asteroids must vary in size, shape, and
 animation speed (linear as well as rotational).  Asteroids cannot collide
 with anything.  Movement is generally slow - like a screen saver for your
 computer desktop.  Asteroid positions are jittered within the belt.



 The question:



 Dispersing objects into a ring is fairly straightforward through a number
 of techniques, but how do you apply the random jitter to the object
 positions?



 The rules:



 -  Cannot use ICE

 -  Cannot use custom scripts, custom operators, or shaders.

 -  Must only use tools out of the box that a junior or staff
 level artist would know how to use.

 -  Must be able to create the asteroid belt, from scratch to
 completion, in less than 30 minutes - and be iteration friendly to react to
 art director feedback.

 -  Ideally, the belt could be made a child of the planet in
 encompasses so it can be reoriented with respect to changes in the planet's
 size/shape/tilt/orbit.

 -  Final output must be able to exist with full integrity on its
 own in a vacuum.  Cannot not have dependencies on custom code, external
 assets, or special case logic.

 -  Asteroid belt fits within the default grid as seen in the
 scene camera.  Think torus with diameter 40 SI units, and cross section of
 roughly 3 SI Units diameter





 Ready.GO!









 Matt




Re: Survey - how would you do this?

2014-02-11 Thread Tim Leydecker

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?


  1   2   >