frosteternal

Getting it to work with A:M's settings etc wouldn't be the worst thing ever. Current A:M materials lights etc would ideally be converted on the fly to Prman shaders. The main advantage that PRman has is its a VERY extensible renderer. Shaders can be written to incorporate any new tech or custom effects that a TD and an army of coders can imagine. However, there are also other advantages: -Motion blur. Prman motion blur is outstanding. (Not always physically accurate, but usually "looks right") -Complex scenes. The renderer can power through pretty much anything you throw at it, given enough time and computing power. -Hair rendering. Again, PRMan excels at complex scenes. Hair can be rendered directly as shaded curves or geometry. There's no reason A:M hair couldn't be exported at render time. -Network rendering optimized. Because it's built for large scale production, distributed rendering was built in early on. -Displacement mapping. PRman displacements are relatively fast and very robust. -Constantly Updated. This is HUGE. The renderer is CONSTANTLY being improved. New lighting models, shading methods, features, speed improvements, stability. -Industry standard. (Supporting PRman in some way definitely improves the prestige of a 3D software. That seems pretty minor, but A:M has a pretty bad reputation of being a closed system. Adding Renderman support would be a great answer to that.) I'm not sure that's it's necessary, but with this new noncommercial license, many hobbyists are going to want their software to support their ability to play with this new toy.

I'll just toss in my 2 cents regarding rendering engines in general: Different rendering systems excel in different areas. One of the most-used production renderers is Pixar's PRMan - but one of the reasons it remains popular is it is entirely customizable. New shading methods can be written for any imaginable effect or surface, and it has been highly optimized for that sort of rigorous and highly extensible environment. PRMan is optimized for animation, it is not, however, optimized for a single artist doing an entire project on their lonesome. As people have already pointed out, A:M is designed to be accessible to a single artist - as much power as possible with the least amount of technical obfuscation. This is definitely a strong point. I personally use rendering features that A:M is not as good at - advanced lighting models, certain blurring effects, instancing, etc etc and while I model many organic forms in A:M, I do move into other packages for texturing and lighting (Texturing, by the way, is MUCH easier in A:M than other packages.) Really, though, depending on what a client needs, I use the best tool for the job. I did a whole project modeled, animated, and rendered in A:M a couple years ago - and the client loved it. It was a cartoon-world theme park project and A:M's renderer was perfect for rendering all the scenes, characters, etc. It was a dream doing everything in one package =) However another project called for a near-photo-real monster that needed matted fur and fire-laced breath. I ended up using three different programs to achieve that. (A:M was used for a multi-limbed humanoid creature in the same project. Renderer and all.) Most recently I needed to model and render a hi-res still of completely photo-real pen. I actually had to switch renderers mid-project to achieve the perfect result and still finish by the deadline. (Client was EXTREMELY picky) Basically, push your tools to their limits, but be willing to learn a new tool if your creative vision demands it =) Okay, done babbling. =)

Do you have "show Advanced Properties" turned on in the options?

I'd recommend first of all changing the neon green color that encompasses the scene. Something a bit more muted will light much better. Also, do what Rodney says - dump all the default lighting. Figure out what you want to highlight and show in your scene and add lights that achieve those goals. Lighting should reveal your scene, not simple flood it. Also, make sure that ambient settings are turned off in camera.

A live action cable show has a good deal less risk, loss-wise, than an animated feature-length film.

This is really interesting. I wasn't aware that something like a character smoking would be seen as a liability nowadays. I mean, look at Pinocchio - the main character himself is seen smoking. Times sure have changed. People are unreasonably jumpy. I'm glad I'm in LA - we usually get films when they say "limited release." Hopefully this is playing somewhere around here it sounds worth a viewing.

This is awesome. Thank you so much!

Agreed 100%

Thank you very much. It works like a dream, temporary fix or not. THANK YOU VERY MUCH

Rodney, I'd be glad to stick with A:M as well as using other software. In fact, that's what I was doing, as I often use several programs to complete jobs. However, my favorite organic modeler just stopped working on my computer.I've always had a soft spot for A:M but if it can't be relied upon to launch after a routine upgrade (Mac users generally consider OS upgrades routine) then I can't rely upon it as a tool in my day to day workflow. Calling out people as "doom and gloom" when some of us express concern over a major failure (inability to launch software at all) that jeopardizes our work and income doesn't help either. A:M is a tool. If it breaks, expect people to be wary of a relying upon it. If the trouble with running A:M on the current OS is fixed, I will of course continue to use it, albeit cautiously. And other Mac users will too. But I think it is reasonable to expect that A:M going forward be made more modern and Mac compatible so that we don't have to live in fear of updating our computers.

