LDraw Torus Generator

[Kevin]

UPDATE:  To save scrolling all the way through this thread, here is the latest version of my LDraw Torus Generator, converted to a web page and hosted on the Google Cloud Platform:  http://ldtorgen.appspot.com/

-----

I've been using 3D arrows for a while in the instructions I create, assembling the components from LDraw primitives.  Recently I've wanted to create curved arrows, but I've found there aren't enough existing LDraw torus primitives to give me the fine control over the major and minor radii that I need.  And there are even fewer high-definition torus primitives--necessary to create smoothly-curved arrows when rendering with POV-Ray. 

I built a simple spreadsheet to generate the specific torus sections I needed, then generalized it to make it more useful.  I've uploaded the spreadsheet to Google Docs so that anyone can use it.  It generates the quadrilaterals and all conditional lines for each section.  

LDraw Torus Generator


Simply enter the number of sections in a full torus (LDraw uses 16 for low-def and 48 for high-def), the major radius (the radius of the full torus), and the minor radius (radius of a cross-section) in the green cells.  The spreadsheet generates a complete .dat file with a file name consistent with the LDraw torus naming standard.  Then copy the blue cells to a file in your LDraw directory or a new model in your MPD file.

The torus segments are generated with 16-sided cross sections aligned for compatibility with existing disc and edge primitives.  This has provided sufficient resolution for my purposes, even with POV-Ray rendering.  I may expand to include 48-sided cross sections in the next iteration.

To generate a complete arrow, you will need to copy and rotate the torus segment to build the desired arc, then add a cone, two discs, and three circles of edges.  

   

I'd appreciate any feedback or recommendations for improvements.

Thank you.


Kevin

[Magnus Forsberg]

How is this different from ToriCalc and PrimGen2 ?

[Kevin]

How is this different from ToriCalc and PrimGen2 ?

Aside from being more limited in scope, apparently not much.  :-)

I could have saved myself a couple hours of work if I'd known about those beforehand.

[Magnus Forsberg]

Sorry, didn't mean to spoil the fun....

But, I think it could be useful to have anyway. It creates a mixed resolution lo/high-primtives. Right?
I sometimes want to have a "primitive" with the minor radius in normal resolution (16-sided) and the major radius in hi-res (48-sided).
This seams to be impossible do in PrimGen2.

[Kevin]

Sorry, didn't mean to spoil the fun....

But, I think it could be useful to have anyway. It creates a mixed resolution lo/high-primtives. Right?
I sometimes want to have a "primitive" with the minor radius in normal resolution (16-sided) and the major radius in hi-res (48-sided).
This seams to be impossible do in PrimGen2.

No worries.  The fun was creating the spreadsheet in the first place.

Yes, that's exactly what it does.  I found that hexadecagons were good enough for the cross section of my tori, but I needed the higher resolution around the major radius.  The arrows in the example I posted had only 2 segments at low resolution.  At high resolution they have 6, and that is enough to smooth them out.

Thanks!

Kevin

[Philippe Hurbain]

I too would like to see mixed mode tori! I often needed them. I propose to create a new kind of tori, with a file name beginning with tm instead of t (the rest of the nomenclature beeing the same) and place them in the \48 folder. What others think of this? To make this really fly, we need an update of primgen2 (Mike, Nils?) though Kevin tool can be used in the meantime, and some primitive substitution support by LDView (Travis?)

[Kevin]

I too would like to see mixed mode tori! I often needed them. I propose to create a new kind of tori, with a file name beginning with tm instead of t (the rest of the nomenclature beeing the same) and place them in the \48 folder. What others think of this? To make this really fly, we need an update of primgen2 (Mike, Nils?) though Kevin tool can be used in the meantime, and some primitive substitution support by LDView (Travis?)

