Suggestions for learning

[pmc]

Agreed - me drawing too many lines is definitely the problem! Thanks Leffman.

I'm learning about this vector stuff all the time and these little experiments with filling are just the first step on another path. I will definitely return to trying to get filled stuff working in the future. No point doing vectors if you don't do filled vectors at some point.

For now though I'm gonna keep on trying new things with this line vector cube routine and hidden lines is the next goal.

[korruptor]

Good skills man. Looking cool already! I wanna write more code now!

[pmc]

@ Leffman - thanks for the example illustrations mate, really appreciated

That'll come in well handy when I go for getting filling working!

@ korruptor - watcha mate - thanks for that. Would be cool to see some new routines from you! All the guys who hang round coders heaven chant: code! code! code!

[pmc]

Watcha chaps.

I've been thinking about getting hidden lines working in my cube routine and I think I've got a way to do it so I'll try to implement that in code soon.

One of the things I need to do for that is a routine to sort some numbers into ascending order which, like most things , I've never done before.

Anyway, I did some reading last night and coded myself a little insertion sort routine. It's short - about 65 bytes - and seems to work OK so I've attached it here in case it's of any use to anyone.


EDIT: Previous posting of the insert sort source code had a little bug - I'd used a bsr instead of a bra at one point in the source (doh!) which was causing some "interesting" things to happen when calling the sort routine! Anyway - now fixed and amended source reposted.

[Leffmann]

As long as you have a cube or any other convex object there is no need to sort the polygon order, in fact you will quickly realize it won't be of any use until you start drawing concave objects (which will quickly become a lot more complicated). What you need to here is determine which polygons are facing you and which ones are facing away.

[pmc]

@ Leffman - it's not actually the polygon order I'm going to be sorting. I need this sorting routine for other reasons.

Regarding which polygons are facing towards or facing away - I've read about this and know that if you calculate the surface normal unit vector of each polygon face of your object you can then test whether the dot product of each surface normal with the view vector yields a positive or negative result. Positive = hidden, negative = visible.

However, my own little idea for a hidden lines algorithm for my wire frame cube routnie does not use this approach. In 'pseudo-code logic' it seems to work but I'll see if I can get my idea working in actual 68k asm code and then, as usual, I'll post it.

[gilgamesh]

I'd be really interested in that pseudo-code. Would you post it if I say 'please'?

[pmc]

Well gilgamesh I was going to keep it a closely guarded secret but seeing as you asked so very nicely I don't mind sharing.

Two things to bear in mind:

Firstly, it's more of a description than a pseudo code really - I hope that's OK.

Secondly, I've been looking at this only from the point of view of something that will (hopefully) work with my routine as it is currently so I can't guarantee that it'll work for other situations. In fact, until I get it working in my routine I can't even guarantee it'll work for that!

Anyways, here it is:

Look at the z values in all the rotated cube points.

Any point whose z value is positive is at the rear of the cube and therefore a candidate to be hidden.

This is the first list of points.

The remaining points will have z values that are 0 or negative.

This is the second list of points.

From the second list of points, the highest and lowest x values and the highest and lowest y values need to be found. These values represent the coordinates of the outside extremities of the front of the cube's edges.

The x and y values of the first list of points need to be compared with these outside extremity x and y coordinates.

Any point from the first list whose x value is greater than the smallest x value but lesser than than the greatest x value of the second list AND whose y value is greater than the smallest y value but lesser than the greatest y value of the second list is therefore a point that is both at the rear of the cube and within the confines of the front of the cube's edges and would therefore be regarded as hidden.

No lines should be drawn from any point on the cube to any point regarded as hidden.

[gilgamesh]

Thanks. I'm sure it does not work in a general situation. Under the premise of rotating the same angle around all axes, it might work. At least I couldn't think of any angle where it fails, until now. But that's not a proof.

[pmc]

Well chaps, check out the attached source.

Unfortunately it looks like I'll have to chalk up my idea for hidden lines on this routine as "close, but no cigar..."

[pmc]

Oh, and for those curios to see my failed attempt but not assemble check the attached Amiga executable version.

[gilgamesh]

Wow, that's the first time that I saw your work with my own eyes. Looks still impressive.
Btw, which assembler do you use, and where can I gat it?

What's the problem with the missing points on the picture? They are all in list1 (negative z) and they fall into the rectangle that is spanned by the extreme points from list2. I'd say using that rectangle isn'n good.

[pmc]

Watcha gilgamesh

