Topic awaiting preservation: 3D javascript

It can't be that this one is simply not possible to resolve?
I stand by the challange for anyone who can crack it.
http://www.naltabyte.se/space/files/deepsea2.htm
Is a live example running this code, and how I calculate the z-index now is this way:
index=z+(-y);

This means that -y is the highest point of the shape, and z is the point furthest out forward along the horisontal plane.
If we draw a car facing forward, that would be the front of the vehicle, even if the roof in actuality would be closer to the 'camera' if we see it slightly from above as well.
That's the problem, it messes up the z-indexing.


<pre>

function point(y, x, a, w, h,x2,y2)
{
var x1=sphereCos(a,w);
var y1=sphereSin(a,h);

var z=eval(cutData(a)+"+"+90);
var c=-((y*h)*(z/100))/1000;

if(h < 0){c=-((y*(-h))*(z/100))/1000;}

if(x != 0)
{
if(h >= 0){ x=x-((x/1000)+(y*(h*0.0009)));}
else { x=x-((x/9.9)+(y*(h*0.0009)));}
if(y > 0){y=y-c;}
if(y < 0){y=eval(y+"+"+c);}
x=x+(z/60);
}

if (x >= 0) { for (j=0; j <= x; j++){p1=Math.round(x2 += x1);p2=Math.round(y2 += y1);}}
else { for (j=0; j <= -x; j++){p1=Math.round(x2 -= x1); p2=Math.round(y2 -= y1);}}

if(h >= 0){tY=(((w-h)*y)/100);}
else {tY=(((w-(-h))*y)/100);p2=-p2;}

//How the hell can I extract the correct Z-INDEXING???

if(z > keys[776])
{
keys[776]=z;
keys[777]=z+(-y);
}

return Math.round(p1-(tY/360))+","+Math.round(p2 + tY)+"; ";
}
function cutData(arg,arg2)
{
if(arg < 0){arg=-arg;}
if(arg=="0"){arg++;}
if(!arg2){arg2=0;}
if(arg > 360){ arg=arg-360;}
if(arg > 90 && arg < 270){arg=180-arg; arg=eval(arg+"+"+arg2); return arg;}
else if(arg >= 180 && arg < 270){arg=arg-180;arg=eval(arg+"+"+arg2); arg=-arg; return arg}
else if(arg >= 270 && arg <= 360){arg=eval(arg+"+"+arg2); return arg-360;}
else return eval(arg+"+"+arg2);
}
function sphereCos(arg1,arg2){return (parseInt(Math.cos(2 * Math.PI * arg1 / 360) * arg2))/160;}
function sphereSin(arg1,arg2){return (parseInt(Math.sin(2 * Math.PI * arg1 / 360) * arg2))/160;}

</pre>



(^-^)b

Have you tried, say, (z*really_big_number-y)? That will give the z value a higher precedence than the y value, and two shapes should only overlap if they're at the same z value.

Of course, there will still be problems with shapes overlapping in that case, but that particular problem is impossible to avoid when using 2D sprites to simulate 3D objects.

If the 3D representations of the 2D sprites never overlap, then the problem won't come up.

This method also depends on the camera looking exactly in the Z direction.

I was thinking that perhaps the z/y values could be made dependent on the h-value?
It's set up so that I have the parameters height and width, and the higher the h-value is, the more the object is seen from above.
This is (sort of) changing the z-indexing dependent on whether I see the object from the side or from the above, making the y-values more important seen from above, and the z more important seen from ahead.

<pre>

if(z > keys[775])
{
keys[775]=z;
z=z/4.5;

if(z >= (h/10)) z=z-(h/10);
else z=(h/10)-z;

keys[777]=(z-y);
}
</pre>



(^-^)b

Why is seeing things from above an issue? Is the camera able to move?

If so, simply take the x,y,z position of the camera, and the x,y,z position of the object being displayed, and use (camx-objx)^2+(camy-objy)^2+(camz-objz)^2 as the z-index. (This relates the z-index to the distance of the object from the camera.)