BSc Computing Year 3 Graphics Programming 3D Maze Room Assignment Two. by Richard M. Mann:

Transcription

1 BSc Computing Year 3 Graphics Programming 3D Maze Room Assignment Two by Richard M. Mann: April 2003

2 Table of Contents 1 INTRODUCTION ANALYSIS & DESIGN ROOM DESIGN Dimensions Lighting Colouring & Textures THE TABLE THE MAZE NAVIGATION Movement Collision Detection (CD) IMPLEMENTATION ROOM & MAZE CONSTRUCTION Wall dimensions PutWall Function Maze Co-ordinates DYNAMIC LIGHT MOVEMENT COLLISION DETECTION View Platform Scaling CONCLUSIONS APPENDICES ASSIGNMENT BRIEF System Requirements Additional functionality/complexity FLOOR TEXTURE BITMAP MAZE CO-ORDINATES SOURCE CODE BIBLIOGRAPHY WEB SITES CONSULTED FOR THIS PAPER of 23

3 Table of Figures Figure 1: Light & Shade Illustration... 5 Figure 2: Table Design... 6 Figure 3: Maze Plan... 7 Figure 4: Controls Key-Map... 8 Figure 5: Rectangular Bumpers... 9 Figure 6: Circular Bumpers Figure 7: PutWall Function Code Sample Figure 8: Revised Maze Plan Figure 9: Light Translation Process Figure 10: Rotation Interpolator Code Sample Figure 11: CreateBumper Code Sample Figure 12: Bumper Creation Code Sample Figure 13: Floor Texture Bitmap of 23

4 1 Introduction The purpose of this assignment is to produce a technical report and accompanying application using Java 3D. The application is to be a Java 3D Environment (3DE) in the form of a room. The room is to contain a table with a maze upon it. The user will be able to move horizontally within the room. The room shown in the figure below will give an idea of the type of environment expected. The assignment brief, containing the specifications for this environment, can be found in the Appendix, section 5.1. It will be the objective of this paper to fulfil all basic and advanced requirements, as listed bellow. Basic System Requirements: Create a VirtualUniverse (not a SimpleUniverse) to contain your room. The room is to be 5 metres wide, 7 metres long and 3 metres high. Use 100mm block walls and 150mm floor and roof slabs. Walls, floors and ceilings should all 'look' different. A table should be placed centrally in the room. Its top should be circular. On the table is to be a maze. Horizontal navigation (back, forward, left and right) within the room should be possible. Additional functionality/complexity: The surfaces can be coloured (minimum) defined as a material or given a texture. Incorporation of lighting effect using material, ambient, directional, point and spot lighting. Primitive shapes, user defined or loaded geometry. The Maze should be navigable. Navigation using buttons (minimum) or the keyboard/mouse. Collision detection. Perspective. 4 of 23

5 2 Analysis & Design 2.1 Room Design Dimensions The dimensions of the room, as specified in section 1, will be set at 5 metres wide by 7 metres long by 3 metres high. The walls will be 100mm thick, or 10cm, and the floor and roof shall be 150mm thick, or 15cm Lighting The main light source for the 3DE will be a light, with shade, hanging from the ceiling, as shown in Figure 1. This light will provide a wide-beamed spotlight effect that will show on the walls, table and maze. The reason this light source has been chosen is to provide a realistic lighting effect and will provide varying shading effects on the maze as some walls face the light while others do not. Figure 1: Light & Shade Illustration To improve on this and emphasise the effect of the light on the walls and maze, it will swing from side to side along the X-axis. By doing this, the light effect will move across the walls and table as it swings. Also, from within the maze, the effect of the light moving over-head will become exaggerated as some walls fall in and out of direct light, i.e. drastically changing shade Colouring & Textures As specified in the assignment brief, section 5.1, each of the walls, floor and ceiling must be different colours or textures. To conform to this the walls will be coloured red, green, yellow and purple. The roof will be another shade of green and the floor will be textured using a checkers effect bitmap, shown in the Appendix, section 5.2. Most of the surfaces are being left un-textured to better illustrate the dynamic lighting effect described in section While the lighting effect can be set to show on textured surfaces, it is not as clearly noticed. 5 of 23

