robcat2075

Stefan, I think this is a bug we can report. i notice that the constraint properly positions the pupil on the 1st, 3rd, 5th, 7th etc, frame but not on the ones inbetween. That is odd. I'll look at this some more. In the mean time... could you add the pupil as a separate model in the chor and do the surface constraint there? Does that not work? I believe a distortion box can do this although it's a bit fiddly to work with.

I'm not sure about the tut, but with your current license you can install and run v15 or 32-bit v16 and use it to rig with TSM2 Just copy the master0.lic file from v17 to either of the other installs.

Yes. After you've looked at enough of them you start to recognize when something is seriously malformed. It helps to have one that works and one that doesn't so you can compare.

Here's another case where text editing was able to resurrect a file damaged by a power outage... Model "disappeared" after power failure, Model won't appear in Project Workspace Post #6 has screen caps comparing damaged and undamaged versions of the file.

The first thing i did was compare the beginnings and ends of the two files. The beginnings looked fairly similar but the ends were very different Junkman07.mdl (the older file) ends normally with a tag, but Junkman_full_02.mdl (the new model) doesn't get that far. It looks like it died halfway through writing a tag: I copied the missing text from the first file and pasted it onto the end of the second file. Try this. It looks like it loads OK. I didn't test it beyond that. Junkman_full_02x.mdl We're lucky that it died at the very end of the file and that only basic housekeeping info was lost. And we are lucky that A:M stores its files in human-readable text so that this sort of repair is easy to do!

Probably the only final render element that might be graphics card dependent would be the Screen Space Ambient occlusion effect in v18, but that would not have been in play in your test anyway. Looks like about an 18% penalty on render time for the mac which isn't too bad. it used to be many x worse in the Power PC days, i think.

I f you want to send me the two versions of the .mdl file I can look at it. You can attach them in a private message if you don't want to post them here.

Thanks, Rodney!

I would note that Ralph Bakshi did way more than characters smoking cigarettes in his stuff right here in the USA. He gave it a shot. There really isn't movie censorship in the US. There is no government panel on that. You can pretty much show just about anything if you can get it in a theater. However, the theater owners themselves generally won't show anything that isn't commercial and lots of cigarettes won't sell lots of tickets. It's true that Miyazaki would never have made it here, but there's really no equivalent to classic Disney or Warner Brothers from Japan, either. Those are things that could never have grown there. Every culture has its limiting factors, that's not a uniquely American problem.

Very amusing! I like the hippopotamus most.

A video and sample PRJ for making a surface constraint can be found this thread: Post#4

Here's a demonstration and sample PRJ SurfCon03__no_constraints.prj SurfaceConstraint_h500.mov

Article from the NYTimes about the problem of presenting "The Wind Rises" outside of Japan. http://www.nytimes.com/2013/11/06/movies/h...l?smid=pl-share

I think you have the concept backwards. The aiming bone should not be constrained to the thing you want to constrain to the surface. The aiming bone should be a bone in the surface you want to constrain to. The bone inthe model you want to constrain to the surface is not a child of the aiming bone. on the bone in the model you want to constrain to a surface Choose New Constraint>Surface Turn off the Compensate Mode Button if it is on Pick the bone the surface is attached to. In the PWS, A surface constraint will be created in the Chor under the model Select the constraint, then go to the properties window Set the Surface Aim Target property to the bone you want to be the aiming bone In my version of A:M, offsets are created even though I don't want them. Set the Translate offsets and Rotate offsets to zero to make the constrained bone follow the surface exactly Now the constrained bone will go to where ever the aiming bone is pointing on the surface. Don't try to animate the constrained bone. Let me know if that works for you.

How about if the freezing ray had icicles on it? And when the ray stops they break and fall to the ground.

I wonder how a spiral ray might look. There are lots of novel possibilities in color but if it's going to be B&W not so much.

That looks good. More than enough res for me! I didn't notice the globe flickering out before. Is there a reason for that?

Yay! Thanks, Steffen and Jason! Why, that little bump caused barely a ripple.

I should pay more attention to the news, I didn't even know there was flooding in Austin. austin-declares-state-of-disaster-in-wake-of-floods-seeks-texas-and-u.s.-aid

This? From this thread....

Sorry about the flood! Glad you have your data!

Did this get you what you needed, Simon?

I'm Facebook friends with one of the former A:M programmers. He still programs for the Mac in his current job so he definitely knows what that involves. I asked him to estimate the programmer-hours it would take to rewrite A:M as a real MacOS app. He said it would take two years full-time to get it rewritten and stable. That's with six programmers, not one. I believe he's right because he astutely noted that v5 and v9 were indeed rewrites from scratch for A:M and that's how long it took Hash's six, full-time programmers to rewrite the code and get it stable. That was with people who had written the originals and knew all about what was going on in it. If you were using A:M in the v5 or v9 days you know those were pretty disastrous for stability. That's what created all the anti-Hash trolls that populate places like CGTalk. There's no way going through that again would be good for A:M and there's no way one person would be able to step in and rewrite it anyway. It's unrealistic to demand that Steffen rewrite A:M for the Mac. There's no way in the past even six people would ever have been able to devote that time to just a Mac version. The only way it's been practical to have the Mac version is the current cross-development method where one code base can be used to make both Windows and Mac versions. Now even that economy is not working well. It's not Steffen's fault or the fault of all the previous A:M programmers that A:M is not coded specifically for MacOS, it was a practical solution to the cost of creating and maintaining a program that can't survive just on Mac sales.

But it wasn't realistically possible to pure code it. Not realistically possible to start over and rebuild it from scratch after it was already done once in a way that Apple allowed. Repeatedly saying it's "unacceptable" now won't make more possible for it to be possible. If the cost of Windows (way less than $110) is the deal breaker for you, then it's a deal breaker for you, and you need to learn some other 3D program. If that inconvenience is smaller that running Windows, that's the way to go for you. I know you want to be angry and want us to know you're angry but that won't get A:M recoded. My suggestion is a simple solution that is proven to work. If you don't want to do that, then so be it.

When v17 came out I had to upgrade to Windows 7 and build a new computer to run it on because v17 wouldn't run on windows 2000 anymore and Windows 7 wouldn't run on what i had for a computer. I asked Steffen if he could make it still run on Windows 2000. No, the new compiler he uses now has many important advantages but it can't do windows 2K code. I would have to upgrade. A:M was the only reason i had to make that upgrade. I didn't get all angry about Hash refusing to support its Windows 2000 users. My judgement was that it was easier to upgrade my computer than to learn a new 3D software. Those of you on the Mac may have to weigh that choice yourselves if the Mac version can't be retained. If i told you there was a plugin for $80 that would make A:M run again on your computer you'd probably say that was worth it to not have to migrate to a different 3D program. That's the cost of adding Windows to your Mac to run the PC version of A:M. $80 If it were me, I know I wouldn't blink at that because I already spent WAY more than that to stay A:M compatible on the PC. But that's me. I enjoy using A:M and I have zero interest in learning something else for 3D. I recognize that it is more possible for me to accommodate A:M than the other way around. I recognize that Hash's options in all this are limited. I'll note that Hash did indeed make the jump from Power PC code to Intel code when Apple made that change. But since then there's been no way for it to be economically feasible to rewrite A:M completely to only use what is in the new operating system. It wouldn't matter if we were 20 years out instead of 7. But if that were done it would be a completely separate program to maintain. My understanding is that now there is one code that Steffen maintains and the compiler can spit out Windows and Mac versions as needed. It's not as bad as having to maintain two differently written programs. In general you only have to add a feature once or fix a bug once to keep both versions equivalent to each other.