webgl代写 ITCS 3120 – Planet Mobile

Compatibility

ITCS 3120 P2: Planet Mobile

Fall 2018

Professor: Zachary Wartell Revision: 11/4/2018

This page has been tested on Firefox v41 and Chrome v46. A PDF version is also available under Canvas in “Files\Projects\”

Objectives

1. Apply and extended knowledge from previous assignments regarding WebGL for 2D graphics
2. Apply and extended knowledge from previous assignments regarding HTML5 input event handling 3. Apply and extended knowledge from previous assignments regarding JavaScript
4. Apply and extended knowledge from previous assignments regarding matrix transformations
5. Apply various 2D geometry computations discussed in class lecture

Overview

AB

Figure 1

In Project “Planet Mobile” you will write a visual simulation of a 2D solar system (Figure 1A) that mechanically works like a hanging mobile (Figure 1B). Planets will circularly orbit around a single sun. Moons will circularly orbit around planets and space debris will circularly orbit around Moons. Each object should have a unique name.

you choose the names

you choose the exact geometry layout of the solar system you choose the speed of rotations
you choose the colors, sizes, etc. of the planetoids.

User Interface:

left click – on any one of the objects will cause the name of the object to be displayed in the bottom of the main OpenGL window.
“Pause Button” – will toggle on and off the animation of all rotations. All other user interactions must remain functional when animation is paused

You must retrieve the skeleton code using a git fork procedure as described in Appendix I: Code Retrieval. An executable demo is at this link:

Planet Mobile

You will implement the 2D orbiting objects using a standard, object oriented approach for describing a scene of geometric objects. The class lecture ITCS_4120-OpenGL_Transforms.ppt, presented the mathematics and pseudo-code for this approach. The approach involves building a scene graph framework of classes. A scene graph framework is an object-oriented layer that builds on top of low-level math classes and low-level matrix routines.

You must follow this strategy and code structure and implement two main classes, a CoordinateSystem class and a Shape class, plus some sub-classes. The precise specification of parts of these classes is given in the skeleton code.

Figure 2: Scene graph classes using UML notation

As discussed in the lecture, a CoordinateSystem represents a coordinate system. It has three data members, origin, orientation and scale, which specify the coordinate system’s origin, orientation angle and x/y scale factors. These attributes completely describe the coordinate system’s origin and basis vectors. Collectively, these attributes are referred to as the pose of the coordinate system.

The Shape class represents geometric shapes with a visual appearance (color, etc.). Shape is an abstract class. In any Shape sub-class, the sub-class’s geometric attributes are always measured relative to a coordinate system. Every Shape instance has an associated CoordinateSystem instance which is called the Shape’s parent. Because Shape’s coordinate data members are measured with respect to its parent CoordinateSystem, changing the pose of its parent in world coordinates causes the Shape’s coordinates in world coordinates to change as well. In this design, the primary method of moving Shapes in the world is by manipulating their parent CoordinateSystem.

Conceptually to store this relationship, each Shape has a data member, .parent, that points to a CoordinateSystem and each CoordinateSystem has a list of Shapes references that link to the Shapes which are attached to the CoordinateSystem. Partial implementation of the Shape class and the CoordinateSystem class are provided in the skeleton code.

Next, there is a CoordinateSystem-CoordinateSystem attachment relationship as well. When one CoordinateSystem is attached to another, one CoordinateSystem is called the parent and one CoordinateSystem is called the child. Similar to the Shape-CoordinateSystem attachment, the child CoordinateSystem’s coordinates, i.e. it’s pose, are measured relative to its parent CoordinateSystem. Any changes to the parent’s pose therefore changes its child’s pose as measured in world coordinates. A CoordinateSystem can have zero or multiple children and zero or one parent. If a CoordinateSystem has no parent, its pose is measured directly relative to world coordinates.

Figure 3: Example CoordinateSystem hierarchy. xxxCS are CoordinateSystem instances; the other names Shape objects. Arrows indicate attachment of CoordinateSystem or Shape to a CoordinateSystem.

