Rodney

I just noticed this earlier yesterday but wasn't able to test until now. Perhaps someone else can confirm if they are having similar issues in v18b? When drawing (any interconnecting) splines in v18b and creating a new spline by attaching to a previous spline A:M goes into 'thinking mode' and a pause spinner initiates like it's searching memory in order to complete the task. A:M is then locked up at this point until a forced close. I checked in both 32bit and 64bit and am getting the same results. I figured this might be something I changed recently but checking in v17g... no problem drawing with splines noted. Very odd. Perhaps I toggled something on/off in v18b that is different. I've reset, restarted the computer and ran A:M in Admin mode and am about at the stage of reinstalling but with a new release on the horizon I want to make sure this isn't something that might show up in the new release too. This surely must be isolated to me because others would have reported this by now. I'm pretty sure I've been modeling in v18b prior to this but perhaps I was using an earlier release and didn't realize it. Can anyone confirm?

Drat. I read your topic title and thought you were posting a Screen Space AO tutorial. I have no clue about SSAO so would love to get educated.

Hehe. Great characters!

Success! The only thing I changed once the files were open was the image filename, filetype and location to render out to. This render is with whatever default settings were setup on my end (I'm pretty sure that was the case). This may be an opportune time to deal with talk that out too although it might be a best to bring in some newbies and discuss it in a new topic. I'd recently reset my settings to default and that appears to be what my render settings defaulted to for your project. Does a project override a user's settings that might be set to 'this dialogue' (local settings) over that of the camera? I ask this because I'm wondering what the optimum approach to 'publishing' A:M Project files is with regard to getting everyone to see a project exactly as the one who submitted it. This is largely due to my current orientation which believes there is no better 'viewer' for A:M files than A:M itself but some variables may not get all the way through? It's my understanding that for such a thing as rendering, the user might have to be told to change the setting within their options tab to render using the camera. My gut feel has been that a Project saved that uses the camera will render perfectly (i.e. as directed by the camera settings) but ONLY if not overwritten by the user's use of 'Render using this Dialogue' setting in the render panel. Sorry to bore you will this off topic stuff... I actually hope I'm wrong in this and it should be easy enough to test. I'd like to think that due to Netrender usage the default will always be the camera but... I think A:M defaults to 'Render using this Dialogue'. Thanks for the prestine project file Nancy! (I saw that rose in there and wondered where you had used it)

I thought I had read that right! Thanks Marcos. What's a little funny discovering this short is that just prior to finding it I had been to several animation blogs that discussed at length the benefits of characters that are 'two heads tall'. This is pretty well known so I didn't think that much of it but as I started to look around I began to see two head tall characters every time I clicked my mouse. I started to think, how long will it be before all the film companies start thinking they need to put out movies with characters that are exclusively two heads tall because that is where the money is. Then I almost immediately ran into this short film and then saw the 'coming soon... feature film... blahblahblah'. These are very simple characters but they didn't cop out entirely as evidenced by the multiple appendages. It'll be interesting to see how they differentiate the characters even more in the film. With Despicable Me's legion of minions and PIXAR's monsters etc. etc. it wasn't going to be long before Dreamworks dived into the two heads tall arena. Given that these films take five or more years to generate I'd say this 'two heads tall' thing has been in the gestation stage for quite some time. One wonders who else this desire for edgy cuteness may rub off on.

Thanks Robert, you are above-and-beyond-the-call-of-duty awesome.

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!