6 2.2 The Table The table will be very simply constructed of one cylinder and a rectangular box, as shown in Figure 2. Figure 2: Table Design To demonstrate an interesting effect with the tabletop, it will be coloured light blue and a transparency effect will be used to give it a glass-like appearance. By doing this, the user will be able to see through the table top, seeing the maze and light from beneath or the floor and table leg from above. 2.3 The Maze The first step in the design of the maze is to draw out a plan of what the maze will look like. The maze will be constructed using rectangular boxes and these boxes will be plotted onto a 100X100 grid, where each 10x10 square represents 1 meter. By plotting the maze in this manner, the implementation of the maze within the 3DE will be made much easier, as the co-ordinates for each of the rectangles can be very simply calculated with reference to the grid. Figure 3 is the maze plan. The centre point of the grid is marked by the red dot. 6 of 23

7 -Z -X +X 2.4 Navigation +Z Figure 3: Maze Plan Movement Movement will be allowed in six directions, those being up, down, left, right, forward and backward. Turning will be limited to 90-degree rotations, the reason for which being to avoid the need to calculate the co-ordinate changes required to move and any direction. While the user will only be permitted to move and turn by 90-degrees, they will be able to look in any direction. From any stationary location the user will be able to look around them using a set of look commands. These commands, while effecting the direction in which the VP is facing, does not effect the direct the user will move in, i.e. left they look left, then press forward, they will seem to move sideways. 7 of 23

8 As well as the moving and looking commands, there will be two toggling controls. These will allow the user to increase and decrease the speed at which they move, Run and Walk, and switch between strafing and turning. The Run/Walk command will be toggled on/off as the user presses the Shift key. The Ctrl key will control the Strafe/Turn command, which will dictate the action performed when the Left and Right Arrow keys are used. When Strafing is turned on, instead of turning by 90 degrees, the VP will be moved to the left or right, i.e. strafing. The movement controls within 3DE will be accessed via the keyboard and have been setout in Figure 4 along with related ASCII numbers for later use. Key ASCII Purpose UP ARROW 38 Move Forward DOWN ARROW 40 Move Backward LEFT ARROW 37 Turn/Strafe Left RIGHT ARROW 39 Turn/Strafe Right PAGE UP 33 Move Up PAGE DOWN 34 Move Down SEMI-COLON 59 Look Up BACKSLASH 47 Look Down COMMA 44 Look Left FULL STOP 46 Look Right SHIFT 16 Toggle Run/Walk CTRL 17 Toggle Turn/Strafe Figure 4: Controls Key-Map Collision Detection (CD) To help with the design of a collision detection (CD) system, a list of requirements that the collision system must be able to do has been compiled: 1) Detect potential collisions, i.e. detect the collision before actually colliding to allow the collision to be prevented. 2) Detect the side on which the collision has/will occur, i.e. is the collision occurring in front, on the left or above and etc? Although these points do seem quite obvious, they do shape the way in which the CD is handled. One way that the CD could be done is to detect when the Viewing Platform (VP) collides with an object, but this method would not conform to either of the above stipulations as the VP has already collided with the object by the time the program would be able to respond. One way to partially solve this would be to simply undo the last translation made on the VP, but this could lead to undesirable flickering effects when continually bumping into objects and temporary disappearing of rendered surfaces. It is also not possible to tell on which side the collision occurred without performing calculations using the last know translation. 8 of 23

9 Due to these points, it is clear that another solution will be required. A system by which bumpers are used to surround and collide in advance of the VP could be used. These bumpers would be objects placed into the View Branch on every side of the VP, i.e. in front, behind, to the left and right, above and bellow. These objects would trigger the CD events as they collide with other objects before the VP hits the object in question and the movement of the VP in the direction of the bumper that collided can then be disabled until the bumper is freed again. Figure 5 illustrates the bumper system by showing the Viewing Platform and four of its bumpers. As the Viewing Platform approaches an object, the front bumper hits the object and would trigger an event to deactivate all forward motion preventing the collision with the VP. Figure 5: Rectangular Bumpers Figure 6 illustrates another bumper system using smaller circular bumpers. The problem with this approach is that for a collision to occur, the bumper must bisect the objects surface at some point for the collision to be detected, otherwise the collision goes un-noticed and the VP would continue on into the object. It is because of this that the longer, rectangular bumpers will be used. 9 of 23

