Julian

Okay, the advantage is this. Let's say we don't scale the stars, and we start off with the rendering I made in which the stars are the right size. 35 mm focal length, 640x480 resolution, star size 12 m: If we leave the stars at 12 meters, then when the frame is rendered at a lower resolution, the stars become almost too small to see. 35 mm focal length, 320x240 resolution, star size 12 m: And if we zoom the camera in, the stars become huge -- 100 mm focal length, 640x480 resolution, star size 12 m: This is what I'm trying to avoid. I want to keep the stars at just the right size so that they occupy only one pixel on the screen and don't lose brightness.

Thank you for your comment! When no one else was replying to this topic, I thought nobody was interested. I'd be willing to make this material available to download, but I'd have to document how to use the star sphere, because it's a little tricky. I forgot to mention that I applied an action to the original sphere of 2048 stars that created 15 duplicates of it as action objects, for a total of 32768 stars. These duplicates all have different rotations and are scaled -100% on 0, 1, 2, or all 3 axes. I'll try to render a test animation demonstrating motion blur soon. I'm also going to produce the boneless fixed-size variants, and before I'm done with the whole project, I want to investigate the possibility of using an expression to automate changing the size of the stars based on the focal length and output resolution of the camera.

You mean 20 millimeters? That actually works out to a bit over 82 degrees. I always thought the focal length property should have its units labeled, or better yet, we should be allowed to enter either a focal length in millimeters or a view angle in degrees and be able to convert between them. (Come to think of it, I wish the velocity of particles could have its units labeled as cm/sec too.)

Well, it's pretty much done, but it's not very practical to use. Sure, it renders really fast, but on my 1.5 GHz Mac it takes nearly six minutes to load up the project. Basically, this is the point of the whole exercise: Focal length 35 mm, 320x240 resolution, star size 20 m: Focal length 35 mm, 640x480 resolution, star size 12 m: Focal length 35 mm, 1024x768 resolution, star size 8 m: Focal length 100 mm, 640x480 resolution, star size 5 m: What I'm probably going to end up doing is to start with this sphere of variable-size stars that I've got, and by exporting actions to models, create different versions where the stars are fixed at particular sizes, and delete all the bones from each of these versions to make them load more efficiently.

