CA
Carsten Arnholm
Thu, Jan 4, 2018 6:05 PM
On 03. jan. 2018 03:24, Dan Shriver wrote:
I was toying with the idea of trying to make a Mayan calendar (short
count 52 year cycle).
On 03. jan. 2018 03:24, Dan Shriver wrote:
> I was toying with the idea of trying to make a Mayan calendar (short
> count 52 year cycle).
Just for the fun of it I downloaded a DXF Mayan Haab calendar from
http://www.carveonecncwoodcraft.com/downloads.html
...and made into an OpenSCAD source file
https://gist.github.com/arnholm/2d082bf5604dcae32ead35e74f07eb76
(use "Download ZIP" button)
It is not what you wanted, but it is quite a number of recursive
booleans :-)
Carsten Arnholm
C
cbernhardt
Thu, Jan 4, 2018 10:47 PM
On 03. jan. 2018 03:24, Dan Shriver wrote:
I was toying with the idea of trying to make a Mayan calendar (short
count 52 year cycle).
I downloaded your "mayan_haab_15_inch.scad" and the corresponding DXF file.
None of my computers could digest it. I simplified it by loading the DXF
file into AutoCAD and exploding the POLYLINEs into simple line segments,
thus eliminating all the polygon point arrays and all of the union() and
difference() functions. Of course this makes the DXF file about 30 MEGS, but
it renders in about 2 sec.
http://forum.openscad.org/file/t1309/mayan_haab_exp.jpg
--
Sent from: http://forum.openscad.org/
cacb wrote
> On 03. jan. 2018 03:24, Dan Shriver wrote:
>> I was toying with the idea of trying to make a Mayan calendar (short
>> count 52 year cycle).
>
> Just for the fun of it I downloaded a DXF Mayan Haab calendar from
> http://www.carveonecncwoodcraft.com/downloads.html
>
> ...and made into an OpenSCAD source file
> https://gist.github.com/arnholm/2d082bf5604dcae32ead35e74f07eb76
> (use "Download ZIP" button)
>
> It is not what you wanted, but it is quite a number of recursive
> booleans :-)
>
> Carsten Arnholm
I downloaded your "mayan_haab_15_inch.scad" and the corresponding DXF file.
None of my computers could digest it. I simplified it by loading the DXF
file into AutoCAD and exploding the POLYLINEs into simple line segments,
thus eliminating all the polygon point arrays and all of the union() and
difference() functions. Of course this makes the DXF file about 30 MEGS, but
it renders in about 2 sec.
<http://forum.openscad.org/file/t1309/mayan_haab_exp.jpg>
--
Sent from: http://forum.openscad.org/
A
arnholm@arnholm.org
Fri, Jan 5, 2018 8:06 AM
On 2018-01-04 23:47, cbernhardt wrote:
I downloaded your "mayan_haab_15_inch.scad" and the corresponding DXF
file.
None of my computers could digest it.
If you mean the DXF file, true. That is why I generated the .scad file.
The .scad runs fine in OpenSCAD on both my Windows 10 and Kubuntu 17.04
machines.
I simplified it by loading the DXF
file into AutoCAD and exploding the POLYLINEs into simple line
segments,
If you have AutoCAD you can do such things, yes. That's essentially the
same thing I do (not using AutoCAD) with conversion to .scad (or other
formats).
Carsten Arnholm
On 2018-01-04 23:47, cbernhardt wrote:
>
> I downloaded your "mayan_haab_15_inch.scad" and the corresponding DXF
> file.
> None of my computers could digest it.
If you mean the DXF file, true. That is why I generated the .scad file.
The .scad runs fine in OpenSCAD on both my Windows 10 and Kubuntu 17.04
machines.
> I simplified it by loading the DXF
> file into AutoCAD and exploding the POLYLINEs into simple line
> segments,
If you have AutoCAD you can do such things, yes. That's essentially the
same thing I do (not using AutoCAD) with conversion to .scad (or other
formats).
Carsten Arnholm
MP
Mark Peeters
Fri, Jan 5, 2018 3:29 PM
I'm confused by the idea of 4 gears.
Looks like the dates are always just 3 characters. I think a 4 gear
solution would be hard to read.
The huge gear is an issue to print, maybe something like the flip clock
could take up less space to display the characters?
On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver tabbydan@gmail.com wrote:
That's a decent representation. But they simplified the "secular year"
(365 day part) to be one BIG ring/gear (to get around the problem of the
odd month at the end).
I'm wondering if there is some way to do it as four gears.
If it was just a 260 day cycle (20 months of 13 days each) and a 360 day
cycle (18 months of 20 days each) it would be relatively easy.
Something would simultaneously turn the 13 day ("sacred month") wheel 1/13
revolution and the 20 day ("secular month") wheel 1/20th revolution. Each
month day wheel would have one tooth between the first and last days of the
month that tooth would cause the outer ring to rotate one spot (advancing
the "month"). The two outer rings would not need teeth between them (this
would reduce wear caused by things not being perfect in the real world and
thus having the months maybe not being perfectly in synch).
The big problem is that the "secular year" has 365 days and thus 19 months
with the last one being only 5 days. If I call the last month Dec and the
first one Jan... I have an imperfect workaround. The 20 day month ring has
2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6 (small
tooth). The month name ring has a smaller inner radius for the last month
so it catches at 5... The problem is that instead of starting over on Jan
1, the first day of the new year will read Jan 6, not sure how to correct
that.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_3732112203366432411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters peetersmarkg@gmail.com
wrote:
I think this shows and describes the calendar cycles and how they go
together.
https://youtu.be/BeE-3BBqG58
On Jan 3, 2018, at 12:25 PM, Dan Shriver tabbydan@gmail.com wrote:
Looking at it again I guess it would be at least four gears because the
"secular" 365 calendar is subdivided in an odd way. 18 months of 20 days
each, plus one special month at the end of just five days.
The Aztec sun stone is odd because it mixes various info together. It
has calendric info but is not a calendar, it has some royal history, and in
the center a prediction about how the 5th" sun/ world" would end. The
Aztecs believed they were living in the 5th world or sun, of a sequence of
such worlds/ suns.
I am curious how that was generated since it could help me with the
glyphs.
On Jan 3, 2018 8:28 AM, "cbernhardt" charlie@carols62.com wrote:
I'm confused by the idea of 4 gears.
Looks like the dates are always just 3 characters. I think a 4 gear
solution would be hard to read.
The huge gear is an issue to print, maybe something like the flip clock
could take up less space to display the characters?
On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver <tabbydan@gmail.com> wrote:
> That's a decent representation. But they simplified the "secular year"
> (365 day part) to be one BIG ring/gear (to get around the problem of the
> odd month at the end).
>
> I'm wondering if there is some way to do it as four gears.
>
> If it was just a 260 day cycle (20 months of 13 days each) and a 360 day
> cycle (18 months of 20 days each) it would be relatively easy.
>
> Something would simultaneously turn the 13 day ("sacred month") wheel 1/13
> revolution and the 20 day ("secular month") wheel 1/20th revolution. Each
> month day wheel would have one tooth between the first and last days of the
> month that tooth would cause the outer ring to rotate one spot (advancing
> the "month"). The two outer rings would not need teeth between them (this
> would reduce wear caused by things not being perfect in the real world and
> thus having the months maybe not being perfectly in synch).
>
> The big problem is that the "secular year" has 365 days and thus 19 months
> with the last one being only 5 days. If I call the last month Dec and the
> first one Jan... I have an imperfect workaround. The 20 day month ring has
> 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6 (small
> tooth). The month name ring has a smaller inner radius for the last month
> so it catches at 5... The problem is that instead of starting over on Jan
> 1, the first day of the new year will read Jan 6, not sure how to correct
> that.
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> <#m_3732112203366432411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters <peetersmarkg@gmail.com>
> wrote:
>
>> I think this shows and describes the calendar cycles and how they go
>> together.
>> https://youtu.be/BeE-3BBqG58
>>
>> On Jan 3, 2018, at 12:25 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>>
>> Looking at it again I guess it would be at least four gears because the
>> "secular" 365 calendar is subdivided in an odd way. 18 months of 20 days
>> each, plus one special month at the end of just five days.
>>
>> The Aztec sun stone is odd because it mixes various info together. It
>> has calendric info but is not a calendar, it has some royal history, and in
>> the center a prediction about how the 5th" sun/ world" would end. The
>> Aztecs believed they were living in the 5th world or sun, of a sequence of
>> such worlds/ suns.
>>
>> I am curious how that was generated since it could help me with the
>> glyphs.
>> On Jan 3, 2018 8:28 AM, "cbernhardt" <charlie@carols62.com> wrote:
>>
>>> I am not certain that this is the calendar you are referring to, but
>>> attached
>>> is a picture of an Aztec calendar produced in OpenSCAD from an AutoCAD
>>> DXF
>>> file. I can send you the DXF file if it would help.
>>> <http://forum.openscad.org/file/t1309/aztec.jpg>
>>>
>>>
>>>
>>> --
>>> Sent from: http://forum.openscad.org/
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
C
cbernhardt
Fri, Jan 5, 2018 3:35 PM
If you mean the DXF file, true. That is why I generated the .scad file.
The .scad runs fine in OpenSCAD on both my Windows 10 and Kubuntu 17.04
machines.
I simplified it by loading the DXF
file into AutoCAD and exploding the POLYLINEs into simple line
segments,
If you have AutoCAD you can do such things, yes. That's essentially the
same thing I do (not using AutoCAD) with conversion to .scad (or other
formats).
Carsten Arnholm
On my Windows 7, 64 bit machine, with 16 GB ram, the program starts with
"Compiling Design (CSG Tree generation)", then "Compiling Design(CSG
Products Generation)". After about 40 seconds I get a Microsoft Visual C++
Runtime Library message "The application has requested the Runtime to
terminate in an unusual way. Please contact the application support team
for more information.
If I remove the linear_extrude() line and start OpenSCAD by selecting
mayan_haab_15_inch. scad file the initial rendering appears in about 3 sec,
but it is still extruded. If I hit F5 the Preview appears (still extruded)
in about 3 sec, but F6 still causes the error message.
I am rather inexperienced with OpenSCAD so could someone explain why when I
remove the linear_extrude() line the initial rendering and the F5 rendering
still appears as an extruded image? If I change the scale_factor the image
changes size, but the image still appears as extruded. Is the image cached
somewhere?
Charles
--
Sent from: http://forum.openscad.org/
cacb wrote
> If you mean the DXF file, true. That is why I generated the .scad file.
> The .scad runs fine in OpenSCAD on both my Windows 10 and Kubuntu 17.04
> machines.
>
>> I simplified it by loading the DXF
>> file into AutoCAD and exploding the POLYLINEs into simple line
>> segments,
>
> If you have AutoCAD you can do such things, yes. That's essentially the
> same thing I do (not using AutoCAD) with conversion to .scad (or other
> formats).
>
> Carsten Arnholm
On my Windows 7, 64 bit machine, with 16 GB ram, the program starts with
"Compiling Design (CSG Tree generation)", then "Compiling Design(CSG
Products Generation)". After about 40 seconds I get a Microsoft Visual C++
Runtime Library message "The application has requested the Runtime to
terminate in an unusual way. Please contact the application support team
for more information.
If I remove the linear_extrude() line and start OpenSCAD by selecting
mayan_haab_15_inch. scad file the initial rendering appears in about 3 sec,
but it is still extruded. If I hit F5 the Preview appears (still extruded)
in about 3 sec, but F6 still causes the error message.
I am rather inexperienced with OpenSCAD so could someone explain why when I
remove the linear_extrude() line the initial rendering and the F5 rendering
still appears as an extruded image? If I change the scale_factor the image
changes size, but the image still appears as extruded. Is the image cached
somewhere?
Charles
--
Sent from: http://forum.openscad.org/
DS
Dan Shriver
Fri, Jan 5, 2018 3:40 PM
The third big gear (365) basically does what two gears should do. It
generates a month day (number), and a month name. The problem is 18 months
are 20 days long and the last one is only 5. I have a concept for
advancing month 19 to month 1 after day 5 passes. Unfortunately, my idea
does not reset the month day wheel back to 1.
I was completely wrong when I earlier said the secular/ solar year was not
subdivided. If you look at the 3 gear animation you see that the 365 gear
has a number (dot/ bars, base 20) then a month name.
On Jan 5, 2018 10:30 AM, "Mark Peeters" peetersmarkg@gmail.com wrote:
I'm confused by the idea of 4 gears.
Looks like the dates are always just 3 characters. I think a 4 gear
solution would be hard to read.
The huge gear is an issue to print, maybe something like the flip clock
could take up less space to display the characters?
On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver tabbydan@gmail.com wrote:
That's a decent representation. But they simplified the "secular year"
(365 day part) to be one BIG ring/gear (to get around the problem of the
odd month at the end).
I'm wondering if there is some way to do it as four gears.
If it was just a 260 day cycle (20 months of 13 days each) and a 360 day
cycle (18 months of 20 days each) it would be relatively easy.
Something would simultaneously turn the 13 day ("sacred month") wheel
1/13 revolution and the 20 day ("secular month") wheel 1/20th revolution.
Each month day wheel would have one tooth between the first and last days
of the month that tooth would cause the outer ring to rotate one spot
(advancing the "month"). The two outer rings would not need teeth between
them (this would reduce wear caused by things not being perfect in the real
world and thus having the months maybe not being perfectly in synch).
The big problem is that the "secular year" has 365 days and thus 19
months with the last one being only 5 days. If I call the last month Dec
and the first one Jan... I have an imperfect workaround. The 20 day month
ring has 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6
(small tooth). The month name ring has a smaller inner radius for the last
month so it catches at 5... The problem is that instead of starting over on
Jan 1, the first day of the new year will read Jan 6, not sure how to
correct that.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_619576433057279994_m_3732112203366432411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters peetersmarkg@gmail.com
wrote:
I think this shows and describes the calendar cycles and how they go
together.
https://youtu.be/BeE-3BBqG58
On Jan 3, 2018, at 12:25 PM, Dan Shriver tabbydan@gmail.com wrote:
Looking at it again I guess it would be at least four gears because the
"secular" 365 calendar is subdivided in an odd way. 18 months of 20 days
each, plus one special month at the end of just five days.
The Aztec sun stone is odd because it mixes various info together. It
has calendric info but is not a calendar, it has some royal history, and in
the center a prediction about how the 5th" sun/ world" would end. The
Aztecs believed they were living in the 5th world or sun, of a sequence of
such worlds/ suns.
I am curious how that was generated since it could help me with the
glyphs.
On Jan 3, 2018 8:28 AM, "cbernhardt" charlie@carols62.com wrote:
The third big gear (365) basically does what two gears should do. It
generates a month day (number), and a month name. The problem is 18 months
are 20 days long and the last one is only 5. I have a concept for
advancing month 19 to month 1 after day 5 passes. Unfortunately, my idea
does not reset the month day wheel back to 1.
I was completely wrong when I earlier said the secular/ solar year was not
subdivided. If you look at the 3 gear animation you see that the 365 gear
has a number (dot/ bars, base 20) then a month name.
On Jan 5, 2018 10:30 AM, "Mark Peeters" <peetersmarkg@gmail.com> wrote:
> I'm confused by the idea of 4 gears.
> Looks like the dates are always just 3 characters. I think a 4 gear
> solution would be hard to read.
>
> The huge gear is an issue to print, maybe something like the flip clock
> could take up less space to display the characters?
>
> On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>
>> That's a decent representation. But they simplified the "secular year"
>> (365 day part) to be one BIG ring/gear (to get around the problem of the
>> odd month at the end).
>>
>> I'm wondering if there is some way to do it as four gears.
>>
>> If it was just a 260 day cycle (20 months of 13 days each) and a 360 day
>> cycle (18 months of 20 days each) it would be relatively easy.
>>
>> Something would simultaneously turn the 13 day ("sacred month") wheel
>> 1/13 revolution and the 20 day ("secular month") wheel 1/20th revolution.
>> Each month day wheel would have one tooth between the first and last days
>> of the month that tooth would cause the outer ring to rotate one spot
>> (advancing the "month"). The two outer rings would not need teeth between
>> them (this would reduce wear caused by things not being perfect in the real
>> world and thus having the months maybe not being perfectly in synch).
>>
>> The big problem is that the "secular year" has 365 days and thus 19
>> months with the last one being only 5 days. If I call the last month Dec
>> and the first one Jan... I have an imperfect workaround. The 20 day month
>> ring has 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6
>> (small tooth). The month name ring has a smaller inner radius for the last
>> month so it catches at 5... The problem is that instead of starting over on
>> Jan 1, the first day of the new year will read Jan 6, not sure how to
>> correct that.
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>> <#m_619576433057279994_m_3732112203366432411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters <peetersmarkg@gmail.com>
>> wrote:
>>
>>> I think this shows and describes the calendar cycles and how they go
>>> together.
>>> https://youtu.be/BeE-3BBqG58
>>>
>>> On Jan 3, 2018, at 12:25 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>>>
>>> Looking at it again I guess it would be at least four gears because the
>>> "secular" 365 calendar is subdivided in an odd way. 18 months of 20 days
>>> each, plus one special month at the end of just five days.
>>>
>>> The Aztec sun stone is odd because it mixes various info together. It
>>> has calendric info but is not a calendar, it has some royal history, and in
>>> the center a prediction about how the 5th" sun/ world" would end. The
>>> Aztecs believed they were living in the 5th world or sun, of a sequence of
>>> such worlds/ suns.
>>>
>>> I am curious how that was generated since it could help me with the
>>> glyphs.
>>> On Jan 3, 2018 8:28 AM, "cbernhardt" <charlie@carols62.com> wrote:
>>>
>>>> I am not certain that this is the calendar you are referring to, but
>>>> attached
>>>> is a picture of an Aztec calendar produced in OpenSCAD from an AutoCAD
>>>> DXF
>>>> file. I can send you the DXF file if it would help.
>>>> <http://forum.openscad.org/file/t1309/aztec.jpg>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://forum.openscad.org/
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> Discuss@lists.openscad.org
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
RP
Ronaldo Persiano
Fri, Jan 5, 2018 3:46 PM
The preview of 2D models in OpenSCAD is deceptive. It always adds a
thickness of 1 to the polygon. But, it is not really extruded so the render
will show a 2D polygon without thickness. Similarly, 2D polygon rotations
have not the same representation in the preview (F5) and the render (F6);
avoid them.
2018-01-05 13:35 GMT-02:00 cbernhardt charlie@carols62.com:
If you mean the DXF file, true. That is why I generated the .scad file.
The .scad runs fine in OpenSCAD on both my Windows 10 and Kubuntu 17.04
machines.
I simplified it by loading the DXF
file into AutoCAD and exploding the POLYLINEs into simple line
segments,
If you have AutoCAD you can do such things, yes. That's essentially the
same thing I do (not using AutoCAD) with conversion to .scad (or other
formats).
Carsten Arnholm
On my Windows 7, 64 bit machine, with 16 GB ram, the program starts with
"Compiling Design (CSG Tree generation)", then "Compiling Design(CSG
Products Generation)". After about 40 seconds I get a Microsoft Visual C++
Runtime Library message "The application has requested the Runtime to
terminate in an unusual way. Please contact the application support team
for more information.
If I remove the linear_extrude() line and start OpenSCAD by selecting
mayan_haab_15_inch. scad file the initial rendering appears in about 3 sec,
but it is still extruded. If I hit F5 the Preview appears (still extruded)
in about 3 sec, but F6 still causes the error message.
I am rather inexperienced with OpenSCAD so could someone explain why when I
remove the linear_extrude() line the initial rendering and the F5 rendering
still appears as an extruded image? If I change the scale_factor the image
changes size, but the image still appears as extruded. Is the image cached
somewhere?
Charles
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The preview of 2D models in OpenSCAD is deceptive. It always adds a
thickness of 1 to the polygon. But, it is not really extruded so the render
will show a 2D polygon without thickness. Similarly, 2D polygon rotations
have not the same representation in the preview (F5) and the render (F6);
avoid them.
2018-01-05 13:35 GMT-02:00 cbernhardt <charlie@carols62.com>:
> cacb wrote
> > If you mean the DXF file, true. That is why I generated the .scad file.
> > The .scad runs fine in OpenSCAD on both my Windows 10 and Kubuntu 17.04
> > machines.
> >
> >> I simplified it by loading the DXF
> >> file into AutoCAD and exploding the POLYLINEs into simple line
> >> segments,
> >
> > If you have AutoCAD you can do such things, yes. That's essentially the
> > same thing I do (not using AutoCAD) with conversion to .scad (or other
> > formats).
> >
> > Carsten Arnholm
>
> On my Windows 7, 64 bit machine, with 16 GB ram, the program starts with
> "Compiling Design (CSG Tree generation)", then "Compiling Design(CSG
> Products Generation)". After about 40 seconds I get a Microsoft Visual C++
> Runtime Library message "The application has requested the Runtime to
> terminate in an unusual way. Please contact the application support team
> for more information.
>
> If I remove the linear_extrude() line and start OpenSCAD by selecting
> mayan_haab_15_inch. scad file the initial rendering appears in about 3 sec,
> but it is still extruded. If I hit F5 the Preview appears (still extruded)
> in about 3 sec, but F6 still causes the error message.
>
> I am rather inexperienced with OpenSCAD so could someone explain why when I
> remove the linear_extrude() line the initial rendering and the F5 rendering
> still appears as an extruded image? If I change the scale_factor the image
> changes size, but the image still appears as extruded. Is the image cached
> somewhere?
>
> Charles
>
>
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
MP
Mark Peeters
Fri, Jan 5, 2018 3:53 PM
Just looking at sizes for fun.....
IF one wanted to use the 3 gear idea (this is optional and maybe not what
Dan wants), then the large gear size can be figured based on how big the
characters are. Looks like for a 1cm size character the gear would need to
be over 1 meter in diameter!
//gears size------------------------------
character_size=10;
characters=356;
circumference=character_sizecharacters;
radius=circumference/(2PI);
echo("diameter of gear(mm)=",radius*2);
//----------------------------------------------------------
OUTPUT= ECHO: "diameter of gear(mm)=", 1133.18
On Fri, Jan 5, 2018 at 10:29 AM, Mark Peeters peetersmarkg@gmail.com
wrote:
I'm confused by the idea of 4 gears.
Looks like the dates are always just 3 characters. I think a 4 gear
solution would be hard to read.
The huge gear is an issue to print, maybe something like the flip clock
could take up less space to display the characters?
On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver tabbydan@gmail.com wrote:
That's a decent representation. But they simplified the "secular year"
(365 day part) to be one BIG ring/gear (to get around the problem of the
odd month at the end).
I'm wondering if there is some way to do it as four gears.
If it was just a 260 day cycle (20 months of 13 days each) and a 360 day
cycle (18 months of 20 days each) it would be relatively easy.
Something would simultaneously turn the 13 day ("sacred month") wheel
1/13 revolution and the 20 day ("secular month") wheel 1/20th revolution.
Each month day wheel would have one tooth between the first and last days
of the month that tooth would cause the outer ring to rotate one spot
(advancing the "month"). The two outer rings would not need teeth between
them (this would reduce wear caused by things not being perfect in the real
world and thus having the months maybe not being perfectly in synch).
The big problem is that the "secular year" has 365 days and thus 19
months with the last one being only 5 days. If I call the last month Dec
and the first one Jan... I have an imperfect workaround. The 20 day month
ring has 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6
(small tooth). The month name ring has a smaller inner radius for the last
month so it catches at 5... The problem is that instead of starting over on
Jan 1, the first day of the new year will read Jan 6, not sure how to
correct that.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_1160951138334493063_m_3732112203366432411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters peetersmarkg@gmail.com
wrote:
I think this shows and describes the calendar cycles and how they go
together.
https://youtu.be/BeE-3BBqG58
On Jan 3, 2018, at 12:25 PM, Dan Shriver tabbydan@gmail.com wrote:
Looking at it again I guess it would be at least four gears because the
"secular" 365 calendar is subdivided in an odd way. 18 months of 20 days
each, plus one special month at the end of just five days.
The Aztec sun stone is odd because it mixes various info together. It
has calendric info but is not a calendar, it has some royal history, and in
the center a prediction about how the 5th" sun/ world" would end. The
Aztecs believed they were living in the 5th world or sun, of a sequence of
such worlds/ suns.
I am curious how that was generated since it could help me with the
glyphs.
On Jan 3, 2018 8:28 AM, "cbernhardt" charlie@carols62.com wrote:
Just looking at sizes for fun.....
IF one wanted to use the 3 gear idea (this is optional and maybe not what
Dan wants), then the large gear size can be figured based on how big the
characters are. Looks like for a 1cm size character the gear would need to
be over 1 meter in diameter!
//gears size------------------------------
character_size=10;
characters=356;
circumference=character_size*characters;
radius=circumference/(2*PI);
echo("diameter of gear(mm)=",radius*2);
//----------------------------------------------------------
OUTPUT= ECHO: "diameter of gear(mm)=", 1133.18
On Fri, Jan 5, 2018 at 10:29 AM, Mark Peeters <peetersmarkg@gmail.com>
wrote:
> I'm confused by the idea of 4 gears.
> Looks like the dates are always just 3 characters. I think a 4 gear
> solution would be hard to read.
>
> The huge gear is an issue to print, maybe something like the flip clock
> could take up less space to display the characters?
>
> On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>
>> That's a decent representation. But they simplified the "secular year"
>> (365 day part) to be one BIG ring/gear (to get around the problem of the
>> odd month at the end).
>>
>> I'm wondering if there is some way to do it as four gears.
>>
>> If it was just a 260 day cycle (20 months of 13 days each) and a 360 day
>> cycle (18 months of 20 days each) it would be relatively easy.
>>
>> Something would simultaneously turn the 13 day ("sacred month") wheel
>> 1/13 revolution and the 20 day ("secular month") wheel 1/20th revolution.
>> Each month day wheel would have one tooth between the first and last days
>> of the month that tooth would cause the outer ring to rotate one spot
>> (advancing the "month"). The two outer rings would not need teeth between
>> them (this would reduce wear caused by things not being perfect in the real
>> world and thus having the months maybe not being perfectly in synch).
>>
>> The big problem is that the "secular year" has 365 days and thus 19
>> months with the last one being only 5 days. If I call the last month Dec
>> and the first one Jan... I have an imperfect workaround. The 20 day month
>> ring has 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6
>> (small tooth). The month name ring has a smaller inner radius for the last
>> month so it catches at 5... The problem is that instead of starting over on
>> Jan 1, the first day of the new year will read Jan 6, not sure how to
>> correct that.
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>> <#m_1160951138334493063_m_3732112203366432411_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters <peetersmarkg@gmail.com>
>> wrote:
>>
>>> I think this shows and describes the calendar cycles and how they go
>>> together.
>>> https://youtu.be/BeE-3BBqG58
>>>
>>> On Jan 3, 2018, at 12:25 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>>>
>>> Looking at it again I guess it would be at least four gears because the
>>> "secular" 365 calendar is subdivided in an odd way. 18 months of 20 days
>>> each, plus one special month at the end of just five days.
>>>
>>> The Aztec sun stone is odd because it mixes various info together. It
>>> has calendric info but is not a calendar, it has some royal history, and in
>>> the center a prediction about how the 5th" sun/ world" would end. The
>>> Aztecs believed they were living in the 5th world or sun, of a sequence of
>>> such worlds/ suns.
>>>
>>> I am curious how that was generated since it could help me with the
>>> glyphs.
>>> On Jan 3, 2018 8:28 AM, "cbernhardt" <charlie@carols62.com> wrote:
>>>
>>>> I am not certain that this is the calendar you are referring to, but
>>>> attached
>>>> is a picture of an Aztec calendar produced in OpenSCAD from an AutoCAD
>>>> DXF
>>>> file. I can send you the DXF file if it would help.
>>>> <http://forum.openscad.org/file/t1309/aztec.jpg>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://forum.openscad.org/
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> Discuss@lists.openscad.org
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>
MP
Mark Peeters
Fri, Jan 5, 2018 4:51 PM
That large gear is so big, I wonder if making the clock into "chains" would be easier to hang on the wall with a bin below to hold the long 365 link chain. The tiles for each day could be printed in two colors to help visibility too.
I hope this image helps
On Jan 5, 2018, at 10:40 AM, Dan Shriver tabbydan@gmail.com wrote:
The third big gear (365) basically does what two gears should do. It generates a month day (number), and a month name. The problem is 18 months are 20 days long and the last one is only 5. I have a concept for advancing month 19 to month 1 after day 5 passes. Unfortunately, my idea does not reset the month day wheel back to 1.
I was completely wrong when I earlier said the secular/ solar year was not subdivided. If you look at the 3 gear animation you see that the 365 gear has a number (dot/ bars, base 20) then a month name.
On Jan 5, 2018 10:30 AM, "Mark Peeters" peetersmarkg@gmail.com wrote:
I'm confused by the idea of 4 gears.
Looks like the dates are always just 3 characters. I think a 4 gear solution would be hard to read.
The huge gear is an issue to print, maybe something like the flip clock could take up less space to display the characters?
On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver tabbydan@gmail.com wrote:
That's a decent representation. But they simplified the "secular year" (365 day part) to be one BIG ring/gear (to get around the problem of the odd month at the end).
I'm wondering if there is some way to do it as four gears.
If it was just a 260 day cycle (20 months of 13 days each) and a 360 day cycle (18 months of 20 days each) it would be relatively easy.
Something would simultaneously turn the 13 day ("sacred month") wheel 1/13 revolution and the 20 day ("secular month") wheel 1/20th revolution. Each month day wheel would have one tooth between the first and last days of the month that tooth would cause the outer ring to rotate one spot (advancing the "month"). The two outer rings would not need teeth between them (this would reduce wear caused by things not being perfect in the real world and thus having the months maybe not being perfectly in synch).
The big problem is that the "secular year" has 365 days and thus 19 months with the last one being only 5 days. If I call the last month Dec and the first one Jan... I have an imperfect workaround. The 20 day month ring has 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6 (small tooth). The month name ring has a smaller inner radius for the last month so it catches at 5... The problem is that instead of starting over on Jan 1, the first day of the new year will read Jan 6, not sure how to correct that.
Virus-free. www.avast.com
On Jan 3, 2018, at 12:25 PM, Dan Shriver tabbydan@gmail.com wrote:
Looking at it again I guess it would be at least four gears because the "secular" 365 calendar is subdivided in an odd way. 18 months of 20 days each, plus one special month at the end of just five days.
The Aztec sun stone is odd because it mixes various info together. It has calendric info but is not a calendar, it has some royal history, and in the center a prediction about how the 5th" sun/ world" would end. The Aztecs believed they were living in the 5th world or sun, of a sequence of such worlds/ suns.
I am curious how that was generated since it could help me with the glyphs.
That large gear is so big, I wonder if making the clock into "chains" would be easier to hang on the wall with a bin below to hold the long 365 link chain. The tiles for each day could be printed in two colors to help visibility too.
I hope this image helps
> On Jan 5, 2018, at 10:40 AM, Dan Shriver <tabbydan@gmail.com> wrote:
>
> The third big gear (365) basically does what two gears should do. It generates a month day (number), and a month name. The problem is 18 months are 20 days long and the last one is only 5. I have a concept for advancing month 19 to month 1 after day 5 passes. Unfortunately, my idea does not reset the month day wheel back to 1.
>
> I was completely wrong when I earlier said the secular/ solar year was not subdivided. If you look at the 3 gear animation you see that the 365 gear has a number (dot/ bars, base 20) then a month name.
>
>> On Jan 5, 2018 10:30 AM, "Mark Peeters" <peetersmarkg@gmail.com> wrote:
>> I'm confused by the idea of 4 gears.
>> Looks like the dates are always just 3 characters. I think a 4 gear solution would be hard to read.
>>
>> The huge gear is an issue to print, maybe something like the flip clock could take up less space to display the characters?
>>
>>> On Wed, Jan 3, 2018 at 4:39 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>>> That's a decent representation. But they simplified the "secular year" (365 day part) to be one BIG ring/gear (to get around the problem of the odd month at the end).
>>>
>>> I'm wondering if there is some way to do it as four gears.
>>>
>>> If it was just a 260 day cycle (20 months of 13 days each) and a 360 day cycle (18 months of 20 days each) it would be relatively easy.
>>>
>>> Something would simultaneously turn the 13 day ("sacred month") wheel 1/13 revolution and the 20 day ("secular month") wheel 1/20th revolution. Each month day wheel would have one tooth between the first and last days of the month that tooth would cause the outer ring to rotate one spot (advancing the "month"). The two outer rings would not need teeth between them (this would reduce wear caused by things not being perfect in the real world and thus having the months maybe not being perfectly in synch).
>>>
>>> The big problem is that the "secular year" has 365 days and thus 19 months with the last one being only 5 days. If I call the last month Dec and the first one Jan... I have an imperfect workaround. The 20 day month ring has 2 teeth. One between 1 & 20 (big tooth) and one between 5 & 6 (small tooth). The month name ring has a smaller inner radius for the last month so it catches at 5... The problem is that instead of starting over on Jan 1, the first day of the new year will read Jan 6, not sure how to correct that.
>>>
>>> Virus-free. www.avast.com
>>>
>>>> On Wed, Jan 3, 2018 at 3:10 PM, Mark Peeters <peetersmarkg@gmail.com> wrote:
>>>> I think this shows and describes the calendar cycles and how they go together.
>>>> https://youtu.be/BeE-3BBqG58
>>>>
>>>>> On Jan 3, 2018, at 12:25 PM, Dan Shriver <tabbydan@gmail.com> wrote:
>>>>>
>>>>> Looking at it again I guess it would be at least four gears because the "secular" 365 calendar is subdivided in an odd way. 18 months of 20 days each, plus one special month at the end of just five days.
>>>>>
>>>>> The Aztec sun stone is odd because it mixes various info together. It has calendric info but is not a calendar, it has some royal history, and in the center a prediction about how the 5th" sun/ world" would end. The Aztecs believed they were living in the 5th world or sun, of a sequence of such worlds/ suns.
>>>>>
>>>>> I am curious how that was generated since it could help me with the glyphs.
>>>>>
>>>>>> On Jan 3, 2018 8:28 AM, "cbernhardt" <charlie@carols62.com> wrote:
>>>>>> I am not certain that this is the calendar you are referring to, but attached
>>>>>> is a picture of an Aztec calendar produced in OpenSCAD from an AutoCAD DXF
>>>>>> file. I can send you the DXF file if it would help.
>>>>>> <http://forum.openscad.org/file/t1309/aztec.jpg>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from: http://forum.openscad.org/
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenSCAD mailing list
>>>>>> Discuss@lists.openscad.org
>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> Discuss@lists.openscad.org
>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> Discuss@lists.openscad.org
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
CA
Carsten Arnholm
Fri, Jan 5, 2018 10:45 PM
On 05. jan. 2018 16:35, cbernhardt wrote:
On my Windows 7, 64 bit machine, with 16 GB ram, the program starts with
"Compiling Design (CSG Tree generation)", then "Compiling Design(CSG
Products Generation)". After about 40 seconds I get a Microsoft Visual C++
Runtime Library message "The application has requested the Runtime to
terminate in an unusual way. Please contact the application support team
for more information.
If I remove the linear_extrude() line and start OpenSCAD by selecting
mayan_haab_15_inch. scad file the initial rendering appears in about 3 sec,
but it is still extruded. If I hit F5 the Preview appears (still extruded)
in about 3 sec, but F6 still causes the error message.
I am rather inexperienced with OpenSCAD so could someone explain why when I
remove the linear_extrude() line the initial rendering and the F5 rendering
still appears as an extruded image? If I change the scale_factor the image
changes size, but the image still appears as extruded. Is the image cached
somewhere?
Charles
Hi Charles
Sounds like you have some issue with your computer, it should work fine.
I don't know if OpenSCAD is compiled using MSVC++ on Windows, but your
message seems to indicate so.
Here are the corresponding numbers for my 3 computers, all run ok.
Flushed caches between runs (Design -> Flush caches)
Computer 1
OS Win10 64
OpenSCAD version 2017.01.20 (git 59df0d1)
Intel Xeon CPU E5-1620 v2 @ 3.70GHz (x4)
12GB DDR3 RAM
with linear_extrude
render F5 49 seconds
render F6 42 seconds
linear_extrude removed:
render F5 13 seconds
render F6 41 seconds
Computer 2
OS Win 7 64
OpenSCAD version 2018.01.02 (git 47402a7)
Intel Core i3-2120 CPU v2 @ 3.30GHz (x4)
4GB RAM
with linear_extrude
render F5 1 min 11 seconds
render F6 1 min 12 seconds
linear_extrude removed:
render F5 15 seconds
render F6 1 min 9 seconds
Computer 3
OS Kubuntu 17.04 64
OpenSCAD version 2015.03-2
Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (x4)
32 GB RAM
with linear_extrude
render F5 27 seconds
render F6 25 seconds
linear_extrude removed:
render F5 1 second
render F6 26 seconds
As Ronaldo Persiano mentioned, the F5 preview of 2D models in OpenSCAD
is deceptive, because it looks like a 3D model, but isn't. The F6 render
is on the other hand more proper 2D visualisation.
Carsten Arnholm
On 05. jan. 2018 16:35, cbernhardt wrote:
> On my Windows 7, 64 bit machine, with 16 GB ram, the program starts with
> "Compiling Design (CSG Tree generation)", then "Compiling Design(CSG
> Products Generation)". After about 40 seconds I get a Microsoft Visual C++
> Runtime Library message "The application has requested the Runtime to
> terminate in an unusual way. Please contact the application support team
> for more information.
>
> If I remove the linear_extrude() line and start OpenSCAD by selecting
> mayan_haab_15_inch. scad file the initial rendering appears in about 3 sec,
> but it is still extruded. If I hit F5 the Preview appears (still extruded)
> in about 3 sec, but F6 still causes the error message.
>
> I am rather inexperienced with OpenSCAD so could someone explain why when I
> remove the linear_extrude() line the initial rendering and the F5 rendering
> still appears as an extruded image? If I change the scale_factor the image
> changes size, but the image still appears as extruded. Is the image cached
> somewhere?
>
> Charles
Hi Charles
Sounds like you have some issue with your computer, it should work fine.
I don't know if OpenSCAD is compiled using MSVC++ on Windows, but your
message seems to indicate so.
Here are the corresponding numbers for my 3 computers, all run ok.
Flushed caches between runs (Design -> Flush caches)
Computer 1
----------
OS Win10 64
OpenSCAD version 2017.01.20 (git 59df0d1)
Intel Xeon CPU E5-1620 v2 @ 3.70GHz (x4)
12GB DDR3 RAM
with linear_extrude
render F5 49 seconds
render F6 42 seconds
linear_extrude removed:
render F5 13 seconds
render F6 41 seconds
Computer 2
----------
OS Win 7 64
OpenSCAD version 2018.01.02 (git 47402a7)
Intel Core i3-2120 CPU v2 @ 3.30GHz (x4)
4GB RAM
with linear_extrude
render F5 1 min 11 seconds
render F6 1 min 12 seconds
linear_extrude removed:
render F5 15 seconds
render F6 1 min 9 seconds
Computer 3
----------
OS Kubuntu 17.04 64
OpenSCAD version 2015.03-2
Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (x4)
32 GB RAM
with linear_extrude
render F5 27 seconds
render F6 25 seconds
linear_extrude removed:
render F5 1 second
render F6 26 seconds
As Ronaldo Persiano mentioned, the F5 preview of 2D models in OpenSCAD
is deceptive, because it looks like a 3D model, but isn't. The F6 render
is on the other hand more proper 2D visualisation.
Carsten Arnholm