10 Figure 6: Circular Bumpers The exact length of the bumpers depends on the distance being traveled by the VP with each step. If the bumpers are smaller then the stepping distance, then collisions may not be properly detected or even missed completely. To avoid this, the length of the bumpers must be at leased as big as the distance being traveled in any one step, this will be important to consider when scaling the VP. 10 of 23

11 3 Implementation 3.1 Room & Maze Construction Wall dimensions The dimensions for the walls are specified in the Appendix, section 5.1.1, and were implemented in the 3DE as follows: Floor & Ceiling- 2.5x0.075x3.5 Left & Right Walls- 0.05x1.5x3.5 Front & Back Walls- 2.5x1.5x0.05 Each unit used to represent distance in the Java 3DE (J3DE) represents one meter. It should be noted that the measurements given above do not directly match those specified in the assignment brief. This is due to the way in which the dimensions are treated within the J3DE. All dimensions given for any 3D shape within the J3DE are treated as measurements to be made from the point of origin in both directions. This means that to get a 2-meter length a value of 1 meter, to be taken in both directions, must be given PutWall Function As specified in the design, the room and maze walls are created using a variety of boxes. The code to create and place these boxes is identical for every one of them, with the exception only of the box dimensions, position and appearance; because of this a PutWall function was implemented, as shown in Figure 7. Figure 7: PutWall Function Code Sample The PutWall function takes in the size, position, primflag value and appearance (as shown at line 9) and returns the transform group containing the positioned box (as shown as line 18). This function can be used as a parameter to generate boxes as they are needed for use within transform groups or scenes, as shown at lines 3-5. By using this function, the need to repeate the section of code used in the PutWall function is avoided, making for much tidier and easier to read code Maze Co-ordinates The maze was implemented as described in section 2.3, with one small change. Figure 8 shows the revised layout used for the maze. 11 of 23

12 X Figure 8: Revised Maze Plan The red line represents the old position of the wall and the green box the new one. The reason for this is to allow enough space for another table, with maze, to be placed at X. This was done simply to demonstrate how easily objects can be reproduced and manipulated within the 3DE. The smaller table and maze are produced using identical sections of code to that of their lager counterparts, but have simply been scaled and translated to position them within the larger maze. This smaller maze is also navigable, using the same shrinking techniques on the VP to allow access as is used for the larger version. The dimensions and co-ordinates used to plot the maze walls are provided in the Appendix, section Dynamic Light Movement The light, as described in section 2.1.1, was implemented as a sphere (Bulb), cone (Shade) and box (Wire). The movement was done using an animation interpolator. The interpolator used was the Rotation Interpolator, which takes an Alpha, a transform group, 3D transform and a max and min rotation range. Using the Alpha object, the progression of the rotation being performed by the interpolator can be controlled. This is done using a range of values to specify: How long it takes to complete one repetition of the specified rotation. How quickly, if at all, the progression should be accelerated and decelerated at the start and end of the rotation. 12 of 23

13 To get the bulb, shade and wire to swing together, they were added to one transform group before being moved. Once together, they were moved to a point that placed the end of the wire at the origin-point of the 3DE, as shown in Figure 9. The reason for this was because to get the light to appear to swing from the ceiling, the end of the wire had to be set as the centre-point for the rotation, marked in Figure 9 by the red dots, which this achieves. The numbers in Figure 9 roughly represent individual translation groups. Figure 9: Light Translation Process Once the light had been moved, the Rotation Interpolator was applied to create the rotation, as illustrated in Figure 9- stage 3. Once the desired swinging effect had been achieved, the rotation group, containing the interpolator and all the 3D shapes, was translated again to move it to the top of the room. By doing this, the light appears to swing from the ceiling. The code used for this can be seen in Figure 10. Figure 10: Rotation Interpolator Code Sample The code shown in Figure 10 assumes that the object(s) being rotated have already been created and added to the walltgroup transformation group (featured at line 22). 13 of 23

