NancyGormezano

I believe he has 2 complete models (groups) in the thom model - the swept group, and the real group. He varies the transparency of the groups

Many, many, happy happies more!

Select all cps of your model, right click/add image - the image is a solid surrounded by black on all sides. It will give you a wireframe look (except for 5 pointers - will look like triangular faces) For this example, I also decaled the thom model (blue) & then I varied the percent of the decal from 100 to 0 - which then allowed the patch image to show I could have just had a blue thom model (surface color), and then only decreased the color percent for the patch image so that the surface color would show The thom model might have some funny normals (pointing wrong way)? If so, that might account for some of the wireframe patche images having variation in how they rendered in intensity. Otherwise I don't know why that would be. wireturn5NompthickerNoalphahalfspeed.mov

Ack. me and my big mouth. I was afraid you were going to ask me that. That is some voodoo setting that I don't play with. Apparently when I start my PC, adobe (photoshop utility) does some sort of screen calibration for my system (don't ask me how) to set my crt gamma to 2.2 (don't ask me why). A:M apparently has knowledge of this - and wants it to be 1 - so it renders it to 1 (whatever that means). So there. Satisfied now? I know I'm not. I don't know what Macs are supposed to be. I also have heard reported by the "cogniscenti" that the adobe utility that calibrates my crt is crapola, and that there are much better, more accurate, more standard? ways to do this. Don't ask. I suspect gamma is some coefficient (exponent?) for some logarithmic curve that sets the brightness (color space?) of the monitor - and that the curve is non-linear EDIT: Ah, yes - Here is the meaning of life, the universe and Gamma Correction

You should also be able to see them in the right - even more clearly - maybe your display is not bright enough?, or contrast is funny? or black isn't black? or your gamma is gramma or grampa? EDIT: I use a crt monitor - you are using lcd? mac?

Do you see a difference in the images I posted above? Do you see the waves on them? If not, then I would say your monitor might need calibration of some sort. I will look at your new project - but please answer the above first. EDIT: if you are on a MAC, then perhaps there is a difference from ver 16 32 bit PC version.

Bubba - I took a look at your original project - And I noticed that the ambiance intensity was set for both the backdrop (85%) and water groups (20%) - those settings are probably preventing you from seeing the effect clearly. A lot of times, old models from previous versions of A:M come in with ambiance set to some value. Probably shouldn't be set if you want to clearly see what is going on and probably should work with general lighting instead. So all I did was change the ambiance settings on the backdrop (0%) and on the water group (not set = 0) I haven't looked at Robert's project - so maybe he has changed those settings already.

I just looked at 1_01_01a - that is the one you are using probably. I also notice that Willow hair has pre-roll 100! frames, straw - 25 frames, tree3 - 4 frames - that is why particle baking takes so long in this chor. That is the answer to your original question. As to why you can't bake it in ver 16 (and can in ver 15) - try baking it without preroll and see if that is the problem with 16? EDIT: those pre-rolls are from what is currently on my harddrive - I do not know if those materials were ever updated/changed since I last downloaded them, and lawd knows what you're using.

Are you using a different archive than me? Here is what the svn looks like to me with the repo-browser - what does your's look like?

I imported 1_01_01.prj My 1_01_01 (both prj & the cho file that it references) on my harddrive are dated 9/29/2007 (last time I grabbed it). I notice from the SVN log that there were adjustments made to that chor by Ken on 10/24/2007, and Mike Sanderson on 11/03/2007. Did they take out the clouds? I remember that cloud scene when I viewed the TWO movie - however I never did get a final copy dvd (I never asked for one) Be careful of those clouds - their sprite system has a preroll of 100 frames - that makes even frame 0 a bitch to look at. That's probably why it took so long to bake Not necessarily. If you groom the hair, then the hair won't stick out, for NON-dynamic hair. It will look how you groomed it. However what I notice is that some people like to put a pre-roll on dynamic hair. I guess so it will settle? And I guess they groom it in an action? or a pose? I don't know why they use pre-roll. I never set a pre-roll for hair. Instead, I groom the hair as to how I want the dynamic hair default to look when still. AND I always turn the "use gravity" OFF in the hair system/dynamic options, but I leave Use Forces = ON. So it still responds to movement, but doesn't drop, nor need pre-roll. Additionally, when I turn dynamic options OFF, it looks how it was groomed. So for example, I notice that the river_plants hair material in MY 1_01_01 project has a pre-roll. (and has dynamic options ON). For the 1_01_01 cho that I am looking at (I have no idea which one you are looking at? - post a screen shot, and I might be able to tell), I wouldn't know why there would be dynamic river plants (or any of the other dynamic hair materials mentioned above), loaded with the project. HOWEVER - I just now also notice that the 1_01_01 chor references only a camera model (that has dome, lighting, camera), mountain2 model (which doesn't appear to have any trees, hair, etc) - so all those dynamic hair systems loaded with the project are probably not referenced by the chor! - and only the cloud sprite system, and the goose (which has non-dynamic hair feathers) are referenced. EDIT: I also notice that Main Camera_v13 model references the forest_1 hair system (dynamic = OFF) - and has 4 emitters.

