This is probably more theory right now then code but oh well..

I have two Meshs. One contains a Player Model, the other contains an accessory like a Hat. Now, IF I just do a Mesh Merge, the Hat will, as I understand it, not know how or be able to follow the location of the player’s head. When standing still it might be perfect, but if the Character was knocked back, laying on the floor etc, the Hat would float in the air. Ideally, the way around this would be to be able to ‘mark’ a vertex in the Player Model as an alignment point, so where ever that vector goes, the Hat follows. This probably doesn’t take into account rotation though.

While the quick and easy fix would be to give the Hat a series of animations that align with the Player, this wouldn’t take into account a range of player models. What if one character was taller? possible to just raise the Hat model so the offset deals with this.. but what if there was more of a range? two characters might not have the very same hurt animation, or something. it would require the same model twice with two different sets..

anyway, I think the Hat idea isn’t the closest to explain the range but it’ll do.

so.. is there some way to mark some vertex’s as ‘lock on’ points for merging of other meshs? I’m using Prefad’s As3 Class models

———-
Addition
———-
The thought crosses my mind about adding invisible boxes or such like meshs to the original model as lock-on points.. that would deal with rotation and placement as these boxes would be animated with the main model..

if you need the hat to be variable in transform, merging has no use.
Plus merging will not support the frames, and unless you share the material, it will make 2 buffers anyway….

In the prehistoric times, I wrote a dedicated class for this very specific case
http://www.closier.nl/blog/away3d-facelink/

If you would refresh/rewrite this class a little by making it use indices instead, that’s all you would need…

Ah, that looks good.. I’ll look into it, Faces would probably be a better idea from the indices..

just figured out why I didn’t notice this class before.. Its in 3.6 but not in 4.1.. a simple copy works or does it need a total rewrite?
———-

I’m working on a quick update to the facelink function.. having a bit of trouble with the faceindex as meshes don’t seam to have a face array in 4.x but i’m sure i’ll figure something out

—-
Oh I misread your comment at the end, sorry ^_^;
I can never understand indices really.. vertices I understand… I trace the indexData[15], and it just returns 15.. I trace indexData[25] and it returns 25; so I just really don’t understand indinces..

VertexData seams to be better or easier for me to figure out, X,Y,Z format, so VertexData[0] is 0X, VertexData[1] is 0Y, VertexData[2] is 0Z, VertexData[3] is 1X etc, as I understand it. So I should be able to get this working if I’m right ^_^

I think I’m heading in the right direction but as it doesn’t work right now, it means I’m not there yet..

the one bit is very dirty code to get it to what I want, and I hope to clean it up but.. does it look like I’m heading the right way?

ahahaha, I like this message
just keep in mind its all in the normal and where it starts.
so if your class does keep track of a single face (3 indices),
you have the face centroid, and the normal so its just a matter of aligning to this direction, (a matrix to compose similar to lookat one)
or placing your hat relative to this location along the normal.

mmm.. I do see that the face details aren’t been kept track of.. It makes a face from the starting point values (or so it seams) and then doesn’t keep track of it as the movement is done.

took me a bit to figure out he normal, having to create it from scratch and all.. with the offset as 10 as a test, changing the face number does move it around, so something is right I guess ^_^

If your hat has its own animation, I think the best way is to update its global position the way facelink does it.
It’s just an idea but you can also get the position of your character’s head with a jointPose.translation or jointpose.orientation and move your hat accordingly.

But if there is no animation on your mesh you can find some more optimised way to link it on your character.

Maybe if you add the hat as a submesh of your character… Then you may just have to connect your hat to the joint in the head… And maybe, if i’m not wrong, it can follow the head whatever the animation applied on your character. can’t it?

Or you can connect the hat on a clone of the skeleton of the character and apply the same animationset on it

The good point by using the animator is that you can use the GPU to play the animation of your hat without calling a function “update” at each frame.

jointPose would probably assume it’s a skeleton animation, where I use vertex animation, but the idea would be somewhat possible… but probably more work and less fun then figuring this out ^_^

Ho! Vertex animation… I didn’t understand that from your first post… Its a bit more complicated. Good luck ^^

^_^ no problem

While Skeleton animation has a lot of pros (like making one set of animation and putting it to tons of different models), I’m far more at home with Vertex animation.

the principle is same, the class does for both type of animations what the joint would allow to do for skeleton. But if you want do cool things like let an object follow the mesh surface, even if its moving, the class would do it for any mesh, animated or static. Adding to it a simple interpolation and update of face reference or pass a vector of faces, would allow complex animation perfectly sync with the geom movements. Think here of flying object above surfaces, the gun coming out holster etc…

