Jump to content
Hash, Inc. - Animation:Master

wingalls

*A:M User*
  • Posts

    19
  • Joined

  • Last visited

Profile Information

  • Name
    Wes

Previous Fields

  • Hardware Platform
    Windows

wingalls's Achievements

New User

New User (2/10)

0

Reputation

  1. Not mine. I stole it. I'm just a talentless hack. That's why AM is perfect for me
  2. Thanks for breaking down that brick wall for me, frosteternal! Onward!
  3. Here it be. Thanks. And, BTW, I reproduced the same effect using AM 13.0l gaia_4___troubleshoot.zip
  4. Yearning to learn, I decided it was time to do the Volumetrics tutorial. Images 1 & 2 show my attempt to animate the Fall Off of the Dust per the tutorial. Before setting the fall off, (image 1), right-clicking the Fall Off property shows that the "Use Cache" is set. After changing the fall off to 0 for frame 1, another look at the Fall Off properties shows that the "Constant" is set. Also, under the Drivers/Action Objects/Dust Action Object property, a Fall Off property has been added showing a lock. That was the experience using AM 14.0a. When replicated using AM 13.0l, after setting the frame 1 fall off to 0, the Fall Off property shows "Time Based" as selected,(image 3). Note also, that "Time Based" is not an option for the properties of the AM 14.0a version of "Fall Off". Anybody know why the Time Based option is not appearing when I use AM 14.0a? - Wes
  5. I've gotten the streak emitter to put out acceptable blood, and it's worked in other projects. Now it's time to incorporate it into the current project and I'm hitting a brick wall. The attached image shows a portion of the project immediately after starting AM. As you can see, the emitter has done its preroll function and produced a half second's worth of blood. The problem is: As soon as I click on the Chor window, (or in the case of start up -- upon removing the hint window), the blood streaks disappear and I can't get them to reappear. (Not in the Chor windor or when rendering). It's not just a matter of rendering particles, because the cigarette smoke is also streak generated, and it behaves properly. Anybody got a clue to this mystery? -Wes P.S. I'm using AM 14.0a
  6. Ok, I gave rotoscopes a shot and came up with these results: (BTW, my project entails placing effects (smoke, blood, etc) over static images, so "On Top" wasn't an option). I liked rotoscopes because I didn't have to scale and place the images in the scene, as I did with layers. Also, the render time for the image (computing and rendering patches) went way down. Buuuuuuut ... Render Time: The render time for Rendering Particles/Fur went through the roof! Over several tests, I found that the render time (particles/fur) increased with the number of rotoscopes in the camera. Even though the transparency of all but one of the rotoscopes was set at 100%, they still effected the render time. Here is a table of the times: Rotoscopes Rendering Particles/Fur (Frame 1) (Frame 2) 0 1 sec 0 sec 1 6 sec 2 sec 2 23 sec 6 sec 10 36 sec 34 sec 4* 21 sec 14 sec * rotoscopes that are transparent in "smoke" area The last test was using four rotoscopes whose transparent section (alpha channel) covered the area where the particles (smoke) was being generated. Apparently, just being present is enough to effect the render time. Other Considerations: Besides render time issues, using rotoscopes lead to other problems. Whenever I finished rendering (usually to file) and was switching back to Chor view, there was a long period where AM had to regenerate each rotoscope. The info bar said "Generating Real Time Texture". This was not render time (which can happen while I sleep), but me time (while I'm sitting on my bu chair). Even if I was happy living with that, there were exceptions thrown while generating these textures. Sometimes, the exceptions resulted in AM crashing. Conclusions: Rotoscopes are not going to be the solution for my case. On the upside, though, I think I will try layers again using the TGA (alpha channel) images that I created for the rototests. Instead of each layer containing a complete picture of the frame, only the changed elements are visible (as was recommended by Rodney). This reduces the number of layers (since I can use them in combination). If this new approach to layers bears no fruit, then it will be on to Rodney's second suggestion ... grids! Wish me luck. -Wes P.S. Quick update -- I just tried a combo of one rotoscope (for my main image) and layers (for changing areas) with outstanding results. Render time went from 15 secs/frame (which was the time with ver 14 using all layers) to 5 secs/frame! Huzzah!
  7. Great! what did I win? A great big heapin' bucket fulla everlasting gratitude. (Gratitude non-negotiable. Void where prohibited).
  8. Upon further investigation ... Luuk Steitner, you are todays winner! (Yay.) Here are two identical projects except for the FPS: 30 FPS - http://home.san.rr.com/xenasubtextcomic/extra/30fps.jpg 300 FPS - http://home.san.rr.com/xenasubtextcomic/extra/300fps.jpg For johnl -- your prj will display the same effects as mine if you change the Blobby Emitter properties thusly: Viscosity -> 0% Rate of Emission -> 1500 Initial Velocity -> 100 The implications of these images are mind-staggering: http://home.san.rr.com/xenasubtextcomic/ex...0fps-bounce.jpg http://home.san.rr.com/xenasubtextcomic/ex...0fps-bounce.jpg Do you think Newton considered the effects of FPS when he wrote his laws of motion? Thanks again, everybody. - Wes
  9. Lots of good stuff here, Rod (can I call you Rod?). I agree! It's just the fact that over 90% of it is redundant. I haven't tried rotoscope, but it sounds like an interesting option. Obviously, the program will only render the rotoscope once ... right? Decaled grids. Ok. Probably will get rendered with every frame also (like the layers), but, hey you never know until you try! I'll probably save this one 'til last. Education, first, last and always!
  10. ERRATA: In my original post I aluded to the fact that my AM update was being delivered via UPS. In fact the parcel was delivered by FEDEX. My apologies to all our brave men and women in purple and black.
  11. Oh, ho! Thanks Mr. Gnome (can I call you Mr. Gnome?). Since this was my first blobby, I didn't know that a sprite emitter wasn't part of a blobby emitter. (Thought it was just a reuse of code kinda thing). Apparently, the "Change Type To" menu option has different results depending on what type you are changing from and to. You can change from a blobby or a streak emitter to any of the other types without any apparent difficulty, and changing from a sprite system to a hair system (and vice versa) works. But if you change from a sprite or hair system to a streak or blobby emitter, trouble ensues. In summary: "Change Type To": Emitter -> Emitter OK Emitter -> System OK System -> System OK System -> Emitter STRANGE There may be a valid reason for a blobby or streak emitter to have a sprite or hair emitter under it instead of attributes. If anyone can think of it, let me know. In the mean time -- THANKS EVERYONE. - Wes
  12. Thanks J.L. (can I call you J.L.?), but there were just so many of them. I was reading through all of the posts that resulted from a "blobbies" search, and your posts were in almost all of them. It's obvious that you've done extensive experimentation with the particles system, and I was hoping to avoid having to rediscover old territory. I see from you profile that you have roadrunner,("wi" ... wisconsin?), too. Instead of going to all the hassle of rebuilding a site you could just ftp them all up under a new folder and publish the link here. Anywho, thanks for the offer and if my suggestion doesn't tickle your fancy, I'll try to narrow down the field a bit and ask you for a few of the most relevant projects. - Wes
  13. Thanks guys, for your prompt and constructive feedback. For jzawacki: Well, duuuuuuuh! I knew shouda known that! For johnl3d: Wait. Version which? For robcat2075: I'll put up a prj file IF the problem still exists in version 14.0a, which I am loading now. Heh, funny story ... see when I got the CD update to AM2007 last week, I installed it and then didn't even think to come here for an update. Thought I was getting AM2007. Ah, well. So ... when I saw john's (can I call you John?) post with a test in ver 14.0 and your post about checking the version on the prj ... well ... I finally put two and two together and went hunting for the upgrade. Ah ... it looks like the install is complete ... and now instead of version 13.0I (13.0L? ... can't tell with that font), I have version 14.0a ... and the problem is still there. So attached here (or at http://home.san.rr.com/xenasubtextcomic/ex...obbies-test.prj <FILE REMOVED FROM URL>, if I can't get the upload to take) is the project that is producing the problem. What's not shown in the project file is that I'm running AM on a Windows XP (SP2) platform, and using Netscape 8.1.3 to (still) unsuccessfully upload an attachment. Thanks again, guys. - Wes
  14. I've started playing with particles, and thought that blobbies would make a good blood effect. I may end up with streaks in the end, but in the mean time, I need to know what is causing this strange grouping of the blobbies. I've tried changing every parameter in the blobby emitter and the sprite emitter, but nothing seems to change the square groups of blobs to a continuous stream of blobs. Does the properties of the emitting surface effect the emissions? My emitter surface has four patches. If it had 49, would the emitted blobbies behave differently? The attached picture shows this unusual (I think) clumping of the blobs. When rendered, the blobs are still grouped. When stepping from frame to frame, the bounding squares stay in exactly the same place and the bubbles flow through them. In other words, at no time during the animation do blobs exist in the spaces between the blocks. Anyway, if someone knows the location of the "Wierd/Not Wierd" switch for this, please let me know. Meanwhile, I'll go back to fiddling with my Rome burning project particles. I've touched on streaks and blobbies, so I guess it's time to tackle sprites. (Why do I feel like I'm reinventing the wheel fire? Oh, I know. It's because I can't find that extensive body of work by johnl3d. Hopefully, someone will know where it went). - Wes P.S. I can't seem to get the jpg to upload, so I'll draw a picture of it. The block made of "S" is the emission source. The blocks of "B" are the resulting bubbles. SSSSSSSS BBBBBB S S BBBB S S BBBBBB BB S S BBBBB BB B S S BBBB BB B S S BBB B B BBB BBB BB SSSSSSSS B BBB B B B BBB B BBB B BB BBBBB B BB B BB BBB B B B BBBB B B BB B BBB B BBB B B BB BBBB BB B BBB BBB BB BB B B BBB B BB B BBB B B BB BB B BBB BB BBBB BB BB B B B BB BB B BBB B B BBBB B B B BBB BB B B BBB The start of a block of bubbles seems to be lined up vertically with the end of another. Horizontally, their seperation suggests the effects of gravity. P.P.S. Is it going to be One of Those Days?! First, the post won't take my upload, and then it won't let me draw any ascii art! (All the leading spaces disappeared). Let's try the ascii again: .SSSSSSSS BBBBBB .S S BBBB .S S BBBBBB BB .S S BBBBB BB B .S S BBBB BB B .S S BBB B B BBB BBB BB .SSSSSSSS B BBB B B B . BBB B BBB B . BB BBBBB B BB . . B BB BBB B B . B BBBB B B BB . B BBB B BBB B . B BB BBBB BB B . . . BBB BBB BB BB . B B BBB B BB B . BBB B B BB BB . B BBB BB BBBB . . . . . BB BB B B B . BB BB B BBB B . B BBBB B B B . BBB BB B B BBB P.P.P.S. ARRRRRRGH! I don't believe this. Apparently, this forum does not allow more than one space between letters! Ok. This is the last attempt. If you've stuck with me this far, please try this link: http://home.san.rr.com/xenasubtextcomic/ex...0of%20blobs.jpg <FILE REMOVED FROM URL> Thank you.
×
×
  • Create New...