NancyGormezano

Ooooo...purty

yeah that's a good one - excellent for clouds!

Most definitely. I have the dvd, and 14c and noticed: The original Dex model off the dvd looks corrupted to me. It comes in with 2 groups both named head. That's a no-no. Not sure how that was even possible. When I isolated just the neck/head area (deleted all other splines), resultant model looked weird, corrupted. This would be the best place to start with fixing your model. I suspect A:M was getting it's widdle brain all confooosed when trying to make the head transparent.

Exr is this weird format that anybody can define how to interpret. The format from A:M requires plugins (I believe?) to be used in PS, aftereffects, or it did at one time. The way to manipulate A:M exr files is via composite in A:M. Is that png image coming directly from A:M?or are you bringing it into PS and saving from there? It looks like it got saved as "interlaced"? Did you try turning OFF alpha for the png (do that) ? Are you rendering with multipass ON (don't do that)? and trying to switch between jpg, png and exr? Remember there's still a bug in your version - unless you tried 17a (do that)? Make a simple chor with just the transparent/reflective window, and your lighting setup, model to reflect in window, and rendering setup. Render 1 frame. There may or may not be a bug, but a simple project would be needed to send to A:M reports if so. EDIT: AND I might add version 17 has added the ability to save individual files for each of the buffer types (depth, shadows, ambiance, diffuse, specular, etc) for the image types png, tga, jpg. No need to fool with exr anymore in PS, AE, etc - whoooo hoooo! And they can be used in A:M composite as well! Muy bueno! EDIT2: I just tried rendering to png with 1) alpha OFF and 2) alpha ON (vers 17). Transparency for the window in the final render cannot be computed correctly when there is no background model (must take into account color, intensity of background). I also downloaded your png file - it definitely was rendered with alpha ON. Turn alpha OFF for your pngs, or put in some dome model for the background. Leave alpha = ON if you intend to add a background in post (aftereffects, PS)

Video drivers have nothing to do with A:M FINAL rendering. And I highly doubt that the registry does either. Even for version 14c. (I assume that's what you're using?) I am willing to bet it is more likely your project settings and/or model (ordering of groups) is doing something funny. The other likely candidate is vers 14c didn't do transparency so well, or had a bug in it. In that case, there may be a work-around or you're outta luck. Upgrade. You will definitely see a difference in resultant renders, especially with transparency, if you are comparing a final render, with an onscreen "render lock" in most every version of A:M (including 17). Show us the group settings in your model, and your render settings. Post 1 still of the final render which has a problem.

Make your ground plane: Front projected & Flat shaded Start with 1 light that has shadows, a default width Klieg type with z buffered shadows., use default softness of shadow, or tweak to taste, tweak darkness of shadow. Add other lights, if you must, but you will have to retweak. For this image: I believe I had chor/global ambiance Type = global Color = white, Ambiance intensity = 50-75-100?%, with 1 white Klieg probably 50-100%, shadow softness = 6.25%? darkness = 80%, color = black. Rotoscope image is all white (could be any image). I also used jenpy's fakeaocpu post effect for more darkening of "creases" on model. EDIT: If you use ray trace shadows (with any kind of light), then the ground should NOT be Flat shaded, or else the shadows won't show. The shadows won't be as dark either.

AS Mark said you should see the channels in the user properties for the phoneme poses. I just tried this in 15j PC

Not sure why this thread is in a private forum? It's a good topic, with valuable question and information for everyone. (Mod: Agreed!)

I might also add, I thought you were asking about the mechanics of blocking within A:M. I did not, in any way, shape or form, address the art of blocking, ie how/why one determines those golden poses, nor the best, most artful creative breakdowns/transitions, nor good timing with good easing, anticipation, follow-thru, overlap.

Not sure what kind of example you're looking for, but here goes: I started first with 3 keyposes where I had the Curve interpolation method set to HOLD, 2nd is where I changed curve interpolation method to LINEAR (could also, and probably more preferable, have chosen ZERO SLOPE). My third example shows linear interpolation of the curves, but added holding of each of the keyposes for 2 frames. I did this by copying the pose and pasting it 2 frames later. 4th example shows zero slope interpolation, which gives some ease in ease out to curves, with holds. (EDIT: Changed linearwithholds.mov, as I uploaded wrong file first time, added zeroslope with holds) hold.mov linear.mov LinearwithHolds2.mov ZeroSlopewithHolds.mov

To what issues are you referring? You can set the curve to "Hold" requiring only 1 blocking pose per interval or as some prefer, "Linear", using 2 poses for each interval (start & stop). I prefer Linear because you can also setup intermediate poses to show transitions.

wonderful!

(yes I know this started as a treez thread) Just thought of 2 other things that can be done in action window that can change the model data: CP weighting, smart skinning. There must be more.