Back in the day, Hash Inc had to develop code (custom libraries, etc.) that didn't exist in the Mac world from scratch to support A:M on the Mac. Apple didn't have the tools for it yet (probably still doesn't) and certainly weren't going to build cross compilers to help push code toward their PC competitors. So Hash Inc had to go the hard route to support their Mac users. Which BTW, they gladly did. In hindsight it's easy to surmise what should've been done where reality dictated it couldn't. The real lesson learned here: Do not make major upgrades to your operating system in the middle of a production cycle. This is especially true for those who are oft tempted to be early adopters. The results: predictable. That is not true. There was a conscious decision made to support one code base for both PC and Mac. It wasn't that the tools "weren't there" - A:M had been running a separate codebase, albeit a bit behind the Win version, for the PPC Macs. The decisions was made to use the cross-platform approach when Mac switched to Intel chips. It wasn't that there wasn't any other way, the easiest solution at the time was chosen. Now that that solution has begun to fall apart, perhaps it is time to re-evaluate the current efficacy of that path. It still should have been caught before the new OS went live. 6 months is more than enough time to install a beta and notice that A:M doesn't launch. Then there could have been a warning issued - not a fix, but a warning - not to upgrade until the problem was ironed out. Over a week later, there still isn't a warning on the web store.

My point is that this a program we pay for. It isn't a hobby, it isn't a lark. This is a product that people pay for, and it does not work on the system that it is advertised to work on. That should be unacceptable to everyone. I understand limited resources. But there is NO excuse for a commercial software program to be "maintained" by a single person in his "spare time". No it won't be fixed by my being upset, but it's really only a matter of time before this kind of shoddy and unprofessional approach pinches someone on the windows version. This really should concern everyone. I have a been a loyal user of the software since 1994. That is almost TWENTY YEARS. I have purchased countless versions and upgrades, multiple licenses. No company in their right mind blows off long time users like this. Again, I point out - WE KNEW THE OS UPGRADE WAS COMING IN ADVANCE. The problem should have been tested and discovered IN ADVANCE. This will affect new users as well as old. Saying "buy a new license AND a new operating system" is not a fix. It's a kludge. And fairly useless. Can't maintain the Mac version? Well then A:M needs to no longer be marketed as a Mac compatible application. Problem solved.

Expecting new software to run on an old system is not a generally expected feature. Expecting new software to run on THE CURRENT OS is not an unreasonable expectation. If A:M had been natively coded in the first place for Mac we would NOT be having this problem now. Paying $110 to install windows on a Mac is not a good solution either. Running a separate system compromises efficiency in workflow (ALL other software used is Mac Mavericks compatible) Also, that entails buying yet another license for A:M. Unacceptable.

Sorry, but just not right. They force you to use a Mac-System with the current MacOS, pay money to be able to develope for their platform, use their IDE and so on. It really is not developer friendly. Play after their rules and everything is fine, but try to play outside of them (like using a Linux or Windows system, use a OS which is not current, etc.) and you are not able to develope at all. This has some advantages (at least for apple) but all in all it is very hard for someone who wants to develope for different platforms. For Windows you can at least compile many applications (MFC-based once are tricky, everything else is not) from other OSes without having to use their IDE (Visual Studio is only needed for MFC-based applications) if the compiler runs on it (like GCC+, which runs on Macs, Windows and Linux and is free). For Linux you can compile with any OS and any IDE you want. Apple may be developer friendly for (no other but current) Mac-developers, but that is the only aspect they tolerate at all. It is a pure "one to rule the world"-approach and the biggest disadvantage Macs have if you ask me. And it is important for a developer that the OS is backward compatible which ApplesOS is not that good at. This is a advantage for developing the OS (or for Apple) because you do not have to careful about what you change, but it is a real pain in the ass for developers... See you *Fuchur* Yeah, except that is *how* you write a program for a Mac. If one don't use the proper tools in the first place then one can expect things to break. Just because one can use whatever IDE etc for developing on X system doesn't mean that that approach does, or should be expected to work for another system. That's like driving the wrong way on a one way street and then getting mad at the road when you get in an accident. There is a right way and a wrong way to develop for the Mac. It's annoying that one of my favorite software programs doesn't follow developer standards and now is broken because of it. It's annoying that no testing was done in the six months that a beta of the new OS has been available to developers. It's annoying because I purchased a brand new second license an hour before finding out that A:M does not run on current OS X. (I feel I am due a refund, which I have requested.) Actually no. It's just sad. This one's a dealbreaker. Bye guys. It's been fun. =(

If you want a transparent image of the character, with cast shadows, that you can overlay on live action, you need to render two passes, minimum. One is the shadow pass, use "shadow only" with alpha turned off. You will add this to your live action scene with a multiply blend, which will make the white transparent anyhow. The next layer is JUST the character. Make sure alpha channel is on, and add this over your live action shot. You will have two image sequences to composite with the live action. (You can't render the character + alpha + cast shadows as one image, if you intend to seamlessly overlay on live action)