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.
Wednesday, October 20, 2010
Friday, September 24, 2010
20/09/10 - 25/09/10
After the previous week's meeting, I had decided to work on developing a new prototype to demonstrate some of the techniques/concepts I had devised recently.
My new design incorporated ideas that had been discussed and discarded in the past, as well as several new concepts and a couple that were borrowed from discussions with Jun and Luke.
As I have started afresh, my demonstration was not finished in time for the Friday meeting, though I was able to show some new functionality (such as the use of multiple viewports, segragating and interacting viewports, etc).
Further work shall be focused on dynamically extending a string by adding “links” as well as modifying nodes along the string.
Friday, August 27, 2010
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.
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.
Subscribe to:
Comments (Atom)