Ooooo...that sounds interesting...me guste.

Yes. Use a transparency map along wiith your color map. The transparency map should be shades of gray (or just black and white) where Black = 100% transparent, and white = 0% transparent (100% opaque)

My guess is that it was done in an action because of the special way it uses sliders to determine the Treez special properties: Thickness, branch length, locality and regularity. See page 6 of the pdf for more explanation. Clever. It could have been done differently of course, but probably Marcel wanted to make use of some functionality that already existed in A:M, ie accessing pose sliders via an action. The pose sliders, defined by the user, for those 4 properties, can be used to refine and give more variation for the shape of the tree trunks, branches. However, it is not necessary to define these sliders, if you want to stick with the default or more automatic way the trees get created.

The treez tutorial also causes me to have MORE questions about the interconnectness of actions and models, and what manipulations in the action window will cause changes to the model itself. It is not always clear what will or will not actually change model data/structure when working in an action window. We more commonly think of actions as being reusable in a chor (eg walk cycle, etc), not as a means to modify a model. Besides making reusable actions, the normal things that one can do in an action window which will cause a change to a model without exporting to a new model (ones that I know about) are: one can decal a model in an action window, and one defines relationships/poses for a model in an action window. And as mentioned before, one can export from the action window a new model. From what I can tell tho, the Treez wizard seems to be a special case in how it uses the "A:M windows/modes". It seems to go way beyond the above. But I suspect it does this only because it was designed that way, and that it has gone rogue. I don't think it follows any standard philosophy of what you can do in a action window versus model window.

I don't know if this is new or not, but I just found out that bitmap plus materials work with imported props! AND so does the matcap shader. I did not try other shaders - but I'm guessing they work as well.

Very interesting effect! It looks like a walking raised relief image on the wall. I am curious tho as to how/why there is a solid black outline on stickguy? And that it changes as he walks across screen/wall? Makes the "walking inside wall" look strange (confuses the illusion). Is that a result of the post effect or are you using toon lines?

I have received notice that the jitter % property will be implemented in next release of 17, and that positioning of lights will be fixed. Thanks Steffen!

I don't exactly know what's happening with you (did you fool with alpha buffer ON/OFF...or key color??? - that might account for the different background colors) but, more likely: My experience with Composite has been that it's been very, icky touchy (in all versions, in different ways), and that it is very hard to get consistent results if you start deleting effects, changing their order, changing parameters, doing things in the wrong order. Very frustrating. I have found that if things start acting weird & inconsistently, it's best to start from scratch: ie, new project, import image sequence, new composite, and go from there adding posteffects.

I am willing to bet that you didn't have apply camera's post effects = ON when you went to render (camera/output/buffers) And yes, oddly, the quick on screen render would have shown the post effect even without that being ON

It may just be a problem with deleting lights and have nothing to do with AI in combo with props. I put in a bug report (which is reported to be fixed in next version) where there are only 2 bulb lights in the chor along with the ground plane. Sometimes when the 2nd instance of the bulb light is deleted, A:M crashes. If it doesn't crash then the 1st bulb light no longer illuminates the ground (scene is dark) (always). Since I couldn't get it to consistently crash, I'm not sure if the fix will address the crash problem. When it did intermittently crash, I believe I had monkeyed with turning on/off other properties, and/or I may have been trying to play with ambiance intensity before deleting the bulb.

Yes, all light types are jittered when rendering with multipass ON. However, if the light is large, the position change will be most noticeable. It is less noticeable with small lights. (This is also true for the camera and DOF). I submitted a bug report, and Steffen said this has been in all versions since 11, or that's as far back as he tested. Currently, the biggest problem is that the position of the light isn't automatically reset back to it's original position, after the multipass render, and with large lights, you will get wildly different results, also depending on number of passes. Currently one can manually reset the position by advancing to next frame, and then back, or trying to grab the light in the window, or some other toggling (shadows on/off/on maybe, not sure?), if you want to retest the lighting with other values for that frame. Or you can render with multipass OFF (lights are not jittered). I believe Steffen said this will be fixed in the next version of 17, but I'm not sure if I understood correctly. He is also considering implementing a jitter % for lights when using multipass. Currently the default is 100%, but eventually one could set the jitter percent to 0%. If the jitter is set to 0, then the shadows could look the same or closer to those rendered with multipass OFF, I believe. At 100% they look the softest (as now). I'm not sure if he has decided to implement this.

Decaling by hand usually renders the fastest. Not sure why baking materials into decals renders slower sometimes. Maybe it's the size of maps, and complicated mapping that causes an uptick in render time? Also - You might consider using a bitmap plus material on your cave walls - that can potentially give good results for such a generic looking cave texture.