14 A similar procedure was used to get the actual lighting effect to swing, but applied to the spotlight object instead. 3.3 Collision Detection Collision detection was implemented as described in section with bumpers at a length of 0.06, as this is the distance covered by the VP in one step when running. A CreateBumper function was implemented to handle the creation, placement and setting-up of the collision detection. This function uses a CollitionDetection2 class to detect and process collisions, which is based on a collision detection class provided by Sun Microsystems, Inc. Figure 11 shows the code used to implement this function. Figure 11: CreateBumper Code Sample Line one sets out the parameters required, which are: collisionid- This is the number returned when the bumper is activated and is used to identify the different bumpers. size- The (square) dimensions of the bumper. position- The position of the bumper (using x, y, z co-ordinates). bumpertgroup- This allows the programmer to specify which transform group the bumper should be added too. The bumpers, created as boxes (see Figure 11, line 12), have their appearance set to be completely transparent. This is done at lines 9 and 10 using the TransparencyAttributes class, which is also used to make the tabletop partially transparent. This allows the bumpers to go unnoticed by the user. The collision detection is set-up using lines 20 and 21 before being added to the transform group at line 22. The CollitionDetection2 class implements the collision detection using the WakeupOnCollision class-set (including WakeupOnCollisionEnter and WakeupOnCollisionExit). When one of the bumpers is activated, an element of the collisions array matching the bumper ID is set to true. Each element of the collisions array corresponds to a direction, which is used, when navigating, to determine if there is an obstacle obstructing the VP. This array is checked before any movement is made and if the value corresponding to the direction being travelled is set to true, i.e. there has been a collision on that side, then the action is not perform. 14 of 23

15 Figure 12 shows the code used to implement the use of the CreateBumper function. There are 6 bumpers, as discussed in section 2.4.2, positioned into the scaleshapegroup transform group, which is used to scale the VP and is later added to the View Branch. Figure 12: Bumper Creation Code Sample View Platform Scaling For the view platform and bumpers to fit into the maze properly it had to be scaled down. Very simply applying a scale transform to the VP did this. Something that had to be considered, however, is the distance that the VP was being moved. This should also be scaled to make sure the distance being travelled in any one step is not bigger then the length of the bumpers, which are scaled with the VP. As long as this stipulation is kept to, then the VP can be scaled, up or down, as required without affecting the collision detection routines. To get the VP to scale down before entering the maze can be done using another collision detection process. This one, implemented as a ViewCollitionDetection class, uses the WakeupOnViewPlatform classes (including WakeupOnViewPlatformEnter and WakeupOnViewPlatformExit) to detect when the VP enters a specified area. Any number of these areas can be created and for this program, two have been used. The first area covers the main maze, and the second it s smaller counterpart. The effects of entering the areas are accumulative, so as the VP enters the second area, it will be scaled down again, allowing it to enter the even smaller maze. The ViewCollitionDetection class uses the following constructor: public ViewCollitionDetector(Bounds b, double su, double sd) Passed into this class are the bounds to which it applies and the factors by which the VP should be scaled up on exiting from the area and scaled down on entering it. 15 of 22

16 4 Conclusions The purpose if this assignment was to produce a report with accompanying program implemented using the Java 3D Environment. The program had to feature a room with a table with a maze on it. The specification for this program was as follows. 1) Basic System Requirements: 2) Create a VirtualUniverse (not a SimpleUniverse) to contain your room. 3) The room is to be 5 metres wide, 7 metres long and 3 metres high. 4) Use 100mm block walls and 150mm floor and roof slabs. 5) Walls, floors and ceilings should all 'look' different. 6) A table should be placed centrally in the room. Its top should be circular. 7) On the table is to be a maze. 8) Horizontal navigation (back, forward, left and right) within the room should be possible. 9) Additional functionality/complexity: 10) The surfaces can be coloured (minimum) defined as a material or given a texture. 11) Incorporation of lighting effect using material, ambient, directional, point and spot lighting. 12) Primitive shapes, user defined or loaded geometry. 13) The Maze should be navigable. 14) Navigation using buttons (minimum) or the keyboard/mouse. 15) Collision detection. 16) Perspective. The program produced during this assignment complies with all of the basic requirements listed above and most of the additional ones. One possible requirement that the program does not fulfil is the use of a mouse for navigation. It was decided that navigation via the keyboard would prove an adequate solution, until additional development was required. 16 of 22