Figure 3 illustrates an example coordinate system hierarchy that could be used for representing a solar system. Figure 4 is an associated geometric layout for some of the objects in this hierarchy. rootCS simply ties all the other objects into a common tree. Continuously incrementing xxxOrbitCS.orientation would cause the associated planet, xxx, and all its smaller sub-orbiting planets to orbit the parent planet.

Continuously incrementing xxxCS.orientation causes an individual planet to spin about its own axis. xxxCS.scale controls the size of exactly one planet (e.g. moonCS scales the Shape Moon). There should only be “non-one” scale factors (scale 􏰆 1) for the xxxCS objects. For all xxxOrbitCS objects the scale = 1. (Note, it is not helpful to have scale factors inheriting between parent-child CoordinateSystems in the design described above). Also observe that an xxxOrbitCS.origin should be coincident with the associated parent xxxCS.origin (e.g. moonOrbitCS.origin and earthCS.origin are assigned the same coordinates).

Figure 4: Example geometric layout of some of the objects from Figure 3. Note, the lengths of the basis vectors are not all drawn to scale. CoordinateSystem system names are abbreviated: eoCS=eathOrbitCS, eCS=earthCS,moCS=moonOrbitCS, mCS=moonCS, etc. Observe that eoCS has the same (coincident) origin as rootCS; likewise, moCS has the same origin as eCS.

In the lecture for ITCS_4120-OpenGL_Transforms.ppt, we discussed the design of pseudo-code for this assignment and did a code simulated trace of the how the data structure is recursively traversed. The skeleton code builds off of this design.

Grading Rubric

This project counts for a total of 100 points.

1. Git & Coding Style [10 pts]
a. Git commits: You should make at least one commit for each labeled sub-part below (i.e.

I.a, I.b, etc.).
b. Clear coding style: comments, indentation practice, etc.

2. Part I: Math Components [25 pt]
a. [12 pt] Implement all remaining Mat3 and Vec3 methods in Mat3.js. Also copy over

any of the Mat2 and Vec2 methods that you implemented in your own previous projects

into Mat2.js.
b. [13 pt] Implement all remaining Mat3Stack methods in Mat3Stack.js

i. Suggestion: After completing the above two items, enable the “test 2” code in function TestStack.prototype.render. If your completed Mat3Stack is working, the

code should draw the following:

3. Part II: Rendering [30 pt]
a. [10 pt] For CoordinateSystem implement the render method using the modelViewStack.

Also implement any other methods called in Test.js CoordinateSystem_test1() and CoordinateSystem_test2().
You must use the algorithm and design given in pseudo-code in ITCS_4120- OpenGL_Transforms.ppt and elaborated upon in this document above.

i. Suggestion:
To test your code first enable CoordinateSystem_test1(). You should see:

Further enable CoordinateSystem_test2(). You should see:

[...your project 1 stuff ...]

[…etc…]

[...the WebGL book code ...]

[…etc…]

2. Create a new remote repository on the Git server called “3120_P2_Planet_Mobile”. a. Remember to make your remote repository “Private” .
b. Remember to give the TA and Professor “Reporter” Access.

3. Now clone your remote repo:

4. Next, retrieve the skeleton code:
(The mechanics below are common git technique called ‘fork’ing).

▽

[... the above connects to the original 'upstream' remote,

to which you have read-only access ...]

6. Test the skeleton code in Chrome. It should display the following:

Academic Integrity

See the course syllabus regarding partial credit and the late penalty policy.
This is an individual student project. Each student should be writing and submitting their own code.

Students can discuss general aspects of the various API’s (WebGL, HTML5, etc) with each other and this is strongly encouraged. Discussing algorithm’s at the pseudo-code level is also acceptable.

However, it is not permissible:

to copy code from other students
copy code implementing entire functions or entire algorithms from “Internet” resources
to copy code from other students from prior semesters
translate an algorithm found on the Internet implemented in programming X and re-write it in language Y.