PDA

Click to See Complete Forum and Search --> : 3D Tilting maze ?!



Jayhoo
09-09-2002, 04:50 AM
I have posted this in the games forum but as i have a short deadline i thought id try here too.

Trying to create a Tilting maze game in Flash MX. THe user controls the tilt of the table with the mouse. This navigates to specific frames within a vector based "3D" animation exported from Vector 3D, via Radial Depth ( Pythagaros) and Sector Area (Trig).

Got this working but my problem is the Ball. Any ideas how i can implement a rolling ball within this structure? Have thought of Multiple plains, Simple animations etc.. but these seem not to give me the "real" ( ish) effect i need, at least not the techniques i use. So any help appreciated

As you can see im trying to use psuedo 3D rather than real 3D Maths here, as im still getting my head round that! But if anyone has a 3D math route i could follow, again would be much appreciated. Would rather follow this route as feel a bit of a cowboy doing it the way im doing it but, needs must as they say

You can see where i am at with this here ( i.e. not very far)

http://www16.brinkster.com/jayhoo/maze/Table.html


Cheers

brutfood
09-09-2002, 09:50 AM
I don't see a problem? - However, this usually means that I haven't understood the problem, or fully realised the issues and difficulties.

Pseudo 3D? - looks 3D to me :) - I can even see a perspective transformation. Do you mean pseudo in the sense that all the 3D stuff was pre-calculated in Vector 3D?