Success! I decided to do the arrangment of stars in an action instead of a pose, because a translate driver in a pose always has two keyframes, one for the pose turned off and one for it turned on, whereas in an action I only need to use one keyframe. It keeps the file size smaller and reduces processing time. I created a model called StarSphere_1-repl2048.mdl which contains 2048 copies of a 15 meter star centered on the origin, each with a 15 meter long bone (Bone1 to Bone2048) starting at the origin. I also have a null called Origin at the origin. The HTML script for generating the action file looks like this: <pre> [ACTIONFILE] ProductVersion=11.1 [POSTEFFECTS] [ENDPOSTEFFECTS] [IMAGES] [ENDIMAGES] [SOUNDS] [ENDSOUNDS] [MATERIALS] [ENDMATERIALS] [POSTEFFECTS] [ENDPOSTEFFECTS] [OBJECTS] [ENDOBJECTS] [ACTIONS] [ACTION] StrideStartPosition=0 0 0 StrideEndPosition=0 0 0 DefaultModel=StarSphere_1-repl2048 PlayRange=0 0 [OBJECTSHORTCUT] MatchName=Bones <script> for (var i=1; i<=2048; i++) { with (Math) { costheta = 1.0 - 2.0 * random() sintheta = sqrt( 1.0 - costheta * costheta ) phi = random() * 2.0 * PI X = round( 1000000 * cos(phi) * sintheta ) Y = round( 1000000 * sin(phi) * sintheta ) Z = round( 1000000 * costheta ) } document.write("[OBJECTSHORTCUT]\n") document.write("MatchName=Bone" + i + "\n") document.write("[EMPTYDRIVER]\n") document.write("MatchName=Transform\n") document.write("[EMPTYDRIVER]\n") document.write("MatchName=Scale\n") document.write("[EXPRESSION]\n") document.write("Value=0.5+Rand()\n") document.write("Name=X\n") document.write("MatchName=X\n") document.write("[ENDEXPRESSION]\n") document.write("[EXPRESSION]\n") document.write("Value=..|X\n") document.write("Name=Y\n") document.write("MatchName=Y\n") document.write("[ENDEXPRESSION]\n") document.write("[ENDEMPTYDRIVER]\n") document.write("[EMPTYDRIVER]\n") document.write("MatchName=Translate\n") document.write("[TRANSFDRIVER]\n") document.write("Name=X\n") document.write("MatchName=X\n") document.write("[SPLINE]\n") document.write("CPs=1\n") document.write("1\n") document.write("0 " + X + "\n") document.write("[ENDSPLINE]\n") document.write("[ENDTRANSFDRIVER]\n") document.write("[TRANSFDRIVER]\n") document.write("Name=Y\n") document.write("MatchName=Y\n") document.write("[SPLINE]\n") document.write("CPs=1\n") document.write("1\n") document.write("0 " + Y + "\n") document.write("[ENDSPLINE]\n") document.write("[ENDTRANSFDRIVER]\n") document.write("[TRANSFDRIVER]\n") document.write("Name=Z\n") document.write("MatchName=Z\n") document.write("[SPLINE]\n") document.write("CPs=1\n") document.write("1\n") document.write("0 " + Z + "\n") document.write("[ENDSPLINE]\n") document.write("[ENDTRANSFDRIVER]\n") document.write("[ENDEMPTYDRIVER]\n") document.write("[ENDEMPTYDRIVER]\n") document.write("[AIMATCONSTRAINT]\n") document.write("BoneTarget=..|Origin\n") document.write("[ENDAIMATCONSTRAINT]\n") document.write("[ENDOBJECTSHORTCUT]\n") } </script>[ENDOBJECTSHORTCUT] [ENDACTION] [ENDACTIONS] [CHOREOGRAPHIES] [ENDCHOREOGRAPHIES] [ENDACTIONFILE] </pre> And here is the distribution of stars it generates, from a top view: The next step will be to generate the pose allowing me to scale each bone.

Wow, that's really cute! I love the way the iMac is startled by the J falling over, and the dejected look it gives us at the end. I also like how you made sure its monitor casts a subtle blue glare on the ground. The only criticism I would give is that the way the iMac moves makes it look more like a basketball being dribbled instead of something hopping. Take a closer look at the way Luxo moves in the Pixar logo.

Anders, Yves, thanks for the help. I can retool the model so that the arrangement of bones depends on translation instead of rotation, which would involve using a short bone for each star with an Aim At constraint to a null at the origin. The necessity of reusing variables means I would be better off computing the coordinates within the script instead letting A:M do it with expressions. In the SDK forum, I asked about generating a normal distribution with the Rand() function, and the thought occurs to me that if I used (Rand() + Rand()) /2, I would be able to produce values close to 0.5 more often than 0 or 1, a bit like rolling two dice. Anyway, I originally wanted to use an expression like that to control the size variablilty among the stars, but I probably won't be doing that now. For future reference, the problem of picking random points on a sphere is also discussed in this page on Wolfram MathWorld.

