weird plane-to-plane alignment behavior

I am trying to port the Font Parser component from VB.net to C# (as a personal exercise and also to add some extra features as text justification and other stuff), but I stumbled into a weird plane-to-plane alignment behavior that I don't understand.

The original font parser in VB.net performs a plane-to-plane orientation of the strokes to go from the WorldXY plane to the assigned input plane (and it works).

When I translated it into C# the strokes are scattered away and do not align properly.

If I output the stroke and perform the alignment in a separate component (standard or custom C#), the alignment happens correctly.

Any idea why plane-to-plane alignment acts funny inside the C# main component?

Screenshot here (and the GH definition attached):

Attachments:

font parser_align problem.gh, 19 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on February 11, 2016 at 5:42am

Maybe this?

Attachments:

fontparser_alignproblem_what_problem_V1.gh, 17 KB

Permalink Reply by peter fotiadis on February 11, 2016 at 5:48am

Oops forgot the close polyline thingy:

   Transform pTop = Transform.PlaneToPlane(Plane.WorldXY, P); // ---outside the loop
   List<Polyline> strokesMod = new List<Polyline>();

   for(int j = 0; j < strokes.Count; j++){
      Polyline poly = new Polyline(strokes[j]); // ---for more than obvious reasons, he he
      if(!poly.IsClosed) poly.Add(poly.PointAt(0)); //---------------------- close, that is
      poly.Transform(pTop); // this is bool you know
      strokesMod.Add(poly);
    }

    C = strokesMod;

Permalink Reply by peter fotiadis on February 11, 2016 at 6:02am

BTW: if the strokes List is a properly made DataTree [cases "e", "o", "a" etc etc] you can do the required bool ops in order to get your chars as more "vivid" breps > see attached.

Attachments:

fontparser_alignproblem_what_problem_V1A.gh, 13 KB

Permalink Reply by Mateusz Zwierzycki on February 11, 2016 at 6:13am

There is something wrong in the loop which adds the points to the polylines. You end up with 200 polylines (should be 16)... There is no bug in the Transform method per se.

Permalink Reply by peter fotiadis on February 11, 2016 at 6:27am

Yikes + yikes ... never checked that one.

Anyway ... until the loop is resolved I've added the font option.

Attachments:

fontparser_alignproblem_what_problem_V1B.gh, 23 KB

Permalink Reply by Alessio Erioli on February 11, 2016 at 7:15am

the font option is a nice touch! Thanks Peter. Since I need this mostly for laser cutting text I use monoline fonts, thus I made the polyline closing operation an option as well.

I also did the same thing you did in here (defining the transformation outside the loop) but the result didn't change. The only real difference is that you build a new List (or set in V1C), but for the life of me I cannot understand why this makes the alignment work (and why it works in the VB.net without resorting to a new List/Set).

Permalink Reply by peter fotiadis on February 11, 2016 at 6:32am

The "optimistic" loop issue addressed via the trad (crude) way:

using HashSet<Polyline> instead of List.

I hear you people: Shame on you > this IS crude to the max.

yes it is.

Attachments:

fontparser_alignproblem_what_problem_V1C.gh, 23 KB

Permalink Reply by Alessio Erioli on February 11, 2016 at 6:53am

They definitely should be 16... I'll look into the loop (also through Peter's solutions), but that doesn't explain why the same 200 are aligning correctly if I pass the list to another component and act funny inside the first one. I'll go fix stuff now... thanks to you both!

Permalink Reply by peter fotiadis on February 11, 2016 at 7:32am

Well ... I wish you the best for resolving the crazy loop issue.

BTW: don't make a habit to use HashSets for correcting "faulty" loops (it's a very crude way, he he, used kinda as an emergency Plan Z).

Since you are after trans matters ... have some fun with this attached.

best

Attachments:

Combine_trans_V1.gh, 122 KB

Permalink Reply by Alessio Erioli on February 11, 2016 at 8:17am

this combine transformation looks interesting, I'll play with it with more time on my hands! Thank you!

Permalink Reply by peter fotiadis on February 11, 2016 at 8:33am

I think that a scale trans is a must (not to mention a myriad of other ways to do WOW stuff: rotated around a point, randomly scaled blah, blah).

Put your corrected code into this.

Attachments:

fontparser_alignproblem_what_problem_V1CA.gh, 16 KB

Permalink Reply by Alessio Erioli on February 11, 2016 at 8:16am

Ok, fixed the loop (made it a lot simpler -I didn't bother to modify it until now, but it was quite tricky for a lot simpler task....) and the problem with the align transformation disappeared concurrently. Mateusz, I agree there's no bug in the alignment per se, but I still cannot understand why it acted funny with single line strokes (that's what those 200 Polylines were...).

Here's the fixed version (I'll add a few more options about justification later on).