A ball/sphere that you want should be easy to incorporate in your model (but perhaps I'm missing the point). It's just a sphere - it doesn't change view/shape - just size - depending on the distance away. It only moves horizontally and vertically - with accelaration depending on horizontal and vertical tilt. It also hits walls and bounces perhaps (How have you stored and represented the maze walls? - for collision detection?) - again only horizontally and vertically. We can go into the physics of this if you like?

The ball may sometimes be obscured by the top surface of your maze - if so - you will need the multiple plains you mention, so that the top surface of the maze is in front of the ball.

What is the 'reality' that you need?

Jayhoo
09-09-2002, 10:08 AM
Thanks for getting back.

I would like it to look as though it is working real time
as in this director demo http://www.havok.com/xtra/demos/demo-maze.htm
(this uses 3Dstudio Maths via the Havoc Xtra)

The Problem is representing the Maze on all plains, i can create an array of points etc.. for a 2d maze but, the way i do it doesnt allow for the perspective you get on the 3D model, at least i cant see how it does.

Its at the defining of the maze and the hit detection that im stumbling. As well as the scaling of the MC as the Table Tilts away.

Im currently working on the hitTest optional parameter, set true for actual shape not bounding box, as the Graphics are in 1 targetable MC. This is ongoing and not sure whether it will work, but seems..ok, but doesnt cover the scaling problem.

Would appreciate going into the maths of it, if you have time, been trying to do real time 3D for a while

brutfood
09-09-2002, 10:09 AM
I had a little think about what your 'reality' issue might be. When I spoke about horizontal and vertical movement - let me clarify:- ok there is a bit of depth movement (which is why you may want to adapt the size of the sphere) -and then there's the perspective transformation that I mentioned.

x'=x*(z+midpoint)/viewport;
y'=y*(z+midpoint)/viewport;

Where midpoint and viewport are constants. The trick is finding the constants that your vector 3D application used.

Jayhoo
09-09-2002, 10:12 AM
Midpoint = Pivot point of table/maze?
ViewPort = Focul Length?

brutfood
09-09-2002, 10:55 AM
Yep, that's right. But whoops - I think I gave you the wrong equations (Which I used these for converting back)

x'=x*viewport/(z+midpoint);
y'=y*viewport/(z+midpoint);

also ball radius r:

r'=r*viewport/(z+midpoint);

I need sleep - it's good to read this maths and physics forum before I go to bed - cure for insomnia.

Before I go -

I can't see why you can't use a 2D array to represent the maze? You don't need to store depth. Imagine the maze is built using 50 pixel blocks (say) that are either wall or channel. Before you move the ball to position (x,y) - check your array at indices: Math.floor(x/50), Math.floor(y/50) for a collision. (x and y of ball rolling down slopes before perspective transformation).

As for using real-time 3D techniques - this problem doesn't require too many of those. The ball rolls along the floor of the maze - it's easy to calculate its distance (z).

But here are the 3D routines I use - that you won't need, but can play around with :-



function initrotate(anglex,angley,anglez) {
sinx=Math.sin(anglex*dtor);
cosx=Math.cos(anglex*dtor);
siny=Math.sin(angley*dtor);
cosy=Math.cos(angley*dtor);
sinz=Math.sin(anglez*dtor);
cosz=Math.cos(anglez*dtor)
}


function rotation(xx,yy,zz,i) {
yyy=yy*cosx-zz*sinx;
zzz=yy*sinx+zz*cosx;
xxx=xx*cosy-zzz*siny;
set("_parent.z" add i,xx*siny+zzz*cosy);
set("_parent.x" add i,xxx*cosz-yyy*sinz);
set("_parent.y" add i,xxx*sinz+yyy*cosz)
}


The only bit missing is the ball rolling down a slope, and bouncing of walls - and the physics for doing that - I'll give someone else on this forum a chance to speak ;)

Jayhoo
09-09-2002, 11:00 AM
Thanks for your help

ericlin
09-12-2002, 07:50 AM
Tried to make a simple model.

http://ericlin2.tripod.com/forum/mazeBall4.html
http://ericlin2.tripod.com/forum/mazeBall4.zip

Jayhoo
09-12-2002, 07:56 AM
Absolutely Superb!
Exactly what i am trying ( and failing) to achieve!

Having problems linking to the zip file though, saying file not available for download?

ericlin
09-12-2002, 09:41 AM
Sorry, I type a wrong name zip. Try again with click save target as.

I am still thinking how to solve the "side" face of the hollow. If I add side surfaces like your mode, then sometimes the side should hide the ball, sometime the ball should hide the side face. I can not solve this problem at present.

So, my model is like a cube with uper face and bottom face without side faces.

Jayhoo
09-12-2002, 10:25 AM
brilliant really appreciate your help!

v v clever way of doing this, wil help me with my 3D development etc...

Thanks again!

brutfood
09-12-2002, 09:29 PM
Nice demo erclin. I would also have used the MX drawing API as opposed to imported 3D artwork. (Incidently - I always imagined the ball being the same diameter as the channel width - hence my 'only horizontal and vertical assumption.)

I think I have a simple algorithm for working out whether a wall is behind or in front of the ball.

Do the following calculations before the perspective transformations. Mathematically represent the walls as lines: at a distance from the floor of the maze equal to the radius of the ball. Lets call the wall end-points (xwall0,ywall0,zwall0) and (xwall1,ywall1,zwall1).

The position of the ball centre is (xball,yball,zball).

Consider a 'vertical' wall. Interpolation tells us the depth z of the wall at the vertical position of the ball (yball) is:-

z=zwall0+(zwall1-zwall0)*(yball0-ywall0)/(ywall1-ywall0)

Or for a 'horizontal' wall:-

z=zwall0+(zwall1-zwall0)*(xball0-xwall0)/(xwall1-xwall0)

Compare z to zball to determine whether the wall is in front of or behind the ball.

ericlin
09-13-2002, 10:20 AM
Usually the visible walls are always behind the ball.

The problem only occurrs when the ball is at the inward corners. I think careful calculation considering wall orientation and ball position might solve it. But I dont want to go further.

So, I give up. Anyway, the corner problems is just trivial. Most of the time when the corner covers the ball, the ball would go off the corners, so it might not be noted.

It occurs when the ball is on the corner and then we quicky tilt the table with north down. The ball soon will goes to north, so the glitch only appears transient.

http://ericlin2.tripod.com/forum/mazeBall7.html
http://ericlin2.tripod.com/forum/mazeBall7.zip

brutfood
09-16-2002, 09:49 PM
My algorithm didn't fully take into consideration the end points of the walls. This is important for inward corners.

I missed out a step:-

function limits(x,lim1,lim2) {
mn=Math.min(lim1,lim2);
mx=Math.max(lim1,lim2);
return Math.max(mn,Math.min(mx,x))
}

yball0=limits(yball,ywall0,ywall1);
z=zwall0+(zwall1-zwall0)*(yball0-ywall0)/(ywall1-ywall0)

Or for a 'horizontal' wall:-

xball0=limits(xball,xwall0,xwall1);
z=zwall0+(zwall1-zwall0)*(xball0-xwall0)/(xwall1-xwall0)


(The above code can be made a little simpler if you ensure ywall0<ywall1 or xwall0<xwall1 respectively.)

ericlin
09-16-2002, 10:19 PM
Hi brutfood,

The draw API and the calculation of 3D data seems to exhaust the CPU.

I tried extend the grid from 4x4 to 6x6 (the link above), it is slow but acceptable in PIII 755, but too slow in my celeron 333.

If we need to make a complex maze of more than 10x10, it seems impossible to play smoothly by draw Api on the fly.

Maybe we still can create frame by frame animation by 3D software and as your first reply: estimate the constants in 3D formula to render the ball by script separatively.