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

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Limitations of the 3D Starfield Engine
« on: June 01, 2011, 10:16:45 PM »
Hey, it's time for one of these again.


I've been thinking about the 3D Starfield Engine a bit lately.  To call it "3D" is not entirely true.  For example, you couldn't render a rotating 3D box using it.  It is limited to rendering points with a radius.  That's ideal for stars, but not much else.

In order to render more complex objects made out of points, lines, and ultimately surfaces, it becomes necessary to add something else.  We must create the idea of "objects" that are essentially a series of points linked together with lines.  The lines always maintain the same relative angular relationship with each other and never change length.

Then, to rotate the object (for example), you perform a "transform" on it.


Today I've been looking at a very simple example of a transform, and trying to figure out what the calculations ought to be.


annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #1 on: June 01, 2011, 10:33:07 PM »
Oooh, there's some good stuff on the road ahead.  Wikipedia says   :D

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #2 on: June 01, 2011, 10:39:34 PM »
Use sin/cos for the rotation, just do the angle in degree or what you want, divide it by the max(in degrees it's 360) and you get a number between 0 and 1, now you multiply with pi*2 and you get a number between 0 and pi*2. Now put that number in the sin/cos.

This is how to make the angle you want to start with, now you can do sin(original angle + new angle) to get the y axis of the rotation, do this to cos too...

I've been coding this before, heres a snippet:

Code: [Select]
DrawX = xpos + math.cos(ModelRotation+Rotation)*(MAPIModelPartDist[i]*size)
DrawY = ypos + math.sin(ModelRotation+Rotation)*(MAPIModelPartDist[i]*size)

Where ModelRotation is the base rotation and rotation is the new.

This system might seem confusing or unuseful for your purpose though, but it's a starter :)

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #3 on: June 01, 2011, 11:13:06 PM »
Thanks dude, that's a pretty useful explanation.  I think I'm going to try to do mine using a matrix, with two "for" loops to represent rows and columns.  That will make things easier in the long run because if I carry out a transform on an extremely large and complicated object, EG with 500 points and a similar number of lines connecting them, it will keep everything nice and compact.

However, I intend to spend a long time studying the maths and concepts behind it before I even attempt to start programming anything.  :>

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #4 on: June 01, 2011, 11:53:09 PM »
Perhaps what I will do is create a matrix called "lines".  This will store a numbered list of points, and a list of other points they connect to with lines.  So points[ i][ j] would refer to point number "i", as having a connection to whatever point number is being stored in [ j].

Take a square.  That's 4 points connected with 4 lines.
The matrix would look like this:


Code: [Select]
{ 0 3 1 }
{ 1 0 2 }
{ 2 1 3 }
{ 3 2 0 }


To store the data about this square, I might use something like this:

Code: [Select]
-- store data about a square

-- point data
pointX[0] = 25
pointY[0] = 25

pointX[1] = 25
pointY[1] = -25

pointX[2] = -25
pointY[2] = -25

pointX[3] = -25
pointY[3] = 25

numberofpoints = 3


-- line data
lines[0][0] = 3
lines[0][1] = 1

lines[1][0] = 0
lines[1][1] = 2

lines[2][0] = 1
lines[2][1] = 3

lines[3][0] = 2
lines[3][1] = 0


Finally, to draw the object, I simply do one Draw command per declared line:


Code: [Select]
-- for each point, draw all its lines
for i = 0,numberofpoints do

-- we need to calculate how many lines this point is part of
linenumber = -1

for numberoflinescheck = 0,100 do
if lines[i][linenumber] ~= nil then
linenumber = linenumber + 1
else
break
end
end

-- we now know this point is connected to "linenumber" other points by lines


for j = 0,linenumber do
-- now we take each of the other points...
destinationpoint = lines[i][j]
-- and retrieve the coordinates of that point
destX = pointX[destinationpoint]
destY = pointY[destinationpoint]

-- then we draw the line from the current point to the stored point.
DrawLine(pointX[i], pointY[i], destX, destY, 1,1,1,1,1,1,1,1,10)
end
end


One major problem of this approach is that many lines will be drawn twice.
Consider 2 points connected by a line.  Under this system, first it would draw a line from Point A to Point B.  Then, it would draw a line from Point B to Point A.  That's the same line!!  This is wasteful.  Wonder how I can optimise that..


By the way this doesn't count as programming anything yet.  :P

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #5 on: June 01, 2011, 11:59:34 PM »
I don't know how to solve the problem or how yuo are thinking about this...

Drawing a line to the shape of a box ain't this hard, just have four points, draw from point 1 to point 2 and so on, when you reach the last point, jsut make it draw to the starting point.

But his might be wrong, as I got no idea what you're thinking of doing :/

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #6 on: June 02, 2011, 12:03:01 AM »
Quote
Drawing a line to the shape of a box ain't this hard, just have four points, draw from point 1 to point 2 and so on

The "and so on" part is what I am doing here.
I need to have a way to record which lines connect which points.  I need to do that not for just one object, but for all possible objects.


I am developing this system with a view to using it in a 3D coordinate system (at the moment I'm just working in 2D).

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #7 on: June 02, 2011, 12:07:29 AM »
So you're going to have a cube, and then you need to draw behind every other point too?

Well, there is no real solution I can think of... *thinking like a train*

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #8 on: June 02, 2011, 12:12:22 AM »
By the way, why do you want to have a fully 3D starfield? Making a starmap are we?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #9 on: June 02, 2011, 12:18:06 AM »
Ultimately I want to draw "Fluffy" on the side of a cube, and rotate the cube.  :P

The system I am planning will be wireframe only, though.  Surfaces will have to come much later, that's another massive leap onward once I've got wireframe down.  For surfaces, you have to calculate which surface is in front.  For surfaces that are partially behind, you have to calculate which parts of the surface are visible and which are not.  It's going to get a bit insane really..

But for now, wireframe is a good step toward a "true" 3D engine.  :>

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #10 on: June 02, 2011, 12:30:30 AM »
If you're still not sure what I'm talking about, imagine drawing a 3D cube.

How many points are in a cube?  (ie, how many corners?)
How many lines are in a cube? (how many straight edges are there linking the corners?)


(click to show/hide)

Not all the points connect to each other though.  Each point connects to just 3 others.  If you want to store the data about such an object, you are going to have to store a few things:

1) The number of points
2) The coordinates of those points
3) For each point, which other points does it connect to with lines?