I updated my Google Doc sheet to use your suggested "tm" prefix.  I think that makes the "48" redundant in the filename (though I haven't removed it yet). 

Perhaps the new standard could be simply tmi####.dat, tmo####.dat, and tmq####.dat.  That would leave one extra character (assuming a desire to adhere to 8.3 filenames) that could potentially be used for some other piece of information--perhaps a count of 1/48 slices with specific letters to describe 12-, 16-, 24-, and 48-slice tori.

Kevin

[Philippe Hurbain]

I too would like to see mixed mode tori! I often needed them. I propose to create a new kind of tori, with a file name beginning with tm instead of t (the rest of the nomenclature beeing the same) and place them in the \48 folder. What others think of this? To make this really fly, we need an update of primgen2 (Mike, Nils?) though Kevin tool can be used in the meantime, and some primitive substitution support by LDView (Travis?)

I updated my Google Doc sheet to use your suggested "tm" prefix.  I think that makes the "48" redundant in the filename (though I haven't removed it yet). 

Perhaps the new standard could be simply tmi####.dat, tmo####.dat, and tmq####.dat.  That would leave one extra character (assuming a desire to adhere to 8.3 filenames) that could potentially be used for some other piece of information--perhaps a count of 1/48 slices with specific letters to describe 12-, 16-, 24-, and 48-slice tori.

Kevin

Sticking with 8.3 is no longer a requirement... 48 in filename remains needed if the new tori are to go in p\48 folder

[Magnus Forsberg]

OK, we need this, but then the header needs more tweaking.

The naming of torus primitives are tricky. A correct name would be:  48/tm48q?????.dat
The parttype should be: Unofficial_48_Primitive.
It should have a BFC statement:  0 BFC CERTIFY CCW
A scalable primitive must have four decimals on every x/y/z value.

OK, maybe I'm nitpicking, but these changes would make it usable.

[Kevin]

OK, we need this, but then the header needs more tweaking.

The naming of torus primitives are tricky. A correct name would be:  48/tm48q?????.dat
The parttype should be: Unofficial_48_Primitive.
It should have a BFC statement:  0 BFC CERTIFY CCW
A scalable primitive must have four decimals on every x/y/z value.

OK, maybe I'm nitpicking, but these changes would make it usable.

Thanks for the additional feedback.  I have made the requested changes:

1) If the sections per circle is 48 or greater, "48\" is prepended to the name, and "_48" is inserted into the parttype. 
2) Added support for "unit" in the file name when the minor radius = 1
3) I corrected and verified the CCW winding for all quadrilaterals and added the BFC statement.
4) I have expanded the precision to 4 decimal places but allow truncation of trailing zeros for quads and edges.

Right now it only generates q-type tori.  Would it be useful to add i-, o-, and r- types as well?

Kevin

[Philippe Hurbain]

Right now it only generates q-type tori.  Would it be useful to add i-, o-, and r- types as well?

For parts modeling usage the i- and o- are the most useful, so yes! For mixed mode tori, the r- makes little sense as the outside of a r- has the same order of magnitude of size in all directions.

