Come learn the art of 3D computer generated art and animation. This blog deals with the lessons learned and the art created by Robert G. Male using DazStudio from Daz3D.
Also covered are the ancillary software, tools, techniques, and processes needed both before and after rendering in the 3D software.
If you watch TV and happen to pay attention to the commercials, especially the "I'm a PC" ones then you have no doubt caught sight of the everyday application of a Microsoft product called Photosynth. Originally the program was shown off at Microsoft's Live Labs. It takes large numbers of photos of the same location showing little pieces of the place and merges them all together into a super-photo of not only massive size but also with the ability to zoom in and out. That application is still at Live Labs, with a plug-in download required. The software, and its results are pretty impressive. Certainly a person could open several large photos in Photoshop or Paintshop and patch them together by overlaying them. However it would be time consuming to say the least.
Right now a basic synthesising program is embedded in Windows Live Photo Gallery--not to be confused with Windows Photo Gallery, which is included in Vista. With it you can take several photos and stitch them together into one giant, but unzoomable, photo. The photos can be out of order, have minor differences in lighting and the camera angle can be somewhat higher or lower. You then select/highlight a number of photos that you have taken covering a broad area, even higher and lower as well as left to right and then right click. On the right-click menu there will be an option titled "Create panoramic photo..." Click it and the software begins to stitch the photos together. When it is done it asks for a filename and saves the file in the same folder as the separate photos.
Here are three examples that I have made to illustrate the stitching software. Though they have been scaled down for the Internet the largest of these samples is 7350 x 1700 at full size and nearly 10 MB. More about this next week.
Something is seriously amiss in my idea to use a human model and the accompanying easy to understand--or so it appeared--BVH movement file. As I had suggested using an offset to correct wobble was the key. The easiest place to affect such an offset is in the BVH file itself. I used the left foot, found it in the hierarchy, and set its offset channels to zero. Now my sphere rotates only along the y-axis. Next comes making the orbit circular around the star in the centre of star system. At zero y-rotation the plane upon which the planet sphere primitive sits is centred. As the y-rotation changes the distance the planet maintains from the star changes, making for a slightly elliptical orbit. Here is where it all falls apart. I thought to zero all offsets for the human figure.
Changing all of the BVH hierarchy offsets was a giant mistake. It makes the figure disappear and the objects parented to it as well. I panned the camera every which way, but could not find them. Selecting the figure shows zeros for the translations and rotations. Selecting the hip results in something odd. The rotation dials are zero, but each translation dial reads "nan". What is that supposed to mean? All other body parts report normal numbers. I instead set to zero only the hierarchy offsets for the left thigh, shin, foot (which was fine as the only thing zero) and toe, which results in a missing figure and parented objects, and the single trio of "nan" again. Unless it can be sorted out his invalidates the idea of using more than one body part for rotations.
As covered last time the BVH file is designed for the humanoid form. It provides a number of points of articulation such as... hip, thigh, shin, foot, toe; abdomen, chest, neck, head, eye; collar, shoulder, forearm, hand. This is a total of 23 parts. The parts have been grouped together above for a specific reason. Those body parts form a chain that share a rotation that is complimentary to the next body part, or link, in the chain. This will allow a figure to rotate several spheres using the BVH motion file, which allows for an easy method of defining every frame in the animation. With every frame defined there can be no errors in the in-betweening because there is none. A sphere is parented to a plane, which is parented to a body part. Complimentary rotations are used for all orbits.
To allow for complete orbits all of the body parts need to have their limits turned off. Next, there is one problem that needs to be solved, but should only require devising the solution once. The body parts are attached to each other in typical human fashion. That means they are not all at perfect 90-degree angles and follow the same single lines, and they have different offsets from each other. Zeroing the figure does not remove these differences. To make all of the orbits even requires determining rotations and translations off of the body part's centre lines. Figuring these numbers out appears to be a difficult task, as they virtually appear to change as the body part is rotated. At zero rotation the parented plane appears level but as the body part is rotated the plane shifts or wobbles.
This topic has come up before, but bears another look through more seasoned eyes, and of course input from anyone else who knows more than is appreciated. This topic is going to be at least two parts. DazStudio accepts motion files in the BVH format. BVH is short for Biovision Hierarchical Data, and was created by Biovision to do motion files for humanoid figures in animation. The file starts with the layout of the body with all of the connections between parts in, as can easily be guessed, an ordered hierarchy. Following the layout of the figure is the motion data for each part. Everything is human readable so it's not too difficult to understand what is what. The difficulty comes in that the motion is run in more than fifty-five columns of numbers.
Each frame of the animation has all of the data for the position of the figure and the rotation for each body part. The columns match up to the channels set for each body part in the hierarchy and follow its order. This makes the first three columns the X, Y, and Z position of the hips. It's an easy matter of zeroing one of the vectors of motion, say Z so that the figure walks in place. Y moves somewhat because the stride has high and low points for the hips, just as x does for side to side. This is all fine for figure motion. For objects though there seems to be limited options. A pose preset can be saved to file for each object. It includes its position and rotation throughout the animated range/timeline. It is saved as a Daz Script (.dsb extension), however this file is not human readable.
Today I am going back to the planet maps. I have created an example of some maps in use, which illustrate some issues dealing with the motion in creating celestial bodies. The video has been posted to YouTube and is titled "Far Off System". The first thing that should be pointed out is that the map for the star in this system is not the most convincing star surface. The reason for this was the complete lack of maps of our own sun, Sol. I made do with a map of Venus and altered the colours. To review quickly the motion is set up by the use of a number of invisible planes. In DazStudio all sphere primitives rotate from a point in the middle at the very edge of the bottom hemisphere. Planetary rotation is only possible moving along the Y-axis otherwise it orbits the bottom point.
The original Daz animation runs for one compete rotation of the large gaseous outer planet. I have then repeated as necessary so that planet makes a few revolutions. I cannot determine if the stutter between is a matter of Daz losing something or of the Movie Maker pausing. The rotation is complete from the starting position back to the exact same spot, it is exactly 0 to 360 for the plane. The other issue I am unsure of has to do with the moon of the second Earth-like planet. Does the moon make a proper rotation of the planet every time or does it slow in spots. This could be a matter of it being an optical illusion that makes it seem off slightly in spots. If it isn't only appearance, then something happened to the in-betweening because all rotations where correct at the key frames.