TFormPoint trouble

Hi

I have 2 entities and all I want to do is convert the first entity's world coords into the second entity's local coords.

I can do this using TFormPoint except when I ScaleEntity one of the entities, TFormedX, TFormedY and TFormedZ seem to be affected by the entities scale.

	Graphics3D 800,600,32
	SetBuffer BackBuffer()
	
	cam = CreateCamera()
	PositionEntity cam,0,0,-15
	
	light = CreateLight()
	
	ball = CreateSphere()
	PositionEntity ball,5,6,7
	
	cube = CreateCube()	
	;ScaleEntity cube,1,2,3 ;Un-comment this to get strange results!
		
	While Not KeyHit(1)

		TFormPoint EntityX(ball,1),EntityY(ball,1),EntityZ(ball,1),0,cube
	
		RenderWorld

		Text 10,10,TFormedX()		
		Text 10,25,TFormedY()		
		Text 10,40,TFormedZ()		

		Flip

	Wend

	End

I can't believe TFormPoint is supposed to work in this way! Any ideas?

Cheers.

You can use ScaleMesh or ScaleEntity.

Just noticed this recently - bit of pain. The only thing I could think of was the obvious .. hold the entityscale somewhere and divide the tformedx etc.. by this scale.

It's probably quicker than the trig involved doing it another way.

jfk: I don't know what you mean. I know it works OK if I use ScaleMesh instead of ScaleEntity but I dont want to scale the mesh.

Stevie G: Definately better than using trig - especially when you take into account my maths abilities. :) It would help if B3D had functions to retrieve an entity's scale. I can't track the scale myself because it's for a library function. I could have an 'entity scale' param but that would require the users' code to track entity scales. Not very user friendly. This is going to turn into another bodge workaround - again. :/

Sorry to rant but why the hell does TFormPoint take scale into account at all?! Makes no sense to me. Rubbish! :P

I just noticed this with TFormVector.

I used Halos library which has EntityScaleX(),EntityScaleY(),EntityScaleZ() commands. Very handy , thank Halo.

Has scaling always had this effect ?

My Particle system was working once ! But now a particle which is parented to the particle generator at spawn time , gets a bigger scale each time. It doesn't look visually bigger but using TFormVector to calculate the force , gave bigger and bigger values making the particles get faster and faster!
Removing the parenting and just using its coords to place the particle fixed the problem. But it was a strange bug to solve!

Just what result was everyone expecting from the example?

Consider this slightly modified version.

Graphics3D 800,600,32

cam = CreateCamera()
PositionEntity cam,0,0,-15

light = CreateLight()

ball = CreateSphere()
EntityColor ball, 0,255,0

cube = CreateCube()	

PositionEntity ball,0,6,0

;ScaleEntity cube,1,6,1 ;Un-comment this.
	
While Not KeyHit(1) 

   RenderWorld

   TFormPoint EntityX(ball,1),EntityY(ball,1),EntityZ(ball,1),0,cube

   Text 10,110,TFormedX()		
   Text 10,125,TFormedY()		
   Text 10,140,TFormedZ()		

   Flip

Wend

The cube initially extends from -1 to +1 on each axis.
The point (0,1,0) is the center of the top (y=1) face of the cube.
This is still true if the cube is moved in space. Suppose the cube were moved up by 5.
The center of the top face would be at (0,6,0) in the world, but still (0,1,0) in the cube's local space.

The same is true after scaling by 6 in the Y-direction. The top of the cube now
has y=6 in world space, but is still at y=1 in cube space.

Yes, and it is very handy in some cases, particularly finding global coordinates of vertices. If you don't like it, just set a pivot to the same position and rotation as the object and do the Tform point there.

Floyd: I'm not sure what you're getting at. As far as I'm concerned, TFormPoint should return the very same point in the destination coord space. Scale should not come into it at all. I don't care what the centre of the top of the cube is. That's not the information I'm requesting with TFormPoint.

bot builder: Yes, that solution occured to me as well. ;) It would just be more helpful if the docs were more specific about how certain commands operate.

I think that scale should come into it. Blitz represents coordinate systems as matrixes, and scale can be and probably is stored in the matrix. So, logically the Tform commands would grab the matrixes of the source and destination and divide/multiply the vector by them. Blitz would have to normalise each axis of the matrix for every TForm command, slowing it down signifigantly. And anyway, incorperating scaling allows you to find global vertex positions etc.

Oh, and if you think it should be specified in the docs, add a comment to the Tform commands in the special docs section of the forums.

Scale has to be involved.

In my example the center of the top of the cube is always (0,1,0) in cube space.

After scaling the cube the center of the ball is now in the same location as the center of the top of the cube.
So it must also be (0,1,0) in the cube's local space.

If you want *local space*, scale must be involved, otherwise it wouldn't be local space.

When you scale an entity, the entity's space is scaled as well as its vertices.

If you don't want it affected by scale, convert everything to global space and do your comparisons there, or just use ScaleMesh instead.

I didn't know this - I thought scaling just moved vertices in 3D space.

I guess it boils down to my lack of knowledge about 3D. I've not that much experience using 3D and have managed to not get my hands dirty with matrices thus far. :)

I think I understand a bit better what's going on, now. Thanks for your input, guys! ;)