Otherwise, the "degrees per section" and "edges per slide" cells are currently locked? (I can't change them)

The open end control points of condlines is wrong: they must be made to meet a tangent cylinder, not another torus. In the same spirit, for i- and o- types if you implement them, top condlines must fit a plane, and side condlines a cylinder.

[Kevin]

Right now it only generates q-type tori.  Would it be useful to add i-, o-, and r- types as well?

For parts modeling usage the i- and o- are the most useful, so yes! For mixed mode tori, the r- makes little sense as the outside of a r- has the same order of magnitude of size in all directions.

Otherwise, the "degrees per section" and "edges per slide" cells are currently locked? (I can't change them)

The open end control points of condlines is wrong: they must be made to meet a tangent cylinder, not another torus. In the same spirit, for i- and o- types if you implement them,  top condlines must fit a plane, and side condlines a cylinder.

Degrees_per_section is locked because it's calculated from Sections_per_circle (degrees = 360/sections). 

Sections per slice is locked because that's all I've ever needed.  It will be unlocked in the next version (after I've learned Google App Script, since VB doesn't port from Excel to Google Docs).  Of course, anything other than 16 or 48 will require additional custom primitives unless you're building a full torus from the generated slice.

I think I understand what you're saying about the condlines.  Instead of using next and prior torus slices for the control points of the two cross sections, I should be using points on perpendicular projections of each cross section.  I'll work on that fix this evening.

Thanks again for the feedback and suggestions.

Kevin

[Philippe Hurbain]

Degrees_per_section is locked because it's calculated from Sections_per_circle (degrees = 360/sections). 

My bad... Actually I was looking for a way to generate say a quarter cylinder (thus with 12 sections) torus?

[Kevin]

Degrees_per_section is locked because it's calculated from Sections_per_circle (degrees = 360/sections). 

My bad... Actually I was looking for a way to generate say a quarter cylinder (thus with 12 sections) torus?

Got it.  That, along with variable number of edges on the cross-sectional polygon, is dependent on my learning Google App Scripting.

In the meantime, I'm using MLCad to duplicate and rotate a section, a 4-4disc, and a 4-4edge simultaneously as many times as I need.  The added benefit is that my terminating disc and edge end up in the right place, though I do have to go back and delete the unneeded discs and edges.

Meanwhile, it appears that my interpretation of your comment about the control points for the condlines is not correct (based on existing torus primitives).  Time to dig in and figure this out.

Kevin

[Kevin]

Right now it only generates q-type tori.  Would it be useful to add i-, o-, and r- types as well?

For parts modeling usage the i- and o- are the most useful, so yes! For mixed mode tori, the r- makes little sense as the outside of a r- has the same order of magnitude of size in all directions.

Otherwise, the "degrees per section" and "edges per slide" cells are currently locked? (I can't change them)

The open end control points of condlines is wrong: they must be made to meet a tangent cylinder, not another torus. In the same spirit, for i- and o- types if you implement them,  top condlines must fit a plane, and side condlines a cylinder.

I have fixed the open end control points for the conditional lines parallel to the cross-section.

Thank you.

Kevin

[Magnus Forsberg]

I have fixed the open end control points for the conditional lines parallel to the cross-section.

Yes, but these conditional lines are only valid on a single section tori. Or at each end of a multi section torus.
If you want to use the method of copy-paste-rotate to create a multi section torus, they will be overlapping and incorrect between the sections.

[Kevin]

I have fixed the open end control points for the conditional lines parallel to the cross-section.

Yes, but these conditional lines are only valid on a single section tori. Or at each end of a multi section torus.
If you want to use the method of copy-paste-rotate to create a multi section torus, they will be overlapping and incorrect between the sections.

Yes, that makes sense. 

I'm working on updating the spreadsheet to properly generate an arbitrary number of sections.    I'll provide a link to the Excel version when I'm done, then work on converting the VBA to GAS for Google Docs.

For a file with 3 of 48 sections, would the file name be 48\3-48tmq####.dat or something else?  Should we stick with 48\tm48q####.dat for single-section tori, or use 48\1-48tmq####.dat?

Thanks again.

Kevin

[Philippe Hurbain]

Tori are supposed to have only a power of two number of sections. That's an heritage of 8.3 filename restrictions, but when this constraint was removed it was preferred to keep a consistent naming scheme and to avoid name change (~movedto creation) of a lot of files.

[Kevin]

Tori are supposed to have only a power of two number of sections. That's an heritage of 8.3 filename restrictions, but when this constraint was removed it was preferred to keep a consistent naming scheme and to avoid name change (~movedto creation) of a lot of files.

I did a little more looking at the existing official torus primitives.  With 48 divisions, it looks like the naming standard requires only that the number of sections being generated be a divisor of 48 (e.g. t06q5000.dat and t12o0349.dat).  The two digits represent the reciprocal of the fraction of the torus being generated.  For low-res primitives with 16 divisions, being a divisor of 16 and being a power of 2 are synonymous.

Consequently, the (potentially) correct name for the 3-of-48 example about would be 48\tm16q####.dat, and it would be permissible to generate hi-res tori with 1, 2, 3, 4, 6, 8, 12, 16, 24, and 48 sections.

Do you agree?

Thanks.

Kevin

[Philippe Hurbain]

For low-res primitives with 16 divisions, being a divisor of 16 and being a power of 2 are synonymous.

Indeed

Do you agree?

I do!

[Kevin]

I have updated my spreadsheet to generate multiple segments with the correct conditional lines.  It's all in VBA right now, so I won't be able to upload it to Google Docs until I convert the VBA to GAS.

Meanwhile, here's a link to the spreadsheet:  https://www.dropbox.com/s/a8qiumwq8vtnol....xlsm?dl=0

Thanks for all the input and recommendations.  I hope I've gotten it to a point where it's useful.

Kevin

[Philippe Hurbain]

Seems to work fine, the condlines look good. On my oooold Excel 2000 I had to comment out the cell tinting functions that seem to be unsupported, and I had to run the macro manually. But worked fine after that.
Edit: once the offending functions are removed, the macro autoruns fine!

[Kevin]

Seems to work fine, the condlines look good. On my oooold Excel 2000 I had to comment out the cell tinting functions that seem to be unsupported, and I had to run the macro manually. But worked fine after that.

Thanks for checking it out and for the feedback.  I'll get started on a port to Google Docs so it's not so version-dependent.

On my version of Excel (2013), it automatically generates the torus whenever any of the 5 input cells are changed.  That functionality should also work in Excel 2000, but it's possible I'm using some feature that isn't supported in that version.

Kevin

[Magnus Forsberg]

Seems to work fine, the condlines look good. On my oooold Excel 2000 I had to comment out the cell tinting functions that seem to be unsupported, and I had to run the macro manually. But worked fine after that.
Edit: once the offending functions are removed, the macro autoruns fine!

It work fine here too, on Excel 2010. Only one issue. Is there a way to force excel to write a point instead of a comma?
If not, it's easy to replace them in LDDP or LDPE.

[Philippe Hurbain]

It work fine here too, on Excel 2010. Only one issue. Is there a way to force excel to write a point instead of a comma?

I have trouble understand how people can survive without making "." the decimal separator of their Windows
So many programs - especially in LDraw realms, but not only - are painful to use otherwise...

[Kevin]

Seems to work fine, the condlines look good. On my oooold Excel 2000 I had to comment out the cell tinting functions that seem to be unsupported, and I had to run the macro manually. But worked fine after that.
Edit: once the offending functions are removed, the macro autoruns fine!

It work fine here too, on Excel 2010. Only one issue. Is there a way to force excel to write a point instead of a comma?
If not, it's easy to replace them in LDDP or LDPE.

Try it now.  I added code to check your decimal separator when the workbook is opened.  If it's not a period, then it saves your current values, sets the decimal separator to a period, the thousands separator to a comma, and turns off the flag to use the system separator values.  It resets those values when you close the workbook.

This may affect other Excel spreadsheets that you have open concurrently.

Better way to do it:  since all the primitives are built up as strings, I Just replace all commas with periods before displaying them.  Let me know if you're still running into a problem.

Kevin

[Kevin]

Seems to work fine, the condlines look good. On my oooold Excel 2000 I had to comment out the cell tinting functions that seem to be unsupported, and I had to run the macro manually. But worked fine after that.
Edit: once the offending functions are removed, the macro autoruns fine!

I updated the macros to only use formatting that is compatible with Excel 2000.  Would you mind trying it?  I've been able to verify that it is compatible with Excel 2003 and above, but I don't have a way to test in Excel 2000.

Thank you.

Kevin

[Travis Cobbs]

I too would like to see mixed mode tori! I often needed them. I propose to create a new kind of tori, with a file name beginning with tm instead of t (the rest of the nomenclature beeing the same) and place them in the \48 folder. What others think of this? To make this really fly, we need an update of primgen2 (Mike, Nils?) though Kevin tool can be used in the meantime, and some primitive substitution support by LDView (Travis?)

Please send me at least one file of each type (q, i, and o), and I'll see about supporting them in LDView. If you have at least one file where at least one of them is used properly, that would also be very helpful.

[Philippe Hurbain]

@ Travis and Kevin: Yes, will do that ASAP!

[Philippe Hurbain]

Yes it works!
Possible improvements:
- display a warning if the number of section is incompatible with naming scheme (eg. a 5 sections torus).

- Give the possibility to normalize the torus to generate primitives (make major radius = 1 while keeping minor/major ratio)

[Kevin]

Yes it works!
Possible improvements:
- display a warning if the number of section is incompatible with naming scheme (eg. a 5 sections torus).

- Give the possibility to normalize the torus to generate primitives (make major radius = 1 while keeping minor/major ratio)

Both suggestions should be fairly easy to implement.  An while I'm at it, what other checks do you think would be useful?  Here are the ones that immediately come to mind:
1)  Divisions around the major radius not 16 or 48
2)  Divisions around the minor axis not 16 or 48
3)  Number of sections not compatible
4)  Major radius not 1

