When it comes to Mouse3DEvent, The still meshes are fine. positions are right.
However when we try to click on the animated meshes, the position seems totally wrong (yet still has event but just position is wrong). It seems like the mouse3DEvent does not take account any bone transform data.

Anyone can throw us some clue on this subject, we would be really preciated, thank you.

kick it up see if anyone have encountered the same problem

i subscribe this post.

The situation : a simple plane with an event attached.

When the plane is facing the camera , the event is triggered. if i rotate the plane by 180 , the event isn’t triggered.

I think this is due to the normal vector of the mesh ... maybe someone more skilled can help us!

bardo - 27 March 2012 02:22 PM

i subscribe this post.

The situation : a simple plane with an event attached.

When the plane is facing the camera , the event is triggered. if i rotate the plane by 180 , the event isn’t triggered.

I think this is due to the normal vector of the mesh ... maybe someone more skilled can help us!

this problem has nothing to do with this topic ,hehe.
if your normal vectors a facing backward, you wouldn’t be able to click on. You shouldn’t even be able to see it if not double-sided

the material IS boublesided. i think the error is the same for both, the problem is getting a correct normal.

I do understand your problem, and you can solve it by adding a few extra line.

But this topic is total a diiferent one, it has something to do with the model transform before animated and after animated.
The mouse event seems to response to the model’s transform before animated, even it is animated to a different place.

kick it up to see if anyone have a clue on this topic, tahnk you.

This seems an offshoot of a problem I’m having.

I could be wrong, but from my investigations, when joint transformations occur in the gpu, this is done directly in Stage3D, and it seems as if there is no way of receiving the outcomes of these transformations. The only half-solution I’ve found is to manually morph the subgeometry, but so far I haven’t figured out how to do this while disabling the Stage3D transformations, so the transformations are occurring twice.

Any input into this problem and its solution would be greatly appreciated.

Colin Cohen - 19 April 2012 06:57 PM

This seems an offshoot of a problem I’m having.

I could be wrong, but from my investigations, when joint transformations occur in the gpu, this is done directly in Stage3D, and it seems as if there is no way of receiving the outcomes of these transformations. The only half-solution I’ve found is to manually morph the subgeometry, but so far I haven’t figured out how to do this while disabling the Stage3D transformations, so the transformations are occurring twice.

Any input into this problem and its solution would be greatly appreciated.

Finally, someone has got some clue on this topic,hehe.
We think your assumption is something towards a true explaination.
However, it can not be solved easily by just switch to software rendering because it’s still stage3d.
However, to morph it twice is also not effective in real production,so we are still looking. And hoping one day someone could come up with a easy away3d built-in solution,hehe.
Thank you very much.

What I finally did is turn on forceCPU, and this gives me a proper animatedVertexData without morphing the geometry twice.

Strangely, while this should turn off hardware rendering, I’ve experienced a noticeable speed improvement.

Now, I just have to write my own antialiaser

Colin Cohen - 26 April 2012 01:39 PM

What I finally did is turn on forceCPU, and this gives me a proper animatedVertexData without morphing the geometry twice.

Strangely, while this should turn off hardware rendering, I’ve experienced a noticeable speed improvement.

Now, I just have to write my own antialiaser

amazing, who’s the man? Yep you are!
Turnning on forceCPU in the animator class does indeed solve the problem of wrong mouse position.
However, the funny thing is our model seems to display wrong when under forceCPU. Some vertex get snapped to the center of the model. Do you have any insightful advice on this problem?

I can’t say I’ve ever seen that behavior. Though you can look at the morphGeometry() method of SkeletonAnimationState—that’s where all the magic happens. It could perhaps be a weighting issue. Maybe the hardware version of this method is more forgiving.

Colin Cohen - 01 May 2012 01:24 PM

I can’t say I’ve ever seen that behavior. Though you can look at the morphGeometry() method of SkeletonAnimationState—that’s where all the magic happens. It could perhaps be a weighting issue. Maybe the hardware version of this method is more forgiving.

We are still trying to figure out what we did wrong, maybe the max num of joints bind or something. But no luck till now.
Also ,one thing you may need to be aware, don’t download the new progress version from Github, it screw up even forceCPU.
So I am thinking maybe if it is us who did wrong some where on the axis direction when parsing binding information. Maybe the gpu cpu animation should behave the same.

Are you certain you don’t have any 0 weights on the points that are moving to the center?

Thanks for the heads-up about the new version. Though I’ve made so many changes to the source at this point that it would be suicide to download anything new. For good or bad, it’s basically mine now.

the new golden version seems also has this problem, and can not fix even forceCPU.
The mouse picking is not updated when the mesh is skeleton animated.

We are wondering why this happens?

kick it up to see if there is anything insightful advise, thank you.