Rodney

Mark, If you've got a could case study that you can push toward A:M Reports that may be just what is needed to push that into 32bit. I haven't investigated enough to know if some 32bit audio is PCM compliant. You never know, it may be that it's not that tough a change in the over all scheme of things. Adding it to A:M Reports helps to get it documented and prioritized.

Ernest, Thanks for that write up. That is very useful information to those of us contemplating productions of our own. You know I'm a fan of 'Subject 99'. It doesn't surprise me a bit that you'd consider taking 'Subject 99' into graphic novel and live action. If nothing else you've got a great animatic that you can show around! Obviously, I hope you can find whatever incentive it'll take to tell us more of the story... I wanna know what is up with this guy. That's easy. I think you should tell the rest of story! I think it's also important to be able to say you're finished with this one... even if you begin to move on with other things (its a given you'll do that). Yes, there most definitely is. I'd say it is when you've brought your story to a satisfactory conclusion. (on your terms) If you don't want to tell the 'big story' perhaps you can still have the characters reach a satisfactory short term conclusion. Perhaps you would prefer to get others involved in your storytelling. It's always time for a new series. Yes, there is but this forum is (at least at this point) populated more by creative types than by consumers. We aren't going to have the same perspective as would a movie going audience. Most of us want to just watch, we want to create products like 'Subject 99'! I'm not sure what your goals are but if you aren't making money at 'Subject 99' then it's important that you enjoy it or (as Robert suggests) place it on hiatus for awhile. But I don't think the series has to end just because new episodes aren't coming out... no... you still might have time to post little teasers and reedits and whatever you like to keep interest going for 'Subject 99'. It's just like you to leave us on such a cliffhanger!

I think... I forgot to post the report to A:M Reports.

Here's my take... I'd say there are both technical and practical reasons that exist for focusing on 16bit support of sound files. A case could be made for other additions and enhancements but ultimately A:M is not a dedicated editors as there are thousands available that fully focus on sounds. File Size Sound files (even 16bit) can grow to large size very quickly and often require considerable compression. In animation this can be especially processor intensive as the files must be encoded and decoded on the fly. Realtime Playback In order focus on animation with as much realtime playback as possible the straightforward approach might be to have two versions of a sound file, using the 16bit as your proxy in A:M and then replacing it with the original at a later time. This is similar to methods for using non-standard graphics (gif animation files) where the files used are temporary (proxies) and then exchanged at the appropriate time. Here's a write up from the Tech Ref/Help File for general information. I believe all of this still applies:

I read this similarly to the old saying, "There is no such thing as a straight line in nature." And if that is true then linear square patches is (purely) theoretical. In my messing around here I note that the thing about linear/square patches seems to be that they are aligned (or in line) with other points in order to formulate 90 degree angles (hehe... no doubt hence the name 'linear'). This does leave the occasional point out of alignment which I think that a fix (not in the graphic) might be to scale or move the extruded points out until aligned with the original. An alternative method might be to scale the original and extruded point together (I assume an average here) but that would remove the original away from it's place with respect to it's own origin. Therefore I think scaling the extrusion back in line with the original would yield the best linear spline square interpolation. (Yes, I have exactly no idea what I just said) Added: While messing I came up with another construct and I'm not sure how or even if it would fit in. It'll require more experimentation.

Congratulations Mark! I agree with your fan base. Make more 'Stalled Trek' films! Having folks enjoy something you've created at that level is a huge reward in and of itself.

This is somewhat related... I've been staring at an issue but don't fully comprehend how to approach understanding what to do with the information. Specifically that of how most programs and plugins (and approaches for that matter) tend to advance from a perspective that works against our goals of having smoother surfaces. In the image below this can be seen in (what I perceive as current approach) versus an optimal approach. What we tend to see is: Block - Prevalent in Bump and Displacement Linear (Triangle) - Prevalent in the Grid Plugin (except optimal Control Point placement by assignment of lower Step Width and Height) We don't see Linear and Bilinear very often and with good reason but they still would be preferrable in some cases over Block and Linear. (Triangle). What we only tend to see in optimal spline generation is biquadratic and that seems to be where the crossroads of optimization is in applying scale, control point placement and magnitude to mesh creation. Note that all of the approaches are (under the hood) comprised of the same spline continuity and are quadratic in nature they just seem to get 'pinched' at critical points along those splines due to the given interpolation. This image taken from 'Efficient Animation Techniques Balancing Both User Control and Physica Realism by Zicheng Liu. It's well worth reviewing as it has a chapter on Optimizing Keyframes (Chapter 4) as well as some exercises for animators.

Nice!

I never pictured you as an excel guru. I learn something new about the Tinkering Gnome every day. Many years ago (about 1994... when Microsoft purchased Foxpro) I was at a demo where a lady showed live video being played from a spreadsheet. (it was of a guy windsurfing). Everyone in the crowd ooo'd and aww'd. Then she showed the easter egg 3D game that someone had programmed into Excel. More smiles from the audience. I've been a fan of excel ever since.

That's wasn't so much of a benchmark but was just to get the ball rolling. The 'perfect' benchmark would likely render a series of sequences to account for default settings and then adjusted settings (thereby forming a way to measure what those settings are 'computationally worth'. Initially I set about rendering 600 frames at 24fps but it looks like I forgot to account for frame zero. Then I typo'd minutes for seconds... and yikes... doesn't that make a difference. But if others are learning from my mistakes that can be a good thing. The neat thing about 600 frames is that it is nicely divided by both 30 and 25fps That 601st frame really got things rolling. 600frames/30fps=20seconds 600frames/24fps=25seconds Without specifically remembering, I believe easy math my initial goal. So, perhaps I instinctively rendered 20 seconds of animation at 30fps and only lucked out that it was so relative to 24? In other words, I just got lucky. Attached is a pdf file I generated from an excel spreadsheet I just threw together that attempts to get a grasp on frame optimization. Assuming no typos it seems to me that when switching over to 30fps things really start to break with regard to keyframe optimization (30fps has advantages but one of them is not syncing with animation with extremes originally drawn on 4s, 8s, 12s, 16s etc. 30fps simply doesn't align well. I haven't studied the 3:2 pulldown enough to understand it's full effects on optimal conversion of keyframes but a cursory view seems to indicate an attempt to targeting key-frames that will maintain a semblance of the original performance. Disclaimer: I do not suggest that the attachment will in any way help understand what I'm going on about here but it's a raw data dump of numbers that I felt like typing into excel to make sure I understood it. frames_per_second_tables___draft___not_reviewed_for_accuracy.pdf

Yes, indeed. 16 plus 1/2 of 16 (8) is 24. You have more than good reason to be assured.

Where SMPTE gets dicey... and people tend to get lost... is where the numbers have to deal with the 'set' frames per second (usually 24 or 30fps). Thusly... What comes next in the sequence?: ... 00:18:20 00:18:21 00:18:22 00:18:23 ? Select the following text with your mouse to see the answer:

I'm straying a bit off topic but this is fun stuff. Something that I didn't understand before was how the reading of xsheets and those timing charts on the extremes was read. That is real gold when trying to analyse classic animation sequences. As a for instance, let's consider our standard timing in SMTPE format (00:00:00) While this equates to hours, minutes and seconds it also equates directly to frames. Thusly: 00:03:04 is the equivalent of 3 seconds (feet) and 4 frames. 00:20:01 equates to 20 seconds (feet) and 1 frame. What then does 601 frames equal (in feet)? 00:20:01 (in SMPTE) which is equivalent to 20 seconds and 1 frame. Is everyone still with me here?

Here's a breakdown for reference: (Image courtesy of: DonBluth Animation) Note: Don's Seminars have been on hiatus for the better part of a year. An announcement recently indicated they will be starting up again with new tech to resolve problems experienced in previous sessions.

Is your fps set to 30fps in the Project Properties? 600 / 22 = 27.3181 on my calculator. Aside: I find it interesting that number is right smack dab in the middle of 24 and 30. That is telling us something. At a glance it looks like the difference of one frame extra per second. A general breakdown: 25 seconds at 601 frames = 24.04fps 24 seconds at 601 frames = 25.0416 fps 23 seconds at 601 frames = 26.1304347826086956521739 fps 22 seconds at 601 frames = 27.3181 fps 21 seconds at 601 frames = 28.619047 fps 20 seconds at 601 frames = 30.05 fps Note: I am trying to make a distinction here between Feet Per Second (FPS) and Frames Per Second (fps) by using the lower case 'fps' as the number that goes by the aperture of a camera can vary. One foot in traditional animation terms is pretty much set in stone as 16fps. Here's an interesting website that covers some of this information: http://frames-per-second.appspot.com/ Marcos understands the higher (and lower) frame rates that drive innovations such as MUFOOF. Here a response from Don Bluth after minds got confused on the issue: Of course the standard for video is closer to 30fps than 24fps and that is largely due to the need to bring down labor cost/time. An animation on 2s for instance simply doubles all the frames so all you need to do is create/draw/render the odd numbered frames and repeat them for the evens. A slower action could be on 4s which means one original and three copies. An even slower action might be on 8s which really slows things down. Reviewing on 8s is a good standard because otherwise the action is too quick to review. David Nethery (whose website is worth checking out) has this to say: Again, he's talking about traditional animation. Some conversion often takes place in order to move to video at 30fps. But note that everyone in the traditional art will 'automatically assume' you are animating at 24fps. This changes with computer animation in that 30fps is often easier to use in math. Everyone should take a moment to recognize the similarity between bits and bytes and traditional animation. It is more than just coincidence. 1 2 4 8 16 32 64 128 256 Fun stuff this is.

Oooo. Really nice render. I like that!

I was going to start listing the various 'features' you've put into this project but I think it's easier to just say... everything!

Ha! That's a great story.

Eric, In the next few years I will be upgrading as will many others who frequent the forum. So information you discover will be appreciated.

Bump. This is a really old topic but I'm liking the economy of splines. :)

If you separate the parts of the train individually in your other program and then import those as Props you'll be able to texture and manipulate them separately. I would separate the parts even if trying to convert them into A:M Models.

Good catch. In my haste I messed that one up. I'll correct it in my post above. The numbers are important in benchmarks. Thanks! Wait a second!!! You know what? hehe. Twenty seconds isn't right either! Although it would be right at 30 frames per second. What isn't given here is that the frames rendered can result in various times. It just depends on how those frames are spaced. But that isn't what I want to talk about here I just want to get into the math of it. 601 frames divided by 24 frames a second gives 25 seconds (and change because of that extra frame). I should have rendered frames versus SMPTE or perhaps cels I would realized that I was rendering an extra frame. What I should have rendered was 600 frames which would have yielded exactly 25 seconds at 24 frames per second. For 600 frames to be displayed in two seconds... that that'd be 300 frames per second. Now that would be some serious frames zooming by...