17 A sacrifice of aesthetics was made to better demonstrate the lighting effect of the moving light source by not texturing all of the surfaces. This was also done to allow for additional development time on the dynamic lighting effect and collision detection (Points 2b & 2f). Even though texturing of the surfaces was of a low priority, if additional time was awarded for this assignment, texturing of all the surfaces in the room would provide for a more polished finish to the environment. Another limitation of the program that, with further development, would be removed is the 90-degree turning and movement (please refer to section 2.4.1). This was enforced to avoid more complex issues concerning movement and collision detection that would occur with real-directional movement. To allow the user to move completely freely within the 3DE might also cause problems while trying to navigate the maze, but this would still be a desirable improvement on the current program. 17 of 22

18 5 Appendices 5.1 Assignment Brief Produce a technical report and accompanying application using Java 3D. The application is to be a Java 3D environment in the form of a room. The room is to contain a table with a maze upon it. The user will be able to move horizontally within the room. The room shown in the figure below will give an idea of the type of environment expected. Figure: System Requirements Create a VirtualUniverse (not a SimpleUniverse) to contain your room. The room is to be 5 metres wide, 7 metres long and 3 metres high. Use 100mm block walls and 150mm floor and roof slabs. Walls, floors and ceilings should all 'look' different. A table should be placed centrally in the room. Its top should be circular. On the table is to be a maze. Horizontal navigation (back, forward, left and right) within the room should be possible. 18 of 22

19 5.1.2 Additional functionality/complexity The surfaces can be coloured (minimum) defined as a material or given a texture. Incorporation of lighting effect using material, ambient, directional, point and spot lighting. Primitive shapes, user defined or loaded geometry. The Maze should be navigable. Navigation using buttons (minimum) or the keyboard/mouse. Collision detection. Perspective. A bare pass will involve displaying the room, with table and maze. A good pass will include buttons to provide horizontal navigation within the scene. A very good pass will incorporate most of the 'Additional functionality/complexity' above. 5.2 Floor Texture Bitmap 5.3 Maze Co-ordinates Figure 13: Floor Texture Bitmap The following is a list of the dimensions used for each blocks used to construct the maze and the co-ordinates used to place them. 19 of 22

20 Dimensions (x, y, z) : Position (x, y, z) 0.025, 0.05, 0.5 : , -0.0, , 0.05, 0.25 : , -0.0, , 0.05, : , -0.0, , 0.05, 0.1 : , -0.0, , 0.05, 0.05 : 0.175, -0.0, , 0.05, : 0.325, -0.0, , 0.05, : 0.475, -0.0, , 0.05, 0.15 : , -0.0, , 0.05, : 0.025, -0.0, , 0.05, 0.1 : 0.175, -0.0, , 0.05, : 0.325, -0.0, , 0.05, : 0.475, -0.0, , 0.05, : 0.0, -0.0, , 0.05, : 0.075, -0.0, , 0.05, : 0.15, -0.0, , 0.05, : -0.1, -0.0, , 0.05, : -0.3, -0.0, , 0.05, : -0.25, -0.0, , 0.05, : f, -0.0, , 0.05, : 0.4, -0.0, , 0.05, : 0.1, -0.0, , 0.05, : 0.375, -0.0, , 0.05, : 0.2, -0.0, , 0.05, : 0.225, -0.0, Source Code Please see below for full Source Code listing. 20 of 22

21 Source Code Removed 21 of 22

22 6 Bibliography 6.1 Web Sites Consulted For This Paper This site provides Java API s and tutorials. 22 of 22