Rodney

When I first saw this I thought it was a trailer for an upcoming movie... did I just imagine that it's suppose to eventually be a full feature? Hmm. Aw well, at any rate they've released this short (starring the voice of Steve Martin as the alien leader) for all to see: FavW-Y1kaxs Something to note: The length of this film is a good measure for shorts. It runs 4 minutes 7 seconds which includes intro and credits. And yet it is more than sufficient to tell the story. It also reminds me of some old A:M shorts.

Hey Robert! Did you have a project file that you could share at the Step 6 stage (after adding the traveling light)? I was considering playing a bit, downloaded the last project file you posted and then realized it didn't have the traveling light in it. I know I'm being lazy.... so will do my due diligence to test with the step 5 project... but wanted to ask anyway. I'm eagerly anticipating the last episode.

This looks like it is the same problem I was running into in Nancy's Panda topic. What is facinating to me is that it appears that this bug is allowing the hair to cut through all geometry to reveal the background behind everything (i.e. leaving only the Alpha Channel). As such if this little bug could be harnessed it could turn out to be a valuable feature. (i.e. anything this material was applied to would not only disappear in that particular scene it would cut a mask/matte all the way through to the background) I suppose it will depend on what exactly the nature of the bug is. What might success look like? I dunno, perhaps a second Multipass setting that allowed the user to enable this strange behavior. It does appear to be Multipass related as I was rendering with 4x passes when it occurred. UPDATE: Note that the hair rendered fine with multipass off (although I tested only for visibility, not for correct color).

Thanks for the follow up Nancy. I did note that there were both C and D directories but when A:M didn't find the images I didn't dig for them. In hindsight I should have. I guess I was too anxious to play with that Panda. Here is where I'll state that I don't like to rely on the Consolidate feature but prefer to embed files in the project and then make sure any images are in the same folder as the project and then zip up that folder. Consolidate works great but copies entire directory structures. But the real reason I don't like to rely on Consolidate is that files still sometimes aren't found. I will note however that they are usually there and can found. I like automation but some things just work well manually. More importantly, it does appear that all your files (images/textures that is) are in the D directory created when unzipping your consolidated project file. This was another image that came up missing BUT... and this is an important BUT... If I run into more than one image that is missing in a project file I will often check the box that says, "Repeat for each subsequent file" (or whatever similar message A:M displays) and then hit Cancel. The file MIGHT HAVE loaded if I would have gone through each and every one and searched or canceled for those that could not initially be found. I'll have to reexamine why it is that I do that but my memory says that when working with older files (such as for the Extra CD/Extra DVD) I got into the habit of discovering many links to missing files. As such I'm really glad A:M has that 'Skip everything else that is missing' option. Note that I usually don't give up on the image at that point... but I don't use A:M to find it. And that should bring us almost up to date I think. As I find time I'll try your Panda again with the correct textures! Edit: You said: Hmmm... I had only assumed that you constrained Panda's eyes to the Eye Target so that is why I moved the Eye Target back when I saw the eyes moving around too much during the jump. Perhaps it was constrained to the Camera? Another thing I'll have to check. That Eye Target is so useful I'd be hard pressed to give it up. It's a rare event that it can't be placed where it won't work (i.e. on the point of interest of the subject, on the camera, etc.)

A couple observations here: - The hair is obviously present but is matching the camera color of the sky I am assuming this is reflectivity but will have to check. If not... we should invest in that material because it would be making things invisible... which would be highly desirable for split renders. Edit: Interestingly, we can see a sliver of green hair underneath the invisible hair. This also suggests a reflection from the sky because that area is in shadow. - Just as I was hitting render for this I remembered that I had 'disappeared' Panda's snout before rendering the jump. My rationale for hiding that geometry in the Model was two-fold; first because it wouldn't really be seen and second because it made the panda look like he had two mouths. If one looks at the bottom of the snout that itself can serve as a mouth... and in the current render if the (red) mouth were removed it would look like a goofy grin. - During any project I usually have a laundry list of things I don't get to and this one had several. Colored ground plane was one and a more elaborate 'bouncing' of the ground when Panda hit was another. In this render the shot is advanced one frame more from the screenshot. This initially was to avoid a nasty tangent with the top of Panda's head and the ground... but then I altered the ground. Not much of an improvement, but that was were I was heading. If this were to be a full fledged scene I might have some trees in the background that launch up out of the ground every time the Panda hits the ground.

