robcat2075

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.

It's possible to start over and rewrite A:M to be compliant with the new Mac system but it would be a huge effort and it comes after all the development time and money has been spent doing it a different way that used to be acceptable to Apple and before there was any warning that this new requirement was coming down the road. All that work just to get back the program we have now. It's possible to do but, as Martin says, "It's possible... like going to Mars is possible." I'm hoping Steffen can find a workaround.

$49? Per month? Doesn't just about any archiver have a way to define a backup "job" that you can tell it to do at any time?

I would think there's already a 3rd party archiving utility that could be directed to archive some specified set of folders for a project. Maybe it couldn't be triggered IN A:M but you could make an icon on the desktop that would do that. Or maybe the icon could be added to run from A:M's Tools menu.

May you have 200,000 more!

True. Of course, that's a problem whether the incrementing is manual or automatic. But that scenario is a reason i tend to save PRJs with everything embedded when i am developing an idea. I like being able to save the whole schmear as one chunk. Disk space is rarely a problem these days.

I used to think that Mr. T came up with "I pity the fool..." but I caught once it in an old movie. Wish i could recall the title.