Conversion of 2D maze generation java code to 3D fps graphics interface

Hi,
I have coded a java 2D random maze generation code and I need to convert it to 3D fps maze. What I mean by fps 3D maze, is that when the user log in, the user can only see the walls in front, at the side of the maze. As the player proceed further, then the player would be able to see more of other walls and even encounter traps and cure.

I hears that it can be done using jogl, hope someone please render some help on how can I get started?

This is my URL(2D GUI maze generated from my java code):
http://www.geocities.com/hazepoh83/maze.html

With Thanks,
haze

Perhaps raycasting would be a good solution?

What you are asking is similar to - how do I build a jet aircraft? :slight_smile:

A good place to start is researching Open GL over all - (NeHe tutorials are good) - and for your final solution, a Binary Space Partition (BSP) tree will work nicely for a maze.

3D is not any more difficult than 2D. Then again I finished my computer graphics subject with a final score of 89%. :stuck_out_tongue:
Generally there is a lot to learn if you are doing it by yourself and you have to take into consideration a lot of different factors.
To be honest if anyone here is willing to give you a tutorial on how it should be done we’d be here for ages.
Let me just contradict Vorax, don’t use BSP’s instead use oct trees as they are more efficient at breaking things up and are used in outdoor areas extremely well with much better performance than BSP’s.

I suggest a good book.
I’m using “Interactive Computer Graphics: A Top down approach using OpenGL”.
This book is one of the better books, IMO it trumps those game development books hands down.

I won’t argue BSP over octree in terms of ease - octree’s are definetly easier to do - but for performance a BSP is very suited to a closed maze (infact ideal by nature) which is why games like Quake 3 used them .

… but anyway - there is a big difference between doing 3D graphics and making a 3D game. A 3D game is much more difficult then a 2D game. A scene graph api like Java3D or Xith, will make it ALOT easier though - I would suggest you start with one of those rather then JOGL. Writing a loader for JOGL can be more difficult then writing a alot of 2D games :slight_smile:

I would suggest raycasting. My Java4k entry Frag4k seems very similar to your project. The advantage of raycasting is that you don’t need a Z buffer & thus ordinary Java2D will do the job. The disadvantage is that you need to push lots of individual pixels if you want to texture the walls. My solution was to use a BufferedImage and then use getRaster() on it (& some further calls) to get the underlying array of colour values. These can then be written to directly, which is quite fast. :slight_smile:

In raycasting, you draw rays in 2D (plan view), from the viewing position, through each vertical line of the screen in turn, calculating the intersections with all the maze walls. You need to keep track of the nearest intersection. Calculate the distance to that intersection (perpendicular to the screen). This needs you to do 2D matrix rotations with sin and cosine. Use similar triangles to work out the position on the screen of the top and bottom of the wall each ray intersected with. In the simplest implentation, draw a line in the sky colour from the top of the screen to the top of the wall; draw a second line in the wall colour from the top of the wall to the bottom of the wall. Lastly draw in the ground colour from the bottom of the wall to the bottom of the screen. Repeat for each ray.

I would post the code, but the competition has only just started, so want to hang on to it for the moment :-\

Alan

Thanks for your help, may I know when will you post your code?

Haze