So that I'm not wasting too much of anyone's time I'll add some more into the mix. While I've got a larger image rendering here's a screenshot from mid jump... Note that I've made three changes since the last render (the one the gif was created from): 1 - Tweaked the hair again to see why it wasn't green (it looked like it had reverted to purple) 2 - Cranked the Cornea Surface Ambiance Intensity up to 100%... I tend to do this for all my eyes to get them to show up clearly... especially for toons 3 - I added a light just in front of the head to light the face (I made it a Light List Light under the Panda to keep it from casting a shadow on the ground) And drat, a this larger size you can now see how lazy I was with positioning the mouth. Stand by for larger render...

I should first apologize profusely. I should have noted that my rendition cannot even be called your character anymore. It's a rather long story... When I opened your file there were missing images (for the hair... both feather and hair that is) but I wanted to play so I started tweaking the hair to taste which ended up being a tweak of almost everything in the model. When I almost had everything done I animated a quick run cycle and... crashed... and lost everything. So, I started over and tweaked more. I used a (mostly) white image for both the hair on his head and the feather (after experimenting with a few other colors). I then used Red (for the feather) and Green (for the hair) in the Group's Surface Properties. As for the body... I didn't see any hair applied to the white of his body at all so I just added a little noise and specular to round out his shape after lighting the shot from the top in the Chor. The gif conversion did that. What can I say, I somewhat partial to the ugliness of low quality. I've been thinking of doing entire movies in low rez because I like the look of it. (although I recognize that few others do) v18.0b Gotta run that new release through its paces! So again, I apologize. A larger image won't reveal anything important but I'll be glad to share the project file (or a larger render) if'n you really want it. (I can't image why anyone would) I posted the small image mostly because there isn't anything else to see beyond what I have shown. And I mean that seriously. I didn't even animate the character correctly enough to be rendered from a 3/4 view. I am a truly sad specimen. But I *was* having a lot of fun while I was doing it. Edit: I see I missed a question or two: I moved the Eye Target farther out in front of him so that when he jumped his eyes wouldn't get lost. The Eye Target is stationary so that he has something to focus on (It's a Don Bluth thing) Probably because I didn't take the time to add a light to do that. Doh. Good eye!

Disclaimer: I haven't tried this out yet but spotted it and wanted to see if anyone had given it a shot. Anyone? http://www.greentoken.de/onlineconv/ Obviously when you upload a model you have shared it with the server. If the model you want to convert is precious to you and you don't want it out there then don't use these types of converters. Here's the basic info (from the website): If enough people upload .MDL files (which will fail to convert) maybe they'll write a converter for A:M model files. One can dream. The author is a/the developer behind the Open Asset Import Library (Assimp) and associated viewer (C++ etc.): http://assimp.sourceforge.net/ Features of the Library include: Written in portable, ISO-compliant C++

This is a fail on several levels but I wanted to post something by way of saying 'Thanks Nancy!' A couple areas that didn't turn out as expected: - The panda's hair appears to have disappeared (I believe it is hiding inside his head) Edit: Looking again it may just be the global ambiance that is making it the same color as the background. - I thought I would subtly animate the camera and overhead light to augment the landing... erk. Not so great. - The whites of his eyes don't show up. Perhaps I need to up the ambiance. - Too many other things to itemize... Fun character though! Love your rendition Nancy!

Made me smile!

Happy Birthday Dimos! Live long and animate!

