Glad to be starting out taking part in the rollout of Rhino for Mac. I’ve recently purchased the commerical build (5.1) and am happy with how things work for regular modeling and my past usage as a Windows operator.
The biggest missing feature for what I’d like to do in Rhino is to import airfoil sections. I used to rely heavily on this rhinoscript and database:
Where to start? I see that Python is being put forward and McNeel is hoping to get folks making cross-platform suppported scripts and plugins functioning.
I am not a programmer, though looking at the old Rhino script, it seems like it ran a fairly simple set of functions to loft curves through the imported points and then close that into a single curve. It worked well enough for my hobby-use of RC plane design up to giant scale model wings.
Can someone please give me specific directions on how I may begin the process of getting this script ported over to Rhino for Mac? Sadly, I do need a bit of hand-holding here as I have not programmed since the late 1980s.
Glancing over the script, it’s indeed not complex at all. I myself have no spare time at hand to help you out, but I reply to maybe provide an incentive for others to give it a go and help you out:
The python script functionality and workflow outline:
1: browse for file .dat file (provided in zip package)
2: read the file with: name in the first line and next lines ascii XY coordinates to be converted to 3D points
3: Create and add to the document an interpolated curve through these 3D points
Yeah, I would have looked at it today, but I have a mill job to get out, if nobody has responded I can look tomorrow…
Edit: you can have a go with the following, it’s my first try at airfoils. I noted on testing a few sections that the points don’t always result in nice, smooth curves… The script below will try to import .dat files in either Lednicer or Selig formats (slightly different) and will add the curves plus the points for reference. Selig should be all one curve if I understood correctly, Lednicer will be 2 (upper and lower). The curves are named after the file name.
Let me know if it errors out somewhere, the file format doesn’t seem to be all that consistent. I hacked this together rather quickly; I didn’t put a lot of comments in the script. If you need more explanations, please ask…
Thank you so much for drafting that. I have been playing with figuring out how to get Rhino to parse the script so that what jodyc111 noticed doesn’t happen; some of the .dat point files loft curves that are not fair between points, particularly around the leading edge (the front) of the wing sections. Even common NACA00-series files are getting messed up.
I found a setting in the new Rhino curve tools that fixes part of this problem. Since your script also keeps the points in the generated object, it was easy for me to experiment. Here is what I found:
Rhino interpolates perfect curves when the Knots selection is set to Chord.
This is great, and I think that with some reading I can figure out how to fine tune the option to do so. I understand your python script, though I do not know how to to write it. What I will seek to add are two primary functions, and to ask one of the community:
Adding the Knot: Chord function to the script to see if that works in automation as it does when building a curve manually through the points.
2.Adding a dialogue that asks how many units in the open model that the coordinates can be scaled to, ex: can it be one major line in the grid, a linear dimension such as, “100mm”, or is this a limitation of the language and how Rhino is able to parse .dat files? I ask because the old script for Windows also only lofted the airfoils into one unit of length, no matter what your file preferences were set to. That leads to always having to scale your wing up to the desired size post import, and can do funny things with tolerances if minor grid lines are microscopic.
Can I pin the RunRhinoScript>‘this script that Helvetosaur is making’, to the user interface? It of course is showing up in the right-click menu after I found the command and ran it the first time, though I’d like to make it a standard icon or tool menu entry. Any help there is great, and I’ve not delved into the new UI deep enough to see what is presently possible.
Very excited to see how this progresses, and it’s already usable so a huge thank you for taking the time to look into the problem and to write the code.
This can be programmed in the script, there are options for Uniform, Chord and SqrtChord as in the normal Rhino command. However, I did not find this helped in all cases. In the points file below (taken from a 737 wing profile), no matter which one of the 3 options is chosen, there is still a “bump” in the lower leading edge area. I marked the offending points in orange/red. Adjusting these points somewhat (especially the red point) can result in a much “fairer” curve.
This is a hidden folder, to navigate to it, press and hold the Alt key and pull down the “Go” menu, you will see “Library” - navigate to the Scripts folder along the above path from there. For ease of use the next time, make a shortcut to the scripts folder on your desktop.
In Preferences>Aliases, create a new alias - call it anything you want- and in the right-hand path box next to the alias, copy and paste the following:
! _-RunPythonScript "ScriptFileName"
Where ScriptFileName is the name of the file you just copied to the scripts folder. Do enclose the name in quotes if the filename has spaces in it, even if not, it will not harm to have them.
That’s it, whenever you type the alias, the script will run. You should see it autocomplete even after typing just the first couple of letters.
Also FWIW, None of the 4 sections (root | midspan 1 | midspan 2 | outboard) match the output in Mitch’s file though they should be reading the same information. Perhaps @andras_sobester has more info…
The coordinates in those files are identical (though organized a bit differently - the AirConics one is not divided in an upper and lower profile and the upper coordinates are in the reversed order [and missing the first row]).
File formats do seem to vary a bit… According to this page, there are two main formats, Lednicer and Selig. It would seem that your format is Selig if there is only one profile… I didn’t specifically parse the header to differentiate between the two, I used the fact that there should be a blank line between the two sets of coordinates in Lednicer. But maybe that’s not always the case, I should probably re-write it to be more rigorous.
For reference, the original airfoils in the list and new ones added by Selig are in an x,y format starting from trailing edge, along the upper surface to the leading edge and back around the lower surface to trailing edge. Lednicer’s contributions are upper surface points leading edge to trailing edge and then lower surface leading edge to trailing edge.
I suppose that a script should read both upper and lower surface in a Lednicer-formatted file…
Mitch, thanks again for stabbing away at this. I just opened the 737 wing section that you and wim are talking about and this seems to be just an errant set of data–you can clearly see that the points that you had marked fall well outside of a fair curve, so something else is going on (probably bad data is my guess).
Nice! This should help with experimenting when someone encounters an odd section, or the example NACA sections which are defined by limited numbers of points and rely on the software’s interpolation capabilities more. Thanks!
Fantastic! This should be more than enough to get hobby designers such as myself rolling with the new build, though I’m honestly surprised that more naval architects and aerodynamicists haven’t recompiled a script like this. Well, either way it will be a great boon to the community. Thanks so much again for putting your efforts into making it work, and also for the inspiration re: seeing what can be done with learning a little bit of code. This is really quite cool.
Oh, that’s clever. Again you have my thanks. Looking forward to playing with the next iteration of your ImportAirfoilData.py
And now I’m going to go dig around my Windows archives. Edit: I found it (attached)coord_selig_fmt.zip (1.5 MB) I had augmented that really large Selig/Lednicer database with my own low Reynolds Numbers wing sections a few years ago. Need to check to see if it is outdated though. This includes a selection of high-lift sections as well as some very high-speed laminar sections for other uses. They played very well with Rhino 4 for Windows and that old script; primarily generated stuff for hobby drones/UAVs with open source software X-Foil and an affordable program called Profili Pro. Feels a bit like starting over but much worth the learning curve to get everything consolidated onto one operating system.
Have a great day, and please let me know if I can contribute to your efforts in any manner.
Thanks for digging this up. That’s a nice pile of useful tools to look into and good to see that others have started tackling the airfoil importation problem.
Ooh, exciting! I’m on my way to work and will have a chance to test out your new script this evening. Are there any sets of functions that you’d like me to run it through aside from using a variety of .dat coordinates from the database in combination with the curve-editing tools that are incorporated? If not, I think that I’ll build a model wing using ten or so sections, and then loft surfaces through them to see if building to a solid airframe from there will work. It should.
That’s great that you added joining the trailing edge curve as an option; sometimes it makes sense to do so when modeling in Rhino, so having it as an option during generation is quite nice.
No, just let me know how it works for you - especially if it errors out somewhere - or if it needs anything else. It’s still a one-shot section by section import and will still place each section on the XY plane at 0 - so you will have to re-orient and move the sections into place yourself.
OK, I did just a quick test on a the commonly used ClarkY section though do need to run out the door. Works. Having the curve-editing in the script fixes the leading edge interpolation problem, whereas by default it is lofted with high spots.
I’ll let you know if I encounter any errors, and yes I suppose it’s superfluous to make anything with the curves because it’s easy enough to inspect them after generating the objects.
So far no odd behavior, and I’m going to use the OS X alias trick that you suggested tonight.
Perhaps