Rodney

Well, it is an animation bootcamp so I'd say you are in the right place to do just that.

See the first post. (I'm limited in what info I can provide but It's an app related to medical education) I'm inclined to use Unity (especially since their latest release!) but one of the more recent responses from a lead asked, "Does it have to be Unity?" I haven't responded to that query yet but while it doesn't have to be any particular software but it does need to be 'something' or else the project won't go anywhere.

The latest news... The committee didn't green light the app so that avenue is out. The team is considering other options. For my part I just press on as before with a plan to adapt as necessary. As some the principles will be offline due to other commitments no deadlines loom large on this project so my focus remains on brainstorming, conceptualizing, research and development.

John got me interested in testing out a few ideas using A:M's flocking feature and along the way I decided to test some of A:M's newer GPU accelerated Postprocess Effects (like Blur) too.

I delayed posting this as an alternative because it's not a standard approach and the pdf file format was your focus. As an alternative, self contained file, you may want to investigate Tiddlywiki (www.tiddlywiki.com) While embedding images, audio etc. increases the filesize dramatically it can be done and... like any html file resources can be externally linked. For those that haven't checked it out in a few years it much improved and actively being developed. Worth checking out: http://tiddlywiki.com/#Features If Tiddlywiki looks a bit complex it's both simple and complex. Simple if you just want to enter your information... and complex if you want to dig deeply under the hood and customize it to meet specific looks or requirements.

It's great to see you back at this again Dan! Nice render!

Here's a quick test of Crowd Flocking... (not related to my project but a quick test to remind myself of the various settings available in flocking. I was actually thinking of Gerry Mooney's 'Bugbots' while making this. Everything except the text is flocked)

That's the time honored number one reason for flocking not to work. Flocking is working here in v18k (with particles on). I am so glad you had this problem though John because it reminded me that flocking is a great option in something I'm working on now.

Mike Hough (the author of the AM2RIB and AM2RIB2 plugins) stated he was frustrated with (i.e. didn't like) the RIB format. His effort was back in the 1999/2000 timeframe (before the current HXT plugin format). Nicolas Yue (I think that's how you spell his name) also wrote a RIB exporter called MasterRIB. I don't know anything about that plugin. Added: I see that Nicolas is or at least fairly recently was involved in some RIB/github activity. Also of possible interest to you... regarding the RIB format it has been said (by PIXAR): *emphasis added (Note that I assume the reference is to OpenSubdiv 3.0 (currently in Beta release)

