Author Topic: Limitations of the 3D Starfield Engine  (Read 85019 times)

0 Members and 1 Guest are viewing this topic.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 27
  • Posts: 1,523
  • They'll eat you next!
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #30 on: June 06, 2011, 10:31:50 PM »
Mhm... what I saw when I used this is that is didn't actually turn so much, it rather just move the one dots in hte background, or furthest away...

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 21
  • Posts: 929
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #31 on: June 07, 2011, 12:03:18 AM »
I *think* Aino meant earlier is that you could have the engine work kinda backwards, with far points moving more than near points. Amirite?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #32 on: June 07, 2011, 12:51:14 AM »
You could by changing the equations, yes.  However, then everything would look wrong.

I've had a bash at fixing the rotation but I've managed to wreck it a bit.. :p  It goes all squashed and stupid-looking.  Oh well..

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 21
  • Posts: 929
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #33 on: June 07, 2011, 12:55:06 AM »
You backed up, I hope?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #34 on: June 07, 2011, 04:33:43 PM »
Yup I'll revert to the latest copy I uploaded.
By the way I still have only vague ideas for what I will eventually do with this thing :p  Think a 3D game would work good?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #35 on: June 07, 2011, 08:28:06 PM »
Well, I've thought about it, and now I've finally figured out what was wrong with it.


Consider this function:

Code: [Select]
function RotateX(firstvertex,lastvertex,rotate, centerX, centerY, centerZ)

for i = firstvertex, lastvertex do

vertex3dY[i] = vertex3dY[i] - centerY
vertex3dZ[i] = vertex3dZ[i] - centerZ

vertex3dY[i] = (vertex3dY[i] * math.cos(rotate)) - (vertex3dZ[i] * math.sin(rotate))
vertex3dZ[i] = (old3dy * math.sin(rotate)) + (vertex3dZ[i] * math.cos(rotate))

vertex3dY[i] = vertex3dY[i] + centerY
vertex3dZ[i] = vertex3dZ[i] + centerZ

end

end

This rotates all the vertices in the object around a point defined by coordinates centerX, centerY, and centerZ.

These two lines are where I found the problem:

Code: [Select]
vertex3dY[i] = (vertex3dY[i] * math.cos(rotate)) - (vertex3dZ[i] * math.sin(rotate))
vertex3dZ[i] = (vertex3dY[i] * math.sin(rotate)) + (vertex3dZ[i] * math.cos(rotate))

Can you spot what it is?
It took me ages to figure out...  but basically, notice how the two results of these two lines are actually referenced by each other.
For example, before these lines are run, vertex3dY[ i] will have a particular value.  After the first line has been run, vertex3dY[ i] will have a new value.  Then, in the second line, we refer to vertex3dY[ i] in making our calculation.  But it has a new value now!

This was leading to a not-terribly-gradual decay in the size of the cube, leading to some interesting dimension effects... but certainly it did not look right.
So, I have made the following change:

Code: [Select]
old3dy = vertex3dY[i]
vertex3dY[i] = (vertex3dY[i] * math.cos(rotate)) - (vertex3dZ[i] * math.sin(rotate))
vertex3dZ[i] = (old3dy * math.sin(rotate)) + (vertex3dZ[i] * math.cos(rotate))

This has fixed the rotation about the X axis - I've had a cube spinning at light speed for 5 minutes now without getting any smaller or flatter.  I now go to implement the same fix on the Y axis and Z axis rotation functions.  :>

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #36 on: June 07, 2011, 08:39:11 PM »
To do:

Near future:
Fix erroneous drawing of edges when both connecting vertices are behind the camera.
When a rotation value becomes greater than 360 degrees it should be reset to (rotation - 360) to prevent decay due to decimal points.

In the next week or two:
Implement faces (insanity incoming!)

Furthert down the line:
Formalise a format that 3D objects should be built in.
Redesign engine to be as simple as possible, and also extensible so it can accept multiple object functions.
Create a visual 3D object designer, capable of outputting 3D object functions.
Figure out what the hell I'm going to use this for!
« Last Edit: June 07, 2011, 08:53:10 PM by annikk.exe »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #37 on: June 07, 2011, 08:40:20 PM »
Check it out.  :>

Left click anywhere onscreen to change the axis of rotation.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #38 on: June 08, 2011, 07:47:01 PM »
It still looks a bit squashed to me, although it doesn't degrade over time anymore.

Anyone got an idea why it looks squashed after a while?

hitman271

  • Shoot
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 22
Re: Limitations of the 3D Starfield Engine
« Reply #39 on: June 29, 2011, 11:28:33 AM »


I don't know if you're still working on this, but I thought seeing this code would help.
Code: [Select]
//timer EAX;// div EAX,8;
//fsin EAX,EAX;
//mul EAX,512;
//fabs EAX,EAX;
//neg EAX;
//add EAX,512;

