Jump to content
Hash, Inc. - Animation:Master

Willi

Craftsman/Mentor
  • Posts

    157
  • Joined

  • Last visited

Posts posted by Willi

  1. thanx nemyax.

    i found it. RotateEuler does the trick for converting from quaternions.

    to quaternion i found something in Rotate.h, like this

     

    Quaternion quat;

    RotateEuler euler;

    euler.x = 10; euler.y = 20; euler.z = 30;

    if ( euler.z )

    quat = YXZRotateQ( euler.y, euler.x, euler.z );

    else

    quat = YXRotateQ( euler.y, euler.x );

     

    maybe this can be shorter like:

     

    Quaternion quat;

    RotateEuler euler;

    euler.x = 10;

    euler.y = 20;

    euler.z = 30;

    quat= Quaternion(euler);

  2. the "SampleRate" slider does nothing at the moment.

    the samplerate is hardcoded to 1 wich means that the plugin records 1 sample per frame.

     

    by increasing this value, lets say 4, then the plugin would record 4 samples per frame, which ends up in a 4 times slower motion.

     

    i made some test with an updated plugin, where the samplerate-slider is active, but i get strange results in 3ds max...

  3. just had a quick look at the source of luxrender and it provides a lot of primitive shapes like polymeshes, nurbs, catmullromsplines, spheres, nurbs, etc...

    the hash-splines primitive shape could be implemented in this "shape" class i think, for a programmer...but i think that the hash-splines are licensed, so not open source...

    the only thing that maybe could work is to convert the hash-splines to polymesh via "IEPoly" with "adaptiv" option...resulting in very very high triangle counts...

  4. @bucket rendering

    this has to do with multithreaded rendering and memory managment. the render screen is devided in little rectangles(buckets). every processor/thread then takes a bucket to render the image.

     

    @third party renderers

    maybe this would never be possible, because of hash-splines...

    i think/guess the am-renderer uses its own primitive type (hash-splines) to determin ray-intersections...

    most of free open-source renderers, like luxrender, mitsuba, pbrt, appleseed, etc, uses ray-triangle-intersection methods...

  5. some wishes:

    -ability to implement third party renderers via sdk

    -sun/sky system for the renderer

    -faster raytraced ambient occlusion (maybe through gpu computing?) (NOT SSAO)

    -true mutithreaded rendering (not instances) and bucket rendering

    -better cp weighting editor, maybe paint weights

  6. if you have an action in "actions" you cant bake the action directly...you have to drag it first in a chor and then bake the action...

    also the baking system in a chor will always bake from frame 0. so if my animation goes from frame 5000 to 5050, it always starts at 0 to bake, wich ends up in very long baking times...especially if you have a lot of bones....

     

    and the baking system, especially the "bake dynamic systems" bugs...

    so i want to write my own baking...

  7. nobody will use the hires mesh of zbrush. there is always a retopology process in conjunction with all the detail maps to get the final model for the animation process...

     

    the bottleneck in the animation-performance is always the "skin-deformer". it doesnt matter if its a spline-model or a poly-model. with a very dense spline-model you have also animation performance leaks.

    thats why animation studios have several models, like a lowres animation model with only to the deformers parented, cut-out, bodyparts, wich avoids the "skin-deformer", and the hires model for rendering...

    also its common to use vertex caches, like alembic, after the animation process, to avoid the preprocessing steps for rendering.

     

    in a:m you cant avoid the "skin deformer" . you cant parent model parts to the bones...

    also a imported mdd cache is always applied to all the model cps as keyframes, wich can end up in a very slow animation, when your model contains a lot of detail. the mdd is not dynamcly read from file during the timeline...

     

    for a polygon-module inside a:m, i think the things for bringing this up, are more or less there...

    -a spline model is also a bunch of cps connected together ( in this case with hash splines). lets them connect as polygons...

    -you can import polygons as props and they are displayed and rendered properly, but you cant edit it, or assign bones to it, or smooth them as subdivisions...

    -mdd importer/exporter is there (also a selfmade pc2 exporter)

  8.  

    Why is it important to you for A:M to interact with other 3D products?

     

    every 3d-app has its advantages and disadvantages.

    some has features that other dont provide. there is no "all-in-one-app" out there. and if you use 3d apps in a professional way, you automatically have to use other 3d-apps than your favorite one...and you have to bring your data in and out...

     

     

     

    This makes me guess you are less impressed with A:M's modelling and rendering

     

    a:m´s modelling is great for its internal splines...i like it.

    but if you dont stay in a "polygonal way of modelling" inside a:m (like not using 5-points, not using hooks, trying to decal without overlapping), you dont get your data out of animation master without rework...

    concerning rendering, thats true...i am not impressed. its slow (no "real" multithreading, slow AO, slow and not usable GI, etc).

    in the end of every 3d project, the final image is what counts. to get there i can use other renderers, but those are all based on polygons...and so i am back to modelling, where i have to try to get the spline-based model data out to my favorite renderer...

     

    its possible to have a workflow of modelling, rigging, animating in a:m and then rendering in other renderers. a:m provides that tools (obj-export, mdd export, my custom cam-export tools). but there are a lot of things to consider (especially in a production enironment) before rendering the first frame out in that external renderer.

     

     

    3rd-party renderers by API is something, that would be very cool and sounds to me as the easiest stuff to do

     

    @fuchur, @steffen: what you think, is it possible to integrate "cycles renderer" in a:m as a plugin?

  9. i know.

    but when it comes to hooks and 5-point-patches you get into trouble exporting that...

     

    i would love to see a "polygon module" that can handle import/export and be able to apply all the animation features on it...

  10. Just imagine...

     

    ...A:M would have polygons and OpenSubDiv....

    ...and alembic support....

    ...and support of integrated 3rd-party renderers in the API / SDK...

     

    with that, A:M could be a serious competitor to all the major 3d-applications out there...

     

    A:M has the best data management, animation and rigging features that i ever seen in all the other major 3d-applications.

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

     

     

     

×
×
  • Create New...