Anyway, this old baby can use an update and tempy111 will do it for us

if I can, it’ll be good ^_^

just looking while debugging.. my main character model for this has a reported 7164 vertices.. number of triangles (faces) is 2388..

but the off thing to me is.. VertexNormalData array? how do you have a normal of 1 vertex?

public static function getTriangleNormal(v0:Vector3D, v1:Vector3D, v2:Vector3D, out:Vector3D = null):Vector3D
  {
  var dx1:Number = v2.x - v0.x;
  var dy1:Number = v2.y - v0.y;
  var dz1:Number = v2.z - v0.z;
 
  var dx2:Number = v1.x - v0.x;
  var dy2:Number = v1.y - v0.y;
  var dz2:Number = v1.z - v0.z;
 
  var cx:Number = dz1*dy2 - dy1*dz2;
  var cy:Number = dx1*dz2 - dz1*dx2;
  var cz:Number = dy1*dx2 - dx1*dy2;
 
  var d:Number = 1/ Math.sqrt(cx*cx+cy*cy+cz*cz);
 
  var normal:Vector3D = out || new Vector3D(0.0,0.0,0.0);
  normal.x = cx*d;
  normal.y = cy*d;
  normal.z = cz*d;
 
  return normal;
  }
just pass the 3 vertices. For vertex animation, normals are not updated for perf reasons.

oohhh and that is SOO close to what I have.. up till the var d bit, it’s pretty much what I have got..

making a minor issue right now to do with getting the vertexdata.. when I set it up:
‘_source.subMeshes[0].vertexData[_faceNum]’
(where, for the sake of things _faceNum is a 0) gets a value. the first update, it gets a value, every update after that, NaN.. despite _faceNum not having changed and the _source still being the right file.. weird.. looking into that

Still not there yet but good progress.. it seams to move with the model

attached current version

——
Debating… it’s close I think.. either one thing is slightly off, or I’ve made a couple of mistakes with my testing.. the object seams to be reversed in the lookat direction, and putting the update call with the Render isn’t working as smoothly as I wanted.. i’m not sure right now if that’s due to the code or the animation is moving faster then it’s rendering (if that is possible).

local time getting on, I got a busy day so i’ll go back to this in the morning ^_^ still, i’m fairly happy with the progress so far

————
Need to / want to update the VertexData bit. I’m taking it that
subMeshes[0].vertexData[0] is point0.x
subMeshes[0].vertexData[1] is point0.y
etc. so it’s in blocks of 9, runnings XYZ,XYZ,XYZ

but that might not be right.. It does lock onto faces but .. not correctly.

Indices still confuse me as I said before IndexData[0] seams to be 0 and IndexData[1] = 1 etc..

————-
looking around.. VertexData is in fact
the three points (XYZ,XYZ,XYZ) and then the U, V, Su and Sv… so that might explain the problem…

much better but still wrong..

okay, attaching current version..

I’m a bit stumped right now but I think something to do with the _source.sceneTransform.deltaTransformVector line… the vertex data appears correct and loads right, but I think the conversion might be creating a problem..

well.. if not that, I’m currently convinced that I’m correctly loading the 3 vertex’s right, but it’s not converting them from local to global right… I might be mistaken but that’s what I’m convinced of right now…

——————
Okay.. working a bit more.. adding comments and.. there isn’t anything that takes scale into account? checking my main model, it seams the scaleX Y and Z is set 407 (small model it seams. it was rescaling with prefab) yet the hat model is a much bigger model which a scale of about 1. it might not be the case but I got the feeling.. what happens if one model is scaled and the other isn’t? does the deltatransform take that into account then converting the local vertex to global.. I can’t see the code that does that.. and .. while it might not be the problem, it would explain some of the issues I’m having… so looking into that right now

——
sigh.. nope.. not that I think…
need to figure out why the hat doesn’t move that far up the model… the reference point is the feet… all I can think is maybe the X,Y,Z isn’t right.. but they should be… mmm. scratching my head a lot..

———-
I’m not sure how, but has to be scaling.. only thing left that makes any sense.. also.. how the hell can a vertex point bring back Not a number?

———-
sigh.. isn’t this fun… I get very sure of something and then back to saying it’s NOT the case.. scaling does seam to be taken into account.. it’s back to the VertexData being wrong.. either not the format I believe, or just wrong somehow.. I wish I knew about why the NaN returns on some values..
_source.subMeshes[0].vertexData just doesn’t seam to be right for some reason.. i’m not sure why.. this should be much easier then it seams to be.. using VertexPositionData, the vertex data is the same (just without the UV lines) so it’s comfirmed.. the delta transform lines up with manually dealing with the scaling so.. confused more..