This is an outgrowth of an idea I originally floated in this post on the SDK forum. My objective is to create a sphere of randomly distributed stars 10 km in radius, where each star is a one-patch object with a diameter randomly ranging from 7.5 to 30 m. I also want to be able to control the size of all stars simultaneously with a pose slider, to ensure that the stars will always be rendered at about one pixel regardless of the resolution of the render or the focal length of the camera. After Yves put me on the track of a bones-based solution, I first tried to implement this idea in which each star has two bones, one to position it randomly and one to scale it, but I had to scrap it. First of all, the program hung when I tried to go from 1024 stars to 2048. Second, I found that having to evaulate an expression with a Rand() function on every bone made the model load up very slowly in an action or choreography. What I'm planning to do now is a two-stage approach: first, I create the randomly distributed and scaled stars with expressions -- this time, using only one bone per star -- then I bake the position of the bones in place by opening it in an action window and exporting as a model. After that, I'm going to create the pose slider that will scale each bone uniformly. The procedure goes like this: I made a single circular patch consisting of two splines, 15 m in diameter and centered on (0, 0, 10000 m). The CPs are assigned to a bone called Radius1 starting at the origin with a length of 10000 m. I replicated this model by saving the file, importing the model into itself and repeating 11 times to give 2048 stars, with bones numbered from Radius1 to Radius2048. What I need to do next is to apply these expressions to each of the 2048 bones: Transform.Rotate.X = 360*(-0.5+Rand()) Transform.Rotate.Y = 360*(-0.5+Rand()) (The Rand() function returns values between 0 and 1, so this will orient the bones randomly in a range of values between -180 and 180 degrees.) Transform.Scale.X = 0.5+Rand() Transform.Scale.Y = ..|X (Scales each bone by X randomly between 50% and 150%, and sets the Y scale equal to the X scale.) I can generate the names of all the bones using a FOR loop, and I'm choosing to do this using JavaScript, because I can very quickly use a web browser to save the ouput to a text file, open the .mdl file in a text editor, and paste the relationship into the right place. The relationship container in the model file looks like this: [RELATION] Name=Relationship1 KeyDim=1 [OBJECTSHORTCUT] MatchName=Bones [ENDOBJECTSHORTCUT] [FileInfo] LastModifiedBy=Julian Fong [EndFileInfo] [ENDRELATION] ...and the code I want to insert goes in where the blank line is. The JavaScript that generates the code is an HTML file which is presented here in its entirety: <script language="JavaScript"> var string1 = "[EMPTYDRIVER]<br>" string1 += "MatchName=Transform<br>" string1 += "[EMPTYDRIVER]<br>" string1 += "MatchName=Rotate<br>" string1 += "[EXPRESSION]<br>" string1 += "Value=360*(-0.5+Rand())<br>" string1 += "MatchName=X<br>" string1 += "[ENDEXPRESSION]<br>" string1 += "[EXPRESSION]<br>" string1 += "Value=360*(-0.5+Rand())<br>" string1 += "MatchName=Y<br>" string1 += "[ENDEXPRESSION]<br>" string1 += "[ENDEMPTYDRIVER]<br>" string1 += "[EMPTYDRIVER]<br>" string1 += "MatchName=Scale<br>" string1 += "[EXPRESSION]<br>" string1 += "Value=0.5+Rand()<br>" string1 += "MatchName=X<br>" string1 += "[ENDEXPRESSION]<br>" string1 += "[EXPRESSION]<br>" string1 += "Value=..|X<br>" string1 += "MatchName=Y<br>" string1 += "[ENDEXPRESSION]<br>" string1 += "[ENDEMPTYDRIVER]<br>" string1 += "[ENDEMPTYDRIVER]<br>" string1 += "[ENDOBJECTSHORTCUT]<br>" for(var i = 1; i <= 2048; i++) { document.write("[OBJECTSHORTCUT]<br>") document.write("MatchName=Radius" + i + "<br>") document.write(string1) } </script> After generating all the code and pasting it in, my model file now has a size of 1.8 MB, but that's okay, because including the model in an action and saving it as a new model will cut the size down almost by half. Opening it in an action window produces this result: But here's where I run into something unexpected: the Rand() function isn't producing a uniform distribution of bones. This is what the action looks like in muscle mode, from a front view: and a top view: Clearly, there's a higher concentration of stars around the poles, and I don't want that. I'm not even sure why this is happening -- something to do with the way the X and Y rotations are combining to produce the orientation of the bones? So now, I'm looking for some advice on how I can fix this. Maybe I can modify the expressions used to orient the bones originally, but how? If I export the action as a model and delete the original relationship, the bones will have random rotations in their Bone Position properties, but they will no longer be controlled by the expression and I can move them around. However, rotating the bones by hand is impractical. I could try using another expression to isolate just the bones clustered around the poles and randomizing their orientation again. As I had done before, I tested this expression on a model that contained only one bone before I'm going to apply it to all 2048 bones of my working model. Given that the name of the model is StarSphere2 and the first bone is called Radius1, I can apply this expression to Radius1: Transform.Rotate.X = If(80<Abs(..|..|..|..|..|..|..|..|Objects|StarSphere2|Bones|Radius1.Bone Position.Rotate.X)<100,180*(-0.5+Rand())) In other words, if the absolute value of the original X-rotation of this bone is between 80 and 100 degrees (which takes care of both the "north pole" and "south pole" clusters), rotate it by X again a random value between -90 and 90 degrees. I have to try this out to see how it'll look, but one problem that I can see may arise is getting stars clustered in two latitudinal circles. Maybe it'll happen and maybe it won't. Does anyone have any better ideas?

