Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > accurate 3d rotation
2013-05-22 12:12
Oswald

Registered: Apr 2002
Posts: 5094
accurate 3d rotation

some silly questions & a lot of text here, its been ages I have done this routine and I am wondering where could I find more accuracy.

I am using the additive method to get the rotation matrix, working with 16 bit sines.

first, I wonder why have I choosen the sinetable max value to be +/- $1fff, there's no consecutive 4 adc's to have overflow over +/- $8000, still an adc / sbc pair may turn into adc/adc because of the case when substracting a negative number? :/ not sure if sine lookups may align this way. also should I round the 16 bit table or those bits will go bad anyway? (dont remember if I have rounded it, boy its been precalculated in basic in the stone ages:)

secondly, I keep adding #$40 to rotation angles in many places before looking them up in sincos tables. I suspect I am doing something wrong here, trying to turn the lookup value into cosine, while still having a label for the cosine offset. sin+$40= cosine, cosine+(angle+#$40)= ??? why ? :D or does this thing come from the sin*cos to addition theoremes?

third: if I recall right each adc/sbc introduces 1 bit error, is this true? so after 2 adc lowmost 2 bits in the 16 bit result is unusable?

fourth: flipping sign of a 2 complement 16 bit number is this correct?:

	lda yxl    ;*-1
	eor #$ff
	clc
	adc #$01
	sta yxl

	lda yxh
	eor #$ff
	adc #$00
	sta yxh


finally, getting a cube coordinate out of the rotation matrix, only using the HI bytes:

	lda xzh    ;mpp
	clc
	adc xyh
	sec
	sbc xxh
	sta vertexes+0


should I rewrite this to gain accuracy including the low 8 bits?:

        lda xzl
        clc
        adc xyl
        sta templ
        
        lda xzh
        adc xyh
        sta temph
        ...
        etc


finally, rounding the final8 bits by looking at the low8 is a good idea? ie, if low8 (signless) msb is high, inc high8 bits?
 
... 13 posts hidden. Click here to view all posts....
 
2013-05-22 15:42
Oswald

Registered: Apr 2002
Posts: 5094
I have to think on this one, sounds like a method graham described earlier. does it work with perspective projection?
2013-05-22 15:49
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: I have to think on this one, sounds like a method graham described earlier. does it work with perspective projection?

It's the exact same method but Graham uses another way of thinking but yields the same result. I'll draw u a pic tonight. Yes, it works with perspective (it's built into the -z/d part, -z is really your distance to the screen which determins field of view)
2013-05-22 16:24
Oswald

Registered: Apr 2002
Posts: 5094
According to your answers I do everything to the book, I think my perspective projection might be the problem (zooming more than available bits), thanks, and waiting for the pic, its really hard to get it by words :)
2013-05-22 16:34
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:
you really can't trust the least significant bit. So adding two untrusted bits will give you a really untrustworthy bit.

i'll print that on a t-shirt :)
2013-05-22 17:37
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: Quote:
you really can't trust the least significant bit. So adding two untrusted bits will give you a really untrustworthy bit.

i'll print that on a t-shirt :)


:) one up!

Anyway, after rounding you are of at worst by 0.5 i.e. Half a bit. Each add will propagate the error so after n additions u'll be of by n/2.
2013-05-22 18:03
Bitbreaker

Registered: Oct 2002
Posts: 508
As for negation of a 16 bit number see the example in http://www.codebase64.org/doku.php?id=base:advanced_optimizing#..

in general it is a good thing to think about swapping add/sbc at times also in term of saving clc/sec. Means, you can always add one too much and then again subtract one too much if carry has the wrong state and such and order your addition/subtraction that way that you merely never need to explicitely set the carry.
2013-05-22 18:07
chatGPZ

Registered: Dec 2001
Posts: 11386
or just comment out all CLC and SEC and make a smash design demo =)
2013-05-22 22:10
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: According to your answers I do everything to the book, I think my perspective projection might be the problem (zooming more than available bits), thanks, and waiting for the pic, its really hard to get it by words :)

Wrote an article. It's the attached PDF at the bottom of this page: http://codebase64.org/doku.php?id=base:backface_culling
2013-05-22 23:01
Ervin

Registered: May 2008
Posts: 14
An old 3d trick is (regardless of the platform) is to back-transform the camera [and the lights] to object space (using the inverse of the transformation matrix) and do the culling [and lighting] in object space. It's trivial to calculate the inverse of a rotation + translation matrix, see http://www.cg.info.hiroshima-cu.ac.jp/~miyazaki/knowledge/teche.., it's one matrix-vector mul.
The algorithm:
1. back-transform the camera to object space (1 vector-matrix multiplication)
2. substitute this camera position to the equation of faces (3 muls and 4 adds). If it's negative, then drop the face.
[3. For the non-dropped faces: do the same with the object-transformed light positions (if negative, the corresponding face is not lit by the light-in-question)].
4. Transform ONLY those vertices, using the real transformation matrix, that belong to visible faces. Maybe it's not worth in a case of a cube when 7 of 8 vertices may be visible, but for a dodecahedron it really works better.
2013-05-23 05:05
JackAsser

Registered: Jun 2002
Posts: 2014
Quote: An old 3d trick is (regardless of the platform) is to back-transform the camera [and the lights] to object space (using the inverse of the transformation matrix) and do the culling [and lighting] in object space. It's trivial to calculate the inverse of a rotation + translation matrix, see http://www.cg.info.hiroshima-cu.ac.jp/~miyazaki/knowledge/teche.., it's one matrix-vector mul.
The algorithm:
1. back-transform the camera to object space (1 vector-matrix multiplication)
2. substitute this camera position to the equation of faces (3 muls and 4 adds). If it's negative, then drop the face.
[3. For the non-dropped faces: do the same with the object-transformed light positions (if negative, the corresponding face is not lit by the light-in-question)].
4. Transform ONLY those vertices, using the real transformation matrix, that belong to visible faces. Maybe it's not worth in a case of a cube when 7 of 8 vertices may be visible, but for a dodecahedron it really works better.


Kinda the same as my method but instead of invtransform the cam i use the fact that the cam is at 0,0,-z which reduce the plane equation alot. Everything becomes constants except the surface normal (which is static in your method, i.e. Good for complicated objs). The thing is, you dont really need to rotate specific normals since most of the are trivial to deduce from the rotation matrix. For a cube f.e. The normals corresponds to the world axes...
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
DJ Gruby/TRiAD
Guests online: 90
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.051 sec.