Some rotation code. [BB2D]

[Stonemonkey]

Since I started writing some of this in blitz anyway I thought I'd add a bit more as someone might find some of it useful, I've added scaling and some camera code.

It should be quite easy to add to as well, for example to add vertex colouring:

add the fields  red#,green#,blue#   to the vertex type

and the function

Code: [Select]

function set_vertex_rgb(vertex_h,red#,green#,blue#)
  vertex.vertex=object.vertex(vertex_h)
  vertex\red=red
  vertex\green=green
  vertex\blue=blue
end function

and you can get the values that you set those to for each vertex in the draw_triangle function to use in your own gouraud shaded triangle rasteriser. Or add anything else you want.

Cheers, Fryer.

[Devils Child]

thats good code!
thanks

[Stonemonkey]

You're welcome Devils Child, I guess most people are happy using their own methods for these things but if you find it's useful that's great.

EDIT: Sorry, I got the descriptions of the rotate and turn functions round the wrong way. The code itself is ok though. Fix uploaded.

[Tetra]

I guess most people are happy using their own methods for these things

This is true but its always great/usefull to get to see how many different ways there are to do the same thing, Thanks for sharing k++

[Stonemonkey]

No problem Tetra, I'd be interested in seeing other solutions to the problem too.

[Tetra]

I'd be interested in seeing other solutions to the problem too.

I went and dug up my old original code in blitz. This is my approach ( a year ago ) on a basic blitz software 3d engine. I've not included any polygon rendering, just the storage, processing of verticies, polygons, cameras and ligts. It can load an infinate number of meshes ( wishfull thinking perhaps ) It takes care of all the storing and rotations, rendering of polys and meshes. The lighting needs some work, its not quite right, but the basics are there. I've tried to basically mimic blitz3d.

Its uses banks, and I've tried to use them in the most optimal way I could think of. Theres no overhead for bank indexing because i've included it in the precalcs. Theres some test code at the bottom that loads a custom mesh file ( also included in the zip ). Normally I would include this file into a new project.

It may or may not be of any use but the storing of data using banks is quite interesting.

[Stonemonkey]

Thanks Tetra, I've just been trying some things with banks too. Using them for image/texture buffers but blitz is way too slow, my solution before was using lots of global arrays, even a large number of local variables in a function could cause noticable slowdown from what I remember so in functions that were called a lot (triangle drawing mainly I think) I found it faster to make all the variables global. Not a nice solution but it's how I got the speed up.

Having a look at your rotation, it's still suffering from gimbal lock, replacing the call to rotate the turtle with:

Code: [Select]

    If ii<90 Then
        Rotate_Frame_By( turtle, 0.0, 1.0, 0.0 )
    Else

        ;change this to rotate around the x axis by 1.0 instead of the z axis
        Rotate_Frame_By( turtle, 0.0, 0.0, 1.0 )
    End If
    ii=ii+1

with the second rotate to rotate around x axis instead ends up with the same result as rotating around the z axis.

[Tetra]

Yeah it does suffer, I unfortunately didnt realize this was on the solution of the gimbal lock

I seem to remember something about updating the original vertex coord with the new rotated coord, well rotated soely with the object matrix i.e no offsets or perspective. The only thing is then you have to keep track of the rotation, and I think its aligned to the camera rather than the objets matrix, not sure though. Also you have to store the original vertices to be able to reset. Not to mention that you will lose detail in the verticies eventually, although its a very give or take process.

Something like this:

Code: [Select]

Function RotateVertices( Camera.TCamera, Frame.TFrame )

Local i

Local tmpX#
Local tmpY#
Local tmpZ#

Local orgX#
Local orgY#
Local orgZ#

For i = Frame\VertexBaseIndex To Frame\VertexTopIndex Step 4

orgX# = PeekFloat( VerticesX, i );
orgY# = PeekFloat( VerticesY, i );
orgZ# = PeekFloat( VerticesZ, i );

PokeFloat( VerticesX, i, ( Frame\rMatrix[0] * orgX# ) + ( Frame\rMatrix[1] * orgY# ) + ( Frame\rMatrix[2] * orgZ# ) )
PokeFloat( VerticesY, i, ( Frame\rMatrix[3] * orgX# ) + ( Frame\rMatrix[4] * orgY# ) + ( Frame\rMatrix[5] * orgZ# ) )
PokeFloat( VerticesZ, i, ( Frame\rMatrix[6] * orgX# ) + ( Frame\rMatrix[7] * orgY# ) + ( Frame\rMatrix[8] * orgZ# ) )

;Rotate the vertices using the camera Rotation Matrix
tmpX# = ( Camera\tempMatrix[0] * orgX# ) + ( Camera\tempMatrix[1] * orgY# ) + ( Camera\tempMatrix[2] * orgZ# )
tmpY# = ( Camera\tempMatrix[3] * orgX# ) + ( Camera\tempMatrix[4] * orgY# ) + ( Camera\tempMatrix[5] * orgZ# )
tmpZ# = ( Camera\tempMatrix[6] * orgX# ) + ( Camera\tempMatrix[7] * orgY# ) + ( Camera\tempMatrix[8] * orgZ# )

;Position vertex relative to camera
tmpX# = Camera\offset[0] + tmpX#
tmpY# = Camera\offset[1] + tmpY#
tmpZ# = Camera\offset[2] + tmpZ#

PokeFloat( RotatedVerticesX, i, tmpX# )
PokeFloat( RotatedVerticesY, i, tmpY# )
PokeFloat( RotatedVerticesZ, i, tmpZ# )

Next

End Function



Code: [Select]

If ii<90 Then
Rotate_Frame_To( turtle, 0.0, 1.0, 0.0 )
Else
If ( bit = 0 )
;change this to rotate around the x axis by 1.0 instead of the z axis
Rotate_Frame_To( turtle, 0.0, 0.0, 1.0 )
Else
;change this to rotate around the x axis by 1.0 instead of the z axis
Rotate_Frame_To( turtle, 1.0, 0.0, 0.0 )
EndIf
End If
ii=ii+1

If ( ii > 180 )
bit = 1 - bit
ii = 0
EndIf

I'm not sure though, I've come to realize that the gimbal lock aint such a bad restriction

[Stonemonkey]

In my method, I think the rotation matrix can suffer from something similar and should be renormalised/adjusted every now and again but even when running for a while i've never noticed the need yet.

[mike_g]

This is the sort of stuff I would really like to learn. As in rotating stuff on the z axis too (if that makes sense). Looks hard tho Maybe I'll just have a go at making something using these functions first

[Jim]

In my method, I think the rotation matrix can suffer from something similar and should be renormalised/adjusted every now and again

I think we used to do that every 1 second or so in the skateboarding game.

Jim

[Stonemonkey]

Quote
In my method, I think the rotation matrix can suffer from something similar and should be renormalised/adjusted every now and again
I think we used to do that every 1 second or so in the skateboarding game.

The only thing that I've really noticed it with is when dealing with child objects, other than that it's not something I've had much trouble with and had programs running for quite some time without any noticable problem.
Was the skateboarding game using fixed point maths or floats smaller than 32 bit or anything like that?

[Jim]

All 16:16 fixed point.  You lose, on average, 1/2 bit of precision every time you multiply.
I just looked at the code, we mostly used it after we'd been doing matrix interpolation, which makes sense because we were being very approximate.

Jim