Last Updated : Dec. 20, 1996
Canvas3D is a software still under development, and very far from perfection (like any other software)! However, still its quite close to its goals. During the implementation, we have noticed several improvements as well as changes that would improve the overall software. We list out all such things that we have in our mind.
Current implementation of the camera is tedious and requires use of matrices initially to set up the viewing frustum as well as the position/direction of the camera. This was done in order to get things working over the way Direct3D immediate-mode understands (see documentations on Direct3D Overviews chapter for projection, window and view matrices). We, Vincent Hammer and I, have tried to figure out the best use of these matrices. And implementation of this feature perfectly would bring the software to a very successful state, since camera plays a very important role in viewing all the other items created.
We want to remove the -proj, -world and -view matrices completely from the viewport options. Instead, the -frustum takes in a list of three values { angle frontCippingPlane BackClippingPlane } to create the projection matrix. The camera position and translation matrices are applied to the window matrix. The window matrix may be manipulated by the -viewpoint, -normal and -up options. The View Matrix role was not very clear when we last experimented, but we got good results by keeping it the identity matrix.
We noticed that we got good results with the -viewpoint and -up specifications, but -normal had a strange behaviour, i.e. changing the normal by 180 degrees actually showed the back of whatever we were currnetly seeing. A check needs to be made as follows (suggested by Vincent, and I too feel that this should work...) Check the directions by dot product between the normal vector and the vector formed by the viewpoint and center of the shape. If the directions are not same, then do not render the shape. This should work. We need to pass Viewport as a parameter in GE_RenderShape funtion to make this change.
A shape item may be transformed (shear, stretch, taper, etc.) by allowing the user to specify a matrix that can be applied upon the shape. Most of the graphics engine library support is ready, however, parsing functions in Tcl/Tk requires to be provided.
In order to add the above feature, we need to provide more options to Matrix so that such a transformation matrix can be easily created. -identity, -translate, -scale, -rotate, -inverse, etc. can be some of such options that can be added to matrix item.
The current implementation uses lists to maintain Canvas3D items. This basically means that when an item is to be passed within option of some other item, as in -surface, then we need a search over the list. A hash table is seen as a better choice for this. Since this feature widely effects different part of the source code, lots of care needs to be taken. Especially, all the items code, that does such parsing needs to be changed ( but they are not huge changes ).
This file has been originally used from tkCanvas.c of Tcl/Tk. Considering the earlier change, as well as several others, it would be great to rewrite and well-define the tkCanvas3d widget file. With the item options now very cleanly written, it is quite clear about the contents of this file.
Since current implementation does all calculations with respect to the origin, any changes in its structure brings back the shape from its transformed state back to the origin. This can be solved by using the `center' element in the item structure to create the shape again. This would maintain the center of the shape always. Also, if the shape is changed by the center, then change the other vertices with respect to the new center. The center will also play an important role in the camera changes as suggested earlier.
Current implementation does not change the texture coordinates with the change in wrap style. This shows some meaningless display of texture mapping for some selections of wrap styles. We can change the shape creation code to include consideration for different types of texture mapping for the shape based on the current wrap style.
This is relatively a very simple fix, that got just out of mind while implementing the mesh. Just as we specify vertices and edges in the list format, we need another option, say -texture to specify the texture coordinates for the different vertices. This also needs to add a function in the graphics engine library.
Current implementaion of Canvas3D requires to set the height and width of the Canvas3D initially. If changed later on, then it looses all data currently held in the Canvas3D. I have added code to release, and recapture all the lost data, but something is still missing. More investigations is required!
A funtion is provided to return back error string values for Canvas3D or Direct3D. Some changes need to be made to check the error conditions for different operations in the code and append these error strings using Tcl_AppendResult or Tcl_SetResult.
Current code uses the texture.c file, as provided alongwith Direct3D demo code, to read in ppm file formats as textures. A simple hack can be provided here to add support for different file formats as textures. See the function that reads in the header and data of a ppm file. Just before it reads the header, it tries to open the ppm file if available. Make a check here for different file formats and accordingly provide a swith statement to jump to the required code fragement added.
Ankit Patel (apatel@cs.cornell.edu)