robcat2075

I'm not familiar with elephant dreams but he looks like a serious work. Gonna be tough to rig but you're up to it.

If you click in the background, the hidden black model bone will become visible. That is what all points are assigned to before you assign them to other bones. When the black bone is flashing you can assign points to it, making them not assigned to other bones.

He needs some sunscreen! The nose seems not quite Indian-like. Is it based on a reference?

Why? Because some one has a Mac, doesn't run windows on it and wants to use A:M. As far as translation... Martin has said in the past that A:M is developed in a codebase crafted so that it can be compiled for PC and compiled for Mac. It's not written for PC then translated to Mac or translated by the mac. The Mac version is "mac code". There was a window feature in V11 that went away in V11.1 because there was no way to do it in the Mac OS. That's an example of the codebase being conformed for both of them. I'm sure the code is "written" on a PC but that's a just working in a text editor. A lot of things are different in the two compiler results and obviously the Mac version isn't as fast. Why? That would probably take some serious technical diagnosis from Apple (or Microsoft, which wrote the libraries that make mac compilation possible). Microsoft no longer supports its Mac libraries, and Apple obviously wont support them either. If you're developing apps for Mac and PC these days you're on your own. So says Martin. Apple is currently screwing one of their oldest developers, Adobe, over Flash. They could probably get together and fix whatever is supposedly wrong with it, but the real problem is it's not Apple's. So i imagine the prospect of a small company like Hash getting help from Apple is dim.

I can tell you that with all the displacement material tests I've done the 127-128 neighborhood gave me no displacement. In those black background tests, the depression for the black spot is gone. that tells me that ,for displacement purposes, the balck alpha area is being interpreted as 0,0,0 gray resulting in full depression.

Is there any value you can put in the gray and not have the edge of the alpha make a visible ridge?

Gray 127 made a slight displacement when I cranked the level up high. 128 seems to be true middle. Here's a test with gray=128 and displacement set to 10000% There's no displacement created where the gray decal meets the undecaled portion of the model.

I'm not sure a transparent PNG is a reliable tool here. A displacement map is a grayscale map. Once you start adding transparency to gray...

Here's my EXR depth map EXRGrayZip.zip Open EXR plugin for Photoshop Open it and see if the gray is indeed 127?

When I set my gray to 127 and paint that on a map, as I did above, I get a map that does what middle gray is supposed to do. Zero displacement. Someone's got a gamma setting somewhere not set to neutral OR maybe they have Photoshop's "Color Management" turned on. Turn that off so that numerical color values retain their numerical color values. I have yet to read a cogent explanation of of how get Color Management to not mess things up for CG work.

If your middle grays aren't coming out middle gray, something is set wrong in Photoshop. When I make a map in Photoshop my middle gray comes out middle gray and creates flat displacement like it ought to.. This 16 bit map was saved in EXR format. My Photoshop doesn't do 16 bit PNG

soften discussed: http://www.hash.com/forums/index.php?s=&am...st&p=165102 I find the effect of Soften to be minute and unnecessary for any purpose I've had. Perhaps someone can demonstrate a useful scenario. You can see the difference by rendering (multipass must be >4) a frame ON and a frame OFF, then dropping both as rotoscopes into a new A:M chor. Zoom WAAAAYYYY in to a sharp edge, then flick the lower rotoscope visibility on and off to quickly compare the two.

But I already have one. That makes it my cheapest path to 64-bit Windows7, which is what i need to get to.

I just tested it. It works the same either way. Make sure "Apply camera post effects" is ON. And make sure you're really rendering from a camera that has that post effect applied.

We got into soft reflection a while ago posts 18-24: http://www.hash.com/forums/index.php?s=&am...st&p=322831 Also TechRef p.234

Thanks for that report. I'm probably going a different way now. I remembered i have an Intel Core 2 Quad Q6600 and a mother board for it sitting on the shelf from the last time I was itching to build a new computer but never got around buying the rest of the parts. So I guess I'll do that. It's like finding a $100 dollar bill in the couch. I'm trying to shave my remaining parts purchases down to $300 The Q6600 is a supposedly very overclock-able version so I'll be curious to see how that does.

They had an external app called a "node cloner", but that only works on files from before V13. Is that what you mean? I'm trying actual dragging in A:M and I'm just getting a no-go symbol so far...

Ease isn't really a part of TransistionToNext Action. Ease is the property of the action that determines how far through the action you are at the current frame. By default it always says 0% but automatically goes thru the action at that same speed as the keyframes in the action. But when you set ease values you can change that. If you set 0% at 1:00 and 50% at 5:00 and 100% at 6:00, the action will slowly play from the beginning to the halfway point from 1:00 to 5:00 then quickly play the last half from 5:00 to 6:00. You can set any % on any frame so you can make actions halt or reverse even. You could use ease to control what part of the action is on when the TransisitonToNextAction begins or what part of the next action the transistion is moving towards. No need for that. You already got me the mic. Thanks!

here's a brief look TransitionToNextActionH300.mov

I don't know enough about MAX to follow the interface, but it resembles what we do with combiners in A:M materials. I know we have those same noise patterns in A:M. Most of my recent material experiments make substantial use of combiners I haven't written my book on this subject yet. We don't yet have the ability to freely drag and rearrange nodes like in that interface (I presume it does that), but I've found moving nodes in a text editor helpful in the mean time. Procedural materials are somewhat un-intuitive to work with. The guy who did that demo knew what he was doing and what his options were. That will be key in A:M also.

in the PWS, on Post Effects>New>Post Effect on the new Post Effect >Change Type To > Hash Inc.>Tint "Tint" has a "style" preset for "Black and White"

Great render!

First, is "transition to next action" not enough for what you are trying to do?

did you enable "Show more than drivers" in the chor?

As i see it, the artifact is at the intersection of the sprite with the emitter. Only the portion of the sprite that is on the viewer's side of the emitter surface is visible. This is apparent by spinning around the model when a particle has a portion on both sides ( I deleted the back half of the sphere so i could see inside) We should be able to see the whole particle thru a 100% transparent surface, but we don't. It's getting clipped. Possible work around... make your sprites 100% transparent at the beginning of their life and fade them to 0% transparent after some point when they would have cleared the surface of the the emitter. Haven't tried this.