Rodney

I'm staring at a dilemma that seems to resolve around the necessity of including bitmaps (for decals, backgrounds, etc.) and am actively searching for a solution to set aside or exclude bitmaps from the general workflow. Now, this isn't to suggest that bitmaps would not be a part of the project workflow at all but rather to set them aside for a time to optimize the given workflow. As an example, let's say we have a system where the use of only text files is the norm and is preferred. Let us also assume that text-based image formats (SVG and base-32/base-64,etc.*) aren't ideal either although additional development might allow for them, especially the latter as they are already being used to an extent in the text files (as tiny little icons). ** Additional Considerations Similar to the above form of embedded Bitmap there is also that form of bitmap that can be generated (rendered) from data in the text file itself. Once rendered the bitmap could then serve as a background elsewhere. The downside of this is that it would result in unnecessary rendering of the same bitmap over and over each time the process is invoked resulting in wasted rendering cycles. This is not insurmountable, especially if/where the bitmap would not be regenerated if the bitmap already existed locally. If present, the user would specify whether the bitmap was allowed to be updated/overwritten. Constraints How difficult would it be for most people to transition to such a bitmap-free workflow? I assume this would not be a difficult workflow if the use of bitmaps were to be relegated to the latter part of the workflow (final lighting, texturing and surfacing). *I use to know more about the embedded icon format within A:M files but have since forgotten the specifics. It doesn't sound quite correct to say they are base-32. **As these embedded images are not optimal for large image size, a thought from many years ago was to use that to advantage by using the embedded image data as a proxy image that would be automatically replaced by the higher rez/external image should it be locally present. In absence of the local file the embedded 'icon' would be used and in absence of icon a default representation for that file type (or solid color) would be used. This being similar to A:M's current implementation of Library icons.

Yes, I'm specifically not using the word 'crowdfunding' for many of the reasons you cite. Although I should state that there is always a crowdfunding aspect to grants and scholarship in that those grants and scholarships must themselves be funded. Crowdfunding being the means to spread the burden of support more widely so that no one individual is overburdened in the process. Kickstarter and other such crowdfunding sources definitely have their place! To my way o thinking Kickstarter doesn't address the underlying problem but rather attempts to circumnavigate the problem by incentivising the funding process. Crowdfunding also currently exists as an option in several varieties which unless we were to suggest a better way and means is probably outside the scope of this topic. New forms of this basic model of financial support are appearig every day, such as Youtube's foray into peer-to-peer funding as well. Concerning grants and sponsorships... and I'll add the word 'scholarship' as well as that opens more fully into the world of specific grants given to further education... would not strictly tie support to a given project. An example: Person A has a desire to learn how to animate dialogue so they receive a grant to take a course in animating dialogue or Person B is pursuing their interest in Lighting for their current project (requiring R&D on their part) so a grant is given to further that activity. For the sake of discussion here is a loose alignment of the terms with a basic definition: Grant - financial support for research and development Scholarship - financial support for furtherance of education Sponsorship - financial support of an event or person I won't say I'm entirely satisfied with this alignment. The thing that strikes me concerning all three is how they would be limited by (yet to be defined) criteria and time frame. The primary limitation appears to be 'until the funding behind the grant/scholarship/sponsorship is gone'. There is also the prospect of potential renewal of each should the they receive additional funding, the goal be achieved or the scope be expanded in some significant way. Added: It should be noted that in most cases the funds under consideration here would be considerably lower than those folks are attempting to raise via crowd sourcing.

Thanks for sharing that.

A:M has that sort of parameter adjustment in at least two varieties: Bone Falloff and CP Weighting. Do you have the most current FBX Converter from Autodesk installed (from 2013)? Short of paying for some other solution, that's what you'll want to have in order to get a proper quad based mesh/OBJ.

I played with the Spherize plugin a little as I had forgotten how it worked. A few things I note: It works well for altering models (in the Modeling Window) - It's neat to be able to see those changes in realtime as the plugin's settings are altered. I had thought it was set and execute type of workflow. It doesn't appear to work in Poses or Actions (crash to the desktop on those)

Looking good from here. I'd missed your last few takes and it has been far too long since I checked in to see what you've been up to, so had to go back and catch up. Seeing Take 5 out of context was more than a bit disorienting! (the plus being that seeing it in isolation I immediately knew I was missing something important) Taken all together you've got quite a performance going on. I'm looking forward to seeing everything put together. I don't know the impetus for the whole presentation so I assume this to be a performance where the camera is motivated to move similarly to shows like 'Dancing with the Stars' etc.

I like! We tend to avoid painful processes don't we. That may be why I haven't delved deeply into rigging myself? I keep thinking 'this is the year I will master rigging' but thus far have always yielded to other priorities. I took a quick look at Mixamo but don't know enough to comment on it. It seems to me though that it's mostly a matter of workflow. On the one hand , *if* you could rig like Mixamo in A:M I assume you wouldn't have much need for Mixamo. If on the other you could export directly from Mixamo to A:M you'd have a more direct workflow. At issue then is the incompatibility between the two rigging approaches. BVH provides a solution but my initial foray into that area met with blank stares. Folks seemed content with starting from scratch every time which doesn't make a lick of sense to me so I shelved that pending additional R&D. My holy grail of rigging (and likely disconnect with reality) is a set of images from a book published in early 1900s that outlines 5 points of primary control/articulation on a character. In the little look I had at Mixamo they seemed to be oriented at least a little toward that approach. You may find yourself to be the pivotal part of your own solution in that if you can express the elements of rigging that keep you from reaching your goal (i.e. the painful vs ideal workflow) you may inspire a solution that improves beyond your original goal. What I'm suggesting here is that what you want isn't really a FBX converter/plugin but a more effective way to rig and animate your characters. At least that is what I perceive so feel free to correct me where I'm off. File formats are like hardware in that the closer someone programs to them the less compatible they are with where we really need to go.

Hey Kombowz, its great to see you again. Good news... that's not entirely correct. While there isn't currently a direct FBX importer/exporter several plugins have been improved and several others added in the recent past. And while there isn't a direct path for FBX to move back and forth it's a fairly trivial matter to move back and forth using secondary utilities. A lot depends on your workflow. If you build incompatible constructs in another program they don't miraculously become compatible in A:M. In time there will be but someone has to actually program and release said converter. Because this is a valuable workflow it stands to reason initial successes will likely be 'close hold' and proprietary for like.. forever. In other words, a programmer usually is hired for such work because the solution has financial value. Other than diving in for the shear challenge of it all why else might a programmer release such code. A constraint in this is that the average A:M User has few reasons to require such conversion. Therefore it depends on those who require the capability to invest (time/talent/money) in the solution. But there then is a key to opening doors in that where others can demonstrate the benefits of the FBX format in A:M (as a standalone all-in-one program) the usefulness of the format is shown. SubD's to splines in not a 'big problem' if you subdivide to quads before exporting (or perhaps more properly stated *before importing into A:M*). Having said that, continuity of splines can be problematic if the modeler isn't conscientious about how they are modeling so care should be taken to ensure smooth and continuous edges and loops. The real issue at hand for most folks is as stated in Kombows post; that of transferring bones and motion/animation. I haven't delved into this enough to offer much of an opinion but have seen enough to know there is a solution. I don't have a lot of incentive to explore in that direction because I have little personal need for that solution. The degree of success you will see will be directly proportional to your own interest in the solution. Since you love A:M I have high hopes. One thing you could do to further your success is fully document your current approach (i.e. what does success look like on both sides of the chasm), then a bridge or at least a better understanding can be built between the two. *It's well established that A:M works best with quads so ignoring this fact will lead to frustration.

On Tuesday I met with Paul Harris for several hours and discussed a very wide range of topics. We should have recorded the meeting although it's surely best that some things were off the record as that allowed us to wander far afield in the discussion. One of the subjects of interest concerned financial support (a very broad topic). I have a lot of opinions on this subject which I'll be more than happy to discuss but I am more interested in the thoughts of everyone in the A:M Community on the subject of grants and sponsorship. Some general parameters should probably be stated for the discussion but I don't want to miss important feedback by artificially limiting discussion so as far as I can tell there are no areas related to funding through grants and sponsorship that are 'off topic'. In addition to your thoughts it might also be good to get your take on the following questions: 1. If you were to (directly or indirectly) sponsor an individual or project what might that look like? 2. If you were to be given a (financial) grant how might that best be applied?

Some folks that frequent the forum from time to time keep in contact with him. AFAIK He can still be contacted via his site which should have the same email address that he's used for years. He still runs his film business (same website as well).

I don't recall it being included before. I think it had to be downloaded. This is similar to Emilio's other plugins such as SetBias which are/were must=haves in my estimation. No kidding. Very nice. I recall using Splitpatch to do something similar and definitely didn't get that nice of results. I started from a more complex/noncontinuous state (garbage in/garbage out).

Attached is the spherize plugin if anyone wants to test it out. I'm not certain if this is a full plugin, a limited version or something else... spherize.zip

Anyone knows about that? See you *Fuchur* Spherize was one of Emilio's paid plugins. His site has been down for years though so it can't be purchased that way. If contacted I'm sure he could still supply it. The trial still might be downloadable via archive.org Correction: Emilio's site is still active but I don't see all of his older plugins. http://www.moscafilms.com.br/emilioleroux/amplugins.html

Ha! Found it. The sphere in question (similar to Matt's first example) was created by Julian Fong: http://www.hash.com/forums/index.php?showtopic=23686

Nice! The first of those reminds me of another sphere someone posted a few years ago. I think it's still in the A:M Exchange area. My first quess would be that you used Excel or some similar spreadsheet like approach to create the model outside of A:M although I suspect you could also have performed some form of text-based search and replace? Do I get two guesses?

This is the wrong question to ask in that UV-unwrapping is an artificial construct to begin with, which isn't even required in some cases. For instance, how does one unwrap a spherical light? Answer: That isn't likely going to be necessary. The brevity of your question with your level of experience suggests to me you think you know the answer already. I hope that I'm wrong in this and your question is simply brief, naive and genuine. The superficial if not unfortunately self-referential answer is 'as many ways as you can UV-unwrap the sphere'. As I'm not you and don't know your specific workflow I can't answer the question without more information. How many ways can you currently UV-unwrap a sphere? Knowing that answer will help in understanding if you are missing out on any known ways to unwrap spheres. It is a easy to record your screen and show us your current (or preferred) approach to UV-unwrap a sphere. Having that information at hand we can better answer the question. The underlying answer approaches infinity based upon who is lighting or shading the sphere as most spheres in A:M are, for most part, simply modified cylinders. Given that, approaching from a view toward modified cylinders is likely to produce the best results. The primary issue then being one of diminishing size of patches as one approaches the poles of said cylinder/sphere. Lest someone thinks I'm dodging the question please consider Disney's PTEX which strives to avoid UV-unwrapping altogether. With this in mind the point of the question becomes moot. i.e. Answer: It isn't always always going to be necessary to UV-unwrap a sphere. But to answer the question. The answer from a purely user interface perspective within A:M is 'three'; spherical, cylindrical and planar (although specific workflows can augment these and approaches using other programs can augment those of A:M). Planar is the least useful of these and generally will only work best if/when the camera perspective is locked down. Planar can work quite well in these cases when decals are applied from the camera's perspective.

Did you know... There are more than 12 different ways to add a spherical shape or model into a project in A:M? (and there are a few more when we consider the variations on those). Here are some basic approaches: - Double Click on a Sphere in the Library - Drag and Drop a Sphere from the Library to the Choreography window - Drag and Drop from anywhere in your computers file system or desktop into A:M - Use the Primitive Wizard - Import a Sphere Model (via one of the many different ways possible) - Import a Sphere Prop (STL, 3DS, OBJ, etc.) - Borrow the Sphere from another project (copy/paste from Model to Model) - Use the Duplicator Wizard (also very useful for creating partial sphere meshes) - Create the sphere out of Light - Fake the sphere via a 5 point circular patch - Fake the sphere via standard patches - Composite the sphere into your scene via image/bitmap - Fake or create the sphere via Font or Adobe Illustrator wizard (bezier curves/vector graphics) - Ask someone in the A;M forum if you can borrow their sphere for your project And last but not least is number er...15... Model the sphere via the classic lathe technique. I'm sure I've forgotten a couple and I haven't included any method I haven't used yet (such as creating the sphere via data in Excel). Where/if there is interest we can explore each one of these methods in detail. This isn't just about adding spheres into a project. Knowing more about these basic processes can open new avenues of approach to solving problems and improve workflow over all.

Thanks Ken, I don't consider that bad news. I appreciate the dose of reality. It is too bad that the Unity/HAMR connection isn't feasible. Could you help my understanding of what you mean by proprietary? When you say 'proprietary' do you mean 'exclusive to Hash Inc' or something more akin to 'code that cannot be shared'? I suppose to me the first implies the viewer code can be shared/licensed by Hash Inc while the second suggests it likely cannot or will never be. To narrow the field of my specific interest let's say this concerned only the code to the HAMR viewer. If the folks at Hash Inc wrote that then I guess I'd have to ask them.

Yes, nice improvement! That's a really fun character. (I'd say scary but... I like fun better) That sounds familiar. I believe there is a workaround to that but I can't put my finger on it at the moment. At a guess try saving first before you copy/paste. (That can't hurt... especially if you save with updated/incremental filenames)

Nice! I am very impressed by your talent. That isn't anything new to say though... keep on impressing us! I'm looking forward to your approach to the bat-belt but even moreso to a bat-pose from here in the future. I know... I know... I'm trying to be patient. In the interim can I suggest that her gloved fingers be tapered just a little? They appear a bit stubby at the ends and looking at my fingers... I most definitely shouldn't have sexier fingers than Batgirl.

I hesitated to respond because there are two basic ways to respond to your situation. The first would be to solve your current issue. The second would be to suggest an alternative approach. Both of those have been discussed here. Briefly, if following your current course of using models as bubbles it might help to think in terms of a starting point, a middle and an end. The end is why your bubbles are returning to the diver. Something... perhaps a keyframe... it set to make them animate that way. So my suggestion there would be to first animate the starting position... then set the end position and with those in place work out the performance (this is the classic animation approach... two key poses... a breakdown... inbetweens) I think this would work out nicely but I perceive you'll want to more fully investigate the Timeline and Keyframes. The other methods would be (as suggested) particles (spriticles... blobbies... flocking). That last one would allow you to use a model. The standard approach will be to use particles sprites (spriticles). This is one of the reason I wish more A:M Users would throw caution to the wind and start posting here in the forum. (I wasted the first few years of using A:M trying to go it alone... in isolation,,, so I can sympathize) But we hope that everyone doesn't have to reinvent the wheel. We've got A:M... we want to create cool stuff with it... and yet we often don't take advantage of the best information available. We wont find everything we need in a book.. we won't find everything in a tutorial... we won't even find everything in a class or course on modeling/rigging/animation... although supplementing our learning those resources certainly can certainly help us along the way. We will find the information we need by interacting with others of similar interest and... barring the ability to meet others locally in person... this forum is the place to be. We won't always know the 'best' answers (only you can determine that) but working together most problems can soon be relegated to history.

I recall another interview being posted with Will that covered a lot of the background of Tar etc. but I don't recall seeing his interview with M dot Strange and Jimmy Screamerclauz. My apologies if it has been posted elsewhere already: (Note that this is all audio although its on youtube) Disclaimer: The video starts out with some harsh language but that is mostly only at the intro... then after the interview. Will keeps them in line during his interview. Of interest, the interview is somewhat relevant to our discussion here on feedback at CG Society. It also covers some of the history of the TWO project etc. Nice interview Will!

I've been thinking about how the Salt video referenced by CGIPadawan over at CGSociety applies and for the most part (as Will suggests in his response) it doesn't. There is one place where it does and that is in the pivotal shot that delivers the big twist at the end. Hopefully I can explain this adequately so it makes sense. The flow of the camera and cuts all work well up to the point where the last hyena is displayed and delivers his line. I'll track this because I don't think it particularly spoils the story for anyone who hasn't yet watched (but seriously... if you are reading this and you haven't watched the video yet... go watch it!!!): Intro - From the map camera descends on Tar (nicely executed BTW) - Tar walks - Cut to Hyenas - Back to Tar and Entry into the fray - Hyenas attack - Tar does his thing - Hyenas hit the ground - Tar moves on - Finale It is the setup of the finale that doesn't match with regard to camera movement in that if we try to match the position of the hyena with one that hits the ground in the earlier shot none of them are in a similar position. This plants a tiny seed of confusion in the brain because the hyena is very obviously one of those hyenas and yet his placement onscreen suggests he isn't. There are several things that could 'fix' this continuity 1) a moving camera during the fight scene that moves around the scene until the angle matches that of where the hyena is oriented on the ground. The second approach is less ideal in that it would be to flip the shot left to right which would more accurately align the shot to match the hyena that got his feet swept out from underneath him followed by a hit to the face with a massive club. Note that I only assume that hyena is the same one that delivers the final dialogue at the end. At any rate... that seems to be the aspect of the dissection of the move Salt that specifically applies to 'Marked for Death'. If CGIPadawan's primary suggestion is that building up to and delivery of that critical final line of dialogue isn't crystal clear then that is a relevant critique. The problem being that he doesn't actually say that in his critique. If the crit was meant to suggest the short needed to be clearer and yet the feedback itself isn't clear, the irony in that isn't lost on me. -

There are some really nice pics in there!

Very nice Robert! Edit: Looking closer it may need a displacement material that echos the main material to break up the smooth contour at the edges. I'm wondering if you could simply duplicate the material but then adjust the displacement setting... layering in the materials.