Rotating a 'quad' .. How to?
Blitz3D Forums/Blitz3D Programming/Rotating a 'quad' .. How to?
| ||
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 |
| ||
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 |
| ||
thanks guys, I was wondering how to deal withit myself. |
| ||
Jim, Where you able to apply Anthony's Functions? |
| ||
Got it working. Thankyou kindly Antony |
| ||
Stole some functions from here. Modified the functions to work with unspecified number of vertices. I deliberately altered the quad shape to demonstrate. |
| ||
Nice. That's a little faster too. Plus, as you demonstrate, the quad can be warped and still rotate correctly. |
| ||
Use TFormPoint, it makes for much simpler code. |
| ||
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. |
| ||
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. :-) |
| ||
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? |
| ||
due to compatibility behavior of Blitz3D: don't think any others than cubemapping, dot3 and blendmode 5 ... |
| ||
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. |
| ||
"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. |
| ||
"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. |
| ||
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? :) |
| ||
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. |
| ||
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... |