Phil - First Entry

As I have neglected to upload my diary entries earlier, this entry shall serve to briefly cover some of topics and issues I addressed in the past few weeks of the project.

09/08/10 - In our first meeting with Luke we discussed possible objectives of the project as well as issues such as how we would go about representing knots mathematically and apply some sort of collision detection system to the digital rope we would be representing.
We settled on using the XNA framework to implement our program, as a game engine could be easily translated to suit our cause. XNA is also free, relatively simple to understand and has a large catalog of resources available.
Our approach to representing string was to use a series of nodes which highlight major pivoting points in the string and links which detail the curvature between one node and the next.

12/08/10 - In the next meeting I suggested that we present the string in 4 view ports, much like in 3D modelling packages, to give the user the best understanding and control of the string as possible. These views would include a top, side, front and a 3D perspective view.
I suggested that we use a physics engine to detect collisions.
We further discussed the advantages and disadvantages of various concepts previously suggested.

16/08/10 - In our meeting with Luke, Jun presented his findings from the weekend and explained how we could represent a curve from node A to node B with only a single handle, rather than the previous method which required 2 handles per node. This seemed like a nice, neat solution.
I further investigated the representation of a knot, attempting to view it in the most abstract light possible.
I suggested that though it may not be as efficient as dynamically allocating nodes along our string during runtime, it may be easier on ourselves if we had a set number of nodes and curves in a piece of string.
In this method, each link would be small enough that only a simple curve could be formed, not a loop or other geometry.

17/08/10 - I presented some examples of collision detection using the BEPU physics library.

23/08/10 - ???

27/08/10 - Jun presented an idea whereupon a set number of curves represented a rope. The curvature from one node to the next was calculated based upon the node's position in relation to its neighboring nodes. Sub-nodes would be generated and their position calculated on the fly. We would create many polygons on the fly and calculate their vertices based upon the sub-nodes generated earlier. We would break up sections of the rope into fields and only check for collisions between polygons from separate fields which had overlapped.
I am not entirely sure how the dynamic allocation and deallocation of nodes, polygons and physics entities would be possible or efficient. So many points being allocated and deallocated would take a toll on the garbage collection system of XNA, let alone then having to consider each of the collision detection calculations between each of the polygons and also weighting the vertices of polygons to nodes on the fly.
Another issue is whether we can add individual primitives to the physics engine or if they need to be part of a larger mesh. I believe these issues need to be explored further before decide if we shall take up this concept or not. I would rather pull apart an idea to the point where I look like a fool for asking such stupid questions than taking it up straight away, only to find an issue later that we had not considered.

I am currently tasked with looking for alternative solutions.
One key point we seem to be missing is how do we actually represent a knot?
We may be heading towards an overkill on this, listing point after point of geometry when we may only need to represent a few key points in a string. Are we overdoing it? Do we need to be as fancy and visually polished as we are aiming for? After all, we are making a program to simulate the knots, not developing a safety critical system whereupon every millimeter of precision counts. I will have to think about this some more.