Despite maintining a Rhino license since Version 4, I’m still only a sometimes user, and never yet a Rhino scripter. I was once halfway competent with Perl, even PostScript, and long, long ago also Forth. But never Python, nor yet VB. It has just now struck me, however, something for which a Rhino script might serve very well. Just maybe perhaps, a description thereof might win the interest of a Rhino scripting guru, this being, I’m sure, a completely new application: transmitting antenna design.
As a ham radio operator, call sign KY8D, my thought goes like this. Via Rhino one could generate a *.3DM file consisting of a single joined line. Said line could traverse 3D space in whatsoever arbitrary fashion as the designer might wish to model. Then, calling a script, the point-to-point coordinates of said joined line would be written out to a file as pure ASCII text.
Let me describe what that would be good for. There exists a program in Fortran called NEC, for “National Electromagnetic Code”, which is used to analyze antenna designs. A number of variants (EZNEC, etc) also exist as stand-alone daughter programs. And it is generally one of these which we ham radio operators make use of in designing antennas. They hide from us the actual Fortran and present instead a convenient GUI.
These daughter programs, younger spinoff’s of the full-fledged NEC also have rudimentary CAD design features … emphasis on ‘rudimentary’. Circles, helixes and such come already built in, but still leave a lot to be desired.
What if, for instance, one wishes to model a helix whose centerline, rather than straight, is warped into a semi-circle? Such things are called “helically wound small loop antennas”. No easy way to model one of those using just only EZNEC. In Rhino, however, it would be easy enough. Likewise many another exotic antenna concept: fractal, figure 8, etc. And yet, even these would be comprised of nothing more than (perhaps a great many) straight-line sequences joined end-to-end.
Saving from Rhino to NEC format would require a pure ASCII output as I shall now describe. My hope, very clearly, is that a capable Rhino scriptor might find the idea a fun project. Probably not much of a market, the cross-section of Rhino license holders with ham radio licenses, and who also design antennas being indeed a very few. Nevertheless…
Find my example *.nec file here: EXAMPLE
… comprised of rows of columns like so …
GW 1 5 -0.391 2.469 10 0.391 2.469 10 0.025
GW 2 5 0.391 2.469 10 1.135 2.228 10 0.025
Where the columns are…
- Always “GW”
- An integer enumerating the “wire number”, same as a line number from 1 to whatever.
- An integer representing “segments”, and could always be “1” just to make things easy.
- Coord X for start of a wire (straight line segment).
- Coord Y for start of a wire.
- Coord Z for start of a wire.
- Coord X for end of same wire.
- Coord Y for end of same wire.
- Coord Z for end of same wire.
- Diameter of said wire (not modelled, just simply stated, or even always just “1”).
… and so on for the next row, with always the starting X, Y and Z equal to the ending X, Y and Z from the “wire” above. Because, in reality, they are all straight segments of the same actual, physical wire. Delimiters are simply spaces, with CRLF for each line’s end.
Many antennas have plural straight wires, often not touching. But Rhino is hardly needed for those. It’s the curvy ones (modelled as many short, straight-line segments), whose geometries wind through loops, where Rhino can prove a most useful tool in antenna design. So much, anyhow, is my thought.
I could, of course, do the same without any script, by clicking on a line end, then copy-and-pasting the X, Y and Z. Over and over, dozens, maybe hundreds of times. Shudder…