This PA3 is due by the end of Thursday, October 20th, emailed as a jar, as in Assignments #1 and #2.
The basic idea:
You have already created a solar system with some planets and ray traced it, in Programming Assignment #2. In this new assignment, you are to use geometric transforms, 4x4 matrices, to move individual planets, moons, and the entire solar system allowing it to be ray traced as "viewed from above" and obliquely if you like. You will need to flesh out the transforms I've placed in these files. Do not confuse this assignment with a full dynamic simulation, because in our approach, moons are locked to planets and "swung around" when the planets are moved, rather than having their independent lunar revolution rates.The details
In doing this PA3, upgrade your previous PA2 system to improve it as needed, e.g., more extensive javadoc comments, carefully written Readme, and better data structures as needed, e.g., place your planets in a collection, not as separately named fields. See my email on this in the archive.
In the assignment above, you can wire together your transforms by hand. But a serious system for this type of task uses hierarchical transforms reflecting the hierarchical structure of your model. To do this, you store transforms at each level of your data structure - one for the entire solar system, ones for each planet stored within the planet instance, and one for each moon. When the solar system is transformed, it calls methods for each its children, passing each the solar system transform, each planet composes that (in the proper order!) with its own transform and passes that to its moons, each of which compose their transforms with the one received from its planet "parent". In each call to a child, the position of the point around which the child is to rotate needs to be passed. Besides passing and composing the transforms, it's important to realize when they are applied. There are many schemes to design and implement hierarchical and other complex graphics scenes. The one I've suggested here is fine for our problem and does treat the issue of centers of rotation explicitly.
To help understand the above discussion, start with all items in the model at their original positions. Then imagine what a moon receives: It receives a composition of transforms (in the correct order!) that will rotate it around the sun with its planet, and rotate it and translate it around an axis for viewing. The moon in addition, adds its own rotation around its planet. The rotation is around the planet's original position. This rotation, compounded with the other transforms it has been given, moves the moon to its final position. Then the planet is separately rotated around the sun's original position. The moon need not be transformed at this point because it is already in its final position. The compounding of the planet's rotation with the larger one passed to it moves the planet to its final position in the fully translated and rotated solar system. That is how compounding works. As usual, drawing some pictures of where things move and some hierarchies of objects and their transforms should help with all of this. It is also easier to understand this if you start with a simpler example in which only the moon is moved around its planet and the planet is moved around the origin, with no larger move of the solar system. The discussion in the book, pages 272-273 may be helpful.
Go to CSU540 home page. or RPF's Teaching Gateway or homepage