Rodney

I've used it for several conversions. Of course the first sort is FBX to OBJ. A less obvious usage would be the OBJ to OBJ conversion that converts tris to quads. The problem with approach this is that the FBX converter doesn't directly convert OBJ to OBJ (that's not an option) so an interim/extra conversion is required. You have to convert OBJ to FBX and then FBX back to OBJ (but with the 'triangulate' checkbox unchecked/off). There are a couple of programs I tested out (MakeHuman and... ah... I forget the other one but it is a lot like MakeHuman). Here's a topic where I posted a few models and others plussed up the results: http://www.hash.com/forums/index.php?showtopic=45450

We'd actually have to have a film project in mind before chasing after such a grant. I'm not opposed to folks creating films but the very first thing I tend to do when meeting new folks help them reconsider the idea of making the next 'Star Wars'. I figure... 1) If they can overcome a little resistance they may have what it takes to actually make a film 2) They'll usually need to build confidence on smaller projects before diving in to the deep end. One 'problem' with grants is that some form of result is expected from those receiving the grant. If there is a likelihood the project will not come to fruition the grant may very likely not be issued. I should have mentioned that for our purposes I am talking about *establishing* a grant although if someone could find one... hey, count me in! This (the pool of resources to draw from) pretty much guarantees the amount of said grant to be small/tiny/minuscule. BUT... if that grant actually satisfies a need then it has served it's purpose right? In previous posts I intentionally dropped a few hints into my general orientation concerning grants (see up there ^^^). The first is to help talented folks maintain access to A:M. The second is to educate them in an area compatible with the interests of the A:M Community. I know that's a tall order but if one is to begin they must start somewhere. I now there was someone who lives/lived in Springfield... Vance maybe? We do have several Chicago denizens (and while he hasn't been seen in ages David (he wrote the book)Rogers use to hang his hat there. The Tinkering Gnome and Jeffrey (Zayrin) Bolle are a bit farther to the north in the Milwaukee area (I need an excuse to visit family there). Den Dotson lives close to me near St. Louis. All we need is a reason to gather. Actually, the next time Hash Inc is in Chicago (is the Chicago Comicon/WizardCon still hosted there?) that's a likely place to meet. Since you (Paul) fly in and out of IL from quite a distance away I suspect you don't care to travel a lot once on the ground.

I'm sorry, I don't follow you. I should use bitmaps in order to avoid using bitmaps? Hmmm... on second thought, I may have to try that.

One use case: Upload a single project file to the forum that contains everything needed to ensure success within that project file. Avoid using zipped files, pdfs with attachments etc. as they introduce unnecessary variations into the process (often leading to missing or misplaced files). On the simple side of this scale this is trivial but on the other with more complex projects this workflow breaks down largely because the average project relies on external files (primarily if not solely bitmap images).

I'm not a purist so much as a realist and don't have issues with polygons where understood properly. And if those models you create with polygons won't move or be distorted in any way... they'll work really well imported as Props. There are still a few issues with texturing those (some transparency settings don't appear to operate properly) but for the most part those are largely resolved. Polygons are easier to manipulate at the lower end of the scale but inversely more difficult to manipulate at the higher end (esp. when animated). I suppose the reverse could be said concerning splines as splines are less beneficial in simple static or non-continuous constructs (there is an inherent tension with spline based patches that doesn't exist with flat planar polygons). I equate this to the difference between bitmaps and vectors; bitmaps work quite well except where they do not. As do vectors. There are classic tricks used to suggest the movement of static images such as the replacement of one static image for another in rapid succession but the real promise of automation (and computer animation) is to move beyond that into actual movement of objects. It's taken 100 years to approach that type of animated movement outside of puppetry and stop motion. I've mainly used the FBX converter as a conduit to transform/subdivide triagonal meshes into quadrilateral meshes (the one being useless to me while the other is not). I'm sure there are strictly OBJ converters that can do that type of conversion but I've yet to find one that produces meshes in the same way that an interim pass through another file format such as FBX does. But note that Autodesk's free FBX converter supports both tris and quads so one must tell it to override the default which is set to spit out triangles. (the good news... in the interface it's a simple checkbox)

. If that were known I think we'd already have a solution but I'll take a stab at it.. As near as I can tell the underlying problem is one of communication. The person with a need must connect with other persons willing and able to answer that need. Or at least to supplement or resolve a portion of that need.*** But this may be entirely too cerebral for our purposes which is exactly why I am more focused on the idea of grants. I may be wrong here but it seems to me that grants are already funded and simply awaiting distribution or disbursement. This is unlike rounds of funding in that grants more specifically target a given need whereas funding raises the money to fulfill those needs. For sake of discussion, let's assume that Kickstarter developed a fund that would be used finance a few projects introduced into their system (say they were to take 10% of their profit and randomly gift it to a Kickstarter project). Random would certainly be controversial... but that's exactly how the lottery system is said to work these days. In a way Kickstarter does this 'granting' to certain projects though exposure via website and email/newsletter (i.e. a few projects are granted prime online real estate). They don't have to pay the project heads anything but occupying that space is certainly valuable. Perhaps folks even pay to occupy that space. Somewhat esoterically something similar happens in the forum banner (for those that opt to use that particular forum skin). As a topic of interest shows up on the banner folks are more likely to see it. Those are all important... and I've gone out on a tangent to outline support that circumvents the monetary exchange... but specifically we are talking of thing that require the exchange of monetary funds here. The assumption being that there are products and services that require payment. For such transactions money is the most direct means of communication. ***Other underlying problems: The person may not know what they need or they may not accurately communicate that need. Regardless, they still have that underlying need. Added: I'd say the most basic need of all A:M Users (outside of Maslow's Hierarchy of Needs) is to maintain access to A:M. Those must be satisfied before any other needs.

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)