Unfortunately not quite impressive enough on this occasion. You're right, there's two points in that screenshot that shouldn't be hidden but are because they fall inside the front point's min / max x and y values. Looks like my "described logic" didn't actually work once I put it into code.

I use Devpac 3.02 as my assembler. I bought a copy years ago and I'm still using it as I really like it. I've put a copy in the zone for you.

I'll keep playing with my hidden line attempt - you never know I might get it working...

[gilgamesh]

Thank you, that's a cool tool. Now I can even assemble your sources.

Well, thinking of cubes and dice I had an idea:
Cubes have 8 corners, and you see between 4 and 7 at a time, if the cube is opaque.

You see
4 points, if the four hindmost points have the same z-component
(they are all in the same plane that is parallel to the xy-plane, the cube points a facet at you)
6 points, if only the two hindmost points have common z-component
(they are on a line parallel to the xy-plane, the cube points an edge at you)
7 points in all other cases (cube points corner at you)

Now my algo is: Sort all 8 points in a list according to their z-component. Check these conditions and ignore the last 4, 2 or 1 points in that list (with smallest z). Then draw the lines between the remaining.

[pmc]

Hmmm, interesting gilgamesh. Nice idea.

My current not quite working routine checks z coord values, separates off candidate hidden and non-hidden points, sorts the non-hidden point x / y values to determine lowest and highest of each and then modifies the candidate hidden points list after doing x / y comparisons to produce an "actually hidden" points list and then doesn't draw lines to these hidden points.

Bearing in mind what it currently does, it hopefully shouldn't be too much work to modify it to test / draw based on your algorithm conditions.

The quest for hidden lines goes on!

[gilgamesh]

Maybe you don't even have to check anything. The 7point condition is the standard situation.

The 4 and 6point conditions are extreme cases, where facets degenerate to lines. Just draw those lines/facets anyway. Then your program will draw the same line several times over. The result should be the same as when it is drawn only once, and you get constant runtime per frame. So, why bother?

I would try and discard the point with lowest z (or rather the last point in the sorted list) only. I think that should work...

[pmc]

The 4 point case definitely occurs in the rotation sequence I'm using.

Angles at the start of the routine are all 0 ie. no rotation around either the x,y or z axes so a correct hidden line representation of the cube under these conditions (ie. head on) should look like a square (rear four points hidden).

Interesting idea in relation to 6 / 7 point though - might save some time.

[gilgamesh]

Of course it occurs.

But then, draw a picture with only the four front points. You get a rectangle.
Now draw a picture with all 8 points. You get the very same rectangle.
Same as with the 7 foremost points. Still the same rectangle.

A line between points A and B should look the same, no matter if it is drawn once or ten times. I'd say avoid avoiding the extra checks saves more time than taking extra care of rare extreme cases.

The results on the screen are the same, anyway.

[pmc]

Originally Posted by gilgamesh

But then, draw a picture with only the four front points. You get a rectangle.
Now draw a picture with all 8 points. You get the very same rectangle.
Same as with the 7 foremost points. Still the same rectangle.

You do, but you don't in this case.

The reason you don't is perspective transform. the three dimensional x, y, z point locations need to be converted to two dimensions so that they can be drawn on the screen. To do this successfully you need a formula that modifies the x / y coordinates by the z coordinates so that you get a two dimensional representation of distance. The formula requires you to define a viewpoint distance (d) and is then:

x = x*d/z+d
y = y*d/z+d

drawing using this formula, a head on cube doesn't look like a square - it looks like a square within a square with the inner four points (ie. the cube corners that are further away) connected with diagonal lines to the outer four points (the cube corners that are closest).

To see this - assemble my optimised wireframe cube routine but amend the cos / sin tables so that they only contain angle 0. As the routine uses 2^14 fixed point values the cos table would contain only the value 16384 and the sin table would contain only the value 0.

Or look at the picture I attached.

[pmc]

OK gilgamesh, check out the attached Amiga executable.

I took your idea and applied it to my routine. What it now does is:

Grabs all the z values of the points, finds the largest one (ie. the furthest away), compares this value to all z values and marks any that are equal as hidden, doesn't draw lines to any points that are marked as hidden.

Doing this gets really, really close to a working hidden line routine.

One thing you might notice is that the only condition under which it fails would be one that would have succeeded under my original routine.

Hmmm, in that case, how about a combination of the two routines...?

More coding to come I think - definitely nearly there.

Gotta say a big nice one for your input gilgamesh - it's really helped.