dcvxpipe 3; //-1..1 (opengl screen)
dvxpipe  5; //matrix projection

//Initialize transform
mperspective mProjectionMatrix,vPerspective;

//Render starts
dclrscr  bg_color;
mlookat mViewMatrix,vLookAt; //View matrix

timer eax;
mov #vRotate.w,eax;

//Rotate translate
mrotate mRotateMatrix,vRotate;
mtranslate mTranslateMatrix,vTranslate;

//Create model matrix
mmov mModelMatrix,mTranslateMatrix;
mmul mModelMatrix,mRotateMatrix;

//modelViewMatrix = ViewMatrix * modelMatrx
mmov mModelViewMatrix,mViewMatrix;
mmul mModelViewMatrix,mModelMatrix;

//load matrix
mload mModelViewMatrix;
mloadproj mProjectionMatrix;

//setup light
dsetlight 0,lightdata;

//setup buffer
denable 0; //Vertex buffer
denable 1; //ZSorting
denable 2; //Lighting
denable 3; //Face culling

//render cube
dcolor fg_color;
dvxdata_3f cube2,12;
dvxflush;

ddisable 0; //Disable everything!
ddisable 1;
ddisable 2;
ddisable 3;

dcvxpipe 0;
dvxpipe  0;

//You can write some text here now
//<right here>
dexit;

//========
cube2:
db -1,-1,-1;
db 1,-1,-1;
db 1,1,-1;
cube3:
db -1,-1,-1;
db 1,1,-1;
db -1,1,-1;
cube4:
db 1,-1,1;
db -1,-1,1;
db 1,1,1;
cube5:
db -1,-1,1;
db -1,1,1;
db 1,1,1;
cube6:
db 1,-1,-1;
db -1,-1,-1;
db 1,-1,1;
cube7:
db -1,-1,-1;
db -1,-1,1;
db 1,-1,1;
cube8:
db -1,1,-1;
db 1,1,-1;
db 1,1,1;
cube9:
db -1,1,1;
db -1,1,-1;
db 1,1,1;
cube10:
db -1,-1,-1;
db -1,1,-1;
db -1,1,1;
cube11:
db -1,-1,1;
db -1,-1,-1;
db -1,1,1;
cube12:
db 1,1,-1;
db 1,-1,-1;
db 1,1,1;
cube13:
db 1,-1,-1;
db 1,-1,1;
db 1,1,1;

lightdata:
vector4f lightpos,  0,50,-50,  0; //x y z <unused, will be falloff>
color    lightcol,255,255,255,  1; //R G B Brightness
//========

matrix mRotateMatrix;
matrix mTranslateMatrix;

matrix mProjectionMatrix; //This defines our projection to screen
matrix mViewMatrix; //This defines our camera transformations

matrix mModelMatrix; //This is our model transformations
matrix mModelViewMatrix; //This is our model relatively to camera transform


vector4f vRotate,      0,  0,  1,  0; //<AXIS X Y Z> <ANGLE W>
vector4f vTranslate,   0,  0,  0,  0; //<TRANLSATION X Y Z> <0>
vector4f vPerspective, 30, 1.6,  1,  20; //<FOV> <ASPECT RATIO> <ZNEAR> <ZFAR>

vLookAt:
vector3f vLookAt_Eye,    -5, 0, 0; //Where our camera is
vector3f vLookAt_Center, 0, 0, 0;  //What we look at
vector3f vLookAt_Up,     0, 1, 0;  //Where our matt-hat is

color fg_color,255,255,25;
color bg_color,64,32,12;

That's some butchered assembly back from Garry's Mod. Basically, instead of typing in every point on the cube,  you start with the same cube centered at the origin every time. This "normal cube" is the one described in the db's in the code above.

With this "normal cube", you perform a scale transformation first to enlarge/shrink it ->
then a rotation transform to rotate it ->
then finally a translation( moving it ) to position it properly.

Described above are the "model" transformations, i.e. where your crap is in the world.
Then comes the "perspective" calculation, simply where the viewer is in the world and what they can view.

whew*

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 27
  • Posts: 1,523
  • They'll eat you next!
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #40 on: June 29, 2011, 12:02:04 PM »
Confusing code >.<

SweetCandyGrimm

  • Grimm
  • Shoot
  • *
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 23
    • My Juggalobook.com Profile.
Re: Limitations of the 3D Starfield Engine
« Reply #41 on: September 15, 2012, 02:19:00 AM »
Oooh, there's some good stuff on the road ahead.  Wikipedia says   :D


baah wtf is that lol i gotz a headache now lol
~SCG~

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 27
  • Posts: 1,523
  • They'll eat you next!
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #42 on: September 15, 2012, 02:50:09 AM »
Oooh, there's some good stuff on the road ahead.  Wikipedia says   :D


baah wtf is that lol i gotz a headache now lol

Not that hard...
The circle with a line in it is the letter for rotation and "u" is position, I guess :)