absolute vs relative positions again - ignore previous

(I'm pretty sure this is a much simplified version of my previous "absolute vs relative positions" question.)

Load the enclosed blend file, do a 'fast preview'.

Why does the red plane appear in the wrong place and is there a way to fix it - i.e. make it show up in the same place it does in blender?
TIA Phil Robinson

Why does the red plane appear in the wrong place and is there a way to fix it - i.e. make it show up in the same place it does in blender?

You have paranted red plane to vertex - it's not supported yet. Change paranting to object.

Ah ok thanks, I was beginning to suspect so.

Here's what Im trying to do; maybe you can suggest a method?

I have an aplication in js using your api. I want to be able to adjust the dimensions of the 'cube' and restrict them according to various formulas.

I can add bones to the mesh so that the faces of the mesh 'follow' the bones and that adjusts the shape exactly as I want, but how can i restrict the length, width and depth according to my needs?

To do so, I need to know where each face _is_ so i can work out if it's allowed or not.

I can't just use the bone positions as the vertex groups they control are influenced by more than one bone, so the bones move further than the vertices. I can't find a way to discover the position of the vetices themselves, and I can't parent another object to a vertex thern find out where that is. I'm out of ideas! Can you think of a way to do this?

All it amounts to is: how can I find out via the api where a face/vertex/vertex group is? Thanks again for your help. Phil

I can't find a way to discover the position of the vetices themselves, and I can't parent another object to a vertex thern find out where that is. I'm out of ideas! Can you think of a way to do this?

You can add to group only onne vertex for one bone, so you can get location of each bone.

Can you give us more explanation so we can find the decision for you? A scheme or something like that will be helpful.

Thanks Mikhail

OK, more info …

Take a look at:
http://philsboatshop.ponytrot.net/node/13?v=joe90_customise
I've uploaded the blend file for it here.

Also, there is a bit of js which is configured to know which bones
can be moved in what directions.

As you see, the idea is that you can adjust the dimensions of the plate
and the positions of the holes, but the holes must stay inside the plate.

A plate edge can be adjusted with the sliders, and when it gets to within a
set distance of the holes, my code detects the fact using get_bone_tsr() and
prevents further movement.

But that doesn't work properly when you adjust the holes positions because
the bones are not in the same place as the vertex groups they are parented
to, because the vertices are being influenced by more than 1 bone, so a (eg) a
1 unit movement of the bone doesn't result in a 1 unit movement of the vertex
group it controls.

That's why I tried parenting a mesh to the vertex group instead, so I could then
detect the position using m_transform.get_translation() instead; unfortunately, as
you say, that's not supported by b4w so that doesn't work either.

(To see this go wrong, make the length or width bigger with the slider, then adjust
the holes 'outwards' too. They will go outside the plate.)

Can you think of a way to do this? It's basically just collision detection, so I hope
I'm missing something obvious?

Thanks, Phil

Take a look at:
http://philsboatshop.ponytrot.net/node/13?v=joe90_customise
I've uploaded the blend file for it here.

Ok, I understand.

So, what you need to do:

1)you need to parent on each bone only one corner and move two bones at the same time. So there will be only one bones on each vertex group.
2)Also you need to parent collision boxes to the bones: for holes and corners and detect collisions between then using phisics.

I prepeared and example for you, but without coding. To avoid collisions between holes and corners use different Collision ID.

> 1)you need to parent on each bone only one corner and move two bones at the same time. So there will be only one bones
> on each vertex group.

I feel completely stupid for not thinking of that. Thanks so much.

> 2)Also you need to parent collision boxes to the bones: for holes and corners and detect collisions between then
> using phisics.
Yes; once the vertices are following the bones properly, I could indeed do that. Actually though, I
already have working code to detect bone collisions, so I think I'll stick with it as it makes the
models simpler, but thanks again. Your support is really fantastic for a free api. Cheers, Phil