Rodney

I had forgotten about that one. Very neat John. The issue with using that type of expresssion is that it is Chor/Time dependent and it needs to be space aware. There is probably some way to setup a scene to where (similar to what Chris is doing) parts of a set are turned on/off through time but my goal would be to automate that process similarly to what is happening in A:M itself when it comes to clipping the viewing area to determine what will get rendered. No small task there. Now... if we consider your expression: If(ChorTime()>0.5,If(ChorTime() The only way I know to proceed (in this ChorTime() vein) is to create a controller that when a value gets to a certain level it turns off an object/character/building etc. Think of this as a proximity value or potential for action. When that value gets either inside or outside of a particular range it would then trigger an action. This in and of itself sounds to me a lot like a percentage pose. (or more for boolean true/false results simple triggers could be called via on/off poses). This would almost call for every Object to have a new parameter (although this could also be an Action or a Pose) called Active State or something similar. Then at whenever time the specific criteria of that Active State is met the expression would fire. This is the primary way I would think using something like ChorTime() would work as key events would be dictated at specific times and that would then trigger all 'live' Objects' Active States. This might be something as simple as turning itself on or off or triggering something far more complex. I thank you for this consideration because it may supply an important element in the process. Using ChorTime() as the initiator does make good sense as whatever happen in the Timeline SHOULD represent the primary action in a scene. Therefore the Active State would drive secondary action/reactions of those primary event. Added: I really don't understand expressions.

I was thinking along those lines but at this point it's not quite ready for camera turns, at least not in the sense that the expression only accounts for triggering on/off in the Z axis.

Even if there isn't a direct way I believe as of the current release (or one or two releases ago) variables can be stored for later use in expressions. I haven't had time to play... heck, this is only my second or third working expression... but I sense that the recent additions by Steffen are a very big deal with regard to expressions.

Here's an approach from a drag and drop angle. I'm liking this because folks wouldn't need to concern themselves so much with coding of expressions because... these actions could be collected/shared as little scripts/macros. The idea is to create an Action that you can drop onto a Character/Object that would tell it when to Activate. The trick is that the Active setting is actually (and I must assume always?) applied to the Model Bone. As such all we need is an expression that turns that state On/Off (or causes some other action) based on some criteria we set in the expression. In my project I put together a little test that expressed that if the Shaggy with the the Action applied was to rise above 100cm he would be 'taken' (i.e. deactivated). The other two Shaggy's rise beyond 100cm with no effect (of course.. because they don't have the required Action. I arrived at this because the other approaches I was investigating were getting too complicated. Simplicity is key. My thought was initially to create a Null called Activator and have things appear based on where that Null is located. You could then constrain the Null to something like a camera. But... that's only approaching the problem from one angle. We know that each model has a steady state of on/off and (even if we alter/augment that) the results of changes to that state can be anticipated. ShaggyGetsTaken.prj

Here's another Project file based on the first with the following changes: - The On/Off state of the Expression has been reversed - A Filter for 'Active' has been created to more easily see what objects are using the expression. Not that this is also how behavioral (artificial intelligence) could be similulated in that a variety of expressions could be created and applied to groups of objects independently. One group might activate (or move farther away) while another group might deactivate (or come closer). Project_Camera_Proximity_Activator__2_.prj

I'm surely using the wrong terminology by using the word 'embedded' but I refer to the nature of a Chor that allows you to work with/save Chors without saving the Projects. Perhaps 'referenced' would be more accurate but that doesn't quite fit either. Slightly unrelated... but for those that save Project files... Chors are embedded by default into Projects unlike other assets. This can be seen in the File Info property under the Chor where Embedded is set to On by default. This is telling, and also a matter of interest. While the over all time should remain constant the keyframes surely change. This could be slightly problematic in that everyone sharing the files may not be using 30FPS so we may not always see the same thing. This then would be another case where Project files are preferred method of file sharing. I dimly recall a common FPS being emphasized during TWO to keep keyframes from changing. The assumption being that because 30FPS was assumed Chor files could be used and Project files themselves jettisoned.

You guys inspired me to consider the possibilities with your Multi-Model Pose Sets and so I did a test to see if an old idea might work. It took me a few tries but I finally came up with something that demonstrates the basic idea. The idea is that through the Active setting we can add an expression that will turn on/off an object based on proximity to another object (such as a Camera). I believe I've got this somewhat in reverse (objects disappear as the camera comes close to them) but it might serve as a proof of concept. In the project file I also created another file called 'The Zone' but I haven't done anything useful with that yet. The idea might be take everything into the same model that is routinely required (camera, lights, etc. etc.). Things outside the zone would then be otherwise effected. Once the general expression is designed it can then be pasted into all objects Active property (probably an ideal use for an Excel spreadsheet or global text replace). There are many alternative uses for such things. One of my initial plans was to use it to automate crowds to move them away from a zone immediately around the camera. Thus simulating the effect of a person walking through (or fighting through) that crowd. The other longer term purpose behind this was to facilitate split rendering based on proximity. In this way a camera could go around 'filming' things in isolation for later addition into composite imagery. As a language of sorts would be needed in order to keep everything organized I shelved the idea pending more R&D. As split rendering is a complicated subject and I wanted to break it down into vital elements adequately. The actual expression I added to each of the three objects in the Chor in this case is: [EXPRESSION] If(..|..|Camera.Transform.Translate.Z [/EXPRESSION] Of course also note that this expression doesn't account for any other direction than the Z axis. There is likely a better approach to activation/deactivation. Project_Camera_Proximity_Activator.prj

I'm not sure what to tell you there. If you paste everything from to into a textfile and name it with a .prj extension it should be an empty Project file. Note that this should produce the same empty project file you'd get (with your personal information of course) when you select Project/New from the menu. Nothing to see or measure there... just the ultra basic starting point. Perhaps you also copied over the forum's [ PROJECT ] and [ /PROJECT ] tags that are used to embed a project's code into a post?

I started playing with a file to check and see for myself but almost injured myself in the process. I kept losing track of the variables. That's when I noted that the FPS isn't stored in a Chor but rather in the Project which in and of itself makes sense because it is in the Project that we set the FPS. (And of course we can set the default FPS in the control panel so that A:M knows what to set FPS at when it creates a new Project). Perhaps something works differently for Chors nowadays because some folks don't use Project files (Like Nancy... using only Chors... albeit they are surely embedded Chors) and yet they still maintain their FPS. But this seems a bit unlikely. I'm not sure what would have changed to make the documentation obsolete in this regard. My initial theory was that FPS didn't matter because A:M treated it's internal time in such a way as to easily be converted. This seemed to be corroborated when I didn't see the FPS entry in the text of the file but now that I see it there consistently I'm softening on that stance considerably. Of course I can (and should) delete that entry and see what happens. I suppose it is possible that at one time the documentation was accurate but since then things have changed. There was one nagging item that suggested itself to me as a final solution but my tired brain decided it needed to sleep first before taking a closer look. More exploration to do! It might help if we were looking at the same file here. Originally I was looking at an empty Project and an empty Chor but one must change something before there is something to measure. Here is the (empty) Project file I am currently working with: [PROJECT] ProductVersion=18 Release= PC Selected=TRUE FPS=1 Embedded=FALSE CreatedBy=Rodney Baker Organization=Fuj10n2020 Url=newartofanimation.wordpress.com Email=rodney.baker@gmail.com LastModifiedBy=Rodney Baker FileInfoPos=248 [/PROJECT] As an aside: Quite awhile ago I noted that 'Selected=TRUE' tag and thought how useful that might be for interactive tutorials that walked people through Projects. The idea being that we can remember to set the focus prior to saving a file (or if properly done via the text of the file later) so that when the Project is opened the correct place is already receiving a highlighted/selected focus. I need to remember to use that!

This is what I've had in mind for creating a master building to morph into various shapes and populate a city with for some time now but I've never worked up the patience and where with all to set aside time to implement it. You've outdone anything I could have put together already. Quality takes time and taking adequate time to build quality into a project is something I'm still working on. You guys have got it going on here!

There are some interesting aspects to all of this as a Chor doesn't store the FPS but the Project file will (I believe A:M assumes 30FPS in the saved file... and therefore doesn't even bother to write it... unless specifically set to something else). Well, now I can't get a project file to save without including the FPS. Go figure. I must have been looking at a Chor file only before. Here for review is the File Info property for FPS: Note that upper case emphasis is present in the original. The bold portion is why I believe your estimation of 30ths of a second is not always going to be accurate. If I understand this correctly that should only be the case when the FPS is set to 30. Edit: In rereading your post perhaps that is what you were saying? This is the write up from the Tech Ref that was planted in my mind to suggest that time itself is the constant in all of this. While the over all time will be maintained the keyframes will adjust accordingly to maintain the desired (or should we say set) FPS. We may desire a certainly result but we'll only get that if we have our settings correct.

I am in way over my head here but it's fun to explore. Perhaps this short decimal is a simple percentage representing the space between 'frames'? In this way an extended decimal such as as .334234 would round to 33 percent and render the next frame accordingly. There being no need for further refinement outside of multipass subframe rendering.

Not that we would want to do this but there are a few places where we can monitor/change (refine/define?) the internal framerate within A:M. There is also a place where we can set 29.97FPS for output but that is in the Quicktime rendering settings. As an aside: I note that there is something strange going on with the FPS being displayed down at the lowever left corner of the interface where it states FPS. Either that or I'm not in sync with what is going on there. In the attached image I saved out the same sequence of images as both 24FPS and 30FPS sequences and (as expected) A:M filled in the gaps by performing the translation. One does have to be careful to make sure that in testing we don't adjust (or fail to adjust) a variable such as the FPS on the output of a Quicktime sequence. I assume such a setting could effectively cancel out (reconvert) the sequence by adjusting the frames present again. It's important to note that in both cases the length of the sequence remains the same at one second. It's the number of frames (and subframes) that gets displayed within that one second that changes. And of course there is Multipass itself which is the whole point of this thread. I'm starting to learn more about that here!

I really enjoyed that Chris! It's great to see inside these time saving approaches.

The problem I have is where folks say that "just because a frame is labeled 00:00:01:00 does not mean that 1 second has passed". It should mean exactly that although there is an important part of the equation missing (i.e. 00:00:01:00@30 frames per second(FPS)). How many frames have been presented at 00:00:03:00? Well, the answer depends on the frame rate. If the frame rate is 1FPS then the answer is 3 frames. If 60FPS then the answer is 180 frames. It is when we get into the floating point numbering that things get harder to follow but only because these were devised for a special case (NTSC color video). I note that NTSC black and white video, although rarely used these days would still be 30fps. (Why do I sense that interlacing is related to this?) But things truly get weird when the labels suggest something is occurring that isn't. For example, the term 'drop frame' would suggest frames are dropped when in fact that isn't the case. In the end it should be enough to know that when we see a timecode we can immediately suggest how much time that represents (00:01:00:00... okay that is 1 minute's worth of frames) BUT we need to ask the all important question "At what Frames Per Second (FPS)?" before transferring our work to someplace else. I *almost* understand this (because I can easily understand that 1 does not always equal 1) but that *almost* is also what can make it so frustrating. There is an aspect of this that suggests to me that (similar to linear/nonlinear color space) publishing to NTSC should be a process reserved for the final phase of a production in order to limit the accumulation of error. It *was* my understanding that A:M resolved this discrepancy in realtime vs frames behind the scenes. But now Robert has introduced a new label into the equation that needs to be defined. (and he did that above) So, as I understand it: A:M stores time in "ticks", not seconds or frames, and A:M counts 135000 ticks per second although we don't have any direct means of seeing these representative ticks. 135000 was chosen because it is evenly divisible by all the common frame rates and further divisible beyond that for most multipass intervals. I'm unclear if there is a formal request to consider using 270000 ticks per second (twice that of the original implementation) being considered or whether this was recently implemented. In essence (and please feel free to correct me here in my terminology!) the 135000 ticks per second can be considered A:M's internal timekeeping codec. The codec being the program (A:M's implementation) used to read and write files. As the codec is designed for use only internally inside A:M its integrity is maintained via the self correcting nature of its implementation. In other words A:M's internal timekeeping is highly accurate and therefore the resulting timecode and fps from internal conversions can be relied upon. At some point it seems that we'd be calibrating individual pieces of hardware if we wanted any additional level of certainty.

Oooooo.... pretty lights!

She had borrowed an SGI workstation so she had the entire film (more or less) copied to it before she took it home with her and then updated incrementally on a daily basis over two modems. I believe it was the older files which would have been directly copied onto it that they were the most interested in as the newer files had been backed up properly. As the newer files hit the upper limit of storage on the backup system it had gotten rid of older files but they weren't exactly sure which files were jettisoned. Her backup allowed them to run that comparison. Now... the other shoe dropping... was that shortly after this Lasseter and crew reviewed the film and decided it wasn't working. They then proceeded to toss out the majority of the film and basically start from scratch with less than a year to release remaining. Heh! There is no failsafe against the human condition.

Everyone dreams of fame and how could I be any exception. I just never knew for me it would be as a dancing... cg... puppet... zombie.

or... 'Why PIXAR movies really cost that much'. EL_g0tyaIeE Direct Link

Curse you animators and your mastery of the principle of anticipation!!! I haven't even seen 'The Wobbling Dead' yet and already I'm looking forward to your next project.

This is an old topic but it appears related to the issue Robert discovered with Multipass. Thought I'd bump it up just in case it is related.

Ah, the sweet smell of success (or the plastic dvd casing equivalent of it!) Congrats for getting this accomplished.

The link is just an email link to: support@hash.com You may want to launch an email to jason at hash (dot) com however as he gets those more directly. I don't know anything about that. Perhaps your system doesn't have an associated email client to launch the email from. On my end the link just doesn't work. Seriously though, there are only two email addresses to remember and you really should use the one that starts with 'jason' and ends with hash.com.

Very nice Robert! I appreciate your efforts and learn a lot from them. Just the other day I was observing the sky and environment around me and the thought occurred that everything looked very unreal. It was an amusing moment because how can you get any more realistic than real? And yet that is what I was perceiving. This can present quite a dilemma in that we can spend an inordinate amount of time lighting a scene only to have it seem like it isn't real. I wish I could go back and study that scene a little more to figure out exactly why it looked the way it did but at a guess I would say that depth cues were off because of stormy weather all around and in the distance. This created harsh light on physical objects that would normally be softer and soft light was diffusing areas that normally would have more detail. I can't help but wonder if a photo might have captured that moment well but in my experience photos never quite do justice to the real thing. There is always something lost in translation. I have been using SSAO of late and have been enjoying the look coming out of A:M's renderer. Thus far I'm liking the look on my Sci Fi WIP.

My set came in the mail today. Now I've got something to watch while A:M is rendering away at frames.