I took a look at 1_01_01.prj - the opening scene, and I notice that the following HAIR material systems have DYNAMIC OPTIONS = ON (when they probably don't need to be): Straw Hair, River Plants, Flowers, Mark Tree Willow Base, Mark leaves Tree3. You could turn them all off in those systems (save them). It would help baking. Not sure about the straw hair - it might need to be ON. There is also a sprite system: Sprite_Clouds - which does need to be ON. That is why you would need to Bake particles. Turning off the display of dynamics, only turns off the real-time display of it and makes it easier to scrub, it does not turn off the dynamic computation for rendering, or baking. I am guessing that there is some conflict between sprite baking and hair baking. If your objective is to just render the scene - then never mind. If your objective is also to help track down why it isn't working in ver 16 - then I would suggest turning off the dynamic option in all the hair material systems mentioned above and just bake with the sprite system and see if you can get it to bake then in ver 16

Nice! Like the use of the gradient, & the symbology

I would have thought there wasn't a need since the hair won't be moving but I was never able to start a render unless it started a frame 0. I was never able to stop, pick up at some middle frame later and continue. Steffen said it would need to be baked to do that. So that's why I'm baking Uh...so just what is a "dynamic" system in that scene? Are there special effects? Dynamic constraints? If I understand, did you not say that there was something in the scene causing a wait "for computing particles". Does the hair material (hair systems) on the houses (or trees or anything) have the dynamic options = ON? when it doesn't need to be? I notice if I turn OFF all my hair dynamic systems - then I can scrub thru my chor in real-time without baking - there is some short computation that still goes on (probably checking for dynamic = ON), but there is not the extraordinary computational wait when it is set on.

Nice test - Do you have collision detection on for the hair system?

I have only been trying 1 chor so far in ver 16 and I am not using netrender. For my particular chor, I hadn't been baking and hair was rendering ok. Then I tried baking, and experienced the hair stretching. So I went back to NOT baking before rendering. However I have recently retried baking (in the same chor that had a stretchy problem) and it appears that I now do have a sucessful baked version. So the problem is elusive. What I did change however in my procedure for baking - was before baking: unhide all models, go to frame 0, bake from there. Save chor, then restart A:M, render. Your particular chor (that set in particular) that you are trying to render for TWO, in my recollection was always a problem for stretchy hair. Baked or not baked (there wasn't any baking in ver 14 iirc). I have found also that funnies happen, if one is using multiple instances of a model in a chor that has hair. I have seen the stretchies when I've used multiple copies of the same plant model. So if those houses are just multiple instances, that might? be contributing to problem. If you can, save the house model under different names house1, house2, etc and substitute those in the chor. The other thing that might? help, is that even tho the models might be unique, is that they are all using the same hair system - and it would be better to have them reference unique hair system. EDIT: I see Matt has also mentioned the stretchies with multiple instances - same name material. I suspect that scene rendered before - only by luck, or magical thinking EDIT2: Are there any dynamic systems in that chor? they should be baked as well, and perhaps before hair is baked.

1)How did you discard? - did you unbake particles, and as well delete the chanels that were created in the chor for all systems (references to pai, par files? before consolidating? delete the par, pai files as well? 2) then after consolidating - try resaving the project (in the new consolidated location) - and then rebake. If you haven't done 1) - then delete the channels, files, etc in the consolidated chors, etc. resave project, rebake in the consolidated project. If you still can't do it: restart A:M before rebaking?

1)Did you consolidate after you baked? or 2) baked after consolidating? I would say if it's the first, then the filepath to the pai, par files in the chor didn't get redirected (updated) during the consolidate process in the chor or if it's the 2nd case then you might have to resave the project first into the newly created consolidated folder, and rebake particles so that the path does get updated in the chor, as well as possible in the .pai file (who knows what's in there?) - or else text edit the files to make sure the paths are correct? Thatsa my wag-olas

You must also delete the poses from the User properties I am guessing you probably didn't turn the pose ON. You can turn the pose ON in the chor, or action (view/pose sliders). Or you can have the pose default to ON by setting it to ON in the User properties and then saving the model.