Thanks, obviously I haven't tried very hard. It's good to know that the Named Groups and colors get through intact. That alone is very useful. My naive view on the subject has me thinking folks have made this much more difficult than it needs to be in that any instance where those groups are preserved it is (relatively) trivial to assign materials to the existing group (and much of that can be automated). If the group is identifiable (i.e. by it's group name created in A:M) then (as Robert suggests) it becomes mostly a matter of swapping textures/materials out. For instance if three folders are created: Live A:M Other Where the files in the live folder are written over as required and the files in the other folders are (for our purposes here) static. The program always points to the same location (regardless of program) while the targeted data from service/provider is then borrowed just in time. One obstacle to this is the naming convention we normally use with files (we see a file extension and begin to assume things (correctly or incorrectly) based on the assigned type). But ultimately we (the end users) don't care about the file type, we simply expect it to work every time. Any file named the same as the Group in the Live folder will work in the scene with texture and lighting. (Here we implement a system that can measure the degree success via the users reaction) So for the users purpose all the files in the Live folder are extension-less (they simply serve as a bridge between otherwise incompatible files). Of course, behind the scenes the program must know the file type in order to deal with it correctly. Any program could look at the live file and determine if a texture or material named 'Tire' is present. If present it proceeds with the test to determine if the correct tire-type can be applied. If the correct tire-type is not present the program prompts the user to supply it. Once supplied the object is tired/re-tired. This becomes even more trivial when the data in the Live folder isn't physically based but stored in memory (where algorithms can fully optimize them). So in the end the problem is not overly complicated but boolean in nature. Then (with regard to user experience) one need only test for false positives which is information the user supplies. At the beginning of the collection of files there are many incompatibilities but the more the system is used the more it reduces to fewer and more trivial incompatibilities. Perhaps the most important thing however is that once in its proper place it can then be relied upon. Added: I should make this post of some use so here's a link to the Mitsuba renderer: http://www.mitsuba-renderer.org/devblog/ (I checked out online renderer Yves posted a link to. Very nice.)

I can't find them now but there where several articles online that used this dragon as an example of game changing technology. Charles is leading the way and it's exciting to see that he's using A:M to get there.

Yes, when first reading Mark's post my initial reaction was, "Oh, that's not a good thing." But very good things can be derived from not so good things and in that Mark has shed a little light.

Sorry to go off topic on you Philip but... I can put your current email address into your old profile if you wish. In order to do that though we'll have to change your new profile's email to something else (even if only temporarily) Feel free to email me at: rodney.baker@gmail.com if you have any concerns with forum login, etc. *You actually have two profiles named Philip Fong. Once was only used twice. I assume you'd want to use the one you've had since 21-February 04.

I'll look into that and see if I can remedy that. I've forgotten as well! Now you've got me curious.

This sounds like a winner to me. Although I would think it would crash on every attempt... not just on v13 files... I'll add (and Robert's video suggests this) not to render out to AVI or MOV but rather to a sequence of images. This saves so much trouble in the end (i.e. what if the power goes out while rendering? What if you need to rerender 3 frames of the 5242 frame sequence? What if you want to remove frames (easily) without rerendering? etc. etc. etc) It's generally very good practice to render out to individual frames and then zap them into the final video format via A:M or any available software tool optimized for converting images to video. An added benefit... you can remove this unnecessarily wasted time from your workflow by shifting it well outside the area of immediate concern. And perhaps best of all you can even automate it. In Robert's video he demonstrates the easy way to convert a sequence of images to MOV or AVI and it takes a lot less time than rerendering. There are a few things to watch out for of course (i.e. frames in the sequence of differing resolution or missing frames within a sequence (that'll stop the process immediately). For what it is worth I will suggest that unless targeting the web for display of images the PNG format should be avoided as well. I realize I might have to defend this position and am more than willing to do that for those interested. For heavy lifting with images that need to have any transparency I would recommend Targa and EXR... Targa being the old standby that rarely fails and EXR being the most modern image format available. If those images are needed for use on the internet then they can easily be converted as well.

Here's the part where I think I get lost. Are you saying that your Named Groups and (basic) Surface properties are retained in the exported model? I've always had trouble 'creating' groups in .obj files (they might be there in the model but the external program doesn't suggest they are there) so that would be a very handy thing to learn.

Ah, I think I'm following you here. Yes indeed that is very interesting... and (more importantly) useful!

Hi Philip! I'm not sure what is going on in your case because without something to test against there are too many variables. Just in case you aren't doing this... here's a simple way to reduce those variations: Immediately after opening an older project (model, action, etc) in a current release it is good practice to save the file again. Under a new name of course as you don't want to overwrite the original. What this does is update all the various bits and bytes that have been optimized or changed. It would be good to resolve what is happening in your specific case of course but you may not have the time or inclination to resolve problems that technically no longer exist. Projects from v13 should have no problem rendering in v18. So the first things I would do after opening the v13 project in v18 would be to save it back out again under a new name (example: 'thisoldproject(v18update).prj) If that doesn't get it to render then at least it narrows down the possibilities to more specific areas.

Lumion has some very nice aspects to it. I suppose it all depends on the purpose it is to be used for and it certainly excels at that architectural flavor of rendering. As such I can see it being used to create/populate backgrounds which in turn could be used with A:M. It does implement some things that would save a lot of time if setup in A:M (creating a Chor setup or Project that allows the user to set a time of day and have the lighting adjust accordingly). That's more about optimizing settings and sharing them with the community than anything else however. The HDR assets are readily available and waiting to be exploited. We (collectively) just don't use them as often as we should. There is a free version for non-commercial use so everyone can use Lumion to some extent. The free version contains a watermark. The next tiers cost $299, $1499 and $2999 respectively. http://lumion3d.com/free/ Note: The free version is 3.2 but 4.0 is about to be released. I'm not sure if the free version lags behind or if both free and paid releases stay in sync. At this point I assume they stay in sync. Disclaimer: Lumion doesn't run on my current system. It fails to pass the initial benchmark test that runs when first loading. I'm not sure if this is a hardware issue, a RAM issue or perhaps both but some sort of graceful exit would be ideal. After all that's the whole point of running the benchmark. Here's the minimum requirements: My current system fails in at least two areas.

A whole lot of folks celebrating their big day today! Mr. Jaqe(25), Newbert_Zero(25), mschoenhals(46), Davoid(56), jason1025(35), Shelton(52), AZ3(42) Happy Birthday one and all! And here's a special shout out to Steve Shelton who is making great progress on his short awhile keeping us updated via the "Cupid's Sick Day" special topic: Cupid's Sick Day (I always enjoy those looks behind the scenes) Have a very happy birthday!

One of the neat things mentioned in the interview was how the artist was able to see the cycling even while creating the art. This has direct implications for the creation of animated art today beyond the element of color cycling. By this I mean to say that one could create a 3D mask (a shape in 3D space) where things either move or do not move (i.e. toggle the mask to be either negative or positive). Outside of this mask the assigned effect would not apply. In other words, the cycling of data would be defined to allow movement/animation of objects (or surfaces of objects) to be visible (or not visible) anywhere in 3D space in realtime. Shades of Boolean cutters anyone? Why would this would work better now than in the past? Because technology such as deep pixels didn't exist back then and the cycling of pixel states is no longer confined to the pixels stored on 2D planes (i.e. linear). This surely must be related in some bit-wise way to the tech that is coming online that allows objects to be removed from video without effecting other content. Seam Carving itself follows the general outline expressed by the artist when he describes how he used a template to limit his view when drawing the path of rain or snow in his color cycling drawings. Okay... I had better stop there before I hurt myself.

While very impressive its still a bit sad in a way because the underlying imagery requires 30 year old software no longer available. According to the write up those image where still created by Deluxe Paint although translated for use in modern day browsers. The orginal imagery being translated to JSON for use in HTML. Very impressive though. Added: It's interesting to note that the author has improved on the original technology by producing what he terms BlendShift Cycling. He explains it thusly: This in my estimation is why old tech needs to be revisited often because things can always be improved upon later.

I was commenting the other day to someone offline that there are many little things from back in the DOS days that current programs don't take advantage of. Color cycling is certainly one of them. It may be that these methods are used but mostly used behind the scenes and not through the interface by current users. Color cycling surely must be leveraged in game engines for instance. This may be one of the downsides of the overpowering (and useful) technologies introduced such as the Alpha Channel. When those came along there wasn't much use for the tricks/workarounds used to overcome the limits of 8bit graphics.