EDITED TO ADD:
5) Yes/No selector for the above LDraw conformance checks. No need to get a warning if you know you're not trying to be compliant.

As for the normalization, I'm imagining that to be a Yes/No option, and not something to force.  I used the generator to build a 24-segment torus with major radius 40 and minor radius 4 for a LEGO project today.

   

I'm most of the way done with the port to Google Docs.  What's your preference going forward--Excel, Google Docs, or both?

BTW--for anybody considering porting VBA to GAS, the ^ is exponentiation in VBA but bitwise XOR in GAS.  That one took me a little while to figure out.  :-)

Kevin

[Philippe Hurbain]

Please send me at least one file of each type (q, i, and o), and I'll see about supporting them in LDView. If you have at least one file where at least one of them is used properly, that would also be very helpful.

Here we are...

[Kevin]

I have completed porting the Excel sheet and code to Google Docs.  It's still in the same location:  

https://docs.google.com/spreadsheets/d/1...ZVxhpZndo/

Google Docs is definitely slower than Excel, but it's not too horrible, even when generating a full 48x16 torus.  And this eliminates any dependence on specific versions of non-free licensed software.

Next up:  checking for LDraw standards compliance.

As always, feedback will be greatly appreciated.

EDIT: Forgot to update the protection, so some input cells weren't editable. I have removed all protection from the sheet for now.

