bugpyFormex - Bugs: bug #42441, extension of coords.sweepCoords to...

 
 

bug #42441: extension of coords.sweepCoords to provide a list of bases instead of one single Coord object

Submitter:  francesco <francio>
Submitted:  Tue 27 May 2014 04:07:16 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Feature request Status:  Ready For Test
Privacy:  Public Assigned to:  bverheg
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 08 Jul 2014 01:32:21 PM UTC, comment #17: 

I think the (moving)Frenet could and should be used.
The whole first part should be moved to Curve and use (moving)Frenet or avgDirections or directions depending on parameters. movingFrenet would give the most stable direction.

But I have to look and see what they exactly do, and we should
find a proper name. I think frenet would we good, because on a 3D curve you normally want the full frenet frame. It can have parameters to smooth/average or not. And how to compute at the ends of an open curve. And how to compensate on a closed curve.

Then the remainder becomes peanuts: a single positioning method,
and a sweep method. I am not convinced that we should keep the scaling inside the sweep method. Rather create an example of
how to create a scaled sweep.

Anonymous
Tue 08 Jul 2014 01:04:40 PM UTC, comment #16: 

I know it is not exactly what you suggested , but I could not get completely what to do, and for this reason  I was trying to keep it as close as possible as it was before. I started by splitting the function because I was too confused on how manage that. can you explain how to structure and split every function? I can work on that but i need some other epxlanations.

1) directions in the curve method. how? create a function (which name?) that computes the directions calling directions and avgDirections? , could the user specify the enddir? the missing variable can be included? frenet is not an option according to gianluca

2) Positioning along path. The change of the different upvectors and nomals can just be added by checking if they are a list. can it be like taht? should the Positioning be a function?

3) sweepCoords is it then ok like it is? only scaling and the rest is computed somewhere else?

I need to know how to structure everything. The change I made is very small, just splitted the functions in 2 functions, but it works exaclty as before. sweepCoords can be easly now included as a method of Coords, but the positiong should be a function?

address me in the direction you want the functions/methods so that I can correct them.


francesco <francio>
Group Member
Tue 08 Jul 2014 11:42:00 AM UTC, comment #15: 

I am not happy with this function. I still think that the computation of the directions should be a Curve method.

And there should be a Coords position method that positions the Coords according to p,d,normal,upvector, or even better csys1,csys2.

And then the user should do himself the list processing.

We can not just create a specialized function for any problem.
Next, a user might want a positioning where normal changes with every item. And another wants to change upvector. All these cases can better be handled by user functionality.

sweepCoords is different, because it generates multiple things from a single object. (but should become a Coords method instead of a function).

Generally, we should try to avoid functions in favor of methods.

And once more: we should not change the core functionality very lightly. I want it to be as stable as possible, and only change where absolutely needed, in coherence with the general philosophy, and well tested. I will leave this in for now, until I have time to look further into it.

But do not close the bug! ;)

Benedict Verhegghe <bverheg>
Group administrator
Tue 08 Jul 2014 10:54:39 AM UTC, comment #14: 

I did this way(commit 409ce91)

sweepCoords only does a replica of the Coord objet and performms the scaling

