Survey - how would you do this?

196 views
Skip to first unread message

Matt Lind

unread,
Feb 11, 2014, 2:23:31 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 11, 2014, 2:46:20 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 2:47:20 PM2/11/14
to soft...@listproc.autodesk.com
use Fabric. but I guess that's considered custom. :-)

Matt Lind

unread,
Feb 11, 2014, 2:47:11 PM2/11/14
to Eric Thivierge, soft...@listproc.autodesk.com
You wouldn't last long in games with that attitude.


Matt

Ponthieux, Joseph G. (LARC-E1A)[LITES]

unread,
Feb 11, 2014, 2:48:04 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 2:48:11 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 2:49:00 PM2/11/14
to Eric Thivierge, soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 2:49:45 PM2/11/14
to Matt Lind, soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 2:51:59 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 2:54:26 PM2/11/14
to soft...@listproc.autodesk.com
Softimage doesn't have a particle system anymore. ICE replaced it.

To answer your question - yes.


Matt

Ponthieux, Joseph G. (LARC-E1A)[LITES]

unread,
Feb 11, 2014, 3:00:13 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:01:48 PM2/11/14
to Eric Thivierge, soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:06:03 PM2/11/14
to soft...@listproc.autodesk.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] 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

unread,
Feb 11, 2014, 3:11:24 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:13:50 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:15:42 PM2/11/14
to soft...@listproc.autodesk.com
$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

unread,
Feb 11, 2014, 3:19:12 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:25:02 PM2/11/14
to soft...@listproc.autodesk.com
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
winmail.dat

Emilio Hernandez

unread,
Feb 11, 2014, 3:28:54 PM2/11/14
to soft...@listproc.autodesk.com
Well not $10 bucks but a sample scene will say yes.

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


Alan Fregtman

unread,
Feb 11, 2014, 3:32:32 PM2/11/14
to XSI Mailing List
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

unread,
Feb 11, 2014, 3:35:36 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:36:48 PM2/11/14
to soft...@listproc.autodesk.com
I meant that Matt was going to say that you can't instance stuff as one additional restriction...

Emilio Hernandez

unread,
Feb 11, 2014, 3:39:03 PM2/11/14
to soft...@listproc.autodesk.com
ahhh  ok.

hahaha.

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

Cheers!



Emilio Hernandez

unread,
Feb 11, 2014, 3:43:56 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 3:59:51 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 4:35:15 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 4:41:22 PM2/11/14
to soft...@listproc.autodesk.com
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?


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

unread,
Feb 11, 2014, 4:47:22 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 11, 2014, 5:03:18 PM2/11/14
to soft...@listproc.autodesk.com
Pay up ;-)

Matt

Manny Papamanos

unread,
Feb 11, 2014, 5:22:21 PM2/11/14
to soft...@listproc.autodesk.com
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
winmail.dat

Eric Thivierge

unread,
Feb 11, 2014, 5:36:00 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 5:38:42 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 5:58:01 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 6:01:51 PM2/11/14
to soft...@listproc.autodesk.com
Excellent !

olivier jeannel

unread,
Feb 11, 2014, 6:03:32 PM2/11/14
to soft...@listproc.autodesk.com
Link not working here..

Christian Gotzinger

unread,
Feb 11, 2014, 6:07:02 PM2/11/14
to soft...@listproc.autodesk.com
Vimeo tells me that the video starts converting in 35 minutes. Link should work then, sorry about the inconvenience.

Matt Lind

unread,
Feb 11, 2014, 6:12:35 PM2/11/14
to soft...@listproc.autodesk.com

…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

unread,
Feb 11, 2014, 6:26:41 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 6:26:59 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 11, 2014, 6:46:25 PM2/11/14
to soft...@listproc.autodesk.com
"…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

unread,
Feb 11, 2014, 6:55:36 PM2/11/14
to soft...@listproc.autodesk.com

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

Christian Gotzinger

unread,
Feb 11, 2014, 7:13:56 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 7:43:03 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 11, 2014, 8:16:34 PM2/11/14
to soft...@listproc.autodesk.com
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



Sven Constable

unread,
Feb 11, 2014, 10:08:05 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 11, 2014, 10:30:12 PM2/11/14
to soft...@listproc.autodesk.com
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

unread,
Feb 11, 2014, 10:38:24 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 11, 2014, 10:59:55 PM2/11/14
to soft...@listproc.autodesk.com
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




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
 



Matt Lind

unread,
Feb 11, 2014, 11:37:30 PM2/11/14
to soft...@listproc.autodesk.com

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

unread,
Feb 12, 2014, 3:36:40 AM2/12/14
to soft...@listproc.autodesk.com
------ Originalnachricht ------
Von: "Matt Lind" <ml...@carbinestudios.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

unread,
Feb 12, 2014, 10:21:02 AM2/12/14
to soft...@listproc.autodesk.com
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

unread,
Feb 12, 2014, 10:37:11 AM2/12/14
to soft...@listproc.autodesk.com
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

unread,
Feb 12, 2014, 12:11:17 PM2/12/14
to soft...@listproc.autodesk.com
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

unread,
Feb 12, 2014, 1:30:19 PM2/12/14
to soft...@listproc.autodesk.com

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

unread,
Feb 12, 2014, 1:35:19 PM2/12/14
to soft...@listproc.autodesk.com
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

unread,
Feb 12, 2014, 1:51:40 PM2/12/14
to soft...@listproc.autodesk.com
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