Forum Replies Created

Page 6 of 8
  • Eric Barker

    November 16, 2007 at 9:36 pm in reply to: Parenting layers for short amounts of time?

    I hate to say it, but asking for dynamic parenting is sorta like asking for a BASIC-style “goto” fuction in the next version of “C++”. Dynamic parenting is nothing more than a work-around for bad setup. Don’t get me wrong, I’ve been there too, and thought, “jeeze I wish I could just switch off my parenting right here”. But usually I realize that I wouldn’t be thinking like that if I had setup my project better ahead of time, or approached it from a more streamlined perspective.

    After Effects is a programming language, in a sense (and I’m not just talking about scripting). It’s graphical, and it’s not setup like most formal languages, but it requires the same thought processes and skills. But it also suffers from the same “bad programming” pitfalls. I can’t really think of an instance in which dynamic parenting would seriously jeapordize the integrity of a project. And I can’t think of an instance in which the same things couldn’t be accomplished by a better, more streamlined method.

    This is not to rag on you, but simply an explanation as to why it likely will never happen.

  • Actually, it’s not just Adobe. Even on the audio front, MOTU, one of the most pro-Apple software companies known to man (they’re such Apple zealot’s that they refuse to sway from Apple’s doctorines even years after Apple itself has given way to other ideas (contextual menus)) are having trouble with Leopard… big trouble. It seems that Apple didn’t fully release a good SDK soon enough to developers, or changed things at the last minute. I know that Core Audio had some major changes from Tiger in which companies were not able to deal with in time. Of course, to Joe Public, Apple isn’t going to bother making a big deal about the inner workings of Core Audio, but you’d think that they’d give developers a bit more leahway.

  • Eric Barker

    November 1, 2007 at 8:19 pm in reply to: Scan lines vs Pixels

    Nope, lines to pixels IS a 1:1 ratio. You’re talking about the non-visual fields as well. The visible area on NTSC format is 720×480, along with 6 additional virtical which is used (for lack of a better term) “metadata”, things like closed captioning, digital information, etc. All YOU need to worry about, though is 480 lines, which translates exactly to 720×480 pixels. DV has nothing to do with it, that’s just a digital standard for encoding video for NTSC playback. The extra pixels you are talking about are basically the equivelent to the space between frames on a film reel. You don’t even need to think about that area… I commonly forget it exists.

    Basically the ONLY thing you need to worry about (and worry is probably too strong of a word), is the transition from square pixel computer monitors to 1×0.9 sized pixels on an NTSC TV screen.

  • Eric Barker

    November 1, 2007 at 8:01 pm in reply to: How could I have done this more efficiently?

    Yes, thankyou. I forgot about the “parent to null” idea for the camera. Thanks for reminding me, I need to do that… it might completely change the way I use AE.

    As for pre-comping, I wish I could, however since the entirety of the grid is around 10,000×7000, when I tried putting them together, the program ran out of memory and had a fit. However, had I taken those 6 hex fields and precomped them, things would have been A LOT better. Obviously, doing them in Photoshop vs. AE wouldn’t make a big difference. Doing them in AE just made more sense because the glow filters are already there for the images. Also, I tend to like AEs vector tools a bit better.

    Anyway, thanks a lot, you’re right, I think your way would have been a lot better.

  • Eric Barker

    November 1, 2007 at 6:47 pm in reply to: How could I have done this more efficiently?

    Oh, actually I did use vectors, I used shape layers for each of the hexigons. Or are you speaking of some different vector type?

  • Eric Barker

    November 1, 2007 at 6:45 pm in reply to: Animating a FONT to look handwritten

    I’ve done this quite a bit, with pretty much 100% success, so it’s not too difficult.

    All you have to do is trace along the center of the lines of text. Basically, make an open mask that follows the exact same path that a person writing it would. Use the “stroke” plugin, but at the bottom select “Reveal Original Image”. This makes the stroke path not so much “paint” on the screen, as reveal whatever is originally on the layer. This means that if your mask is drawn over transparent areas in the layer, it won’t do anything (which is usefull for crossing T’s and dotting i’s).

    Set your brush size large enough to be able to get the entire line of the letters in. An easy way of checking this is, after you’re drawn your mask and applied the stroke, set “start” and “end” properties so that the stroke reveals everything, and then simply flip the stroke on and off to see whether there are any spots that it didn’t reveal. 95% of the time, you shouldn’t have to worry about changing your brush size during the course of the reveal, but if your font changes width drastically, you might have to… but usually you can get around that by tweeking the path.

    Also keep in mind that handwriting is fast enough that you usually shouldn’t need to worry about every little detail in the animation.

    You can always use this path again, later, to animate a pen, if you so desire.

  • Eric Barker

    November 1, 2007 at 6:30 pm in reply to: Scan lines vs Pixels

    Pixel Height and Scan Line Height are the same. In older TV technology (CRTs in pre-HD formats like NTSC), due to the fact that lines are drawn slightly appart from each other (and interlaced), the common lingo is that TVs use “scan lines”, for heigh dilleniation. In actuality, all monitors have pixels, there’s no fundimental difference that makes older TVs have scan lines, it’s just that because of that visual separation, the lingo is slightly different. In HD, that’s all moot because HD TVs are basically identical to computer monitors.

    So when they ask for 23 scan-lines high, you can think of 23 pixels high. Also, keep in mind, that because of overscan, you’re going to lose the bottom 20 or so pixels on most TVs, so turn on the title/action safe guides (little crosshairs button in the preview monitor), and make sure that the disclaimer is cleanly within the title safe area (inner guide). I guarentee that if they have line height criteria, they will also require that the text be within the title safe area.

  • Eric Barker

    October 30, 2007 at 5:55 pm in reply to: changing the name of blessed folders…

    That doesn’t help much, because then I’d have to change it for every project I create, and “scratch disks” doesn’t allow me change the name of the folders. What would be great is if I could make Premiere put all of it’s crap into one “Render Files” folder for every project. I think Final Cut does this.

  • Eric Barker

    October 10, 2007 at 11:44 pm in reply to: relative 3D positioning…

    WOW! I just did a little dance! I had no idea that you could pre-comp 3D and maintain the Z-axis! That’s AWESOME! Excuse me for being so excited, but that just opens up a whole new world of possibilities. Is this new to CS3 (since I’ve been using AE7 for about a year now), or did I just miss it?

  • Eric Barker

    August 29, 2007 at 12:57 am in reply to: No Underlining of Text? Why?

    1. Underlining judiciously has its place, especially in headings.

    No to #1. Headings should NEVER be underlined. This is one of the biggest mistakes people make. A good looking document will always resort to using other techniques like using a different font, or larger point size with bold.

    – If you want to give the document character, use a fantasy or less traditional font for headings

    – If the document is in a serif font (Times New Roman, Garamond, etc.) a great practice is to use a large san-serif font for headings. San-serif fonts are slower to read in big blocks of text, but tend to call attention to themselves more, which is better for headings.

    – If it’s a in-house business document, just use a larger typeface, or bold, or both.

    – Use you’re page layout to separate the headers from the body of the text. Indent, or justfy right, if it’s appropriate for your design.

    – Use graphical elements from your layout. Horizontal Rules (very different from underlines), or half rules, can separate headers from body text and can be worked into the overall format.

    Underlines are an almost absolute no-no. The ONLY time you would ever underline things is if you want to point out specific points in the body, and it’s a completely informal document (ie: internal business memo).

Page 6 of 8

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy