| |
In lugnet.cad, Kevin L. Clague wrote:
> I've been up to my ears in NXT land, in case anyone noticed or wondered about
> my absence. Needless to say there are "unoffical" Ldraw parts being developed.
Yeah. :)
> I've increased my skill set as a part author (previously I've only modified
> parts that were there.) Contrary to the recommnendations I did my work in
> MLCad. Now I have a better understanding why a text editor might be a good
> alternative.
BTW, there are at least 2 reason not to use MLCAD to create parts which you want
to contribute to LDraw.org:
1. (General reason) it's more work than doing it in an enhanced text editor.
2. (Specifically) MLCAD does things to the file that are not allowed in official
part files, so you have to clean up the code afterwards (and then you can no
longer edit it in MLCAD).
> I don't have the time, *but* if a 3D GUI editor (e.g. LeoCAD or MLCad) were to
> provide the concept of identified (maybe named) verticies, intersections of
> planes with planes, cylinders with circles, etc.... I think it would be much
> easier to create and edit parts.
I don't know if this helps, but we already have language to support this
concept. The LDLite language extensions support the definition of named points
and matrices (and colors, but that's not so useful in this context). In LDLite
code, you can create a file like:
0 POINT A1 10 0 10
0 POINT B2 -10 -10 -10
0 POINT C3 0 -10 0
0 POINT D4 10 -10 10
3 1 A1 B2 C3
3 2 B2 C3 D4
Even if the user were not aware of the point-names, I could see this format
being useful for programs that use point-lists.
It also typically results in smaller files than straight DAT code.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > I've been up to my ears in NXT land, in case anyone noticed or wondered about
> > my absence. Needless to say there are "unoffical" Ldraw parts being developed.
>
> Yeah. :)
>
> > I've increased my skill set as a part author (previously I've only modified
> > parts that were there.) Contrary to the recommnendations I did my work in
> > MLCad. Now I have a better understanding why a text editor might be a good
> > alternative.
>
> BTW, there are at least 2 reason not to use MLCAD to create parts which you want
> to contribute to LDraw.org:
>
> 1. (General reason) it's more work than doing it in an enhanced text editor.
> 2. (Specifically) MLCAD does things to the file that are not allowed in official
> part files, so you have to clean up the code afterwards (and then you can no
> longer edit it in MLCAD).
>
> > I don't have the time, *but* if a 3D GUI editor (e.g. LeoCAD or MLCad) were to
> > provide the concept of identified (maybe named) verticies, intersections of
> > planes with planes, cylinders with circles, etc.... I think it would be much
> > easier to create and edit parts.
>
> I don't know if this helps, but we already have language to support this
> concept. The LDLite language extensions support the definition of named points
> and matrices (and colors, but that's not so useful in this context). In LDLite
> code, you can create a file like:
>
> 0 POINT A1 10 0 10
> 0 POINT B2 -10 -10 -10
> 0 POINT C3 0 -10 0
> 0 POINT D4 10 -10 10
> 3 1 A1 B2 C3
> 3 2 B2 C3 D4
I had no idea of that. How long has this been an LDLite feature? It reminds at
least me of LDS code. The same thing in LDS would look like this:
P1 10 0 10
P2 -10 -10 -10
P3 0 -10 0
P4 10 -10 10
3 1 P1 P2 P3
3 2 P2 P3 P4
Is it possible to let, say C3's and D4's y values follow B2? Like, in LDS, you
can change the code to:
P2 -10 -10 -10
P3 0 y2 0
P4 10 y2 10
and you only have to edit the y value of P2, then y3 and y4 will also follow. If
so, that would be really handy.
> Even if the user were not aware of the point-names, I could see this format
> being useful for programs that use point-lists.
>
> It also typically results in smaller files than straight DAT code.
But not as small as the corresponding LDS code. :)
>
> Steve
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
>
> Is it possible to let, say C3's and D4's y values follow B2? Like, in LDS, you
> can change the code to:
> P2 -10 -10 -10
> P3 0 y2 0
> P4 10 y2 10
> and you only have to edit the y value of P2, then y3 and y4 will also follow. If
> so, that would be really handy.
That's cool. Probably a more versatile notation would be:
P2 -10 -10 -10
P3 0 P2.y 0
P4 10 P2.y 10
Can you also do chained values? eg:
P2 -10 -10 -10
P3 0 y2 0
P4 10 y3 10
ROSCO
|
|
| |
In lugnet.cad, Ross Crawford wrote:
> In lugnet.cad, Tore Eriksson wrote:
> >
> > Is it possible to let, say C3's and D4's y values follow B2? Like, in LDS, you
> > can change the code to:
> > P2 -10 -10 -10
> > P3 0 y2 0
> > P4 10 y2 10
> > and you only have to edit the y value of P2, then y3 and y4 will also follow. If
> > so, that would be really handy.
>
> That's cool. Probably a more versatile notation would be:
>
> P2 -10 -10 -10
> P3 0 P2.y 0
> P4 10 P2.y 10
Yes, but I try to keep it as short as possible. :)
> Can you also do chained values? eg:
>
> P2 -10 -10 -10
> P3 0 y2 0
> P4 10 y3 10
>
> ROSCO
No problems at all. You may also rotate 90 deg's by assigning a -z at the x and
x at z if you like... Almost anything. These are also legal:
P2 -10 -10 -10
P3 0 y2 0
P4 0-z3 y3+4 x3
c=16
FOR i=-200 TO 200 STEP 20
1 c i 0 0 1 0 0 0 1 0 0 0 1 stud.dat
NEXT i
btw, "1 c i 0 0 1 0 0 0 1 0 0 0 1 stud.dat" is too long for lazy me to
write, so LDS does that for me if I just write:
stud.dat c i 0 0
See more example at:
http://web.telia.com/~u66203131/LDraw/lds/ldssyntx.htm
/Tore
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Steve Bliss wrote:
> > I don't know if this helps, but we already have language to support this
> > concept. The LDLite language extensions support the definition of named points
> > and matrices (and colors, but that's not so useful in this context). In LDLite
> > code, you can create a file like:
> >
> > 0 POINT A1 10 0 10
> > 0 POINT B2 -10 -10 -10
> > 0 POINT C3 0 -10 0
> > 0 POINT D4 10 -10 10
> > 3 1 A1 B2 C3
> > 3 2 B2 C3 D4
>
> I had no idea of that. How long has this been an LDLite feature?
Since a very long time; LDLite 1.6 supported it, and it wasn't the first version
to do so. My LDLite 1.6 files are dated March, 1999.
The LDLite meta-commands are very useful -- I used them when I modeled the
soccer ball, way back when.
> It reminds at
> least me of LDS code. The same thing in LDS would look like this:
> P1 10 0 10
> P2 -10 -10 -10
> P3 0 -10 0
> P4 10 -10 10
> 3 1 P1 P2 P3
> 3 2 P2 P3 P4
>
> Is it possible to let, say C3's and D4's y values follow B2? Like, in LDS, you
> can change the code to:
> P2 -10 -10 -10
> P3 0 y2 0
> P4 10 y2 10
> and you only have to edit the y value of P2, then y3 and y4 will also follow. If
> so, that would be really handy.
No, you can't do that with the LDLite statements -- each named point is atomic
(the component values can't be accessed), and there's no expression language --
the actual value of a named point is really just a text string.
Not to say it would be a big stretch to define a syntax like B2.y, to access the
y component of B2. But it's not part of the existing definition.
> > Even if the user were not aware of the point-names, I could see this format
> > being useful for programs that use point-lists.
> >
> > It also typically results in smaller files than straight DAT code.
>
> But not as small as the corresponding LDS code. :)
True. But the LDLite code has the advantage of having a straightforward
translation to standard DAT code.
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > I've been up to my ears in NXT land, in case anyone noticed or wondered about
> > my absence. Needless to say there are "unoffical" Ldraw parts being developed.
>
> Yeah. :)
>
> > I've increased my skill set as a part author (previously I've only modified
> > parts that were there.) Contrary to the recommnendations I did my work in
> > MLCad. Now I have a better understanding why a text editor might be a good
> > alternative.
>
> BTW, there are at least 2 reason not to use MLCAD to create parts which you want
> to contribute to LDraw.org:
>
> 1. (General reason) it's more work than doing it in an enhanced text editor.
> 2. (Specifically) MLCAD does things to the file that are not allowed in official
> part files, so you have to clean up the code afterwards (and then you can no
> longer edit it in MLCAD).
Ummmm.... given that.... could you be so kind as to tell me what those are?
This way I can choose to/or not use MLCad and then clean things up afterwards.
Thanks...
> > I don't have the time, *but* if a 3D GUI editor (e.g. LeoCAD or MLCad) were to
> > provide the concept of identified (maybe named) verticies, intersections of
> > planes with planes, cylinders with circles, etc.... I think it would be much
> > easier to create and edit parts.
>
> I don't know if this helps, but we already have language to support this
> concept. The LDLite language extensions support the definition of named points
> and matrices (and colors, but that's not so useful in this context). In LDLite
> code, you can create a file like:
>
> 0 POINT A1 10 0 10
> 0 POINT B2 -10 -10 -10
> 0 POINT C3 0 -10 0
> 0 POINT D4 10 -10 10
> 3 1 A1 B2 C3
> 3 2 B2 C3 D4
>
> Even if the user were not aware of the point-names, I could see this format
> being useful for programs that use point-lists.
>
> It also typically results in smaller files than straight DAT code.
>
> Steve
To be honest, I figured there were some approaches to this issue already
implemented. The topic was too obvious for me to be the first to recognize it.
I'll have to do some homework..... when I find a few nano-seconds of free time.
Kev
P.S. Sorry you had to clean up those unofficial parts I created using MLCad.
|
|
| |
Steve Bliss schrieb:
snip
>
> BTW, there are at least 2 reason not to use MLCAD to create parts which you want
> to contribute to LDraw.org:
>
> 1. (General reason) it's more work than doing it in an enhanced text editor.
> 2. (Specifically) MLCAD does things to the file that are not allowed in official
> part files, so you have to clean up the code afterwards (and then you can no
> longer edit it in MLCAD).
snip
I can not agree.
All parts that I have done are made with MLCad.
The only things I have to do before uploading is:
1) Remove lines with color entries (if you have some special added)
2) Remove lines with "ROTATE" statements
3) Remove all other meta statements (ex. MLCAD HIDE)
4) Change all "BFC CERTIFY INVERTNEXT" to "BFC INVERTNEXT"
5) Change "Unofficial Model" to "Unofficial Part"
Most of this can be done by scripts.
I can edit every part that I have created and uploaded to the parts
tracker again in MLCad. I only have to do the corrections (see above)
again before uploading.
I would not be a part author without MLCad.
MikeHeide
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
> In lugnet.cad, Steve Bliss wrote:
> > BTW, there are at least 2 reason not to use MLCAD to create parts which you want
> > to contribute to LDraw.org:
> >
> > 1. (General reason) it's more work than doing it in an enhanced text editor.
> > 2. (Specifically) MLCAD does things to the file that are not allowed in official
> > part files, so you have to clean up the code afterwards (and then you can no
> > longer edit it in MLCAD).
>
> Ummmm.... given that.... could you be so kind as to tell me what those are?
> This way I can choose to/or not use MLCad and then clean things up afterwards.
I did a quick test with MLCAD 3.11 and noticed the following:
(Opened a partfile in MLCAD and save it under a different filename
and then compared the two files)
MLCad adds two rotation commands to the header
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
MLCad replaces every
0 BFC INVERTNEXT
with
0 BFC CERTIFY INVERTNEXT
No harmfull things are:
MLCad removes unnesseccary spaces and empty lines
MLCad replaces numbers as 3.10 with 3.1
MLCad replaces numbers as .123 with 0.123
Niels
|
|
| |
In lugnet.cad, Niels Karsdorp wrote:
> I did a quick test with MLCAD 3.11 and noticed the following:
> (Opened a partfile in MLCAD and save it under a different filename
> and then compared the two files)
Thanks for doing this, Niels.
> No harmfull things are:
> MLCad removes unnesseccary spaces and empty lines
When creating part files, I frequently add 'unnecessary' spaces and empty lines
to improve (IMO) readability.
> MLCad replaces numbers as 3.10 with 3.1
> MLCad replaces numbers as .123 with 0.123
Change-tracking is much simpler if lines of code aren't changed unless they
actual need to be changed. For people making new parts, MLCad's forced-format
isn't a big deal. When people update/correct official files, I consider MLCad's
forced-format changes to be hostile to the update process.
Steve
|
|
|