Kevin

[Travis Cobbs]

Please send me at least one file of each type (q, i, and o), and I'll see about supporting them in LDView. If you have at least one file where at least one of them is used properly, that would also be very helpful.

Here we are...

Thanks. I got them supported in my development code (including POV-Ray export). The next beta will include this support.

[Kevin]

I have added support for Inner and Outer torus sections to my LDraw Torus Generator on Google Docs:

https://docs.google.com/spreadsheets/d/1...ZVxhpZndo/

Also, instead of automatically generating a torus with each cell update, I added a button.  This allows you to make multiple input parameter changes before generating your desired torus.

I haven't yet implemented the checks for LDraw compliance even though I have added the drop-down selector for this option.

As always, any feedback is greatly appreciated.

Thank you.

Kevin

[Magnus Forsberg]

I can't get it running. All I get is an error message: An error occured in the script ButtonClick

[Kevin]

I can't get it running. All I get is an error message: An error occured in the script ButtonClick

Apparently I need to understand how to authorize bound scripts for any user.  Working on it now.

Sorry for the inconvenience.

Kevin

[Kevin]

I have given up trying to get Google Docs to allow everybody--including anonymous users--to run the bound scripts attached to the sheet container.  Consequently, I have ported the code to a Google Cloud web page.  The URL is http://ldtorgen.appspot.com/

The page is pretty basic, but I wanted to get it back up as quickly as I could.  I have added support for Inner and Outer torus sections to go along with the Tube.  I have also added some basic input validity checking as well.

As always, any feedback is greatly appreciated.

Thank you.

Kevin