Jump to content
Hash, Inc. - Animation:Master

nemyax

*A:M User*
  • Posts

    373
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by nemyax

  1. Do you know what the differences are between Voodoo and BUF software?

    I'd love to compare them, but, needless to say, I haven't touched either. From the promotional videos and images it looks like the UI design is different (BUF's stuff is reminiscent of the old Softimage 3D).

  2. Rodney

    It appears that BUF Compagnie and R&H aren't (weren't) affiliated. Their paths crossed, of course, as they worked on shots for the same titles, but the studios have separate histories. Why did you mention R&H? Did you mean it became the "last straw" for BUF?

  3. animation A:M >export to rendering external polyrenderer

    For this part, you're probably best off using the existing export path through MDD. If you want to keep the curvature you have in your patch model, you have to give it a couple of subdivisions to apply the shape, so that the subsequent subdivision by the external renderer doesn't unexpectedly shave the model.

    However, A:M's pre-export patch subdivision could use some improvement, as Malo suggests above.

  4. If the specifications for A:M's proprietary formats (which are plain text anyway) were made publicly available, that would be a huge step towards problem-free data interchange. That's the least Hash Inc. could do, and it wouldn't even cost them anything in development.

    This is somewhat related to Rodney's question elsewhere:

    where are the big guys coding bridges to Hash Inc?

    The company isn't giving their specs away, so why should anyone bother?

    Newtek document their formats, and as a result they are popular and well-supported.

     

  5. Fuchur

    Do you mean reimporting them as hooks again? This would require agreeing upon a convention for what kind of polygon to treat as "hooked". For example, you might want to interpret the topology below as a patch with 3 hooks on one side. Looks easy enough.

     

    3b910c7ceb18340b24d4c835b6cfe26e.png

     

    But it's always going to be ambiguous. If you make the topology a tiny bit more interesting, it becomes unclear which way a hook should go. See the selected point:

     

    a0dbf834ef00a5ae78d52064b99ab4f7.png

     

    I don't think you can support hooks using strictly topological cues.

  6. One solution would be to get to create a topology like this:

    hooks3.jpg

    If you have to subdivide them, you may as well give them the regular Catmull–Clark treatment:

    2dfeea8757813ab6604224a50098cdf2.png

    It's ugly, but at least it's consistent and expected.

  7. The problem are approaches like micropolygone modeling or voxel modeling with ZBrush, 3dCoat or MudBox which will create millions of polygones. Simple SDS-modelling will not create these complex control cages, but these micromodelling-models are close to unmanageable for A:M. I am not sure how well these models are animateable at all using even weight transfering, since these details would need a special form of rigging to animate perfectly, but I doubt that many people do that at all...

    These models aren't normally supposed to be animatable. They are mainly for displacement map generation and material design.

     

    If the answer is actually easy and you know what it is, get a programmer to do it and tell him what to do to make it happen.

    Do you mean polygonal export? Styler implemented it recently in his 3D Coat link without much trouble. I believe he even used an external FBX library.

  8. Polygon models need so many vertices (CPs) to simulate smoothness that it is no longer feasible for a human to weight them between bones for smooth deformations. You would also have to add all the "deformers" that try to automate that process in polygon programs and those things are not simple.

    Wrong. Firstly, the smoothness is provided by the subdivision algorithm. Secondly, you have the option of using a very lightweight deformation proxy mesh, which drives the deformations of the denser mesh like a lattice, and you only need to weight a handful of verts. Thirdly, a good spline model—I don't mean the likes of "Thom", but the really good stuff on display in the gallery and in this forum—is about as detailed as its polygonal counterparts would be.

    Note: I'm assuming the case in point is prerendered animation, not real-time as in games. If it's animation for modern games, you are in the same kind of trouble in A:M—direct manipulation of dense geometry.

    The "lots and lots of polygons" prejudice is common in this community, probably stemming from this bit of misinformation (and others like it) in the reference:

     

    Without getting too technical, modeling technologies are divided into two camps: Polygons are prevailing, but patches are the future. Polygonal programs represent models, such as a vase, a gear, or a human head, as large numbers of tiny flat surfaces. At close inspection, the polygonal models appear to be made out of crystal, for example with many tiny facets forming the curvature of an eye. A polygon model that is composed of hundreds of thousands of polygons is not uncommon.

    Polygons have a long history, they are easy for programmers to understand and implement (most computer hardware use polygons for this reason), and have a large installed base of existing models and tools to manipulate them. However, building the model in the first place is extremely difficult, and manipulating the thousands of polygons that make up a character’s mouth for lip-syncing is virtually impossible for a human. Consequently, polygon programs must provide an endless variety of tools to help move the large amounts of polygons indirectly. For example, you would associate the dozens of polygons that form the upper corner of the top lip of a character’s mouth with a bone, do this with all other parts of the mouth, then manipulate the dozens of bones to make the model talk. This explanation glosses over the difficulty in identifying the polygons that go with each bone, and the model distortion that occurs at the junction between the bones. Whatever the difficulties, many fine animations have been created with this technology by animators who sweat blood on every frame to make it look just right. Certainly, this is not something you want to do.

    It reads like a 70's Pravda article. These things may have been somewhat true in 1995, but today it's utter FUD.

     

     

    I could imagine a SDS- / NURBS-modeller in A:M which will use Spline-Data from A:M to create the cages, animate only the cages and just interpretes it differently.

    A non-spline modeller in A:M will never happen, but if it did, this would be a waste of effort. Excellent polygonal modellers are a dime a dozen these days. Off the top of my head, at least four of them are free (Blender, Wings, Softimage Mod Tool, VoidWorld). And it's entirely possible to bring a polygonal model into A:M.

     

    A good interchange-format would be cool, but I am not sure where to start there. It only makes sense, if other software programs could handle splines (or better to say: Hash Splines).

    They never will, and any interchange would involve pretending that spline models are polygonal models and exporting them accordingly. And if you are animating for games, for example, you have no use for spline output anyway.

  9. the lack of not having polygons makes it really, really hard to interact with the other 3d products...

    I don't agree that's the problem. Polygons are easily represented by patches, but not the other way around. Crank the geometry resolution in the viewport all the way down, and you'll have polygons.

    In other words, polygons can be derived losslessly from spline and patch data, but the reverse is not true because of hooks and bias handles.

    It's the lack of interchange format support that's really at the heart of the interaction issues.

  10. the OpenGL issues... that's surely going to be easier to solve with good feedback provided to Steffen... although I haven't seen those in A:M Reports

    I didn't post that one, so it's probably my bad. But robcat2075 said he'd pass it on to Steffen.

     

     

    where are the big guys coding bridges to Hash Inc?

    But they are. That's what interchange formats are for. You don't see them supporting each other's native formats either, but the middleman stuff is supported both ways.

  11. Rodney

    Well, I'd subscribe again if FBX/Collada export materialised and Hash Inc. fixed the OpenGL issues that keep me on an old version.

    I don't see A:M as a complete solution for myself. I like the choreography workflow very much, but that's about it. And due to lack of export I can't extract the work I do in choreography. As it stands, I'm better off using the free Softimage Mod Tool or "the B word".

    It's a sad thing that users like rasikrodri and Malo have to do Hash Inc.'s work and pay for the privilege =(

  12. how do you export to blender ?

    You don't. There's no support for animation interchange formats (FBX or Collada). There's some support for BVH, which handles bone motions, and you can export geometry separately. You'd have to rebuild your work in Blender piece by piece if you took that route. You could also export posed geometry (one file per frame), but you probably don't want to go on that adventure.

    Do it all in A:M.

×
×
  • Create New...