Variables in LDraw files

[Cam's Bricks]

I am pretty sure the answer is "no, no, not ever, no thanks, that is a terrible idea" BUT I wanted to ask if there is support for variables in the LDraw file format? 

It would probably take support of all the editors and renders which is probably causing someone's eyebrows to make odd shapes as even type this out  

I am someone who enjoys the "make it once and for all use cases", so the pragmatic nature of making a lot of similar parts that have one or two changes for each iteration feels quite bothersome.

[Max Murtazin]

I am pretty sure the answer is "no, no, not ever, no thanks, that is a terrible idea" BUT I wanted to ask if there is support for variables in the LDraw file format? 

It would probably take support of all the editors and renders which is probably causing someone's eyebrows to make odd shapes as even type this out  

I am someone who enjoys the "make it once and for all use cases", so the pragmatic nature of making a lot of similar parts that have one or two changes for each iteration feels quite bothersome.

I'm not sure how this can be useful, any examples?

[Magnus Forsberg]

I'm not sure how this can be useful, any examples?

I'm not sure I even understand the question...

[Cam's Bricks]

I'm not sure how this can be useful, any examples?

At a basic level something as simple as bricks and plates could be "automated" in this fashion. 

You would have a line type that is used to define a variable. That variable can be used in the part where repetitive dimensions are used or sub-parts are called or any number of other useful calculation points. 

If we look at 3005.dat Brick 1 x 1 we see that the number 24 all over the file:

Code:

1 16 0 24 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 24 10 6 24 6 -6 24 6 -10 24 10
4 16 -10 24 10 -6 24 6 -6 24 -6 -10 24 -10
4 16 -10 24 -10 -6 24 -6 6 24 -6 10 24 -10
4 16 10 24 -10 6 24 -6 6 24 6 10 24 10

1 16 0 24 0 10 0 0 0 -24 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

Now if we look at 3024.dat Plate 1 x 1 we see it is the same exact file but with every instance of 24 replaced with 8:

Code:

1 16 0 8 0 6 0 0 0 -4 0 0 0 6 box5.dat

4 16 10 8 10 6 8 6 -6 8 6 -10 8 10
4 16 -10 8 10 -6 8 6 -6 8 -6 -10 8 -10
4 16 -10 8 -10 -6 8 -6 6 8 -6 10 8 -10
4 16 10 8 -10 6 8 -6 6 8 6 10 8 10

1 16 0 8 0 10 0 0 0 -8 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

If variables could be used then making both parts would be as simple as adding a line like this and changing the line to equal 8 or 24 or 48 or whatever we want without changing anything else in the file:

Code:

0 !VAR "height" = 24

1 16 0 "height" 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 "height" 10 6 "height" 6 -6 "height" 6 -10 "height" 10
4 16 -10 "height" 10 -6 "height" 6 -6 "height" -6 -10 "height" -10
4 16 -10 "height" -10 -6 "height" -6 6 "height" -6 10 "height" -10
4 16 10 "Height" -10 6 "height" -6 6 "height" 6 10 "height" 10

1 16 0 "height" 0 10 0 0 0 -"height" 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

This is a simple use case and I would not expect to be able to do math in these lines except for adding "-" to make it negative as needed to meet the BFC rules. Doing math would be bad for rounding errors unless the standard defined a calculation method to be used by all editors and renders.

My more advanced use case is that I want to make train wheels of various sizes and combinations but I would like to write the file once then just change a few variables (radius, subfile call(s), etc) in each of the files without having to type it all again or copy/paste and have errors.

[Orion Pobursky]

While this is a good idea, it would break backwards compatibility in a huge way.

In my (long neglected) LPov project, I created a POV-Ray macro to programmatically create plates and bricks in much the same way as you describe above.

[Cam's Bricks]

While this is a good idea, it would break backwards compatibility in a huge way.

In my (long neglected) LPov project, I created a POV-Ray macro to programmatically create plates and bricks in much the same way as you describe above.

I am not asking to change anything. I am glad I am not the only one to have thought of this. 

I was more or less doing a check to make sure there wasnt some hidden feature to do this kind of programing in the files before I do it outside the ldraw format and then export to dat.

[Max Murtazin]

At a basic level something as simple as bricks and plates could be "automated" in this fashion. 

You would have a line type that is used to define a variable. That variable can be used in the part where repetitive dimensions are used or sub-parts are called or any number of other useful calculation points. 

If we look at 3005.dat Brick 1 x 1 we see that the number 24 all over the file:

Code:

1 16 0 24 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 24 10 6 24 6 -6 24 6 -10 24 10
4 16 -10 24 10 -6 24 6 -6 24 -6 -10 24 -10
4 16 -10 24 -10 -6 24 -6 6 24 -6 10 24 -10
4 16 10 24 -10 6 24 -6 6 24 6 10 24 10

1 16 0 24 0 10 0 0 0 -24 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

Now if we look at 3024.dat Plate 1 x 1 we see it is the same exact file but with every instance of 24 replaced with 8:

Code:

1 16 0 8 0 6 0 0 0 -4 0 0 0 6 box5.dat

4 16 10 8 10 6 8 6 -6 8 6 -10 8 10
4 16 -10 8 10 -6 8 6 -6 8 -6 -10 8 -10
4 16 -10 8 -10 -6 8 -6 6 8 -6 10 8 -10
4 16 10 8 -10 6 8 -6 6 8 6 10 8 10

1 16 0 8 0 10 0 0 0 -8 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

If variables could be used then making both parts would be as simple as adding a line like this and changing the line to equal 8 or 24 or 48 or whatever we want without changing anything else in the file:

Code:

0 !VAR "height" = 24

1 16 0 "height" 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 "height" 10 6 "height" 6 -6 "height" 6 -10 "height" 10
4 16 -10 "height" 10 -6 "height" 6 -6 "height" -6 -10 "height" -10
4 16 -10 "height" -10 -6 "height" -6 6 "height" -6 10 "height" -10
4 16 10 "Height" -10 6 "height" -6 6 "height" 6 10 "height" 10

1 16 0 "height" 0 10 0 0 0 -"height" 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

This is a simple use case and I would not expect to be able to do math in these lines except for adding "-" to make it negative as needed to meet the BFC rules. Doing math would be bad for rounding errors unless the standard defined a calculation method to be used by all editors and renders.

My more advanced use case is that I want to make train wheels of various sizes and combinations but I would like to write the file once then just change a few variables (radius, subfile call(s), etc) in each of the files without having to type it all again or copy/paste and have errors.

I don't think there is a much need of this. LDraw files are just models most of the time you don't touch, so there is no much need than this
Also, as mentioned by Orion, LDraw is built to be backwards compatible. It's not a good idea to mess with something that has pretty much became a core of the LDraw - new things should be extending the tools by not changing the ones that exist already

[Orion Pobursky]

In hindsight, I think a meta to tell the LDraw programs to simple geometric primitives (think cylinders, cones, discs, etc.) with a well defined spec would have saved a lot of heartache. But, alas, that train left the station long ago.

[Orion Pobursky]

Here's the link to my POV-Ray macros for bricks, plates, tiles, and Technic bricks.
https://github.com/billthefish/LDrawPOV/...macros.inc

[Philippe Hurbain]

At a basic level something as simple as bricks and plates could be "automated" in this fashion. 

You would have a line type that is used to define a variable. That variable can be used in the part where repetitive dimensions are used or sub-parts are called or any number of other useful calculation points. 

If we look at 3005.dat Brick 1 x 1 we see that the number 24 all over the file:

Code:

1 16 0 24 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 24 10 6 24 6 -6 24 6 -10 24 10
4 16 -10 24 10 -6 24 6 -6 24 -6 -10 24 -10
4 16 -10 24 -10 -6 24 -6 6 24 -6 10 24 -10
4 16 10 24 -10 6 24 -6 6 24 6 10 24 10

1 16 0 24 0 10 0 0 0 -24 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

Now if we look at 3024.dat Plate 1 x 1 we see it is the same exact file but with every instance of 24 replaced with 8:

Code:

1 16 0 8 0 6 0 0 0 -4 0 0 0 6 box5.dat

4 16 10 8 10 6 8 6 -6 8 6 -10 8 10
4 16 -10 8 10 -6 8 6 -6 8 -6 -10 8 -10
4 16 -10 8 -10 -6 8 -6 6 8 -6 10 8 -10
4 16 10 8 -10 6 8 -6 6 8 6 10 8 10

1 16 0 8 0 10 0 0 0 -8 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

If variables could be used then making both parts would be as simple as adding a line like this and changing the line to equal 8 or 24 or 48 or whatever we want without changing anything else in the file:

Code:

0 !VAR "height" = 24

1 16 0 "height" 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 "height" 10 6 "height" 6 -6 "height" 6 -10 "height" 10
4 16 -10 "height" 10 -6 "height" 6 -6 "height" -6 -10 "height" -10
4 16 -10 "height" -10 -6 "height" -6 6 "height" -6 10 "height" -10
4 16 10 "Height" -10 6 "height" -6 6 "height" 6 10 "height" 10

1 16 0 "height" 0 10 0 0 0 -"height" 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

This is a simple use case and I would not expect to be able to do math in these lines except for adding "-" to make it negative as needed to meet the BFC rules. Doing math would be bad for rounding errors unless the standard defined a calculation method to be used by all editors and renders.

My more advanced use case is that I want to make train wheels of various sizes and combinations but I would like to write the file once then just change a few variables (radius, subfile call(s), etc) in each of the files without having to type it all again or copy/paste and have errors.

You may want to try to track this...
https://news.lugnet.com/cad/?n=13657

[Milan Vančura]

I am not asking to change anything. I am glad I am not the only one to have thought of this. 

I was more or less doing a check to make sure there wasnt some hidden feature to do this kind of programing in the files before I do it outside the ldraw format and then export to dat.

AFAIK, there is one feature in this way, kind of. Some basic shapes are in the included files which are modified by matrix on the line they are included/used. "box5.dat" on the first line of your example is such a case. It is very limited from your POV but this is how parts in ldraw are constructed. If you need more advanced features you need to generate .dat files from richer language.

[Roland Melkert]

Code:

0 !VAR "height" = 24
1 16 0 "height" 0 6 0 0 0 -20 0 0 0 6 box5.dat

4 16 10 "height" 10 6 "height" 6 -6 "height" 6 -10 "height" 10
4 16 -10 "height" 10 -6 "height" 6 -6 "height" -6 -10 "height" -10
4 16 -10 "height" -10 -6 "height" -6 6 "height" -6 10 "height" -10
4 16 10 "Height" -10 6 "height" -6 6 "height" 6 10 "height" 10

1 16 0 "height" 0 10 0 0 0 -"height" 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

You could (should?) do this using a new meta, especially since you would need to extend existing software in order to use it anyway.

Something like:

Code:

!VAR "height" = 24
!VAR 1 16 0 "height" 0 6 0 0 0 -20 0 0 0 6 box5.dat

You Could also loose the quotes (I always hate those) by defining grammar for the variable name, for example ([a-zA-z]+[a-zA-Z0-9]*) (case insensitive if needed)

[Cam's Bricks]

You could (should?) do this using a new meta, especially since you would need to extend existing software in order to use it anyway.

Something like:

Code:

!VAR "height" = 24
!VAR 1 16 0 "height" 0 6 0 0 0 -20 0 0 0 6 box5.dat

You Could also loose the quotes (I always hate those) by defining grammar for the variable name, for example ([a-zA-z]+[a-zA-Z0-9]*)  (case insensitive if needed)

Fortunately for LDraw community, I am no where near a good enough programmer to extend the file format or any of the existing editors to support this. I was just looking to make sure that this hadnt been developed but never got a write up or was still in an alpha or beta phase of development. 

Thanks for all the interesting thoughts about this. I will probably do some simple scripting to get what I want then just export to .dat and go from there.

[Cam's Bricks]

You may want to try to track this...
https://news.lugnet.com/cad/?n=13657

This is very interesting. I dont know that a tool from 2006 would still be around or work on modern systems. Do you happen to know if the person who posted there is still active in the LDraw community?

[Cam's Bricks]

Here's the link to my POV-Ray macros for bricks, plates, tiles, and Technic bricks.
https://github.com/billthefish/LDrawPOV/...macros.inc

Thanks for this!

[Nils Schmidt]

I am pretty sure the answer is "no, no, not ever, no thanks, that is a terrible idea" BUT I wanted to ask if there is support for variables in the LDraw file format? 

It would probably take support of all the editors and renders which is probably causing someone's eyebrows to make odd shapes as even type this out  

I am someone who enjoys the "make it once and for all use cases", so the pragmatic nature of making a lot of similar parts that have one or two changes for each iteration feels quite bothersome.

I did a quick implementation to try it out.
One difficulty is to parse the occurences in an efficient manner, otherwise I would need to try to replace every substring of a line with a potential constant which slows down the parsing of the file significantly.

I am not sure if I am going to finally implement this in LDPE.
But I suggest to use global constants instead of variables.
A variable implies some kind of re-assignment, a scope or a calculation.
For this I would create some kind of unofficial specification for the use of a scripting language (LDCad for example supports lua scripts ).

[Max Murtazin]

I would like to see this being adopted as an optional feature, maybe even one day this growing into smth like an internal ldraw scripting language, since stuff like this would probably be really neat for use in custom parts and stuff. 

For example, what I could see being a thig are also matrix variables, that could probably be applied to the line after them with a meta command. All such QOL stuff

Also, with those ideas, I could also imagine something like a "compiler" of LDraw files using those features into a proper LDraw file

[Nils Schmidt]

I am pretty sure the answer is "no, no, not ever, no thanks, that is a terrible idea" BUT I wanted to ask if there is support for variables in the LDraw file format?
I am someone who enjoys the "make it once and for all use cases", so the pragmatic nature of making a lot of similar parts that have one or two changes for each iteration feels quite bothersome.

I would like to see this being adopted as an optional feature, maybe even one day this growing into smth like an internal ldraw scripting language, since stuff like this would probably be really neat for use in custom parts and stuff. 

For example, what I could see being a thig are also matrix variables, that could probably be applied to the line after them with a meta command. All such QOL stuff

Also, with those ideas, I could also imagine something like a "compiler" of LDraw files using those features into a proper LDraw file

A part editor supports now variables on its own.

Example:

Code:

0
0 Name: new.dat
0 Author: Nils Schmidt [BlackBrick89]
0 !LDRAW_ORG Unofficial_Part
0 !LICENSE Licensed under CC BY 4.0 : see CAreadme.txt

0 BFC CERTIFY CCW

0 !LPE CONST height = 1*24
0 !LPE CONST inner = height-4
1 16 0 height 0 6 0 0 0 -inner 0 0 0 6 box5.dat

4 16 10 height 10 6 height 6 -6 height 6 -10 height 10
4 16 -10 height 10 -6 height 6 -6 height -6 -10 height -10
4 16 -10 height -10 -6 height -6 6 height -6 10 height -10
4 16 10 height -10 6 height -6 6 height 6 10 height 10

1 16 0 height 0 10 0 0 0 -height 0 0 0 10 box5.dat

1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat

More here:
https://forums.ldraw.org/showthread.php?...e=threaded