A different way to rotate a point?

[LaBodilsen]

I don't know if this have been done before, but i've been pondering on this for a little while, and i think the idea came from a dot sphere in some demo. As i was watching this sphere, it came to me that every dot in this sphere could be described as an angle and distance from center, instead of a coordinate in a 3d world.

So what if we used this as a coordinate system where we describe each point as an angle and distance from center, eg 45,50 is angle = 45 and distance from center is 50. Then to rotate that point we could simply add the rotation angle to the initial angle, and voila be done with it.

To convert this angle,distance coodinate to screen space, we would derive the X coordinate with Sin(angle)*Distance, and the Y Coordinate with Cos(angle)*Distance.

example:
Coord: 22,50
X = Sin(22)*50 = 18,73
Y = Cos(22)*50 = 46,35

So the coord 22,50 would translate to X,Y coord (18,73),(46,35).

To rotate the point by 30 degree, we add that to the initial coord and get:
Coord: 52,50
X = Sin(52)*50 = 39,40
Y = Cos(52)*50 = 30,78

With this we can get a rotate loop without any multiplication, and only use addition.

I tried this out in assembler yesterday, and the code becomes very simple:

	lea	Plots,A0	;list of Angle coords
	lea	SinTable,A1	;Sintable start
	lea	CosTable,A2	;Costable start
	move.w	RotAngle,D5

.Rotate_Loop
	move.w	(A0)+,D2	;Coord Angle
	add.w	D5,D2		;Add rotation angle to angle coord
	and.w	#2047,D2	;Limit to Sin/Costable size	

.Convert_To_ScreenCoords
	move.w	(A0)+,D0	;Coord Distance
	move.w	D0,D1
	muls	(A1,D2),D0	;Convert X coord
	muls	(A2,D2),D1	;Convert Y coord

This is ofcourse only a 2D rotation, but i don't think expanding this to 3D would add that much complexity, eg expand the coord to (AngleZ,AngleX,AngleY,Distance) and convert that to screenspace. But creating objects in this angle,distance system might be pretty hard, but not impossible. Maybe a converter would be the best way.

So have this been done before?, and/or was it trashed for some reason. Any thoughts would be appreciated.

[hooverphonique]

I have been thinking of this before as well.. Basically, you describe your model in polar coordinates, and then transform to cartesian for projection/rendering. I can't remember if I used this for any demoscene-related stuff myself though..

[thomas]

It's called the polar coordinate system.

Yes, rotating becomes very easy. But scaling and/or moving objects will become quite difficult, especially if the direction of movement is not towards or away from the center point.

[LaBodilsen]

Originally Posted by thomas

It's called the polar coordinate system.

Yes, rotating becomes very easy. But scaling and/or moving objects will become quite difficult, especially if the direction of movement is not towards or away from the center point.

Doh... It seems i discovered what is known to the educated man as the Polar coordinate system.

Well thank you for the pointer, it will properly make it easier to get a better understanding of it, now that i know that a greek astronomer and astrologer figured this out 2200 years ago.

[Codetapper]

The first time I'd heard of this was Andrew Braybrook's diary of a game for C64 Morpheus in 1987.

Fastjack used polar coordinates in his bump-mapped ball from [ Show youtube player ] and Mnemonics.
And I think also Mr. Pet used it in [ Show youtube player ] to rotate the dots.

[grond]

There are lots of demos that use spherical coordinates for faster projection. You can usually see it because movement is restricted. You can fake a lot, e.g. project using table lookups and then just scale linearly to achieve the impression of varying distance. You can use perspectively incorrect direct projection. You can use a base vector for an object, project that correctly and then just project difference vectors from the base vector using smaller tables. You can use logarithmic tables to replace muls and divs by adds and subs.

All of these techniques have the problem that they are imprecise, visually incorrect and don't allow for random movement. They can be made to look good in a demo where you have everything under control but would hardly work well in games where the player decides the movement.

E.g. the bump mapped bouncing ball from the above linked demo probably just uses some vertical linear stretching to achieve the bumping effect. How could you tell watching the demo that the angle of incident light is not changed correctly with the "deformation" of the ball? Demos are about faking something much more complex and that's the fun in them.