Rotating a 'quad' .. How to?

Blitz3D Forums/Blitz3D Programming/Rotating a 'quad' .. How to?

EOF(Posted 2004) [#1]
What funky maths do I need to successfully rotate a quad?
In the example below I'm using Sin/Cos to rotate 4 vertices by around 360 degrees.
As you press SPACE in the example you'll see the quad snap into a larger version then shrink and grow as it rotates.
How do I prevent this from happening?

For reference the quad is constructed/displayed like this:

-1 +1             +1 +1
       2--------3
       |        |
       |        |
       |        |
       0--------1
-1 -1             +1 -1





AntonyWells(Posted 2004) [#2]
You need to take each dimension into account for each dimension you're rotating.

So in 2d, you need to take both X and Y into account for both rotations. (In other words, it's a 3d tform still, just applied on the Z-axis)

Something like,

Function rotate_x#(x#,y#,roll#)
	Return(Cos(roll)*x+Sin(roll)*y)
End Function

Function rotate_y#(x#,y#,roll#)
	Return(-Sin(roll)*x+Cos(roll)*y)
End Function




Techlord(Posted 2004) [#3]
thanks guys, I was wondering how to deal withit myself.


Techlord(Posted 2004) [#4]
Jim,

Where you able to apply Anthony's Functions?


EOF(Posted 2004) [#5]
Got it working. Thankyou kindly Antony




Techlord(Posted 2004) [#6]
Stole some functions from here. Modified the functions to work with unspecified number of vertices. I deliberately altered the quad shape to demonstrate.




EOF(Posted 2004) [#7]
Nice. That's a little faster too.
Plus, as you demonstrate, the quad can be warped and still rotate correctly.


sswift(Posted 2004) [#8]
Use TFormPoint, it makes for much simpler code.


big10p(Posted 2004) [#9]
Or copy the quad's verts into a separate, pre-made quad mesh, RotateMesh, then copy the verts back. This has the benefit of doing hardware accelorated rotations instead of doing it in software with those slow cos/sin calls. Of course, there's still going to be some overhead having to do the vertex copying, but I'm pretty sure it'll still be faster.


sswift(Posted 2004) [#10]
I doubt that making a new mesh to rotate four vertices will be faster.

Also even if the mesh has a thousand vertices I doubt it will be faster.

In fact, I doubt that rotatemesh uses hardware transformations at all. :-)


big10p(Posted 2004) [#11]
You dont make a new 4-vert mesh, use it then destroy it every time; you just make the mesh at the start and re-use it.

I used this technique for the exploding mesh demo I did and found it was pretty fast.

In fact, I doubt that rotatemesh uses hardware transformations at all. :-)

Why wouldn't it? If it doesn't, what commands do?


Dreamora(Posted 2004) [#12]
due to compatibility behavior of Blitz3D:

don't think any others than cubemapping, dot3 and blendmode 5 ...


Trixx(Posted 2004) [#13]
Making a quad and using it for rotations is definitely slower than using good math ( optimized with sin/cos arrays ) on vertices.
Tform commands are also ( some of them much ) slower than plain math coded for particular case.
Believe me, I have spent a LOT of hours on finding fastest ways for dealing with single surface/quad systems.


sswift(Posted 2004) [#14]
"Why wouldn't it? If it doesn't, what commands do?"

The data needs to be available in ram for fast access, so even if it is calculated on the card it still needs to be downloaded to main ram.

As for what commands use hardware transformation... I don't know if any do. But if any do, then I'd guess that the bone animations commands do, and that is why you don't have access to the modified vertex locations... Because downloading those from the card as they are changed by the hardware would slow down animation so much that it's not worth it. That would explain why that data is not available to us, but normal mesh rotations and vertex location changes are.


sswift(Posted 2004) [#15]
"Tform commands are also ( some of them much ) slower than plain math coded for particular case."

Yes but I don't think that the speed difference would actually affect the speed of your average game, and the code is a lot easier to understand and make changes to than a bunch of sin/cos commands, which is why I suggested that method.


big10p(Posted 2004) [#16]
Trix, I'm still not 100% convinced, tbh. I'm sure I tried my demo using Birdie's TurnTriangle function and found it to be slower. Although, I don't think Birdie's function used sin/cos lookup tables but LUTs seem to be of limited use with modern CPUs.

Got any demo code that'll convince me? :)


Techlord(Posted 2004) [#17]
Which is faster accessing vertex data using Blitz Commands EntityX(e), VertexX(s,i), etc -OR- Storing and accessing data in variables (ie MyEntityX#). It seems like a waste of additional memory to use variables when the data can be accessed from the entity itself. However, I dont mind using variables if there is a speed advantage.


Trixx(Posted 2004) [#18]
Yes but I don't think that the speed difference would actually affect the speed of your average game, and the code is a lot easier to understand

I agree, but if you are using them 500 times in a frame it may be well worth to replace them with plain math. My particle system gained at least 20% more FPS by eliminating Tform commands.
@big10p : Soon...