The system above is my attempt to store that information in a programmatically accessible way.

If it's STILL not clear, let me know and I will try to draw a diagram that illustrates it.  :>

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #11 on: June 02, 2011, 12:31:06 AM »
And I think I've got the idea how to draw it...

Code: [Select]
Init:

LineX1 = {} --X1 of the line
LineY1 = {}
LineX2 = {}
LineY2 = {}

LinesInSide = {} --How many lines are there in the square
LinesInSideIDs = {}

LineDrawn = {}

That was the initialization for the line problem, now to the code:

Code: [Select]
draw code:

function BlahBlah()

LineDrawn = {}

for square = 0,numsquares do -- or the amount of boxes!!!
for side = 0,NumSides[square] do
for line = 0,LinesInSide[side] do
if LineDrawn[LinesInSideIDs[line]] ~= true then
DrawLine(LineX1[LinesInSideIDs[line]],LineY1[LinesInSideIDs[line]],LineX2[LinesInSideIDs[line]],LineY2[LinesInSideIDs[line]],..(do the rest of the variables!))
LineDrawn[LinesInSideIDs[line]]
end
end
end
end
end

Hope it was clear and easily understandable :)

It might not work or it might, I've not tested it :/
« Last Edit: June 02, 2011, 12:34:37 AM by Aino »

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #12 on: June 02, 2011, 12:51:48 AM »
What might be useful is the fact that ANY polyhedron (3-dimensional shape) has edges, vertices (corners/points) and faces linked by the equation VERTICES + FACES = EDGES + 2

Any polyGON (2D) has sides equal to the number of points.

Also: http://en.wikipedia.org/wiki/Vertex_arrangement


annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #13 on: June 02, 2011, 02:40:54 AM »
Hmm, yes... that might prove very useful..   Thanks ! :>

Sniped50

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 97
Re: Limitations of the 3D Starfield Engine
« Reply #14 on: June 02, 2011, 04:50:03 AM »
Are you still trying to get rid of that 'drawing lines twice' thing? Cos I might have a solution for it.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #15 on: June 02, 2011, 05:12:11 AM »
Jus ttell, we might get use for it later :P

Sniped50

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 97
Re: Limitations of the 3D Starfield Engine
« Reply #16 on: June 02, 2011, 07:43:12 AM »
Alright then.

Instead of having the engine check if vertex 1 is connected to vertex 2, drawing the line, and then doing it again the opposite way, why don't you just check if one vertex ID is smaller than the other, and then not drawing the connecting line at all if it returns true?

For instance, the square annikk had earlier. Vertex 0 is the first to be checked, so the lines connecting it to vertices 1 and 3 are drawn. Simple enough. Then vertex 1 is checked, and when the engine checks the line connecting it to vertex 0, it sees it is already drawn because the subject vertex ID (1) is larger than the checked vertex ID (0), so another line isn't drawn. It then checks the line connecting it to vertex 2, and because 1 < 2, it is then drawn. The process continues until it has checked all the vertices and drawn all the lines.