Your alpha channel is all white - meaning all of the image is used for the decal. The alpha channel, if you wish to exclude the background, should only be white where the design is, and the surrounds of the alpha channel should be black. I also shrunk the area around the design to get rid of the potential for the halo. Here is the color tga only, 32 bit with a corrected alpha channel. AnTirMidPlateColFlat_copy_withalpha.tga

The files get written into the same directory as the Project is stored. What I do is start a new project, import my chor, create a folder for my project, then save the project in that folder, then bake, then save the chor. I then do not work with the project any more - those file paths seem to get permanently embedded in the chor data. There doesn't currently seem to be a way to specify where the files should be stored. Also be aware that if you start a new project, import a different chor (in same session as the previous), and do a bake - it appears that the par,pai files will be written into the same folder/directory in which the last project was saved. Not good. But obviously one can move the par, pai files and then text edit the chor files to point to the new location.

Voo-dooo, and in particular, chicken bones. Some things that sometimes work: I sometimes find that this clears up if I save the chor (after baking) & then restart A:M. I have in general found that it is best to be on frame 0, before baking, or starting a render. (with hair or anything). It is best to render after restarting A:M in general, always. With my current animation, I am noticing that it is NOT good to bake before rendering. I only experienced the hair stretch problem after baking. But hadn't experienced it before then in this particular chor, if I didn't bake. I am running 32bit, and run only 1 render thread I also have observed that in previous versions (and maybe the release version), if it didn't clear up by going to frame 0, then sometimes the act of going to frame 1, and then back to frame 0 might clear it up. EDIT: the other thing that may or may not have anything to do with anything - is to unhide any hidden models in your chor before baking, rendering. That is a workaround, for a current bug, that I reported, that Steffen has fixed for the next release, and he let me know that the workaround was to unhide all models for my particular problem (non-related models getting corrupted after "Bake Dynamic Systems")

yes definitely. It's best to bake at the end 1) to see what corrections you might need based on dynamic hair movement, because you can play the animation in real-time and 2) maybe? to save on render time later perhaps - ie doesn't have to be recalculated EDIT: Note that it is not necessary to bake particles (hair) before rendering - and I find that sometimes it works better, ie more consistent, to NOT bake. If you have problems with hair rendering funny, unbake if you've baked, or try baking if you haven't baked. I've uploaded screen grab of what .par,.pai files look like in the project directory

Hair is a particle system. When you choose to "bake particles" in the chor, an extra file is created in the project directory with the name of the particle system eg hairmaterial.par, along with an index into the .par file (called .pai). The .par file contains the values for the dynamic hair splines, so that, in theory (and works most of the time), hair will not be recalculated on the fly, and one can then observe the behavior of the hair/particle systems in real-time, as well as, in theory (not so sure about this), save on render time (maybe). Presumably data for sprites are also stored in similar files, with the name spritematerial.par. The name of these files are referenced in the chor, under the name of the group that that has an associated particle/hair system, after baking. I have found that funny stuff happens if one tries to turn particle systems on/off individually: the .par files, .pai indices can get corrupted - so it is better to rebake, rather than fool with that switch. Also be careful about sharing project directories, as baked files will get created in the last project saved, and for someone like me, who doesn't work with projects, that can make a mess, if the same model is used in multiple chors.

I will assume you are talking about scrubbing in real time with a chor that has particles baked, & in particular hair. Is the property in chor, groups/hair group name/Hair system/Particle baked = ON? Baking sprites, streaks etc may work differently, especially if there is also hair. I find sometimes when there is funny behavior, I have to restart A:M and then it works properly. I am only baking hair, & there are multiple systems, but only on one character, and he is not in an action. I also find if I turn off "Particle baked" on only one of the hair systems - the real-time playback still seems to assume it is baked for all of them. I have to turn OFF particle baked for all systems for the real time to acknowledge that. And then when I turn it back ON for only 1 of the systems, the real-time recomputes for the system, but still has other systems that aren't baked. So perhaps not all your systems are particle baked? And there is some toggleling-demon at work.

Bravo! Bravo! Excellent imagery, lighting, camera work; fabulous, interesting sound design, love the stop-mo puppet style! Wonderful. Congrats! My only crit would be that the sub-titles distract one's attention away from the terrific imagery. I had to replay it in order to get the story, as I was entranced by the style. Your voice quality is excellent. If at all possible, perhaps it might be better if you were to also have a version with a sound track using your voice, in English, without sub-titles? Loved it!