Eufloria > Eufloria Classic Mods

Limitations of the 3D Starfield Engine

(1/9) > >>

annikk.exe:
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:
Oooh, there's some good stuff on the road ahead.  Wikipedia says   :D

Aino:
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: ---DrawX = xpos + math.cos(ModelRotation+Rotation)*(MAPIModelPartDist[i]*size)
DrawY = ypos + math.sin(ModelRotation+Rotation)*(MAPIModelPartDist[i]*size)
--- End code ---

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:
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:
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: --- { 0 3 1 }
{ 1 0 2 }
{ 2 1 3 }
{ 3 2 0 }

--- End code ---


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


--- Code: --- -- 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
--- End code ---


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



--- Code: --- -- 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
--- End code ---


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

Navigation

[0] Message Index

[#] Next page