positionCoordsObj, performes the positioning along the path but not the scaling. the directions are computed and checked here, because the frenet function cannot be used (thanks to gianbluca's clarifications). I am not suyre if a new method in curve can do this part, by unifying directions and avgDirections and setting enddirs and missing values.


francesco <francio>
Group Member
Mon 07 Jul 2014 12:09:15 PM UTC, comment #13: 

I am not really following but just to clarify: in curve.py there is Frenet and movingFrenet.

The original Frenet is a local coordinate system, which is not good for sweeping because the twist angle is unstable: twisting of 180 degrees can happen when moving to next point (when going from a concave to a convex piece), leading to kinking.

The MovingFrenet minimizes the twisting, exactly like is done in vmtk Parallel Transport Normals (http://www.vmtk.org/tutorials/GeometricAnalysis.html). With the movingFrenet there is no kinking.

Hope this helps.

gianluca de santis <gianlucadesi>
Group Member
Mon 07 Jul 2014 11:49:23 AM UTC, comment #12: 

Actually I don t get why we need frenet. the function directions and avgDirections are not sufficient?

francesco <francio>
Group Member
Mon 07 Jul 2014 11:07:39 AM UTC, comment #11: 

I need some help in this to organize the new functions.

For the directions I can use frenet, though
1 this need to be changed to compute the direction on the points without approximation.

2 How the computation of the directions should work and be named?

francesco <francio>
Group Member
Tue 27 May 2014 08:25:35 PM UTC, comment #10: 

For the first function in https://savannah.nongnu.org/bugs/?42441#comment9, we could probably just use Curve.frenet?

Benedict Verhegghe <bverheg>
Group administrator
Tue 27 May 2014 05:37:11 PM UTC, comment #9: 

But we still shouldn't make the function even more complex than it is already. Your application is not a sweep anyway but a positioning. The best we can do is to break the function up into smaller functional parts. Something like this:

- The computation of the directions could become a method of the Curve classes.

- A function can position items from a list aligned along the directions of the curve, without scaling.

- SweepCoords positions identical copies with scaling.


Benedict Verhegghe <bverheg>
Group administrator
Tue 27 May 2014 05:27:34 PM UTC, comment #8: 

just a small observation. your example would have also worked if path was just a Coord because now has property coords (but failed for the missing directions).

francesco <francio>
Group Member
Tue 27 May 2014 05:20:12 PM UTC, comment #7: 

exactly that.
In ypur example if in sweepCoords(Ci,pi) pi is a Coord object the function will not work, because the path need to be a PolyLine becuse the function need to get the directions and the coords.

the change in the funtion would be just a check if self is list of Coords or just one Coords. Then it will work exactly as before. Something like this




if isinstance(self,list):
        base = [Coords(s).translate(-Coords(origin)) for s in self]
    else:
        base = self.translate(-Coords(origin))
        base = [base for p in points]
    sequence = [ b.scale([scx, scy, scz]).rotate(vectorRotation(normal, d, upvector)).translate(p)
                 for b,scx, scy, scz, d, p in zip(base,scalex, scaley, scalez, directions, points)]
return sequence






francesco <francio>
Group Member
Tue 27 May 2014 05:07:34 PM UTC, comment #6: 

I think I may be getting it now: you probably just want to replace the 'base' variable in the function by some own list?

If so, what you want is just to use the directions and points computed in sweepCoords, and use this for another purpose.
If this is your intention, then we could just create a function returning these points and directions, and then have it used in sweepCoords and in your function.


Benedict Verhegghe <bverheg>
Group administrator
Tue 27 May 2014 05:02:51 PM UTC, comment #5: 

I still do not understand what you are trying to do, or why you can not use something like

[ sweepCoords(Ci,pi) for Ci,pi in zip(Clist,plist) ]

It is important that we get some stability in the core, therefore I only want to change when it is really needed.
Changing this function may again create problems in a lot of Mesh methods.

Benedict Verhegghe <bverheg>
Group administrator
Tue 27 May 2014 04:31:56 PM UTC, comment #4: 

I dont think I can do what I want with this.
Maybe my request is not clear enough. if I have a PolyLine path with points [p1,p2,p3] and a list of Coord objects [C1,C2,C3]
I want to put C1 over p1, ... Cx over px with the directions computed in sweepCoords.
I need otherwise have to do  the same exact function that can also loop over the bases, whiel this was just a small extension of sweepCoors

francesco <francio>
Group Member
Tue 27 May 2014 04:22:31 PM UTC, comment #3: 

[ X.sweepCoords() for X in Xlist ]

Benedict Verhegghe <bverheg>
Group administrator
Tue 27 May 2014 04:21:07 PM UTC, comment #2: 

i have diffrent shape to put over one path, which cannot just be scaled. so concatenation is not an option. sweep coords does exactly what i need orienting every object along the path, but I need to provide the objects.
What do you mean with list comprehension?

francesco <francio>
Group Member
Tue 27 May 2014 04:15:44 PM UTC, comment #1: 

Why do you need a special function to do that? You can probably just concatenate the Coords and then use the single concatenation, or else use a list comprehension.

Benedict Verhegghe <bverheg>
Group administrator
Tue 27 May 2014 04:07:16 PM UTC, original submission:  

I need a function that behaves exactly like sweepCoords, but the base can be a list of Coord objects instead of a single object.

Can I make this change directly in sweepCoords?
Though in this way the input can be of type Coord or a list of Coord. but I am not sure if we can still call it sweepCoords.

 or should I create a function
'arrangeAlongPath'

and let sweepCoords call this one? If this is the case should arrangeAlongPath still be in coords or should be moved somewhere else?

francesco <francio>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gianlucadesi (Posted a comment)
  • -email is unavailable- added by bverheg (Posted a comment)
  • -email is unavailable- added by francio (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-23 bverheg Open/ClosedOpen Closed
    2014-07-08 francio StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code