I'm curious if there is anyone that frequents the forum that is familiar with the command line use of Renderman. It seems to me that might be the way forward with A:M and Renderman. Added: Here's a little information on using the standalone Renderman (which doesn't need Maya, Katana or any plugin): https://community.renderman.pixar.com/article/293/using-renderman-without-maya.html Aside: Way back in the day A:M use to have a RIB exporter... While it's not a high priority to use Renderman I've started the process of installing it. Let's see if there is anyone tenacious/stubborn enough to beat me to the first A:M/Renderman rendering. (Using the Maya or Katana plugin as a conduit doesn't count!) Update: Installed (Rendering with the command line will likely require installation/launching of 'it'. For those taking notes: It can be run via plugin or command line.

Need a few posters on those walls! Hmmm... and don't forget one of those 'sharps' containers for collecting needles and such. Here are some examples of wall mounted containers: LINK

I recommend Creative Talent Network (CTN) which will be November 20-22. It's largely comic book artists, animators and such which makes it a prime place to exhibit Animation:Master because A:M is more attuned to these folks than those whose focus is more toward technical proficiency. The demos I saw before by Hash Inc at SIGGRAPH and what I assume James et al. still present is ideal for this type of event where creative types are sharing knowledge of classical approaches to animation but have a keen interest in computer animation. CTN is still a small and cozy gathering in comparison to many other events but it's also a rare opportunity for talented folks to meet with highly skilled folks that one would never think they could ever meet in person. It's also where a lot of young students who haven't yet been jaded by 'industry standards' seek ways to express their creativity in their own unique way. If Hash Inc will be there I will redouble my efforts to be there as well. Here's a link: http://ctnanimationexpo.com/axFloorPlans.php#prettyPhoto The timing is right because exhibitor registration begins in April.

As A:M doesn't have macros I assume you refer here to a text editor like Notepad ++? And DOH! I forgot a very important step in my setup of what I'll call the Grid Alignment Method (GAM) above: 1. Establish your Model/mesh at a scale where the grid (of the Model space) most accurately places the majority of Control Points at or on a grid intersection 2. Establish your Bones at the same or similar scale 3. Select all CPs, Right Click and Snap to Grid 4. Select a Bone, Right Clock and Snap to Grid (Note that we cannot multiple select Bones so another approach may be necessary) When creating Bones the Snap Manipulator to Grid icon could be toggled on to ensure all Bone origins are already at an intersection of the grid. ADDED: In either Model Mode or Bones Mode, Right Click and select Auto Assign Bones to connect Bones to CPs.

I'm trying to imagine what success might look like so bear with me here. Of course there is solving the process of matching Bones to CPs but there is also the matter of what that would accomplish that couldn't be accomplished in some better way. But... moving on... I note the following: It appears the minimum required for a CP to be assigned to a Group is the following entry in the Model: (Scroll down in window to see all code) [Model] Name=CP1 1 Pivot=-13.3138 0 0 Name=CP2 2 Pivot=14.8886 -0.0715798 0 [/Model] And for the Group Constraint it gets a bit more complicated but we need it's corresponding Bone (already existing in a/the Model) to have the following (in an Action): (Scroll down in window to see all code) [Action] MatchName=Bones MatchName=Bone1 GroupTarget=..|..|Groups|CP1 MatchName=Rotate MatchName=X 1 0 -2.71051e-018 MatchName=Y 1 0 5.55112e-015 MatchName=Z 1 0 0 MatchName=W 1 0 100 MatchName=Translate.X 1 0 0 MatchName=Translate.Y 1 0 0 MatchName=Translate.Z 1 0 -0.000134537 [/Action] The Action may not require all these various channels (we'd have to test) but that is what is created in the natural order of activating the Group constraint. The critical part of the assignment being: /// The beginning of the constraint container GroupTarget=..|..|Groups|CP1 /// GroupTarget= followed by the location and name of the Group to connect to which we can assume could be same name for easy identification ... /// Additional Orientation information as required** /// The end of the constraint container ** While I'm sure this ommission (and direct manipulation of the file) is not recommended my tests indicate the orientation data can be omitted and A:M will resolve the constraint automatically. Somewhat related... This process of creating Bones and attaching (or placing) them at CPs is not unlike the creation of Skydome/Light Rigs where an array of Lights (basically the same as Bones in A:M) is created. The primary addition is that of 'parenting' the Bones/Lights to specific CPs (in this case using the Group Constraint. Note that in the above I haven't moved on to look at the orientation and length of the Bone that would place the Bone at a specific location. In Robert's video he shows how to get the ends of the Bones at the next CPs (By using the base of the next Bone in the chain) but I would imagine that where the Bone points could be any number of different locations. Alternately, the bases of every Bone might be desired to be all be at the same location while their tips/ends might be where individual CPs are located. And another observation... In some cases a workflow helper to match Bone locations to CPS might be as simple as this: 1. Establish your Model/mesh at a scale where the grid (of the Model space) most accurately places the majority of Control Points at or on a grid intersection 2. Establish your Bones at the same or similar scale 3. Select all CPs, Right Click and Snap to Grid 4. Select a Bone, Right Clock and Snap to Grid (Note that we cannot multiple select Bones so another approach may be necessary) When creating Bones the Snap Manipulator to Grid icon could be toggled on to ensure all Bone origins are already at an intersection of the grid. Or something like that... I'd be curious to see a mockup of what success might look like for even a simple case. I can thing of one: connecting all of the CPs of a mouth to a ring of Bones to better facilitate dialogue/articulation

I'll guess the primary reason is that the z-axis-position option isn't in the TextureGrid Wizard. We'll have to wait for the GridImages Wizard's release for that. The TextureGrid WIzard only has X and Z offset (and lacks the option to automatically drop the Models into the Chor as well). I should say though that stacking of images on patches is as simple as a Right Click followed by an Add Image. The patch image approach is inferior to these new grid decals in several ways (no x-axis adjustment of the images and images set to cookie cut cut through all of the images on the stack. With this new Wizard we can go in and adjust the positioning of the images via the Decal Editor which is a very nice way to make modifications. I'll also add that v18k's new ability to bake patch images (into decals) is yet another nice way to quickly combine imagery into a single decal (or layering of decals if you count the various other surface properties; transparency, specular, bump, etc.) .

I will assume that's what Serg means until he clarifies. It's a rare bird who takes advantage of A:M's Layers. I don't think a lot of users even know what a Layer (in A:M terms) means. At any rate I don't think Serg is referring to A:M's Layers. Although its a toss up... perhaps he is. Having the ability to stack/layer images above each other (ala patch images) would indeed be useful as that would allow us to immediate composite a series or sequence of images together. Currently that is a manual process adding images to images via decal or patch images. The downside of 'stacking' is that allowances have to be made for image formats that don't have an alpha channel. I suppose the user could be left to figure that out for themselves but folks tend to have a tough time grasping the concept of alpha channels. I would probably refer to the stacking of images in one place over the top of each other as 'compositing' because that'd be what the final result would be; a composited image of all the stacked imagery. If using a camera the effect might be referred to a 'multiplane'.

Nice one Douglas. I'm really liking your economy of spline on this last one. Added: You are running up against something I recently did with a cartoony character in that I like the look of him from a side view but the front view didn't seem to capture the same character. Not that I know in your case but the front view of your last head model from the front view seems a bit the same in that it doesn't quite seem to capture the character represented in the profile/side view. Manybe it's the width of the jaw? The sameness of distance between features? Not sure. I do really like that profile though!

Wow. I can't recall when an update to A:M was as immediately useful as this one has been already. Specifically the Camera View addition, Textured Grid (haven't delved deeply here yet but I will soon) and.... better rendering Boolean cutters! And I haven't had a chance to look yet at some of the others but I know the SSS speedup will be appreciated and rendering from Perspective view is something I've just committed to using for a project. Very nice! Edit: And oh my goodness... I completely skipped over the lineitem for ' 6311: Patch Images do not Bake' Thank you!

I'm guessing that would be a whole new feature as Layers use patch images instead of decals. Or... are you using the term layers in the sense of 'stacking'.

There were several characters modeled as the first LOTR movie was released. Ken Heslip created his Troll and Will Sutton created his Balrog based on the inspiration they saw therein. Nice test William. That faceless Troll is freakin me out. Of course that is the shade of a dozen or more character rigs released since your test to steer folks away from facial animation and concentrate on body mechanics.

I was about to say.... aren't new features generally reserved for new versions? Gerald, Thanks again for the video. A:M has some great image manipulating features already and I'm sure this will be a nice addition as well. I have a back-burner project I've been wanting to do for years that a wizard like this might serve quite well. Added: I already have a use for this so am looking forward to the next release.

Thanks Gerald that's got me going in the right direction. I was using Fragmotion myself as a conduit to FBX although for static objects I usually just stick with OBJ format. Short of testing the 64bit A:M to see if it will fail on the same files that succeed with 32bit I'd say this one is resolved. Update: No issues with 64bit. It must be the complexity of Rabbit's bones as you suggest. P.S. Your website was a great help back when I first attempted to export to Direct X. Thanks for that as well!

I was partially successful with a simple character although I'm still trying to get the action to show up in the other program. It does appear to work on A:M's end. One thing I didn't check was whether I was using the 64bit A:M the first time I tried and the 32bit A:M the second. I should narrow that variable down as well. The good news: I'm not getting a crash with my test model. Edit: I just saw your project file and I'll try that. Yes, that worked as well. Thanks! Here's a related question as well: Is there any specific program you are using these .X files with outside of A:M?

No need to upload as you have the same thing. Open Rabbit Export as .X Create New Action with Rabbit Pose Rabbit Export as .X action with Rabbit I tried the simplest test I could think of to see if the exporter would work.

The good news: The process of exporting the model first then the action is working The bad news: A:M crashes upon exporting the action More investigation...