Survey - how would you do this?

[Matt Lind]

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

[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

[Helge Mathee]

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

[Matt Lind]

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


Matt

[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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Tuesday, February 11, 2014 2:46 PM
To: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

[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

[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'; soft...@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:ethiv...@hybride.com]
Sent: Tuesday, February 11, 2014 11:46 AM
To: soft...@listproc.autodesk.com
Cc: Matt Lind

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

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

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

[Matt Lind]

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

To answer your question - yes.


Matt

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

:)

[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 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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Bradley Gabe
Sent: Tuesday, February 11, 2014 11:48 AM
To: soft...@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. 

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

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

[Eric Thivierge]

$10 says you can't use instances....

On Tuesday, February 11, 2014 3:13:50 PM, Emilio Hernandez wrote:
> 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

> <mailto: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:*softimag...@listproc.autodesk.com
> <mailto:softimag...@listproc.autodesk.com>
> [mailto:softimag...@listproc.autodesk.com
> <mailto:softimag...@listproc.autodesk.com>] *On Behalf Of
> *Bradley Gabe
> *Sent:* Tuesday, February 11, 2014 11:48 AM
> *To:* soft...@listproc.autodesk.com
> <mailto:soft...@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

> <mailto: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____
>
>

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

[Graham Bell]

I'd go with animated sprites for the asteroids.

As for jitter, the old school way would be to the coder to do it in the game engine. Otherwise, I'd animated the torus size very slightly with some offsets

[Emilio Hernandez]

Well not $10 bucks but a sample scene will say yes.

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

[Alan Fregtman]

It's too bad about the No ICE rule because it's not terribly hard to write a pointcloud exporter to whatever format the engine takes.

[Mirko Jankovic]

create couple models of asteroids for variety, LOD for each of them.

let programmers do instancing, duplication and animation in engine and deal with nasty math

[Eric Thivierge]

I meant that Matt was going to say that you can't instance stuff as one additional restriction...

[Emilio Hernandez]

ahhh  ok.

hahaha.

I double checked the instructions and it didn't say anything about not using instances...

Cheers!

[Emilio Hernandez]

I mean, I used the regular model instance of the Edit->duplicate/instantiate->single model.  No ICE instances in the sample scene.

Cheers.

[Bradley Gabe]

Can you use ICE to plot out a layout, and then convert it over to explicit controls? Or are you trying to design a system that can randomize, in game, on the fly?


Sent from my iPad

[Ed Harriss]

Sounds like a fantastic idea Joey.
Go old school. Do it in SI3D with Kaboom! Make sure your Gravity is set properly, check Collision Detection and don't forget to adjust the Tumble Rate. ;)
If you've forgotten how to use SI3D, go here: http://www.erimez.com/misc/Softimage/tutorials/si_help/si_uk_frames.htm

Matt, I know this was no help.
Sorry.

Cheese and Monkeys!
Ed

[Jordi Bares]

Nice challenge… 

I would approach in a brute force way by using path animation with multiple nulls, apply a linear interpolation L(0,100) to the nulls and copy a few rocks onto the nulls (instances). Then apply jitter to the curve, The rotation on the rocks I would apply on the rocks themselves before they are instanced as with so many copies any chance of seeing a pattern would be minimal.

Then I would copy paste the curves as many times required and change the radius of the curve.

Surely will be heavy but you could do this in 20 minutes.

If you have to exactly mimic a torus then you could first extract the curves although then  you would have to copy paste for ages… may be a hybrid by using a shape key to the curves to match the curves extracted?

Jordi Bares

jordi...@gmail.com

On 11 Feb 2014, at 19:23, 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

[Matt Lind]

Instances are allowed

 

 

Matt

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Tuesday, February 11, 2014 12:37 PM
To: soft...@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...

[Matt Lind]

Pay up ;-)

Matt

[Manny Papamanos]

Here's something quick and dirty just I made.
http://youtu.be/-77ALwrySsQ
Hope this gives you some inspiration.


-manny
SI Mobu Support

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Tuesday, February 11, 2014 5:03 PM
To: soft...@listproc.autodesk.com

[Eric Thivierge]

Sorry my money is tied up in my MMO accounts right now...

On 2/11/2014 5:03 PM, Matt Lind wrote:
> Pay up ;-)
>
> Matt
>

[Emilio Hernandez]

Thanks for clarifying Matt.

So then my sample scene is totaly feasible in this scenario.

Ok Eric.  One beer to go on your tab.

Cheers!

[Christian Gotzinger]

Here's my take on it (will take an hour or so before the link shows up)
https://vimeo.com/86461624
7 minutes to set up, but no collision avoidance.

Not sure how best to automate collision avoidance without ICE or scripting. Maybe rigid body dynamics with a big convex hull? But that's not allowed I suppose ;-)

Christian

On Tue, Feb 11, 2014 at 8: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

[olivier jeannel]

Excellent !

[olivier jeannel]

Link not working here..

[Christian Gotzinger]

Vimeo tells me that the video starts converting in 35 minutes. Link should work then, sorry about the inconvenience.

[Matt Lind]

…and how do you propose we get the ICE data into the engine while fitting into existing game play AND not introducing bugs AND not introducing more work for the engineering staff AND not requiring file format changes which would force us to re-export all assets which precede it – we have nearly 9 year of backlog which would need to be supported?

 

In film/video terms, imagine introducing your next tool required you re-submit every shot back to the render farm to be re-rendered and forwarded to every department afterwards to redo their work (compositing, fx, color correct, audio, editing, conforming, etc…)  – when 90% of the work is in the can and people are already working 16 hours days 7 days a week.  Probably wouldn’t be a popular decision.

 

When resources are scarce, solutions issued to artists of limited knowledge/skill must be in a form they can manage unsupervised which are also safe from jeopardizing the production.

 

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Alan Fregtman
Sent: Tuesday, February 11, 2014 12:33 PM
To: XSI Mailing List
Subject: Re: Survey - how would you do this?

 

It's too bad about the No ICE rule because it's not terribly hard to write a pointcloud exporter to whatever format the engine takes.

 

[Matt Lind]

Very nice. Very similar to what I told the artist yesterday. The main difference being I advised him to use the NURBS torus instead of NURBS disc.

My thinking at the time was to activate tangency and normal in the surface constraint to align their axes along the surface tangents, then deactivate the constraint using the R(-N,N), where N is the # SI Units to translate the asteroids in local Y, to push the asteroids in/out of the torus' surface to jitter the positions. The problem I ran into is Softimage treated the selection of asteroids like a branch selection and translated them uniformly in the same direction, instead of translating them individually along their own axes.

Plan B was to increase subdivisions on the torus and use the shape randomization like you and Emilio did to provide the randomization.

[Matt Lind]

1 Beer for you.  J

 

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Emilio Hernandez
Sent: Tuesday, February 11, 2014 2:39 PM
To: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

 

Thanks for clarifying Matt.

Cheers!

[Peter Agg]

"…and how do you propose we get the ICE data into the engine while fitting into existing game play AND not introducing bugs AND not introducing more work for the engineering staff AND not requiring file format changes which would force us to re-export all assets which precede it – we have nearly 9 year of backlog which would need to be supported?"

By writing as script that will convert the ICE Tree animation into regular objects with baked out animation. Then you're free to use whatever archaic devilry on them you normally would.

[Matt Lind]

You’re ignoring one of the rules – no scripting.

[Christian Gotzinger]

Whoops, while cleaning up my account I managed to delete the video.

The correct (and now working) link is:
https://vimeo.com/86464710

[Matt Lind]

Good job - very impressive!  Not sure collisions will be avoided, but looks very convincing.

 

What I find interesting is every solution so far has gravitated towards the parameter randomization feature - R(start,end).  I thought for sure at least one person would open the expression editor and plot out some randomized FCurves or do something in the animation mixer.

 

I’m curious to know if everybody would choose the same solution if the asteroids had to be 2D sprites?  Or if the number of polygons and keyframes were capped to specific amount of data?

 

 

Matt

 

 

 

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Christian Gotzinger
Sent: Tuesday, February 11, 2014 4:14 PM
To: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

 

Whoops, while cleaning up my account I managed to delete the video.

[Sylvain Lebeau]

Maybe it could work as well.....

I think of rendering sequences of a bunch of individual rotating asteriods with camera locked down on them, maybe 10 different ones. So you end up with small rez little videos with a rotating asteroid in the middle. 

And use the same technique with simple grids....but with orientation constraints to the camera? Worth to try.  Only thing is lighting will be baked out in thoses sprite textures.. So hopefully your camera doesnt travel to much and keeps looking in the same light/sprite light direction relation...

cool to see everyone chipping in!!

sly

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

VFX Curriculum 03: Compositing Basics

mail to: s...@shedmtl.com

[Sven Constable]

I did this with a curve deform, animating a few values. It give the inner-circle rocks a faster motion than the outmost parts. The belt is a single object. You can adjust the gaps between the rings if you switch the viewport to 'Sync with current mode" and using modeling construction mode. Not very interactive though.

There is no avoidance or collision. THe belt geo is heavy, maybe to much for a game engine, I dont know. But the scene is very light.

 

https://vimeo.com/86475294

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Tuesday, February 11, 2014 8:24 PM
To: soft...@listproc.autodesk.com
Subject: Survey - how would you do this?

 

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

[Matt Lind]

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.



Matt

[Matt Lind]

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

 

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

[Sylvain Lebeau]

of course!!!.... 

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

no ice, no nothing!! 

good luck Matt!!!!!

good challenge!

sly

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

VFX Curriculum 03: Compositing Basics

mail to: s...@shedmtl.com

On Feb 11, 2014, at 10:38 PM, Matt Lind <ml...@carbinestudios.com> wrote:

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

 

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

 

 

Matt

 

 

 

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

 

Maybe it could work as well.....

 

I think of rendering sequences of a bunch of individual rotating asteriods with camera locked down on them, maybe 10 different ones. So you end up with small rez little videos with a rotating asteroid in the middle. 

 

And use the same technique with simple grids....but with orientation constraints to the camera? Worth to try.  Only thing is lighting will be baked out in thoses sprite textures.. So hopefully your camera doesnt travel to much and keeps looking in the same light/sprite light direction relation...

 

cool to see everyone chipping in!!

 

sly

 

 

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

<image001.jpg>

VFX Curriculum 03: Compositing Basics

mail to: s...@shedmtl.com

 

[Matt Lind]

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

 

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

 

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

[Eugen Sares]

------ Originalnachricht ------

Von: "Matt Lind" <ml...@carbinestudios.com>

An: "soft...@listproc.autodesk.com" <soft...@listproc.autodesk.com>

Gesendet: 12.02.2014 05:37:30

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

 

 

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

 

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

 

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

 

Matt

Amen!

 

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

 

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

---

Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.

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

[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

[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

[Matt Lind]

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

[Matt 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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Wednesday, February 12, 2014 7:21 AM
To: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

[Bradley Gabe]

In less than the amount of time you've spent on this thread, you could have written a simple script to bake out ICE particle SRT's, which would not only help in this situation, but a million and one others. :-)

Sent from my iPhone

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

[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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Wednesday, February 12, 2014 1:35 PM
To: soft...@listproc.autodesk.com

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

[Eugen Sares]

------ Originalnachricht ------

Von: "Matt Lind" <ml...@carbinestudios.com>

An: "soft...@listproc.autodesk.com" <soft...@listproc.autodesk.com>

Gesendet: 12.02.2014 19:30:19

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

 

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

 

 

Matt

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

Those 4 bugs I refer to are simple ones, really. One is related to surfaces, too, btw - in JScript, you can only set Nurbs surfaces with only one subsurface in a custom operator. In VB it works. How hard can this be?

Another is that subcurves that you add in a custom tool cannot be selected until you freeze (or use a strange trick - add some factory operator, too).

I reported the same problem for polygons added in a custom op, and it was fixed almost immediately.

 

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

 

https://vimeo..com/86464710

 

On Tue, Feb 11, 2014 at 11:58 PM, Christian Gotzinger <cgo...@googlemail.com> wrote:

Here's my take on it (will take an hour or so before the link shows up)

 

---

Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.

 

[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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Wednesday, February 12, 2014 11:01 AM
To: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

[Matt Lind]

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

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

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

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

[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

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

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

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

[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 <ethiv...@hybride.com

> <mailto:ethiv...@hybride.com>>:

[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 :-) .

--

[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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Tuesday, February 11, 2014 12:37 PM
To: soft...@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

 

2014-02-11 14:19 GMT-06:00 Tim Leydecker <baue...@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:

[Eric Thivierge]

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

Eric T.

[Steven Caron]

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

[Eric Thivierge]

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

[Steven Caron]

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

[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
> <ethiv...@hybride.com <mailto:ethiv...@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
> <ethiv...@hybride.com <mailto:ethiv...@hybride.com>

> <mailto:ethiv...@hybride.com

[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

[Matt Lind]

Well, if you want to use the Apollo 13 analogy:

NASA had teams of engineers to collectively work on solutions in parallel to get through that crisis. I don't have teams, it's just me. I have to choose between retrofitting the CO2 monitor vs. figuring out the LEM power up sequence for re-entry. I don't have the time or resources to solve all the problems. I have to pick one and address it the best I can. Perhaps that'll put it into perspective.


The quick snapshot of our pipeline is we currently have 450,000+ assets developed over nearly 9 years. Approximately 15% of those assets were created in XSI v6.x or earlier and haven't been touched since (largely because many cannot be opened anymore and we don't have time/resources to revisit). We were stuck on Softimage 7.5 for nearly 5 years, which comprises 70% of our total assets. Many things did not work in XSI 6.x or Softimage 7.5. So lots of crashes, corruptions, and bugs when working with that data. That leaves assets created in Softimage 2013 SP1 and later as truly eligible for working in ICE. That is about 10-15% of our total asset library because we've only been using Softimage 2013 SP1 since February 2013.....in fact, almost exactly one year ago today. Unless somebody can give me a magic 'cleanse asset' button, to use ICE on the older data is full of land mines and very high risk. 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 majority of the assets produced in Softimage are simple props, buildings for environments, or character animation of simple discrete sequences (walk, run, jump, ...). Artists have very small windows on the schedule to get assets done. Prop team, for example, they get a few hours to create an asset from scratch and complete it - modeling, texturing, and animation. They produce a few props apiece every day. To work that fast requires the asset be very primitive and workflow include a lot of corner cutting. The heavy lifting is done in custom editors for designing and modeling terrain, and placing items in the worlds. The art department is a factory for generating pieces in a LEGO kit where each piece is unique. It's very difficult to come up with cookie cutter solutions to the types of problems we face as you cannot make assumptions how individual assets will be used in a world. I have already coded up solutions for most of the problems we could think of such as taking clothing from one character and refitting it onto another, or remapping face animation between dissimilar faces of other characters while retaining intent of the pose. I tried re-writing those tools in ICE to provide more interactivity, but couldn't do it because ICE doesn't support needed features. Working around those limitations was more work than it was worth with a final result no better than what I was trying to replace. Since almost any tool created must talk to a SQL database, that puts constraints on where I can implement ICE as ICE doesn't talk to databases, or if it did, would probably pound it mercilessly.


As for ICE itself:

- ICE is not stable and mature in our experience. We've tested quite a bit since inception.
- ICE crashes frequently on referenced models, 90% of our assets are referenced models.
- ICE crashes frequently when manipulating texture UVs and cluster properties such as user normals. We use those properties very heavily.
- ICE is very slow for kinematics. I tried it for a face animation system but the load was too much. I had to resort to the animation mixer w expressions.
- ICE doesn't support NURBS for looking up closest locations on NURBS Surfaces where the surface is a surface mesh. I wanted to re-write our clothing refit and transfer tool, but couldn't because of this roadblock. I tried working around the problem with a custom ICE node in C++, but the SDK doesn't support location searches in custom ICE nodes.
- ICE does not preserve custom data in topology operations. If an artist uses an ICE topology operator to do modeling, the asset loses its custom data to instruct the game engine how to use it which generates a lot of bugs in QA. I submitted bug reports to Autodesk, but it has yet to be addressed.

ICE is not mature in the respect it's standards/ways of doing things keeps changing. Example - in softimage 7.5 and 2010 the way paths (fullname) were defined for parameters on cluster properties were not consistent depending on the context which you accessed them. In 2011 they changed again invalidating ICE compounds made in previous versions. We cannot afford those kinds of changes. We don't have the resources to go back and revisit tens of thousands of assets to make corrections.

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

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

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

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

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

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

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

[pet...@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: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

[Matt Lind]

That is correct.

 

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

 

 

Matt

 

 

 

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Sergio Mucino
Sent: Thursday, February 13, 2014 8:35 AM
To: soft...@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 :-) .

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

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

[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

--

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

[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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 2:26 PM
To: soft...@listproc.autodesk.com
Subject: Re: Survey - how would you do this?

[Marc Brinkley]

Just to tack on...

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

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

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

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


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

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

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Thursday, February 13, 2014 3:16 PM
To: soft...@listproc.autodesk.com

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

[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

 

[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: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Graham Bell
Sent: Thursday, February 13, 2014 4:12 PM
To: soft...@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.

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

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

[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

[Steven Caron]

ya, i get that feeling too ;)

its magical

[Guillaume Laforge]

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

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

[Guillaume Laforge]

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

[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

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

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

[Matt Lind]

Below:

-----Original Message-----
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: soft...@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

[Guillaume Laforge]

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

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