Enough people have to ask loud enough
Let me interject a technical answer on that, Noel. Mathematically, there is absolutely no reason the original IBM PC with all of it's many limitations could not do the axis translations needed to rotate a board and have it reprocessed to merge 90-270 degrees should N3V want to hire a summer intern, any college sophomore should be able to outline the subroutines needed. Actually, since we're discussing only 90 degree steps, that simplifies the math considerably.
The math is a simple straight forward exercise in mainly applied trigonometry, generating a general transformation of the stored co-ordinates of the data set onto the new co-ordinate reference axis...calculated in this case, around the theoretical center, much the way a centroid is calculated. (Think Areas, and filling areas of a planar shape. The altitudes are paired with X-Y co-ord pairs and just go along for the ride in the data storage elements.)
Technically the centroid is the center of rotation of a rigid body, which in a plane, we generally describe in terms of some polygon, which in the aggregate is a mesh. Many triangles. (Triangle math is taught in Junior High through college, when engineers and scientists finally see where the physical world meets the applied mathematics many get too bored with to learn properly. But I digress.)
Gee think N3V programmers know anything about meshes? Or that any polygon can be (and usually is) resolved down to a series of triangles, the simplest polygon? Even a circle, at the limits of digital representations is mathematically approximated by large rectangles inscribed within, the filled with the smaller triangles to fill up the edges, so to speak. The center of rotation is determined by the perimeter shape, in our case a function of nn X720 meter boards along the two reference axes. However, in sum, the math used to calculate the 3D world on the fly as we ride through it probably already has the right math functions as sub-program and subroutines that could be called to do the calculations. The rest of it is mass, a big merge element would require the intermediary step of using hard disk storage of the translated data set. Then, math completed, the stored new axis data set could be brought back into memory supplanting the data of the rotated map layout.
Have you ever had the experience of working with a tool or even three tools back and forth for a while in surveyor, then wanted to change tools, but the applications software delays, almost seems to stagger, only slowly with some delay slowly opening up the tab for the new tool? Happens to me all the time. I surmised after the first couple of dozen times Surveyor was shifting resource libraries, the .dll (dynamic linked libraries) files holding specialized parts of the computer systems smarts. It staggers, because it's designed to take up as little space in RAM as it can... so the tool .dll needs loaded, and then so does its API data, roads, bridges, and all that. There's no reason they couldn't put the math in the .dll container, and then stagger through the calculations one point at a time. We just need enough people to ask often enough for the feature to have them develop itl
I don't see a lot of virtue in this standard module business, but if you do implement it, do it at a higher elevation than zero. No reason a set of modules once you settle on the track layout can't be elevation shifted in 20 m steps and generate a family of modules suffixed or prefixed with the elevation (e.g. "Z-0320m-EtoW mainline module, level", "Z-0140m-EtoS 6x6 corner turn module", and so forth). The Z- prefix will serve to put such pieces down off the alphabetically sorted routes lists, a little trick I learned once programming a data base language that ran 2 million lines of code, give or take. In other words, before building modules, also build a naming convention which self-identifies what you are storing with that name. Something I went through earlier today organizing screenshots for tutorials on the Trainz Wikibook. // Frank
Let me interject a technical answer on that, Noel. Mathematically, there is absolutely no reason the original IBM PC with all of it's many limitations could not do the axis translations needed to rotate a board and have it reprocessed to merge 90-270 degrees should N3V want to hire a summer intern, any college sophomore should be able to outline the subroutines needed. Actually, since we're discussing only 90 degree steps, that simplifies the math considerably.
The math is a simple straight forward exercise in mainly applied trigonometry, generating a general transformation of the stored co-ordinates of the data set onto the new co-ordinate reference axis...calculated in this case, around the theoretical center, much the way a centroid is calculated. (Think Areas, and filling areas of a planar shape. The altitudes are paired with X-Y co-ord pairs and just go along for the ride in the data storage elements.)
Technically the centroid is the center of rotation of a rigid body, which in a plane, we generally describe in terms of some polygon, which in the aggregate is a mesh. Many triangles. (Triangle math is taught in Junior High through college, when engineers and scientists finally see where the physical world meets the applied mathematics many get too bored with to learn properly. But I digress.)
Gee think N3V programmers know anything about meshes? Or that any polygon can be (and usually is) resolved down to a series of triangles, the simplest polygon? Even a circle, at the limits of digital representations is mathematically approximated by large rectangles inscribed within, the filled with the smaller triangles to fill up the edges, so to speak. The center of rotation is determined by the perimeter shape, in our case a function of nn X720 meter boards along the two reference axes. However, in sum, the math used to calculate the 3D world on the fly as we ride through it probably already has the right math functions as sub-program and subroutines that could be called to do the calculations. The rest of it is mass, a big merge element would require the intermediary step of using hard disk storage of the translated data set. Then, math completed, the stored new axis data set could be brought back into memory supplanting the data of the rotated map layout.
Have you ever had the experience of working with a tool or even three tools back and forth for a while in surveyor, then wanted to change tools, but the applications software delays, almost seems to stagger, only slowly with some delay slowly opening up the tab for the new tool? Happens to me all the time. I surmised after the first couple of dozen times Surveyor was shifting resource libraries, the .dll (dynamic linked libraries) files holding specialized parts of the computer systems smarts. It staggers, because it's designed to take up as little space in RAM as it can... so the tool .dll needs loaded, and then so does its API data, roads, bridges, and all that. There's no reason they couldn't put the math in the .dll container, and then stagger through the calculations one point at a time. We just need enough people to ask often enough for the feature to have them develop itl
I don't see a lot of virtue in this standard module business, but if you do implement it, do it at a higher elevation than zero. No reason a set of modules once you settle on the track layout can't be elevation shifted in 20 m steps and generate a family of modules suffixed or prefixed with the elevation (e.g. "Z-0320m-EtoW mainline module, level", "Z-0140m-EtoS 6x6 corner turn module", and so forth). The Z- prefix will serve to put such pieces down off the alphabetically sorted routes lists, a little trick I learned once programming a data base language that ran 2 million lines of code, give or take. In other words, before building modules, also build a naming convention which self-identifies what you are storing with that name. Something I went through earlier today organizing screenshots for tutorials on the Trainz Wikibook. // Frank
