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