Why do you want to create your own system for this, instead of just using the VertexAnimator and the SkeletonAnimator classes in Away4?
Whether or not an animation happens on GPU depends on a lot of things, like how many joints each vertex is bound to, the total number of joints altogether, the material that is used, et c. It basically boils down to whether all the necessary variables can fit in Molehill GPU memory at once. However, if it won't fit on GPU, Away3D will just fall back to using CPU for the deformations and you shouldn't even know the difference (except maybe performance-wise of course.) In theory, you can have thousands of joints, and bind each vertex to all joints, and the animation will still play, albeit on CPU (because obviously that's too much data for the GPU to accommodate at once.) So the limits that you are mentioning are purely related to GPU animation, not animation as a whole. Have you tried using the VertexAnimator and SkeletonAnimator classes and not succeeded? If so, let us know so we can look into fixing any shortcomings that are in the animation system. Cheers /R On May 16, 2:26 am, 80prozent <[email protected]> wrote: > sorry > didnt made much more progress on the problem... > there is so much progress going on in broomstick right now, i decided > to wait and continue when a stable version is available. > > On 28 Apr., 09:15, Choons <[email protected]> wrote: > > > > > > > > > Hi 80pro, I'm curious about to handle this in broomstick as well. I'm > > curious if you have made any progress on the problem since you > > posted? > > > On Apr 4, 3:38 pm, 80prozent <[email protected]> wrote: > > > > hi, > > > > i am new to all this GPU Programming stuff, but i am trying to > > > understand shader-coding in Broomhill... > > > > what i am trying to achiv is a combination of skinning and morphing on > > > one single mesh (skeleton for body / morphing for face). > > > > the kind of morphing i am looking for is using relative MorphTargets, > > > not storing new positions for every vert, but just the vector, by > > > which the original (base) vert should by morphed. this way i am only > > > storing actual deformation, and no data for verts with no deformation. > > > > most of my riggs do not need more than max 3 joints per vert (current > > > skeleton handles max 4) > > > > my guess would be to make up a new set of skeleton classes, thats like > > > your original ones, but reduced in number of maximum joints, so their > > > are some vertex-constants left in the vertexbuffer to handle the > > > morphing. > > > > before handling the skeleton-data the shader could set the verticles > > > position by this vc. > > > (take vertex position->applymorph-constants->handle skeleton-data- > > > > >sent to fragmentshader) > > > > all the calculations for the morphing would be done on CPU, but in a > > > 10.000 vertices Mesh, it could be that only 3000 vertices are actually > > > moved by morphing, so you dont need do do any calculations for the > > > left 7000 verts. > > > > this vc would have to be updated to the GPU on every Frame the > > > morphing changes, but before building the mesh i could set up the data > > > in a way that the verts beeing not morphed appear first in the > > > vertexbuffer and then using a offset when setting the vc-data, so only > > > the acctuall 3000 morphed verts of the mesh gots passed to the GPU. > > > > is this right, or dead wrong? > > > > anothert question: > > > the vertex animation classes how manymorphtargets can they use? > > > > some code of VertexAnimation.as function "getAbsoluteAGALCode": > > > -------------------------------------- > > > var regs : Array = ["x", "y", "z", "w"]; > > > > for (var i : uint = 0; i < len; ++i) { > > > for (var j : uint = 0; j < _numPoses; ++j) { > > > if (j == 0){ > > > code += AGAL.mul(temp1, attribs[i], "vc" + pass.numUsedVertexConstants > > > + "." + regs[j]); > > > -------------------------------------------------- > > > > doesnt that mean their are only 4morph-targets (_numPoses) possible? > > > > Thanks for any help on this topics! > > > sorry for bad english!
