XPlane2Blender icon indicating copy to clipboard operation
XPlane2Blender copied to clipboard

Imp: Every ANIM_rotate_begin must be its own Empty until later optimization

Open tngreene opened this issue 3 years ago • 1 comments

See

ANIM_rotate_begin	1	0	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	10
	ANIM_rotate_end
ANIM_rotate_begin	1	0	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	20
	ANIM_rotate_end
ANIM_rotate_begin	1	0	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	30
	ANIM_rotate_end
	```
	
	Or
	```
	ANIM_rotate_begin	1	0	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	10
	ANIM_rotate_end
ANIM_rotate_begin	1	0	-0	dref2
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	20
	ANIM_rotate_end
ANIM_rotate_begin	1	0	-0	dref3
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	30
	ANIM_rotate_end
	```
	
	In each case, what should the object's rotation be?

The answer is actually that each ANIM_rotate_begin should be making itself as a new frame - a new Empty and we later optimize to reduce this as best as possible. In the first case we'd need to accumulate. The final rotations are 0 degrees X on frame 1 and 30 degrees on X along frame 2.

The second case will have a chain of 3 Empties.

tngreene avatar Jun 25 '21 20:06 tngreene

#CASE 1 Actually optimization ready
ANIM_rotate_begin	1	0	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	10
	ANIM_rotate_end
ANIM_rotate_begin	0	1	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	20
	ANIM_rotate_end
ANIM_rotate_begin	1	0	-0	dref2
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	30
	ANIM_rotate_end
ANIM_rotate_begin	0	1	-0	dref2
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	40
	ANIM_rotate_end
TRIS...

#CASE 2 - can't be optimized, order matters
ANIM_rotate_begin	1	0	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	10
	ANIM_rotate_end
ANIM_rotate_begin	1	0	-0	dref2
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	30
	ANIM_rotate_end
ANIM_rotate_begin	0	1	-0	dref1
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	20
	ANIM_rotate_end
ANIM_rotate_begin	0	1	-0	dref2
	ANIM_rotate_key	0	0
	ANIM_rotate_key	1	40
	ANIM_rotate_end

In case one both of the dref1 blocks will get merged. In the second one the dref1 blocks can't be merged because the order of transformations . Had the second case been something like dref1, dref1, dref2, dref1, there could have been some optimization for the 1st dref1's.

tngreene avatar Jun 25 '21 20:06 tngreene