International Guild of Knot Tyers Forum

General => Knot-related Computing => Topic started by: DerekSmith on June 06, 2008, 11:32:58 PM

Title: Another Step Forward
Post by: DerekSmith on June 06, 2008, 11:32:58 PM
When I first came to the IGKT Website, I expected to find a complete database of all known rational knots and a means of filtering through them to find the knot which had piqued my interest.  I was disappointed that I did not find such a resource, but perhaps I should not have been dissappointed with the IGKT, because I could not find such a resource anywhere, perhaps because to date such a repository and locational tool probably did not exist.

As I thought about how you might search such a repository (when one eventually does exist) I was struck with the fact that knots are so three dimensionally complex, we would probably be stuck with having to find a person with the experience and mental caliber of  Budworth or Lehmanian proportions, send them the knot and beg their time to find its 'name' for you.  After a while it struck me that knots could be roughly categorised by making some measure of their complexity - how many times the cords crossed to make the knot.  My 'Overs Index' was born and quickly dashed with a "Read Budworth's 'Knots in Crime' - he did this years ago"  And sure enough, so he had - 120 knots categorised out across 24 groups based on the number of 'crossings' the knot exhibited when laid out flat and as simply as possible.

I started to build on Geoffrey's 120 knots but quickly came to realise that the 80 : 20 rule (or worse) was going to get to work here as most of the knots fell ever more often into certain popular 'pots'.  The Crossings count was a useful segregator but was no where near sensitive enough to be anything other than a crude segregation.

Further thought led me to realise that probably the next important distinction between knots was how 'complete' their crossings were.  The most 'complete' or as I came to think of it 'saturated' a knot could not possibly be more 'tangled'  - every over crossing was followed by an under crossing - they were fully saturated, but a pile of cord which might have the same number of crossings would effectively have zero saturation because as you pulled on the ends, nothing held on to anything else and the whole thing just unravelled.  This way two knots belonging to the 'Six' crossing pot say, the Reef and the Granny, could now be split into two sub groups, the Reef was 6:10 while the Granny was 6:12.  But it was still fairly poor.  Using this method the 20 knots in Budworth's V1 class could only be resolved into five sub classes and did only marginally better with the 19 knots in his VIII class which could be resolved into eight subclasses but we still had over half the knots in just two of those sub classes.

Allied to the limited ability of the Overs Index to be able to locate any particular knot was the almost universal call of 'It's just too complicated - the man in the street can't do it'.  So, although the Overs Index was potentially better than nothing, in reality it was a useless as nothing because virtually no one could count the crossings and the saturations....   and so it languished until FCB4 came into being.

If you have read the post, then you will be familar with Frank Brown's cypher method for exchanging a knot diagram and the little drawing program that has been written to allow knot diagrams to be easily drawn and recreated from their cypher files.  While writing the program, it struck me that it would be relatively straightforward to add in a function to count the crossings and work out the saturation - at least this would remove one of the hurdles to using the OI - just draw out your knot and the OI gets worked out for you -- handy.

As I worked on how to calculate the OI, I started by creating a 'picture' of the path of the cord by writing down a '1' if the cord went over and writing down a '0' when it went under.  From this pattern, the 'Crossings' was simply the number of 1's and the saturation was twice this number minus the number of consecutive events.  Taking the following diagram of the overhand knot, starting with the WP symbol, first the cord goes over (so a '1'), then under (so a '0')etc. its full sequence is 101010 giving an OI of 3:6

