09/10/10
Progress on the demonstration has been put onto the back burner lately, with other projects due relatively soon.
I have been exploring existing 3D modeling packages as a reference in designing our project and taking notes.
The more I look, the more appropriate our decision to using multiple viewports seems.
In those packages which manipulate a 3D model in a single view, control of a point can become confusing.
Often in this case an object that is to be transformed will have arrows representing the X, Y and Z axis and manipulation is achieved by clicking and dragging an arrow to move by that particular axis.
This is something that we COULD implement, though I believe it would be easier to stick with the use of multiple views initially and extend functionality at a later point.
I shall keep this in mind while designing.
15/10/10
This week I discussed my thoughts on the contents of the technical manual with the other group members. Generally the document is very pleasing and I had little to add. We clarified a couple of the finer details and decided what needed to be addressed. We also discussed what content should be included in the project website.
While Tim and Allen develop the website, I shall continue to my demo.
18/10/10
I have been addressing the matter of accuracy versus data representation this week.
Jun's model represents smooth curves and given his method of implementation, is storage cost it relatively cheep.
The issue I am still unsure about could cause problems, though.
Both Jun and myself are taking a linear approach in drawing string. That is, we extend the string at an end and do not drag any points in the existing string afterwards. This is a rather unconventional way of tieing string and may confuse and annoy users.
To be realistic we need to include some sort of method to manipulate the string at any point and drag other nodes at the same time.
As I see it, we have two options:
1) Restrict the user to only be able to manipulate existing nodes.
* Jun's method strides on minimizing the number of nodes in the string and would limit the user significantly.
* My method would cause confusion, as links would appear in varying lengths, causing strange behaviour of the string.
2) Add an additional point in the link and manipulate geometry from there.
* If Jun can do this, great, but I am not entirely sure how it would work. Perhaps we allow string to "stretch" and eliminate the complexity added by moving other nodes?
* I believe this approach in my method would just be sloppy.
I have reconsidered my design and decided that I will return to an earlier suggestion: each link will be of set length X. In this way I can add a destination point to my string and calclulate how many links are needed to arrive at that point. I can add a variable to control how direct the path is from the existing string to the destination to create a curve-like path.
Advantages:
* Can control level of detail by specifying at the begining how long each link is. Shorter links = greater detail.
* Uniformity of links means it is easier for a user understand how manipulation of the existing string would work.
Disadvantages:
* Larger data sets are required to represent a string. Though, to be realistic, a saved string file containing floats should not exceed a couple of killobites.
* String reprosentation will not be as smooth as Jun's method.
There are a few concepts I shall discuss with the group relating to data compression and representation which are not easily explained in text format.
I shall continue to further this plan until our next meeting.