If you also include checks against lines between specific vertices, you only have to do it once (an if statement prevents a line between vertex 0 and vertex 2, and vertex 2 doesn't connect to vertex 0 anyways because of the higher ID number) to get a desired shape.

So there you go. If you already thought of that/a much cooler way of doing it, then all I can say is...

Awwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww... Sad face...

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #17 on: June 02, 2011, 05:53:16 PM »
Sweet, that's a pretty smart idea. :>

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #18 on: June 02, 2011, 10:51:02 PM »
Modified to include the approach detailed in the posts immediately above.  Thanks Sniped!

Code: [Select]
-- for each point, draw all its lines
for i = 0,numberofpoints do

-- we need to calculate how many lines this point is part of
linenumber = -1

for numberoflinescheck = 0,100 do
if lines[i][linenumber] ~= nil then
linenumber = linenumber + 1
else
break
end
end

-- we now know this point is connected to "linenumber" other points by lines


for j = 0,linenumber do
-- Only draw the line if the opposing vertex's ID is greater than this vertex's ID
if lines[i][j] > i then
-- now we take each of the other points...
destinationpoint = lines[i][j]
-- and retrieve the coordinates of that point
destX = pointX[destinationpoint]
destY = pointY[destinationpoint]

-- then we draw the line from the current point to the stored point.
DrawLine(pointX[i], pointY[i], destX, destY, 1,1,1,1,1,1,1,1,10)
end
end
end

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #19 on: June 02, 2011, 11:01:32 PM »
If anyone can spot any problems or improvements to the efficiency of that code, let me know!  It's all still at a very formative stage, nothing is final.

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #20 on: June 02, 2011, 11:47:36 PM »
This might help, along with load of other stuff about graph theory:

http://en.wikipedia.org/wiki/Adjacency_matrix

Just beware: It can get very boring if it's anything like the exam I had to sit in the subject.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #21 on: June 03, 2011, 07:44:48 PM »
Made some progress with this.  Take a look at this demo map.

I've decided to keep the vertices having a "size" property, so they can be displayed on-screen and developers can see where they are.  I've learned from experience this morning that manually entering the data for even a simple object like this one is very time-consuming and not really workable for more complicated objects, so it seems like a 3D Designer level will be necessary so that objects can be created visually in an editor, then output so they can be used elsewhere.

Lots to think about.. :>  Going to do some more tidying of this code, and then I'll have a go at rotating one of the vertices around a point.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #22 on: June 03, 2011, 07:47:50 PM »
Hmm I take screenshot :>



annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #23 on: June 03, 2011, 08:54:24 PM »
More progress, got it rotating around the Z axis now, and it rotates around a specific point.
Going to get the X and Y rotations done next.  :>

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #24 on: June 03, 2011, 09:14:59 PM »
Can rotate around all axis now.


However, there is a problem.  After each rotation, the cube gets slightly smaller in both the axis that are NOT being rotated around.  The cube swiftly becomes rectangular.

I have an idea of how to fix it.  Will require some reorganising.  In the mean time, check it out... if you want to.. :>

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #25 on: June 04, 2011, 08:04:00 PM »
Nice to see progress :D

Have been in Sweden, Gõteborg in Liseberg(an Amusements park :))...

So I haven't got to check the forum, but I am back now :)

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #26 on: June 06, 2011, 01:55:25 AM »
Wait... just realized that you can do the opposite of the parralax effect on the dots closest, but not fully 3D as it will just stretch further out...

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #27 on: June 06, 2011, 05:21:43 PM »
Not sure what you mean..  Things that are in the foreground (ie have a negative Z coordinate) can be "behind" the camera, that's in keeping with true 3D..


Not done any further work on this.  Might get some done today.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Limitations of the 3D Starfield Engine
« Reply #28 on: June 06, 2011, 09:10:09 PM »
When you drag your screen, the points behind gets dragged too, so if you also count with the one closest to the screen will be dragged the opoosite way of the one currently being dragged...

Screen Dragged --->

Furthest away points <--
Closest to screen -->

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Limitations of the 3D Starfield Engine
« Reply #29 on: June 06, 2011, 10:19:15 PM »
Still not sure what you mean I'm afraid.  Yes, points in the foreground behave different to those in the far background...  that's because they are closer to the camera than the asteroids are.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • 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: 24
  • Posts: 932
  • 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: 24
  • Posts: 932
  • 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: 30
  • Posts: 1,527
  • 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
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

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • 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 :)