Booleans don't like sprites? What happens, does the application crash? Because I've already determined that Booleans don't like "render as lines" either, but it didn't start becoming a problem until version 10 -- which was when hierarchical Booleans were introduced.

The way you're deforming the statue's mesh makes it look like it's melting insted of crumbling. How about if you used an irregular shape as a Boolean cutter and dropped it over the statue with jerky-looking muscle animation?

Here's something else that might help: if you have a Photoshop layer with a transparent background, you can choose Load Selection, pick the layer's Transparency from the drop-down menu, and save that selection as an alpha channel. Then, on the original layer, you can apply a free plugin from Flaming Pear Software called Solidify, which is part of their freebies pack. This extends the outline of the opaque part of the layer until it fills in all the transparent parts. Save that as a Targa with an alpha channel, and fringies become a non-issue.

This is how to solve the problem of twisting arms in the 2001 rig. I made a post about this to the mailing list a while back, but apparently it's not part of the forum's archive. In the IK Arms Setup relationship, the left and right forearm bones have Kinematic Chain constraints to their respective hand targets. Within the properties of the Kinematic Chain constraints, "Support Limits/Damping" is turned on by default. If you turn this property off, the biceps will no longer twist when the hand targets are extended beyond the wrist.

Very 2001-like!

The "Walking with Dinosaurs" production team have a new show about exploring the planets of the Solar System, called "Space Odyssey: Voyage to the Planets", which is currently on the air in the UK. It'll probably end up on Discovery Channel like all their other shows have been. Information on "Space Odyssey": BBC official site BBC press pack Framestore CFC site with trailer The article by Framestore, who produced CGI for the show, makes a point about the amount of detail required for mechanical modeling. That's something that strikes me about Far Star: I don't think the design of the Explorer is impressive enough for a "hero ship" that we're going to be seeing in every episode. Looking at the forward section of the ship, I can't really tell what its function is, what's in it, and why it has to be that shape. And personally, I'm getting a little tired of science fiction CGI models with chrome textures. If one of the selling points of the show is that it's being made with low-cost software on personal computers, you at least have to aspire to the kind of quality Babylon 5 had, which started out being made on Amigas ten years ago. I'd like to know more about the characters on Far Star too.

I'd recommend making one of the moons smaller than the other. Right now, the composition of the moons looks too static. And maybe the moons should be lit from the side?

Also, does keeping the renderer static mean there isn't going to be graphics card-supported rendering? How about graphics card support for rendering polygon objects as props, at least? (I'm not sure how you'll get antialiasing to work, though.)

See, the Balrog really does look a lot cooler when it's completely self-illuminated without any external light sources.

To turn a light off, create a pose in which the ambiance of the light is zero. Actually, it would be better to make the ambiance of the lights zero by default within the model, and then create poses which set the ambiance of each light to 100% when the pose is turned on.

Can you show us what the original photo looks like? I want to see whether the shadowing on her face or the lack of specularity in her eyes is something from the original that you wanted to reproduce.

The important question is, if the hairs are very wide and flat, will the toon renderer draw their outlines correctly?

Steve, what kind of software are you using for speech synthesis? There are much better alternatives out there, like this one: http://www.research.att.com/projects/tts/demo.html

But do the lights and the ground model appear in the PWS? Could you have accidentally deleted the Default Chor.cho file from your A:M directory?

At the end of the animation, when there isn't any more motion blur applied to the sprites, the smoke looks very much like it's made of individual sprites. Maybe the sprite image should have more blur applied to it.

Have you tried pressing L to unlock the points?

Can we see a bottom view? Did you model the beak too? The thought occurs to me that if you replaced the Balrog's head with this octopus (and moved the tentacles so that they all faced forward), you'd have the beginnings of a pretty good Cthulhu.