(http://knotcyphers.pbwiki.com/f/OH-FCBV3.jpg)

You have probably seen it already, but it took me a couple of days to realise that the sequence was just a binary number that reflects the passage of the cord through the knot - it IS the knot.  As nobody can remember binary numbers, I converted it to decimal and when I saw what 101010 was in decimal I new - sure as my name is not Zaphod Beedlebrock - that I was onto something significant.

THE BINARY SIGNATURE OF THE SIMPLEST KNOT - THE OVERHAND KNOT - IS     42    AKA THE ULTIMATE ANSWER TO THE ULTIMATE QUESTION !!!!

Naturally I immediately started looking at other knot diagrams and working out their binary signatures.  In the following diagram, the cord and the bent cord have no crossings and have a signature of zero.  Make a loop and it has a signature of 2.  Two piled loops has a signature of 56, but with an OI of 3:2 it is so unsaturated that it just falls to pieces a non knot.  But change one little crossing shown in green in the red diagram and the unsaturated pile turns to a fully saturated OH 3:6 with a signature of 42.

(http://knotcyphers.pbwiki.com/f/OH%20sequence.jpg)

I checked the 20 knots in Budworth's Group VI  Unfortunately eight of them were all fully saturated so they scored 101010101010 or 2730 in decimal, however the remainder were all different variations except for a small group - the Reef, Thief, Strap and Phoebe counting in at 2898.

By the time I had got up to the 19 knots in group VIII there were 17 discrete groups  --  almost complete seperation.

How easy is it to get this index number - well, if you have downloaded the FCB4 utility, then if you can draw out the diagram, you can either work it out by hand, or email me the cypher file and I will send the result back to you.  Alternatively, in a couple of weeks I should have managed to write the code to do the calculations automatically, and then it will be as simple as drawing the diagram.

Here is one I did earlier - the Sliding Grip Hitch  - OI 12:19  binary index  10,048,725

(http://knotcyphers.pbwiki.com/f/adjustable%20grip%20hitch.jpg)

Imagine one day, when the database is built, draw the diagram and the utility could link you to the wiki database and take you directly to the page that features the knot(s) with that binary signature.

"One day my son, meat will come in little boxes"  --  and  "one day you will just have to draw a knot to find out all about it"

Derek
Title: Re: Another Step Forward
Post by: squarerigger on June 07, 2008, 12:36:09 AM
Thanks Derek,

If not yet a conclusion, then at least a step along the path - great!  I loved the reference to Zaphod B - would that life were really that easy!  Incredible! ;D

SR
Title: Re: Another Step Forward
Post by: Dan_Lehman on June 08, 2008, 05:47:17 AM
I don't know about Beeblebrox (what was it Derek said?),
but let me take Marvin's position on this latest message about
the good ol' "OI Index":  Oh, no, not another one.   ::)

Lemme ask:  will topologically equal knots have the same OI Index?
Well, no, they can't or you'd have 0 for the TIB (tiable in-the bight) knots,
and that's no fun.

But this necessary flattening--taking to 2 dimensions--of knots still
strikes me as an arbitrariness likely to lose the entity's uniqueness.
E.g., I can manipulate (with some increasing reliability, now, at long
last after getting a clue or two) a "Fig.9" knot (the near-Stevedore)
into THREE forms, each able to survive in rope/cord to my heavy
loading (and, I'd think, to rupture--but I don't go there).  So, they are
certainly distinct and durable in this distinctness (useful?, you might
ask, wellllll ... ).  But I must wonder at how this OI-ing would treat them.
(#525 is one, and the near-Fig.8/Stevedore is another which should be
obvious to form; the 3rd form will take an artful sketch transmitted by me).

But, hey, so far we've not enlisted Godel numbers!

 :)
Title: Re: Another Step Forward
Post by: DerekSmith on June 08, 2008, 12:10:54 PM

Lemme ask:  will topologically equal knots have the same OI Index?
Well, no, they can't or you'd have 0 for the TIB (tiable in-the bight) knots,
and that's no fun.


Hi Dan,

My nickname is 'The Dot Counter' because of my fascination with the details of a problem - I think we may have found yours - 'Marvin' - because of your encyclopaedic knowledge of knots (and much much more).

So Marvin - what happens when we tie the simple OH knot in the bight?  The answer is quite inciteful.

First, the crossings goes up by the square of the number of cords, so 3 crossings become 12 crossings, but the saturation remains the same because it is the same knot, however it looses one degree because the bight causes the cord to make two consecutive unders (overs) as the cord leaves, then re-enters the knot so OI 12:11

(http://knotcyphers.pbwiki.com/f/OH%20in%20bight.jpg)

As for the Binary index.  Well, a three crossing knot is described by a six digit binary number, but a 12 crossing knot requires a 24 digit binary number to record its overs and unders which makes it a big number for such a little (simple) knot.. The BI for the OH in the bight is 110011001100001100110011 (trace it out for yourself)  --  in decimal notation that's 13419315.  It's a big number, (and for me unmemorable, particularly in contrast with the OH index of 42 which I shall probably remember long into senility).  But what does that matter, it's only an index and some of the URL's which we use to navigate the internet are hugely cumbersome, however, they work, especially when they remain largely within the internet (i.e. transparent(UK) to us).

So to the Marvinesque quip 'Oh No, not ANOTHER overs index' I would have to respond, No, not another OI, but a more detailed extraction of discrete information from the existing OI.  And that of course means that it is subject to all the criticisms quite rightly laid against the original versions of the OI and its precursor the Crossings Index.

In 'Knots and Crime', Budworth acknowledged "It is possible to be misled over the precise number of crossing points a knot has.  Try to arrive at the lowest possible number - extra and unnecessary ones can be created by accidental rearrangements of the knot, or simply by miscounting - but be prepared to search knot groups one or two crossing points more or less than the knot under consideration.".  You have also added to this the observation that one given diagram can be dressed into a number of final knot forms, all of which would be represented by the same diagram and therefore the same index.

This system is still flawed and far from perfect, but with today's tools we can to some large extent mitigate against those flaws.  For example - knowing that a knot can be 'laid out' in three popular configurations, the BI's of all three can be pointed to the same knot information page - much the way that a website owner will point  a number of similar url's at their website to help folks who have mistyped the url or search phrase.

To do this though, the project will need the skills of someone like yourself to identify the probable variants needed for inclusion.

I believe the world of knotting needs a Library and simple indexing system and that the Wiki in conjunction with the OI and the BI offer an imperfect route to create this.  I also believe that these tools are all we are likely to have access to until technology brings forth a 3D camera able to look inside a knot to reveal its dressed structure alongside 3D graphical search technology.  I look forward to the day that technology arrives, but until then I hope we can organise our world and learn a lot using the simplistic tools of two and a half dimensional diagrams, the OI and the BI to help us make the call -

'I'll name that knot in one'.

However, even with these tools, it is still a job requiring a team effort to pull it off, and for that, as Geoffrey indicated, the Guild members are perfect candidates.

We have 'The dot counter' to help create the tools.
We might have 'Marvin' to map out the obstacles.
We are still going to need a 'Co-ordinator', a 'Librarian' and numerous 'Draftsmen'.

Anyone tempted?

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on June 27, 2008, 06:01:41 PM
 
When I first came to the IGKT Website, I expected to find a complete database of all known rational knots and a means of filtering through them to find the knot which had piqued my interest.

Here's another idea for filtering through knots, which might be intuitive for most people.

Imagine a "Knot Finder" website with several high-level categories, such as:

   Fixed Loops (with a representative image, e.g. Bowline and/or Spanish Bowline)
   Hitches (with a representative image, e.g. Clove Hitch and/or Two Half Hitches)
   Bends (with a representative image)
   (etc.)
 
The user can click on the "Fixed Loops" category (for example) to drill down to the subcategories, such as:

   End-Line (with a representative image)
   Mid-Line (with a representative image)

Then the user clicks the "End-Line" category (for example) to drill down to the subcategories, such as:

   Single Loops (with a representative image)
   Double Loops (with a representative image)
   Multi Loops (with a representative image)

Say the user clicks the "Single Loops" category.  Perhaps there might be subcategories such as:

   Bowlines (with a representative image)
   Other (with a representative image)

If the user clicks the "Other" category (for example), this will bring up a page with a list of non-Bowline single-loop end-line knots, with a picture of each knot (similar to http://www.layhands.com/Knots/Knots_KnotsIndex.htm#SingleLoops (http://www.layhands.com/Knots/Knots_KnotsIndex.htm#SingleLoops)).  Clicking the Figure-Eight picture (for example) will bring up a page with information about the knot, such as front views and back views and exploded views of the knot, explanations of how to tie it (and its variations), various names for the knot, the pro's and con's of the knot for various applications, the Overs Index information, and so on.

One of the benefits of this approach is that people without a stitch of knot-knowledge can compare the pictures in the Knot Finder with the knot that they're holding in their hand, and be able to find out about the knot.  Another benefit is its simplicity, making it easy to develop.

Instead of a numeric value for indexing the knot (or in addition to a numeric value), an indexing value can be derived from the knot's "path," such as: Loop-End-Single-Other-FigureEight, for example.

That's the bare-bones germ of an idea, in case it seems to have potential.

Dave
Title: Re: Another Step Forward
Post by: squarerigger on June 28, 2008, 02:27:53 AM
Brilliant!  And ideally suited to a forum like this one.  Now, who can get it started and is there enough space....

SR
Title: Re: Another Step Forward
Post by: DerekSmith on June 28, 2008, 10:25:00 AM
Hi Dave,

So good to hear from you again after so long.  I hope you and your family are well.

I agree totally with your suggestion, because the problem will not, I believe, be solved by one technique alone.  To achieve this goal, we will almost certainly have to utilise some sort of amalgam of techniques.

Tell me though, do you think your proposed approach might be amenable to a decision tree style of approach?

Is the knot tied to something?         If it is branch to the hitches and continue with questions and diagrams to further classify.
Is the knot tied with two cords?      If it is branch to the bends etc.
Is it tied in the middle of a cord?      etc.
Does it have a loop or loops?           etc.

If you can think up the questions and the structure of the decision tree, then we could easily build a prototype into the wiki pages.

Fancy giving it a try?

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on June 28, 2008, 04:38:34 PM
Dan's concerns about topology and the fact that the deformation of a knot needed to 'lay it out' in readiness for diagramming making it into a different knot.

Taking those concerns and then taking another step forward.

Budworth with the Crossings Index, and then latterly Root and Smith with the Overs Index, all extolled the importance of reducing a knot to its simplest (i.e. least crossings) form in order to establish some uniformity in counting the crossings.  Others, including Dan, warned that this process destroyed the structural elements of a knot deemed necessary to be created during the knot dressing.

Naturally, Dan is right, and I must now conclude that the 'Rationalisation' of the knot was WRONG.  And, as it turns out, it was also totally unnecessary.

I was recently proof reading the PACI 'Knot Study Guide'  When I was reminded yet again of the importance of the correct dressing structure for the Fig. 8 loop knot (I don't know how many times I need reminding of something before it finally gels into an 'Oh YES' moment - but this was one of them.)

Up until now, the Fig 8 loopknot has been depicted like this ;

(http://knotcyphers.pbwiki.com/f/Simplified%20Fig%208%20Loopknot.jpg)

With an Overs Index of 16:15 --  BUT  - it is NOT the Fig 8 loopknot used in climbing applications.

So, I loosened slightly the correctly dressed Fig 8 Loop Knot, sufficiently to see the path of the cords but keeping exactly the dressed structure and drew it out again.

(http://knotcyphers.pbwiki.com/f/FIG%208%20Loopknot%20dressed%20version.jpg)

Now it is a much more complex knot -- OI 20:15, yet almost intuitively, we can see that it is a more truethful representation of the real knot.  If we tied this structure, all we would have to do would be to draw it up to make the final knot, keeping all the cords in the same relative positions to create the correctly dressed Fig 8 loopknot.

Now when you click through to the Library page it goes straight to details of the correctly dressed Fig 8 loop knot.

You might have noticed the word 'Find' in the above image, just after the long Binary Signature string.  The FCB program now allows you to draw the diagram, then click 'Find' and if a page with the same Binary Signature exists in the Knot Library Wiki, it is loaded immediately for you in order to be able to compare its details with the knot you have tried to find.

The program is not quite ready for release because it only works with single cord knots at the moment and will have to be able to cope with two cord knots before it is ready for use.

But essentially, here we have it  -- See it, draw it, click it, go straight to its library page.



"One day, meat will come in little boxes"

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on June 30, 2008, 06:01:33 PM
So good to hear from you again after so long.  I hope you and your family are well.

Thanks, we're doing well!


Tell me though, do you think your proposed approach might be amenable to a decision tree style of approach?

Is the knot tied to something?         If it is branch to the hitches and continue with questions and diagrams to further classify.
Is the knot tied with two cords?      If it is branch to the bends etc.
Is it tied in the middle of a cord?      etc.
Does it have a loop or loops?           etc.

If you can think up the questions and the structure of the decision tree, then we could easily build a prototype into the wiki pages.

When I visit the support pages of various businesses, some of them ask questions in order to "help" me narrow down my search (e.g. http://support.skype.com/?_a=knowledgebase (http://support.skype.com/?_a=knowledgebase)).  However, I find that it takes some thought to read through the questions and determine which one fits my needs.

In contrast, if we have just a few top-level categories (Loops, Hitches, Bends, etc.) with some well-chosen pictures next to each category (e.g. showing a Clove Hitch and a Two Half Hitches, which are different ways of tying to an object), then the Knot Finder page is likely to be cleaner and easier to navigate.  That would be my preference, but others might prefer the questions approach b/c some people are more visual or more auditory, etc.

Maybe someone can put together a few prototypes with different navigation schemes so that we can test out the look and feel of different approaches.

Dave


Title: Re: Another Step Forward
Post by: DerekSmith on July 15, 2008, 01:51:50 PM
Well, it has been a slog, but now version 4.2 is available for download from here.

https://knotcyphers.pbwiki.com/The+FCB+Cypher (https://knotcyphers.pbwiki.com/The+FCB+Cypher)

It calculates the OI and the binary Signatures for both one cord and two cord knots.

There is just one requirement and that is the cord depicted in cord #1 MUST have a working end in order to trigger the OI and the Binary Sig functions.  This means that knots TIB must be assigned a temporary WE in order to have the utility calculate the signatures.

So please give it a try.  Download it, it does not need to be installed it does not register itself into your registry and it does not load any dll's which could interfere with other programs on your PC.  Just download it and double click the icon to run it.

You can use it to diagram out knots and having created a diagram, just click on the 'Find' button to go straight to The Knot Library to see if a page exists yet for the diagram you have created.  If it has not been entered into the library yet, then please save the diagram and post the .cyp file on this forum so that other members can look at the knot and so that it can be recorded into the Library.

Your comments on the utility would be most appreciated.

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on July 15, 2008, 08:27:57 PM
Derek,

Nice utility for drawing knots!  Making a knot diagram was quick and simple....the hardest part was laying out my rope so that the knot only consisted of orthogonal lines!  ;D

I have been playing with the Grapple Hitch, so I used it as my test case with FCB4.  I used different colors in different sections of the knot in order to help visualize the knot, and I made two different diagrams to visualize the knot in different ways (I decided that I wanted to keep the Standing Part straight, which is why I made a second diagram).  Here's the file contents:

-----------------------------
FCB Version 4.x


0:0
 daj lae maj dbf mbf dcf mcf ddh mdh dek fej ffh mfh dgi egg fgl mgh dio mio
 cai kai cbr kbr ccf kcf cdh kdh cef eeh kef lei meg nel cgf kgf lgk ngj chk dhg ehl khk lhe mhg nhl
 bdi edj jdi lde ndj bef jef bfk cfg dfe efg gfa jfk kfg lfg nfa
10
0
-----------------------------


Some thoughts for future releases:

1. It would be helpful if the active tile in the pallet is highlighted.

2. An Undo feature would be handy.

3. At first I didn't see how to delete a tile in the drawing area.  Maybe a blank pallet tile (or a right-click menu with a Delete option) would be more intuitive.

4. It would be very helpful to be able to highlight one or more tiles in the drawing area (e.g. CTRL+click) and move them left/right/up/down in order to make more room!

5. When we can highlight multiple tiles in the drawing area, it would be nice to have the ability to Copy/Paste those tiles in another place, especially if we can then rotate them or mirror-image them.

6. Instead of placing the cursor in the "Draw cord #2" text box to change colors, it would be more intuitive to have something like radio buttons ("Blue", "Red", "Black," etc.) for changing colors.

7. For me, the dotted-line tiles make it easy to visualize that the rope is behind a spar.  Similarly, I suspect that dotted-line tiles would make it easy to visualize that the rope is behind another section of rope.  The current "crossing" tiles cause me to do some extra mental processing since they look different than the "spar crossing" tiles.

8. Sometimes it might be useful if multiple vertical spars (or multiple horizontal spars) can be placed in the drawing area.

9. File/New should remove all of the spars in the drawing area.

10. When we close the application, it would nice to be prompted if we have made some modifications which we haven't yet saved.

11. It would be useful to be able to write comments in the drawing area (and be able to draw an arrow from a comment to the particular section of the knot).

12. To help make the knots easier to visualize in FCB, what if you use actual photographs of rope for your pallet tiles instead of line drawings?!  ;D


Again, nice work!

Dave
 
Title: Re: Another Step Forward
Post by: DaveRoot on July 15, 2008, 09:14:18 PM
I wonder if any of these "3D rotating cube" applets can be tweaked to make 3D rotating knots?   8)

http://www.google.com/search?q=3d+rotating+cube&hl=en&sa=2 (http://www.google.com/search?q=3d+rotating+cube&hl=en&sa=2)

Dave
Title: Re: Another Step Forward
Post by: Snowman on July 16, 2008, 05:25:03 AM
Derek:

Your program appears to work well under Linux (using Wine).

Regards,
Snowman
Title: Re: Another Step Forward
Post by: DerekSmith on July 16, 2008, 03:03:44 PM
Hi Dave,

Thank you for such a thorough review of the utility and for such an excellent list of 'ToDo's'.  A couple - the highlight, copy paste and drag/drop ideas were already on the ToDo list, I just don't know how to do them yet (very much a case of learning as I go).

No.9 - remove old spars when New is initiated is a bug - well spotted.  I have corrected the fault straight away.

The other ideas are all excellent and will go into the ToDo list for action.  Do you have any preference for order? i.e. if you could have one but none of the others which would it be sort of approach.

Re No. 12 - photo's instead of drawings.  'A long time ago' (seems like it at least) when the utility was very much at the stage of trying to make a cheap (i.e. FREE) alternative to Frank Browns use of a top end CAD program to make diagrams, I started by using literally small .gif images of segments of cords.  Although it was simple enough, it consumed large amounts of memory and meant that there was no way of progressing to multi cord diagrams without the need for an army of image tiles, so I dropped the image route and moved to representing the cords by lines.  There are advantage to be had by using the lines approach that have not been developed yet but which are very much on the books for future development.

The first of these is that by using line drawings for the cord we can make the thickness of the cord change, so we can 'bulk up' the cord to better 'see' the knot.  Further in the future, there is the opportunity of making the cord displace itself as it is made thicker, so the knot effectively 'dresses' itself, then we can reduce down the cord thickness again to allow us to see into the structure of the dressed knot.  This of course will be when we are dealing with 3D diagrams and are no longer limited to the restrictive four faces of the square that we are constrained within by today's version of FCB.  I have on the drawing board for version five the outline for using the cube instead of the square, the cube will  give us direct access to 3D, albeit still very restricted to the simplistic 'any direction so long as it is at right angles' type of approach.

Also, it was the move to a line diagram that led me to the perception of how to establish the essence of the 'path' of the cord through the knot and from that the ability to create the algorithms for the Binary Signature and the Overs Index.  Again, by retaining the cord as a line concept, we are also allowing ourselves access in the future to 3D generation of the knot image with full rendering of the cord surface texture and curvature.  this is way beyond my abilities today, but hopefully we will be able to attract someone with 3D skill to the project if it ever gains sufficient credibility.

The other nice potential of staying with a 'line based model' is that we can potentially drop the tile pallet all together and simply click through from face to face and have the utility 'join the dots' for us.  Again, this is on the drawing board for version 5.

Strangely enough, I am beginning to find that the restriction of drawing out knots in this two dimensional manner is actually able to bring insight to various structures.  For example, in your two diagrams for the Grapple Hitch, in one the SP is kept straight, and in the other it is displaced out to the side.  These diagrams each represent two forms of the grapple.  One which is little more than a noose and the other which indeed has the ability to hold under load.

I have put the grapple page into the Library now, so if you click the Find button you should go to its page (which needs detail adding to it).

By the way, did you find that if you right click anywhere on the drawing grid, the tile and the cord are copied and can then be used to paint new tiles and this includes the blank tile which can be used for erase?  Also, that the Overs Index and Bin Sig only compute when a working end has been assigned to cord #1?

Thanks for the feedback, without it, this project would be poorer.

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on July 16, 2008, 06:56:48 PM
By the way, did you find that if you right click anywhere on the drawing grid, the tile and the cord are copied and can then be used to paint new tiles and this includes the blank tile which can be used for erase?

I didn't notice the right-click functionality.  It's handy, so my "blank tile" idea is not urgent (or not needed).  But for first-time users it's not the most intuitive feature.  What if you add a status bar at the bottom of the screen?  When the mouse is in the drawing area then you could place a message in the status bar such as "Right-click to copy a tile."  When the mouse is in the pallet area then you could place a message in the status bar such as "Left-click to select a tile."

By the way, does FCB need a screen resolution greater than 1024x768?  Looks like part of the FCB window is cut off (e.g. the "Fin..." button at the bottom right is cut off).

   
Also, that the Overs Index and Bin Sig only compute when a working end has been assigned to cord #1?

I saw this in the Help file, but in my case I wanted to use different colors for different sections of a single cord.  Since I created two diagrams, I'm assuming that the Overs Index and Bin Sig were not accurate, is that correct?


Updates on my suggestions:

1. It would be helpful if the active tile in the pallet is highlighted.

   Nice to have, but not urgent.  Makes FCB a bit more intuitive for first-time users.

2. An Undo feature would be handy.

   Nice to have, but not urgent.

3. At first I didn't see how to delete a tile in the drawing area.  Maybe a blank pallet tile (or a right-click menu with a Delete option) would be more intuitive.

   This is addressed in my comments above.
   
4. It would be very helpful to be able to highlight one or more tiles in the drawing area (e.g. CTRL+click) and move them left/right/up/down in order to make more room!

   This would be my #2 choice.  If you find a way to highlight multiple tiles then perhaps a set of up/down/left/right buttons can be used for moving those tiles.  The right-click functionality is useful when trying to move tiles, but it's easy to introduce errors into the diagram this way.

5. When we can highlight multiple tiles in the drawing area, it would be nice to have the ability to Copy/Paste those tiles in another place, especially if we can then rotate them or mirror-image them.

   This would be my #3 choice.

6. Instead of placing the cursor in the "Draw cord #2" text box to change colors, it would be more intuitive to have something like radio buttons ("Blue", "Red", "Black," etc.) for changing colors.

   Nice to have, but not urgent.

7. For me, the dotted-line tiles make it easy to visualize that the rope is behind a spar.  Similarly, I suspect that dotted-line tiles would make it easy to visualize that the rope is behind another section of rope.  The current "crossing" tiles cause me to do some extra mental processing since they look different than the "spar crossing" tiles.

   This would be my #1 choice.  I'd like to see this in order to compare it with the current implementation of the "rope crossing" tiles.  This will bring consistency between the "spar crossing" tiles and the "rope crossing" tiles, and I think it will be visually clearer than the current implementation of the "rope crossing" tiles.

8. Sometimes it might be useful if multiple vertical spars (or multiple horizontal spars) can be placed in the drawing area.

   Not urgent.

9. File/New should remove all of the spars in the drawing area.

   You've already addressed this.

10. When we close the application, it would nice to be prompted if we have made some modifications which we haven't yet saved.

   Not urgent.

11. It would be useful to be able to write comments in the drawing area (and be able to draw an arrow from a comment to the particular section of the knot).

   Not urgent.

12. To help make the knots easier to visualize in FCB, what if you use actual photographs of rope for your pallet tiles instead of line drawings?!  

   You've already addressed this with some interesting points in favor of line drawings.

13. Would it be possible to make the drawing area essentially an "infinite plane" with scroll bars?

   This would be my #4 choice.

14. Would it be possible to allow zooming in/out in the drawing area?  I.e. the ability to make the grid squares larger or smaller.  This way we can "zoom out" to get a bird's eye view of the knot, or "zoom in" to see the details of a section of the knot.

   Not urgent.

15. How about the ability to rotate a diagram (or a section of a diagram)?  For example, I might draw a loop knot with the loop at the top, and then decide that I want the loop at the bottom.

   Not urgent.

   
Dave
Title: Re: Another Step Forward
Post by: DaveRoot on July 16, 2008, 07:10:41 PM
Here's a thought!  Consider tweaking FCB so that a variety of games can be played with it!

For example, display a photo of a knot and the player tries to diagram the knot in the shortest time.  On the "easy" level you could display a photo of a knot as well as a diagram of the knot, and the player tries to find and fix the errors in the diagram.

If you can get some basic animation to work, you could show an ant crawling along the rope in a diagram of a knot.  The diagram contains a number of erroneous crossings, and the player tries to fix the crossings before the ant reaches them so that the ant follows an unbroken path from start to finish.

Might stimulate some interest in knotting for the kiddos!

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on July 18, 2008, 04:47:10 PM
FYI - Some interesting 3D photo technologies on the way!

http://make3d.stanford.edu/ (http://make3d.stanford.edu/)

http://mobile-stuffed.blogspot.com/2008/02/stanford-camera-chip-can-see-in-3d.html (http://mobile-stuffed.blogspot.com/2008/02/stanford-camera-chip-can-see-in-3d.html)

Dave
Title: Re: Another Step Forward
Post by: SS369 on July 19, 2008, 12:56:59 PM
Adding an "Undo" function would be a delightful boon to me, since I am impatient and subject to impetuous button pushing.
Once that is added to the program I will use is a bit more often.
S
Title: Re: Another Step Forward
Post by: DerekSmith on July 25, 2008, 04:17:37 PM
Well, there is a new 'kid' on the block and his wonderful KnotTyer3D program has blown away FCB42.

It includes an ultra simple click to draw utility, creates a small text based KT3 file for transfer, but most importantly, it renders the knot in 3D and even shows the knot 'growing' and then you can spin the knot around to view it from any perspective, above, below, end on etc etc.

This is an amazing little utility, it's free and if you have Win 2000 or XP then it is a very small download that runs without any need for messy 'Installation'.

Get the program and a load of sample diagrams here http://www.abbott.demon.co.uk/knottyer3d.html (http://www.abbott.demon.co.uk/knottyer3d.html)

From nothing to two programs and 3D animation in just a few short months - amazing.

Derek
Title: Re: Another Step Forward
Post by: TheTreeSpyder on August 10, 2008, 02:37:54 PM
i applaud all of your efforts and force thrown forwards.

The 3d effect in these 2dimensions has all ways been tough.  Especially the amount of times a line has to change depth and proving it by wrapping around, through other lines in a knot lacing, then hold and not move (where the eye can really take scrutiny).  i also think until Flash etc. comes up with a vectorized real time 3d, the file sizes will be large (and thus slow download speed).  But, then vectorized, gives computer commands, not pictures, so it is more cpu intensive/draining on resources in trade for the small filesize (of commands) that give the lower download speeds.  So, this all depends on the end user, and what their strengths are (cpu and or connection speed) in ratio to demands of the particular strategy.  Real time 3d has a lot steeper l-earning curve too IMLHO.  Thus, presently i think the 2 dimensions faked to 3 with masking and shading is presently

As far as categorizing; i think it should be a front of the shop/ back of the shop type.   In an electronics shop, the sorting for the customer sales and use, might not be the same as the back of the shop.   A rope to me, is like a conducting device; like a wire is to electricity.  The conducting device, carries the force if there is the equal and opposite calling it on the other end.   A front of the shop, might have a more external, end user sorting.  But the back of the shop, might sort stuff apart in components, or how those components lace together. They might know stuff down to the resistor, and how each resistor can take such a load and have such an effect to train and focus power to their bidding.   Also, how this component can be bound with others.  i think if you look at knots to understand them, you should do so into families by their properties and base components, like a periodic table, just to begin.  Then, also; this would bear out families suited to different things, or component strategies that are added to other knot base configurations to alter, add to, or just be named different.  The proper categorizing is important to get those borders in head, to then share observations of one amongst like types; thereby increasing all observations assigned for each; and making each observation more worthy to be taken.  Then, keep taking this knwledge to higher levels as it is unwrapped and digested, rinse and repeat as necessary.  As we have done with all else we take seriously in the sciences.  For, to me; this is science, with sines, cosines, frictions, efficiencies, deformations etc.; only the conducted force through the rope pipeline is in this case mechanical; just not the more familiar animations to see of electrical, water, pneumatic nor hydraulic conducted forces.  For force, is the only thing that can cause something to move, or stop something from moving.  And once ya know the ropes, they certainly do that!
Title: Re: Another Step Forward
Post by: DerekSmith on August 10, 2008, 06:31:04 PM
Charles Hamel recently challenged me to draw out this knot using the diagramming tool.
(http://knotcyphers.pbwiki.com/f/MOEBIUS%20TH.jpg)

It took about ten minutes and of course, it is not as pretty as the hand crafted version, but here is the result:-

(http://knotcyphers.pbwiki.com/f/MS%20TH.jpg)

It has the impressive signature of 100110101010111100101010101110101010101000110010101000

If you load the attached cypher file into FCB utility and click Find, it will use the signature to take you right to the library webpage featuring the knot here http://theknotlibrary.wikidot.com/100110101010111100101010101110101010101000110010101000 (http://theknotlibrary.wikidot.com/100110101010111100101010101110101010101000110010101000)

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on August 10, 2008, 07:11:06 PM
Hi KC,

I very much agree with your line of thinking.

In conversation with Charles Hamel, I have been trying to find ways of identifying a knot by its components.  The FCB utility has been useful in helping to visualise these aspects.  Take for example the simple Overhand Knot, normally depicted with the signature 101010 as in the side view shown here

(http://knotcyphers.pbwiki.com/f/OH%20Knot%20perspective.jpg)

But as you will see, in the plan view, it has a totally different signature 10011001 and in the 'end on' view it simply has the signature of 10.

Clearly the signature method is severely restricted to describing a knot from one perspective only and this is meaningless when in reality a knot exists in all perspectives at once.

Moving on from this, I have been experimenting with describing a knot as a number of components.

The principle component for the OH is the primary 'S' laid wrap of the two loaded lines which make a complete turn around one another.  Then each line makes a half turn and performs a single line 'Z' wrap over the the double line 'S' wrap section.

This is a better description of structure, yet it still totally fails to formulate the flows of forces within the knot when it goes to work.

I am intuitively led to believe that some marriage of force vectors based upon the the 'S' and 'Z' and turns structures will be where we eventually have to be able to describe, before we are indeed describing the essence of the knot itself.

My head hurts !!

Derek
Title: Re: Another Step Forward
Post by: TheTreeSpyder on August 10, 2008, 11:02:19 PM
i think we must see the curves as if pulley mounts; just with extra frictions.  Then we should speak in as you say a round turn around itself / another leg of line.  Then assess that the round turn would have 2 or 3 pulley bends at such and such a deflection.  Then assess; if this round turn would meet it's mount at a perpendicular angle (turns close together) or an inline angle (turns spread apart, longer distance for same amount of turns) like a splice, or yet even some mixture there of.  Then moderate for gradients in between.  Like by so much influence of each, like a sine/cosine scaling (for so much perpendicular and inline force together for total force potential at a given angle) to make up the whole assessed forces.

Then we have to look at the initiating force(s) and their directions, to then assess what direction the pulls are in these systems.  For example, if we have a U shape turn around a straight line at near a perpendicular angle.  It makes a difference if the force is coming in to the U shape and bending the straight line, or if the straight line is leaning back into the U in my mind.  Also, on which side of the friction buffer is higher tension, etc.  Thus, once again, just a microcosm of a larger rigging system with pulleys etc.; with some of the friction values etc. changed.  The same mechanics as all else, for under the same forces and the same math, on the same planet..

 

Title: Re: Another Step Forward
Post by: DaveRoot on January 08, 2009, 04:11:28 AM
7. For me, the dotted-line tiles make it easy to visualize that the rope is behind a spar.  Similarly, I suspect that dotted-line tiles would make it easy to visualize that the rope is behind another section of rope.  The current "crossing" tiles cause me to do some extra mental processing since they look different than the "spar crossing" tiles.

   This would be my #1 choice.  I'd like to see this in order to compare it with the current implementation of the "rope crossing" tiles.  This will bring consistency between the "spar crossing" tiles and the "rope crossing" tiles, and I think it will be visually clearer than the current implementation of the "rope crossing" tiles.

Derek,

Are you still making enhancements to the FCB utility?  If so, would it be difficult to add an option which will read in the pallet tiles from separate BMP files (instead of only being able to use the pallet tiles which are built into FCB)?

This would allow people to make their own BMP files (of the appropriate size) containing various sections of cord for building diagrams.  I have a few ideas to try out, but didn't want to re-build the wheel in .Net!   :D

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 08, 2009, 10:42:48 AM
Hi Dave,

There seemed to be no interest in the utility, so although I use it myself, I stopped flogging the proverbial 'dead horse', especially as I think the next enhancements would have to be moving to 3D.  Then we had the recent release of two excellent 3D initiatives which I had hoped would take over the baton (albeit that they were lacking in structural identity analysis and library lookup functions).  Sadly, neither seems to be getting any more attention.

Re your enquiry for the option to utilise customised tiles and import a 'user bmp set'.  When I first wrote the utility, back at issue 1, I used the system whereby the selected bmp image was pasted onto the working grid, and had I stayed with that system, then indeed it would have been very easy to add the feature of using any user edited bmp set.  But very early on, Frank wanted the use of coloured cords to differentiate between two cord systems.  At that point, I completely rewrote the utility so that now it draws the lines instead of painting in a gif.  This gave me the option of being able to adapt the colour of the crossings to reflect the individual cord above or behind.  To have achieved this with bmp tiles I would have had to have made available six alternative colour combinations just for three cord colours and it would have made changing cord colours and thickness very hard to adopt in later revisions.

The gif tile panel now is simply a link to a descriptor set which defines entry and exit faces and calls the line draw routine to create that diagram wherever the paint mouse is clicked, plus a little bit of additional logic which looks at adjacent cells to identify a face entry from a cord of a different colour, then paint the over/under lines in the appropriate colours.  You may have noticed that the displayed shape does not exactly match the gif tile image, this is why.   At the moment, all these are hard coded, and to enable user modification, I would probably have to start off with producing a tile creator utility which allowed the user to create a pallet gif and drawing rule set for inclusion in a custom pallet, then mod the FCB utility to utilise a custom pallet instead of a hard coded pallet.  It would actually be easier to customise the code to match new gif tiles you develop.

Are you programming in Delphi?  I understand that Delphi has a .Net 'flavour'.

It would be good to have someone else involved in developing the utility, either in collaboration or even totally independently.  It is valuable to have someone to discuss options with when developing a new function.  Actually, I think there is considerable merit in rebuilding the wheel, in fact the next version of FCB will be a total rewrite based on utilising the lessons I have learnt from the work so far and the sort of functionality I need from a tool like this.  My first step would be to move from a simple flat cell matrix to a vector diagram model, because in truth, there are no such things as 'crossings', these are simply visualisations dependant upon viewing perspective.  Strangely, I have learnt a lot about knots since I started to develop this utility.  If you can spare the time, I would certainly recommend the journey to create your own flavour of 'wheel' and should you want company on the trip, you can count me in.

Let me know which way you would like to proceed.

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 08, 2009, 06:48:25 PM
I use VB.Net at work, but I've never used Delphi.

I like how "clean-looking" the FCB diagrams are, but I don't find the crossings to be as easy to visualize as they are in a picture of a knot tied in rope.  In order to test out a different way to draw the lines, I used MS Paint to create 4 BMP files, then I simply copied and pasted them into Paint (rotating as necessary).  It wasn't as convenient and quick as using FCB, but it got the job done for my test case.

Here is a diagram of a Bowline which I did in FCB, plus another diagram which uses a different approach for drawing the lines.  To me, this new approach makes it easier and quicker to visualize the crossings.  In the third diagram I just wanted to see how the new idea would look with colors.

This line-drawing approach would require a few more "Line" commands than your current approach does, but it should be do-able without needing a "user bmp set."

Anyway, just another idea to toss into the mix!

Dave

Title: Re: Another Step Forward
Post by: DerekSmith on January 09, 2009, 01:25:59 AM
Dave,

Such a small change but such an amazing improvement, and relatively easy to implement into the present utility.  I will implement it and let you have the mod to play with and give me your feedback.

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 09, 2009, 03:19:18 PM
Hi Dave,

Mod made as follows

(http://knotbox1.pbwiki.com/f/HH%20%20on%20a%20Bight.jpg)

I tried to email you the file but it bounced straight back, I guess because it is an exe file, so if you would like a play you can download it from here http://knotbox1.pbwiki.com/Dave-Root-FCB-Mod (http://knotbox1.pbwiki.com/Dave-Root-FCB-Mod)

I have only implemented the style for the connectors, curves and crossovers, so let me know what you think before I do any more work on it.

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 09, 2009, 03:49:13 PM
Even the TH diagram from above is improved

(http://knotbox1.pbwiki.com/f/MS-TH.jpg)
Title: Re: Another Step Forward
Post by: DaveRoot on January 09, 2009, 03:58:49 PM
Nice!  You even added some shading!

I'll try out the new version today.

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on January 10, 2009, 02:29:42 PM
Derek,

The new drawing logic seems to be working well.

By the way, I came up with a fairly straightforward way for FCB to create a .KT3 file which can be loaded into KnotTyer3D.

For this to work, your SPart tile should only be used to indicate the SPart of a rope.  When the user places one or more SPart tiles on the diagram, store the locations (e.g. "fan").  Let's assume that there is one SPart tile on the diagram, and it's the north-pointing tile.

To create the coordinates for KnotTyer3D, simply assign a multiple of 10 to each row and column in the FCB diagram (a=10, b=20, c=30, etc.).

Now, if the SPart tile has a value of "fan" in FCB (i.e. the north-pointing SPart tile is at location "fa"), then the first .KT3 coordinates are:  60, 10, 0 (the third value will always be 0 unless a section of rope is traveling *behind* another section of rope).

Since the SPart tile is pointing north, the next tile in sequence will be at "fb" (i.e. just below the SPart tile).  You'll need to keep track of which direction the rope is traveling at each step.  If the "fb" tile is a vertical strand of rope, for example, then the next tile in sequence is at "fc" (the same is true if the "fb" tile is one of the crossing tiles).  If the "fc" tile curves to the west then the direction has changed, so the next tile is at "ec", and so on.  Using this approach, you can programmatically follow the rope through all of its gyrations, building a sequence of coordinates in the proper order.  The order in which the user placed the FCB tiles makes no difference, because at each step you simply need to scan through FCB's list of coordinates (for each color) looking for the appropriate location (e.g. "ec") in order to find out which tile is at that location.

With the exception of the curved tiles, the .KT3 coordinates are very simple.  The first two values will always be the numeric equivalents for the column and row (e.g. "60, 20" if the tile is at "fb").  The third value in the .KT3 coordinates will always be 0 unless the tile is a crossing tile and the rope is traveling in a direction which will take it *behind* a section of rope, in which case the third value needs to be -1.

For a curved tile, we need to create three .KT3 coordinates based on the direction in which the rope is traveling.  In the following instructions, "c" refers to the numeric column value of the curved tile (e.g. f=60) and "r" refers to the numeric row value.  "Upper right" refers to the curved tile in the FCB pallet which is in the upper right corner of the four curved tiles.

-- For the "upper right" curved tile:
If the rope is traveling north, then the .KT3 coordinates are:
c, r+4, 0
c-2, r+2, 0
c-4, r, 0

If the rope is traveling east, then the .KT3 coordinates are:
c-4, r, 0
c-2, r+2, 0
c, r+4, 0

-- For the "upper left" curved tile:
If the rope is traveling east, then the .KT3 coordinates are:
c+4, r, 0
c+2, r+2, 0
c, r+4, 0

If the rope is traveling north, then the .KT3 coordinates are:
c, r+4, 0
c+2, r+2, 0
c+4, r, 0

-- For the "lower left" curved tile:
If the rope is traveling south, then the .KT3 coordinates are:
c, r-4, 0
c+2, r-2, 0
c+4, r, 0

If the rope is traveling west, then the .KT3 coordinates are:
c+4, r, 0
c+2, r-2, 0
c, r-4, 0

-- For the "lower right" curved tile:
If the rope is traveling east, then the .KT3 coordinates are:
c-4, r, 0
c-2, r-2, 0
c, r-4, 0

If the rope is traveling south, then the .KT3 coordinates are:
c, r-4, 0
c-2, r-2, 0
c-4, r, 0


When there are no more FCB tiles to process then you're done.  If you come to a WEnd tile then write the coordinates for that tile (e.g. "70, 80, 0" if the WEnd tile is at "gh").

That's all there is to it!  Simply provide a button which prompts the user for a filename, then write the KnotTyer3D coordinates to the file using a .KT3 extension, then the file can be loaded into KnotTyer3D (for a single rope, it usually looks best if you use the "Rainbow" option in KnotTyer3D).

If the user placed a second SPart tile then write "C" to the output file to indicate a new rope ("C" stands for "Color").  Then follow the above logic to write the coordinates for the second rope.  This will cause both ropes to be drawn simultaneously in KnotTyer3D.  Use "CF" instead of "C" if you want the first rope to be drawn before the second rope.  Use "CJ" (or "CFJ") if you want the first rope to be a closed loop such as a sling ("J" stands for "Join").

For a spar, first write out the KnotTyer3D coordinates of the spar just as if it were a rope.  Then use "CF" and write out the KnotTyer3D coordinates for the rope.

I have attached the .CYP file for a Bowline, and a .KT3 file which I made using the above logic (you'll need to rename it from FCB_Bowline.txt to FCB_Bowline.kt3 in order to load it into KnotTyer3D).

Anyway, this will get you started (if you're interested), and the logic can be tweaked later (such as smoothing out the curves).

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on January 10, 2009, 05:04:39 PM
Maybe you can create a "Tools/Options" screen, and provide a way for the user to specify the location of KnotTyer3D.exe on his/her machine (from http://www.abbott.demon.co.uk/knottyer3d.html (http://www.abbott.demon.co.uk/knottyer3d.html)).  This way, when the user clicks the button to create a .KT3 file, FCB can pop up KnotTyer3D and automatically load the new .KT3 file.

Hmmm, I just tried sending a .KT3 filename to KnotTyer3D.exe, but it didn't load the file automatically.  If you can't get the auto-load to work, then perhaps you can save the .KT3 file to the KnotTyer3D.exe folder, then pop up KnotTyer3D.  The user simply needs to click "File/Load knot," and the new .KT3 file will be right there in the list.

If you create a "Tools/Options" screen, you might consider removing all of the stuff at the bottom of the main screen and putting those things in the "Tools/Options" screen.  This will give the main screen a more clean and streamlined look, and I believe that it will be more intuitive for new users (in other words, new users won't be confronted with features and options which they don't yet know what to do with).

You could add a row of colored boxes in the pallet (blue, red, and maybe black or brown), and when the user left-clicks a color then all of the pallet tiles change to that color.  For crossing tiles, only the "over" part of the crossing changes color.  When the user right-clicks a color, then the "under" part of the crossing tiles changes color.  As a user, I would prefer to have control over the color behavior, but your "Tools/Options" screen could have a checkbox to turn on "Smart Colors" (which is the current FCB behavior).

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 10, 2009, 07:53:24 PM
Hi Dave,

I like the way you are thinking.

When FCB was first created, it was to help Frank create knot drawings (he was using a CAD program and placing pre drawn cells onto a grid, much as you did the other day with MS Paint).  The idea was to create a diagram using only a set of tiles and from this create a simple cypher string which could be sent, faxed, or spoken to another tyer and from this cypher, they could faithfully recreate the diagram.  The little utility made placing tiles easy and wrote out the little three character cypher strings as it went, saving the cypher to a tiny text file came next and naturally that was followed by the ability to load one of these text cypher files and recreate the diagram.  But that is all they were, simple text codes and pictures built up from set tiles.  The picture created could be anything from gibberish to a knot, any meaning was formulated by the human mind looking at the picture, there was no essence of knot or cord in the code or the program.

It was only much later, after several revisions, that I faced the challenge of making the utility automatically work out the Overs Index and the Binary Signature for the knot represented by the diagram.  To do this I first had to give the utility the ability to do what you achieved by utilising the picture of the knot you had created in your minds eye so that you could follow the 'path' of an imagined continuous cord.  I did this by adding to each picture tile, information about which face the cord came in and went out by.  This then allowed the utility to 'Trace out' the path of the cord.  I gave the utility the trigger of waiting for a WE tile to be placed for cord 1 and when this trigger happened, 'Trace' worked its way along the tiles and created a representation of the continuous path of the cord.  Naturally, as I was doing this to create the Binary Sig and the OI, each time a crossing was encountered the corresponding 0 or 1 was recorded into the Signature (these correspond to the -1's and 0's of the kt3 'language').

So, I already have the heart of the kt3 interpreter and instead of just recording crossings, I just have to record the other 2D moves as well in order to create a kt3 equivalent of the FCB cypher.  As for creating a kt3 file, that would simply require adding a kt3 'type' to the 'Save As' menu and then writing an appropriately scripted csv file to produce a functional kt3 file.  It is all relatively easily doable because the structure is already there, and I think it will be a potentially useful enhancement, so I will 'set to' on the enhancement (it will take me a little longer than the drawing style mod took, so watch this space).

Unfortunately, the next bit you wanted - Auto execute Knottyer3d.exe and load the newly created kt3 file - cannot be done with Knottyer3d.exe as it presently stands.  If you drag and drop a .cyp file onto FCB4.exe, it will launch the utility and load the file because I have built in the method of inspecting the command line for a file handle and attempting to auto load it (I have yet to build in error handling if the format is bum).  Steve has not built this function into Knottyer3d and if you hand it a file it simply ignores it.  So I am afraid, you will be stuck with having to hand load the converted file.

Your other ideas about clearing up the bottom of the work area are excellent, the cyp fields have long since lost their use, but before I do this, I need to build in copy and paste to allow chunks of diagram to be copied not only around the work area, but also between cords.  I have been toying with floating out a 'Tools' pallet along with the Tile pallet.  I think you have convinced me to do this for the next release, along with the facility to annotate the diagram (haven't found out how to do this yet.)

You have given me a lot to work on here, shame you don't have Delphi (yet?).

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 11, 2009, 03:27:05 PM
I believe that there is a team of Delphi developers on my floor at work, which means that there's a chance I can install Delphi through our site license.  Depending on how steep the learning curve is, I might be able to help out with some of the tasks.  Feel free to send me the source code, and I'll see what I can do.

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on January 11, 2009, 07:09:09 PM
I sent a note to Steve Abbott this morning to see if he might modify KnotTyer3D to accept a .KT3 filename as a parameter, and within an hour he had sent me a new version of KnotTyer3D with the modification!

I have asked him if he is planning to update his website (http://www.abbott.demon.co.uk/knottyer3d.html (http://www.abbott.demon.co.uk/knottyer3d.html)) with the new version, and I sent him a link to this thread.

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 11, 2009, 11:11:19 PM
Wow, you really make things happen, and you have access to a whole team of Delphi programmers, I am in deep envy, it is really hard to learn Delphi without access to someone who knows and uses the language.

Of course I will make the source code open to you, I think you can run with it far faster than I have managed thus far.  I will post it onto the KnotCypher wiki http://knotcyphers.pbwiki.com/ (http://knotcyphers.pbwiki.com/) and send you a user link when it is up. (could you confirm your email please).

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 11, 2009, 11:15:29 PM
LOL, it was Steve who made things happen quickly!

Edit: My email address is: dave <> Layhands . com

Dave
Title: Re: Another Step Forward
Post by: Dan_Lehman on January 12, 2009, 07:53:58 AM
LOL, it was Steve who made things happen quickly!

I love seeing the Net facilitate good growth (in stark contrast to SPAM & scams).

Quote
My email address is:  <omitted!>

Thinking of which, Dave, you might want to delete this piece of text--do SPAMbots
crawl here and collect addresses?  'dave <> Layhands.com' is one way I've put
e-addresses; and 'dave456<>Layhands99.com [remove all numerals!]' is another
and surer way to defeat a bot, I'd think.

Cheers,
--dl*
====
Title: Re: Another Step Forward
Post by: DerekSmith on January 12, 2009, 10:58:03 PM
OK,

The full project source code is now posted to https://knotcyphers.pbwiki.com/FCB-Development (https://knotcyphers.pbwiki.com/FCB-Development) so no jokes please about my novice programming, but all contributions to improve the utility gratefully received.

We probably need to agree some protocol for updating the files after change with some sort of date and versioning - being a lone programmer, I have not had to bother with this.

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 13, 2009, 12:49:02 AM
Great, I'll download it and have a go at it!

Now that the source code has been made available to more people, let's be sure to comment our changes with our name (and the date) to help with the merging.

I use a file compare and directory compare utility called "Beyond Compare" (http://www.scootersoftware.com/moreinfo.php (http://www.scootersoftware.com/moreinfo.php)) every day at work and at home for merging software changes, HTML changes, etc., between the work and home copies of my programs.  It's one piece of software which really lives up to its name!   8)

BTW, I found out that those developers at my work are not Delphi developers, they are PowerBuilder developers....

I received your email.  I'm assuming that I can now upload to the wiki, and that we can discuss the app on the wiki forum, right?

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on January 13, 2009, 04:15:36 AM
Okay, I'm able to run the FCB application in Turbo Delphi now.

In order to avoid too many collisions, what part are you currently working on?

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 13, 2009, 12:11:55 PM
Hi Dave,

I am seriously impressed at the speed at which you work, bodes well for the future of FCB I hope.

Yes, you now have full access to the Wiki.  You have Administrator access which means the wiki is fully at your disposal, including invitation of new contributors and full create delete authority.

I agree, we should probably keep the development work over on the Wiki, I doubt the good folks here will be too interested in ---

------------------------------------------

// Converts the full binary signature into the Overs Index
// but do not start until sig is over three characters long

function sigtooi(sig: string): string;
var
c, overs, sat :integer;
j : string;
begin
 result :='';
 if length(sig)>3  then
 begin
   overs :=0;
    for c := 1 to length(sig) do
      if sig[c] = '1' then overs := overs +1; //count over crossings

     sat := overs *2; //assume fully saturated
     j := sig[1];
     for c := 2 to length(sig) do
        begin
          if sig[c] <> '-'  then  //ignore hyphens
            begin
              if j = sig[c] then
                 begin
                 sat := sat-1;  //decrease saturation for every repeat
                 end;
              j:= sig[c];
            end;
        end;
    result := inttostr(overs)+':'+inttostr(sat);
 end;
end;

--------------------------------------------

However, it would be valuable to keep updates of the progress in this thread so that others interested in using the utility can decide if the changes are of interest to them.

At the moment, I am working on tidying up the drawing function to curve the crossings and have the cord paint over the grid lines in the FCBForm.pas unit - procedures drawcella() through to drawcellr().

However, I really do not want to stint your enthusiasm, so please feel free to consider and decide on how you see this project going forward and how it would be best to approach the goals ahead - do you even agree with the ToDo's that have amassed as time has gone by?

I am a hobby programmer with only the FCB utility, a genealogy transcription search utility, and a GPS tracking / verge audit facility to my credit.  I certainly feel that the FCB utility can benefit greatly from the professional rigour you can impose on it so please feel free to take over leadership of the project for us.  It is time for the project to have some renewed vigour, I hope you will be happy to be the initiator.

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 13, 2009, 12:24:41 PM
I'm now able to pop up KnotTyer3D and auto-load a .KT3 file, so I'll work on creating a "Tools/Options" form to allow the user to enter the appropriate file paths, and I'll add the logic to create the .KT3 file.  This seems like a discrete piece of functionality which shouldn't impact anything you're doing, plus it will give me the opportunity to learn how to do a number of different things in Delphi.

I'm not sure where to continue this discussion on the Wiki, so I'll let you post a comment there and then post a link to it here.

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 13, 2009, 01:11:23 PM
The Wiki does not have its own forum, so we will have to use the pages or the comments for text, ideas, code discussions etc.

I have created a new page linked from here https://knotcyphers.pbwiki.com/FCB-Development (https://knotcyphers.pbwiki.com/FCB-Development)

let me know if this will be useful or not.

Meanwhile, anyone wants to download the utility and have a play, the latest version can be downloaded from here https://knotcyphers.pbwiki.com/The+FCB+Cypher (https://knotcyphers.pbwiki.com/The+FCB+Cypher)  click on the FCB42.b.exe file download link, save the file to your PC.  Right click the file to create a shortcut and put the shortcut onto your desktop (or wherever you keep your shortcuts).  To run the utility simply double click or drag and drop a .cyp file onto it - don't worry about messy installations, it doesn't need any, it just runs.

If you need some help, we are building a user guide over at https://knotcyphers.pbwiki.com/FCB4+User+Guide (https://knotcyphers.pbwiki.com/FCB4+User+Guide) or just post your questions here.

Just a Note  - You can run multiple copies of FCB at the same time, this can be handy to have one copy open displaying one diagram, while you draw a new diagram in another copy of FCB.

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 13, 2009, 02:30:55 PM
Any chance of the Knottyer3D with auto load?

Post it to the Wiki if you like and if Steve agrees.

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 13, 2009, 03:22:14 PM
The FCB program logic is straightforward and easy to follow, nice job!

In your TODO list there's an item which says, "Discard tiles and move to face click connection drawing mode."  What does this mean?


Any chance of the Knottyer3D with auto load?

Post it to the Wiki if you like and if Steve agrees.

Steve has updated his website with the new version.

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 13, 2009, 08:40:50 PM
The FCB program logic is straightforward and easy to follow, nice job!

In your TODO list there's an item which says, "Discard tiles and move to face click connection drawing mode."  What does this mean?

Dave


It means that we don't need the 'tiles' in order to make a diagram.  Each cell of the grid has four faces and the cord comes in one face and goes out one of the others.  This means that we could select a cord to draw with, then draw the cord (much as Steve does but with more rigour) simply by clicking on the path of the cord via the cell faces.  So if we started on say the 'west' face of a cell, then clicked on the 'east' face, we would be indicating that we needed a horizontal cord to be drawn in that cell, while if we went from 'west' to 'north' then we would want an upwards quadrant curve to be drawn.  Even crossing cells become straight forward simply by drawing a line across an existing one, we would need to be able to assign its position (either above or below the existing line) possibly by using say the shift key for below, otherwise default above (same concept for crossing a spar, default above and shift for behind).  Then we only need a couple of extra keys to add say the 'W' key for the terminator symbol and the 'S' key for the SPart symbol.

It would make drawing very rapid because you would not have to keep picking up tiles, just click from face to face and click twice to 'unconnect' a previous connection or break a cord.  Two cords would simply be a matter of selecting the second cord colour and start tracing out the path.

I had come to the conclusion that I needed to move to this system, then Steve came out with his freehand style of drawing and I considered moving totally to a gridless system.  But a little practice with Knottyer3D had me thinking that the rigour from a grid was actually a useful control to help draw good curves, but we perhaps needed a more flexible grid allowing corner routing as well to give diagonals instead of having to create diagonals by using stacks of bends.

At that point, I realised we were only a small jump away from 3D, simply by adding an above layer and a behind layer, we have the makings of 3D, but that was for the future because I did not know how to render 3D and generate the 3D rotational viewing functionality of Steves utility.

So, taking small steps, my next issue was going to move to face clicking and drop the tiles pallet.

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 13, 2009, 09:45:02 PM
Because the whole drawing system already exists, we could implement the face click system very easily, simply by changing the 'On Click' function to locate the nearest face of a cell, then on the next click event, us a simple Case of list to identify the tile that would have been used to create this effect and inject that tile letter into the existing code.  We might instigate it by having a toggle option which switches between pick'n'place (i.e. the now system) and the simpler 'face click' system.

What do you think?

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 13, 2009, 10:03:13 PM
About the time I was working on the Binary Signature and the Auto link/launch to the Knot Library, I was in discussion with Charles Hamel (AKA Nautile) about other ways of describing a knot i.e. by decomposing a knot into basic elements.

At that time I realised that a knot does not strictly have crossings, these are figments of perspective from the point of an external observer.  But a knot does not function from the perspective of an external observer.  A knot functions from within itself.  A knot functions because it wraps around itself in a series of Z and S twists which continue for given angles and have certain radii, but most of all, a Real Knot is a working system of force vectors.

I realised then that my humble little FCB was a million miles from being anything other than a representation of layout (for the external observer) and that I would have to start to think from within the knot if I was to have a chance of creating any form of meaningful signature capable of spelling out the essence of a knot.  Thanks to FCB I am a lot closer to that realisation, but this realisation still hands out there in the mists, just beyond rational perception.

I hope that future developments of the utility will help me 'see' what is so close that I can almost taste it.

Derek 
Title: Re: Another Step Forward
Post by: DaveRoot on January 14, 2009, 02:21:06 PM
Two cords would simply be a matter of selecting the second cord colour and start tracing out the path.
Another idea is that two cords would simply be a matter of having two WEnds.  If the program is modified to use a two-dimensional matrix (without a third dimension of cord color) then the user can place the appropriate tiles for multiple cords, selecting any colors for any sections of cord.  Multiple cords could all be the same color if the user wishes, just as they might be in a photograph of a knot.  As long as there is a termination point for each cord (i.e. a WEnd tile) then we will be able to programmatically follow each cord separately, ignoring the colors.

For example, I have the KnotTyer3D logic working properly for a single cord, although at the moment I am simply hard-coding the file paths.  I need to add a way for the user to specify the location of KnotTyer3D.exe, and I should be able to upload the changes later today.  But it doesn't work for multiple cords (yet) because when the program is looping through the tiles for cord #1, it doesn't see the tiles for any other cords.  Yet those tiles of other cords might cross over cord #1, so their crossings need to be taken into account.  If the program were to use a two-dimensional array to store the tiles (exactly modeling the two-dimensional matrix of the diagram) and if it ignores the cord colors, then it will easily be able to follow the separate cords from their WEnds all the way to their SParts (even if there are no SPart tiles). 


But a little practice with Knottyer3D had me thinking that the rigour from a grid was actually a useful control to help draw good curves, but we perhaps needed a more flexible grid allowing corner routing as well to give diagonals instead of having to create diagonals by using stacks of bends.
I agree.  A grid provides more control over the drawing of each type of tile, leading to a "cleaner" diagram.  I have been thinking about diagonals as well, but I haven't yet played with the idea to see how well it might work out.


We might instigate it by having a toggle option which switches between pick'n'place (i.e. the now system) and the simpler 'face click' system.

What do you think?
I like the toggle idea.  Different people think differently and approach tasks differently, so it would be good to retain the original method of placing tiles as an option.  I think it would also be very helpful to be able to select one or more tiles and then cut/copy/paste/drag them to another area of the diagram.  Perhaps CTRL+click can be the mechanism for selecting tiles.  The reason I mention it is so that we can think through all of the different types of "click" functionality that we might want to have before implementing any of them.


I realised then that my humble little FCB was a million miles from being anything other than a representation of layout (for the external observer) and that I would have to start to think from within the knot if I was to have a chance of creating any form of meaningful signature capable of spelling out the essence of a knot.  Thanks to FCB I am a lot closer to that realisation, but this realisation still hands out there in the mists, just beyond rational perception.

I hope that future developments of the utility will help me 'see' what is so close that I can almost taste it.
I have wrestled with this as well, trying to think past the apparent limitations of a 2D representation.  But keep in mind that FCB has already shown itself to be very handy for making quick diagrams which can easily be attached to forum posts!

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on January 14, 2009, 07:07:21 PM
Here are some examples of KnotTyer3D files which were exported from FCB.  I hope to have the new version of FCB uploaded within the next day or two.

I have attached the .CYP files for an Overhand Loop and a Sliding Grip Hitch (which I drew in FCB), as well as the KnotTyer3D files which were exported from FCB.  The attached .TXT files need to be renamed to .KT3 because it doesn't look like I can attach .KT3 files.  The comments in the KnotTyer3D files were manually added after the files were exported from FCB.

Dave
Title: Re: Another Step Forward
Post by: DaveRoot on January 14, 2009, 07:10:08 PM
Here are the .CYP files for a Figure-Eight Loop and a Turk's Head (which I drew in FCB), as well as the KnotTyer3D files which were exported from FCB.  The attached .TXT files need to be renamed to .KT3 because it doesn't look like I can attach .KT3 files.  The comments in the KnotTyer3D files were manually added after the files were exported from FCB.

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 14, 2009, 11:40:25 PM
Here are some examples of KnotTyer3D files which were exported from FCB.  I hope to have the new version of FCB uploaded within the next day or two.

I have attached the .CYP files for an Overhand Loop and a Sliding Grip Hitch (which I drew in FCB), as well as the KnotTyer3D files which were exported from FCB.  The attached .TXT files need to be renamed to .KT3 because it doesn't look like I can attach .KT3 files.  The comments in the KnotTyer3D files were manually added after the files were exported from FCB.

Dave


Do I understand you correctly !  You have created an FCB to KT3 parser and coded it in Delphi ALREADY ??  You didn't even know Delphi three days ago  --  serious bit of hero worship going on here Dave, it took me months before I could even start to understand what an object was - you are one clever feller Mr Root, it is good to have you on board.

Re the parsed files, good first attempts.  They demonstrate the need to use lookahead/lookback to be able to angle the curves downwards if the next junction is under or upwards if it is over, it is the curve which is transiting the third dimension rather than just the cord going behind the crossing.  You have transitioned around the 2D bends very effectively, can you transition in the third dimension as smoothly?

The Mobius TH was very much a surprise for me when I loaded it into KT3.  It was easy to follow in FCB, but in KT3 I was unable to follow it at all, a serious case of 'less is more', however, you must have been well satisfied when your parser popped out that file.

Note.  as .kt3 files are simple text files, if you ask Mel, she can confirm the safety of uploading them and add them to the permitted types (she added .fcb for me).
Title: Re: Another Step Forward
Post by: DerekSmith on January 14, 2009, 11:48:09 PM

We might instigate it by having a toggle option which switches between pick'n'place (i.e. the now system) and the simpler 'face click' system.

What do you think?
I like the toggle idea.  Different people think differently and approach tasks differently, so it would be good to retain the original method of placing tiles as an option.  I think it would also be very helpful to be able to select one or more tiles and then cut/copy/paste/drag them to another area of the diagram.  Perhaps CTRL+click can be the mechanism for selecting tiles.  The reason I mention it is so that we can think through all of the different types of "click" functionality that we might want to have before implementing any of them.

Dave


The toggle also lets us keep the tiles for the oddments like WE, SP, Spar crossings etc.  Just draw out the lines, curves and crossings using face click, then toggle to tiles mode and select/place the specials.  I have been pondering on how to do the specials if we moved to face click, but keeping both and allowing direct toggle between both solves the problem (after all, face click through is simply a fast means of putting down tiles).

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 15, 2009, 12:16:25 PM
Well, after I installed Turbo Delphi, my first happy surprise was that it is similar enough to Visual Studio (which I use all day at work) that I was able to get a feel for it pretty quickly.  I didn't know the Delphi syntax (for...next loops, case statements, file I/O, etc.), but my second happy surprise was that no matter what I needed to do, you had usually already done it somewhere in FCB.  So I just copied off of you!   :D   I had already worked out the logic for the KT3 parser before I mentioned it the other day, so basically it was just a matter of typing it all in and working out the bugs.  The part that I'm finding tricky is the GUI stuff....some of the user-interface features are similar to Visual Studio, but some aren't.  The Internet sure comes in handy!  I think my new GUI (for capturing the path to the user's installation of KnotTyer3D.exe) is finished, but I realized that we'll need an INI file to store the path so that the user only needs to point to KnotTyer3D.exe one time.  Still need to finish that part.



Re the parsed files, good first attempts.  They demonstrate the need to use lookahead/lookback to be able to angle the curves downwards if the next junction is under or upwards if it is over, it is the curve which is transiting the third dimension rather than just the cord going behind the crossing.  You have transitioned around the 2D bends very effectively, can you transition in the third dimension as smoothly?
Yeah, I tried to tweak some of the transitions a bit after looking at the results, but I decided to focus on finishing up the user-interface pieces so that others can try it out and provide some feedback and ideas for improvement.  I need to play with KnotTyer3D some more in order to figure how to improve the display.



The Mobius TH was very much a surprise for me when I loaded it into KT3.  It was easy to follow in FCB, but in KT3 I was unable to follow it at all, a serious case of 'less is more', however, you must have been well satisfied when your parser popped out that file.
Turning on the "Rainbow" option in KnotTyer3D helps a lot, but I don't see a way to set that option automatically when I pop it up.  Also, the "Zooms" values should all be 1...sometimes one of them is set to 2 when KnotTyer3D pops up.

For the release version, how about we choose a name which is descriptive of the program's functionality?  KnotDiagrammer.exe, perhaps.  Something which will call to mind what the program does.  Also, I'd like to figure out how to get it to scale itself to different screen resolutions.

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 15, 2009, 06:19:58 PM
Dave, I really am not precious about the name, it is a long time and a long transition since 'Frank Browns Cypher and Drawing Utility' crawled onto the screen, and the beast which it is likely soon to become deserves a fitting and catch name.  Perhaps the good folks here could suggest some names, especially as they have contributed so much to its development.

Still, you are quite good at naming (I remember the lovely Myrtle Knot), so I am happy to leave choosing to you.

I am really pleased that your slide into Delphi is going smoothly.  Hopefully before long I can be coming to you for help on using it.  Before OOP I used to code apps straight in machine code and later I used Basic.  The move to OOP and Delphi is hard but I am really enjoying Delphi - what is your perception of it so far?

Derek
Title: Re: Another Step Forward
Post by: DaveRoot on January 15, 2009, 06:31:25 PM
I started with BASIC many years ago, then played with C for awhile, then used PL/1 on the mainframe.  Then I started using VB 1.0 and stayed with it through its final 6.0 release.  Then we switched to VB.Net, which I thought would be a fairly simple transition since I had been using VB for many years.  Boy was I wrong!  Like you said, the move to OOP was hard.  But now I have been using VB.Net for 4+ years, so it wasn't difficult to start using Delphi.  I'm enjoying it!

Dave
Title: Re: Another Step Forward
Post by: roo on January 15, 2009, 06:36:41 PM
I started with BASIC many years ago, then played with C for awhile, then used PL/1 on the mainframe.  Then I started using VB 1.0 and stayed with it through its final 6.0 release.  Then we switched to VB.Net, which I thought would be a fairly simple transition since I had been using VB for many years.  Boy was I wrong!  Like you said, the move to OOP was hard.  But now I have been using VB.Net for 4+ years, so it wasn't difficult to start using Delphi.  I'm enjoying it!

Dave


You might want to move this to e-mail. 
Title: Re: Another Step Forward
Post by: DerekSmith on January 15, 2009, 09:49:07 PM
I started with BASIC many years ago, then played with C for awhile, then used PL/1 on the mainframe.  Then I started using VB 1.0 and stayed with it through its final 6.0 release.  Then we switched to VB.Net, which I thought would be a fairly simple transition since I had been using VB for many years.  Boy was I wrong!  Like you said, the move to OOP was hard.  But now I have been using VB.Net for 4+ years, so it wasn't difficult to start using Delphi.  I'm enjoying it!

Dave


You might want to move this to e-mail. 

Why is that Roo ??

Are you not finding the discussion interesting?  Still, even if you aren't, someone else might, and we might just interest others into joining in with the project (there are numerous ways, not just programming).  It's definitely one of those situations where more hands make light work and it also makes the task a lot more interesting.

A few knotters are already using and finding the FCB a useful tool for knotting, and posting diagrams made with it here has helped in certain discussions, so I think the tool has merit for the knotting world although perhaps not for the branch which you enjoy.  As for peripheral banter between those involved in the development of the tool for everyone else to use should they want to (for free), I am sure that it has not offended anyone any more than chats between old salts, climbers or simply folks on holiday sharing some of their experiences with their knotting friends.  In a way it extends one of the important values of the forums early equivalent - KM - A Knotters Profile, where people continue to share life stories and snippets in the process of making new acquaintances and friends, and in case you hadn't spotted it, that is what Dave and I were doing.

So, as there is likely to be a lot more of this sort of thing and even some code snippets swapped, could I suggest that you cut us some slack and give this thread a miss for a while.  While we would love to have your constructive input to the project, your freelance censorship is not appreciated.

Thanks
Derek
Title: Re: Another Step Forward
Post by: roo on January 15, 2009, 10:40:36 PM
I started with BASIC many years ago, then played with C for awhile, then used PL/1 on the mainframe.  Then I started using VB 1.0 and stayed with it through its final 6.0 release.  Then we switched to VB.Net, which I thought would be a fairly simple transition since I had been using VB for many years.  Boy was I wrong!  Like you said, the move to OOP was hard.  But now I have been using VB.Net for 4+ years, so it wasn't difficult to start using Delphi.  I'm enjoying it!

Dave


You might want to move this to e-mail. 

Why is that Roo ??


Certain aspects of the discussion are drifting far, far afield of knotting.  Is there a reason you are averse to using private communication or a different forum site for discussing topics not related to knotting?

Title: Re: Another Step Forward
Post by: SS369 on January 15, 2009, 11:22:16 PM
I for one do not mind the tech banter. In fact I am learning something, for free, that may well be of some knotting usage or elsewhere.
Kudos to the tech- geniuses! ;-)
And keep us informed please.

Scott
Title: Re: Another Step Forward
Post by: DaveRoot on January 17, 2009, 10:55:30 PM
I just uploaded a new version of FCB (FCB.exe) to http://knotcyphers.pbwiki.com/The-FCB-Cypher (http://knotcyphers.pbwiki.com/The-FCB-Cypher).  It was fun working on the KnotTyer3D parser, so I kept on adding more bells and whistles to the program!

I uploaded the source code as well (https://knotcyphers.pbwiki.com/browse/#view=ViewAllFiles (https://knotcyphers.pbwiki.com/browse/#view=ViewAllFiles)).  Derek, is that the proper place to upload these files?  I have started to refactor (re-work) the KnotTyer3D logic in order to build some re-usable routines (e.g. a routine to find all of the WEnds in a diagram, and a routine to trace through an entire cord, etc.), but it is still a work-in-progress.  See GridProcessor.pas.

Derek, do you have any modifications which need to be merged in?

Here are the updates in v4.3:

1. Under the File menu, there is a new option called "View With KnotTyer3D."  This will pop up a window which explains what KnotTyer3D is, and it provides a link to the KnotTyer3D website.  If KnotTyer3D is installed on your machine then enter the path and filename for KnotTyer3D.exe in this new window, as well as the filename to be used for exporting the current diagram (these filenames will be saved to a new INI file in the FCB.exe folder).  Clicking the "Run KnotTyer3D" button will display your diagram in KnotTyer3D.  It will display up to 3 cords.

The .KT3 file which the new parser creates is simply a text file, so Derek suggested popping up the .KT3 file to allow it to be edited (for tweaking the knot in KnotTyer3D).  However, KnotTyer3D has an editor which allows you to modify the file and view the results.  Let me know if you find some ways to improve the way that a knot looks in KnotTyer3D!

2. The main FCB window is now automatically maximized when it loads (because most of the window was off of my screen when it loaded).  I'm hoping that Derek or I can get it to scale the grid size based on the user's screen resolution, which will also enable us to provide zoom in/zoom out capability.

3. Added an Undo feature.

4. I thought it would be nice if the active palette tile is highlighted, but I just couldn't get it to put a satisfactory border around the active tile.  Therefore, I simply made the active tile bigger so that it stands out.

5. If you CTRL+click a cell on the diagram, the tile in that cell will be rotated.

6. For operations which will destroy your current diagram (e.g. File/New, File/Open, File/Exit), you'll now be prompted to save your changes.

7. The File/Save menu item is now disabled until a filename has been selected.


I tried to make it "bulletproof," so do your best to break it and let us know what bugs you find!

What would be a good name for this tool?  Some ideas:

   KnotDiagrammer
   KnotMaker
   KnotCharter
   KnotIllustrator
   KnotDesigner
   KnotCanvas
   KnotDraw
   KnotPaint
   KnotArtist
   KnotSketch


Dave
Title: Re: Another Step Forward
Post by: squarerigger on January 18, 2009, 06:24:51 AM
I like Knotsketch
 ;D
SR
Title: Re: Another Step Forward
Post by: SS369 on January 18, 2009, 03:49:29 PM
Is there anyway to make tiles that will allow an angled path(s)?
I vote for KnotPath.
Ooops, that isn't in the list.   ;-)

SS
Title: Re: Another Step Forward
Post by: DerekSmith on January 18, 2009, 07:46:21 PM
Dave,

I am so glad you are a knot tyer and also a professional programmer.

You have moved this little utility on so far in just a matter of days.  The advantage of having another perspective in play is also wonderfully demonstrated.  Suddenly the whole utility feels much more 'in control' with the inclusion of tools like 'Undo' and disabling 'Save' until there is something to save ! 

By parsing the diagram and linking it to KT3D, you have started the next evolutionary stage of this utility - visualising the knot in 3D.  It seems as though KT3D has a number of issues to be resolved before it fully satisfies the needs of 3D visualisation and loading, but it is a marvellous jumping in point.  You said that you are refactoring KT3, have you obtained the source code?

Your 'tiny' enhancement of 'spinning' a cell using CTRL plus 'click' has improved usability by an order of magnitude.  Now instead of selecting all the right curves and right crossings, I simply place the same curve wherever I need a corner and any crossing wherever I need a crossing, then spin them around to the right orientation.  Massively faster than going and clicking on the correct corner they placing it.  It also allows me to 'play' with a structure so easily.  It is truly a massive leap forward in usability short of moving to face clicking.  Potentially, this means we can dump a load of tiles and run with just six, i.e. one of each 'sort'.;

I spotted a couple of issues, the behind spar lines do not rotate and, seemingly randomly, on the tiles pallet some of the tiles stay enlarged so it is possible over time to have three or four 'large' tiles present.  I have not sorted the logic behind this event yet.

I think I have learnt more in one day by reading your code than I have in the last three months.  For example, in one line

ShellExecute(Handle, 'open', 'http://www.abbott.demon.co.uk/knottyer3d.html', nil, nil, SW_SHOWNORMAL);

You showed me the right way to launch the library.  Because I did not know how to do this, I had created a rather simplistic browser and displayed the library within it, but now the library form can be disposed of and we can utilise the users default browser.  Could you pop this code in for me (I think around line 390 in FCB.pas) to replace the existing Button1Click procedure.

procedure TForm5.Button1Click(Sender: TObject);
//call up the webbrowser with the binsig url.
var
LibraryUrl : PAnsiChar;
begin
   LibraryUrl:= PAnsichar('http://theknotlibrary.wikidot.com/'+form1.compsig(binarySig));
   ShellExecute(Handle,'open',LibraryUrl, nil, nil, SW_SHOWNORMAL);
end;


I also learnt about the type PAnsichar while I was at it - woohoo.

In terms of updating the code.  I do not mean to impose on you, but would you be happy with doing this for a while, as you are likely to be making far more changes than I can and I can always post my tiny pieces of code for you to splice in (there, a knotting term to keep the post legit).

As for a name, the utility is already far more than just a drawing program.  It computes Overs Index and the Binary Signature and allows the user to look up the knot in the Knot Library just from its structural signature, and now it is moving into 3D visualisation.  It would be nice if the name could more capture the essence of all the parts which the utility has and will in time hopefully come to include.  However, the simple 'KnotPath' has the right connotations perhaps, although so would KnotMaker or KnotFinder ?

Well Done Dave, you are a star.

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 18, 2009, 10:18:19 PM
Is there anyway to make tiles that will allow an angled path(s)?
I vote for KnotPath.
Ooops, that isn't in the list.   ;-)

SS

Scott, a method Dave and I have discussed called 'face clicking' might just be the answer to giving us the ability to add in diagonals.  I have long felt that not having a diagonal was quite a drawback and 'face clicking' plus 'corner clicking' could give us this facility.

Watch this space, but in the meantime have a play with the new FCB with the tile spinning tile functionality. 
Title: Re: Another Step Forward
Post by: DaveRoot on January 18, 2009, 10:33:02 PM
You said that you are refactoring KT3, have you obtained the source code?
I'm refactoring my KT3D parser logic, with the intention of using the new routines in GridProcessor.pas.  I don't have the source code for KT3D itself.


I spotted a couple of issues, the behind spar lines do not rotate and, seemingly randomly, on the tiles pallet some of the tiles stay enlarged so it is possible over time to have three or four 'large' tiles present.  I have not sorted the logic behind this event yet.
I was experiencing the issue of palette tiles sometimes staying enlarged, but I thought I had fixed it because I couldn't reproduce it after I made a minor change.  If you spot a pattern which consistently reproduces the problem, let me know!  I haven't worked on the spars yet, so I'll get that done soon.


Could you pop this code in for me (I think around line 390 in FCB.pas) to replace the existing Button1Click procedure.
Sure, I'll try to get that done in the next day or two.


In terms of updating the code.  I do not mean to impose on you, but would you be happy with doing this for a while, as you are likely to be making far more changes than I can and I can always post my tiny pieces of code for you to splice in (there, a knotting term to keep the post legit).
I don't mind making the updates (okay, I'm enjoying it!), and "splicing in" (LOL) your pieces of code.  The only issue will be finding/making the time to work on it.


As for a name, the utility is already far more than just a drawing program.  It computes Overs Index and the Binary Signature and allows the user to look up the knot in the Knot Library just from its structural signature, and now it is moving into 3D visualisation.  It would be nice if the name could more capture the essence of all the parts which the utility has and will in time hopefully come to include.  However, the simple 'KnotPath' has the right connotations perhaps, although so would KnotMaker or KnotFinder ?
I was leaning towards KnotSketch, which conveys the drawing aspect of the tool.  However, it doesn't capture the other functionality.

KnotPath and KnotFinder convey certain aspects of the tool, but to me they don't conjure up an image of being able to make diagrams of knots.

Since the tool allows a person to make a drawing of a knot, and it can make a KnotTyer3D version of a knot, and it can make an Overs Index, and it can make a Binary Signature (see where I'm going with this yet?)....I think that KnotMaker best captures most of the functionality.

Dave
Title: Re: Another Step Forward
Post by: SS369 on January 19, 2009, 12:48:05 AM
I've been giving it a run and enjoying the learning curves. Pretty cool.
I hope the diagonal tiles come into being.
I need an erase function, because if I've worked a knot and then find that deep into it a mistaken routing, I've had to dump it all and start again.
Also I have not found/figured out the tile spinning. I must be over looking it.
I think I have the latest version = 4.30.
And perhaps as the bugs and mods are done, there will be a version that will have smaller tiles for more complex/bigger knots.

SS
Title: Re: Another Step Forward
Post by: DerekSmith on January 19, 2009, 12:53:36 AM

Since the tool allows a person to make a drawing of a knot, and it can make a KnotTyer3D version of a knot, and it can make an Overs Index, and it can make a Binary Signature (see where I'm going with this yet?)....I think that KnotMaker best captures most of the functionality.

Dave


And as I have used it to make a couple of knot structures to fit a specific need, then it definitely feels like we are making some headway in coming up with a name !!

Derek
Title: Re: Another Step Forward
Post by: DerekSmith on January 19, 2009, 12:59:28 AM
I've been giving it a run and enjoying the learning curves. Pretty cool.
I hope the diagonal tiles come into being.
I need an erase function, because if I've worked a knot and then find that deep into it a mistaken routing, I've had to dump it all and start again.
Also I have not found/figured out the tile spinning. I must be over looking it.
I think I have the latest version = 4.30.
And perhaps as the bugs and mods are done, there will be a version that will have smaller tiles for more complex/bigger knots.

SS

To delete a tile, just right click on a blank square to select it, then paint (left click) the blank tile over any mistakes and it wipes them out.  You can use right click to select any tile from the already drawn diagram and then continue painting with it.

To spin, hold down the control key then left click on the cell you want to spin - it works for elbows, crossings and lines - Isn't that Dave a clever bugger !!

And yes, a 'Zoom Out' facility is on the ToDo list.

Derek
Title: Re: Another Step Forward
Post by: SS369 on January 19, 2009, 01:19:20 AM
Yes Derek, he is a clever one, but then so is you.
Thanks for the pointers!
They all work !!!

SS
Title: Re: Another Step Forward
Post by: DerekSmith on January 19, 2009, 10:26:17 PM
Today we have a 'side based' drawing scheme - a line comes in one side of the grid square and goes out one of the other sides.

We number the sides 1 though 4, so a cord might come in side 1 and go straight across and out side 3, or it might curve up and go out side 2 or curve down and go out side 4.

If we include diagonals, then we have to add in the corners (number them 5 through 8 ).  Now as well as going through the sides, a cord can come in through a corner and go out any corner or side, a bit like this --

(http://knotbox1.pbwiki.com/f/Side%20%26%20corners.jpg)

Today, an OH might look like this with just face connections

(http://knotbox1.pbwiki.com/f/OH%20Knot%20perspective.jpg)

But if we implement corner access as well we could draw like this ...

(http://knotbox1.pbwiki.com/f/Overhand%20diagonals.jpg)

The question is  --  is it a worth while enhancement?

Derek

Title: Re: Another Step Forward
Post by: DaveRoot on January 20, 2009, 12:10:08 PM
For me, the diagonals are more of a help in visualizing the knot than I had expected.  I'd say it's a worthwhile enhancement.

Dave
Title: Re: Another Step Forward
Post by: DerekSmith on January 20, 2009, 07:09:01 PM
OK Dave, but in that case, then might I suggest that we take a new approach to drawing the cells based on orientation plus the basic moves

across face to face,
face crossing,
across corner to corner,
corner crossing,
quarter turn,
knight move (face to corner, left and right)
WEnd,
Spart / loop return,
Behind spar.

Nine face connection options (four faces, four corners and the middle), and ten shape options.

If we build a new drawing procedure from this basis, then we can design in the option to scale at the same time.

We would need to hand it the cell coordinates, style, face coordinates, cord No. and zoom level.  Perhaps this warrants a new unit?

Thankfully you are driving this forward now with your professional skill level, so it stands a good chance of becoming a reality.

Derek
Title: Re: Another Step Forward
Post by: PwH on January 20, 2009, 10:55:25 PM
Well done all you guys who actually understand all this!  (I used to be quite good in Sinclair Basic all those long years ago!)  ;)  I would just like to vote for the diagonal enhancement- I can see immediately that it's an OHK without having to squint and look sideways as I do with the 'squared off' version. I for one would be infinitely more inclined to use the app with this visualisation style. Keep up the good work Derek et al.
Title: Re: Another Step Forward
Post by: WebAdmin on January 23, 2009, 07:53:23 AM
Good morning Gentlemen,

As I will be posting elsewhere, please accept my apologies for not being around for a few weeks, my home was severely hit by illnesses and I myself was ill for 3 weeks.  I am just this week getting back into real life.

I would just like to make note that a concern was expressed that this subject digressed a bit too far out of knotting and into programming.  That was about a week ago, and I wasn't able to respond at the time.

Having read - and completely not understood very much - the five pages of discussion, I felt that the following was appropriate as a mediation:

A significant development is clearly well in progress in the representation of knots by computer graphics and image-making.  This is a field which the mainstream of knotters may not be aware of or able to assist in, but it is nonetheless an area in which the Guild is proud to have members whose dual skills are blended so effectively.  However, I feel that the Practical Knots board is not the most appropriate home for this discussion, since although the knots themselves are practical, the discussion creating their representation is very specialised.

By way of allowing all their fair say and space to say it I will gladly make this thread (as being the most active most recently) the first entry of a new board entitled Knot Theory and Computing, which I have today asked Mel to create.  I know that elements of knot theory may appear in ordinary discussions on any board.  That's not a problem, and helps us amateurs to grow in the craft.  This board is for those who really want to get the knot between their teeth and shake it apart, either literally, figuratively, or binarily.

I have also asked Mel to move this discussion into it's new home.  Feel free to put up curtains, paintings, lay carpet, etc, guys!  Don't forget the comfy sofa, well stocked kitchen and the PC   ;)

If anyone feels that there is another, historic thread which should be rehomed, please drop me a PM and I'll send it over.

Regards

Glenys
Title: Re: Another Step Forward
Post by: DaveRoot on January 29, 2009, 11:58:29 AM
Derek,

Just checking if you received the new version that I emailed you on Sunday, as well as the follow-up issues and questions.

Dave
Title: Re: Another Step Forward
Post by: SS369 on February 15, 2009, 05:06:52 PM
If I am alone, so be it, but an update of the progress would be surely welcomed.

I hope this endeavor succeeds for all the right reasons, such as a pleasurable journey into the unknown, a voyage of learning with the ever evolving outcome being a repository of universally understood descriptions and cataloging of knots.

SS
Title: Re: Another Step Forward
Post by: DaveRoot on February 18, 2009, 06:14:57 PM
Derek and I have been adding new features and trying out different ideas offline.  We're working the kinks out of our new feature set, and then we'll post a new version for testing and suggestions.

Dave
Title: Re: Another Step Forward
Post by: SS369 on February 18, 2009, 07:16:41 PM
Ahhh, there is life yet.  ;)

Terrific, I had thought I heard a screeching halt.

Thanks for the hard work in advance. I think the members of the knotting world will benefit from your labors.

Hopefully this will aid the cataloging of the known knots one day and make it somewhat easier to recognize what is new, if there is such a thing.

SS
Title: Re: Another Step Forward
Post by: Sweeney on February 19, 2009, 12:34:14 PM
Dave

Glad you're carrying on with this as Derek has withdrawn unfortunately. Derek and I had discussed the ABOK index project and he was going to add the overs index and the binary signature (in decimal because of length) to the spreadsheet using the utility you're developing. The idea is to record Ashley and then add knots not in Ashley so we start to build a complete computer index of knots. Unfortunately I haven't had any volunteers to help yet so this might take a long time!

Barry
Title: Re: Another Step Forward
Post by: DaveRoot on April 19, 2009, 02:36:43 PM
Derek and I have renamed the "FCB" program to "KnotMaker," and I started a new topic for the enhanced tool: http://igkt.net/sm/index.php?topic=1346.0 (http://igkt.net/sm/index.php?topic=1346.0).

Dave