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.
(2022-07-06, 12:31)Cam's Bricks Wrote: [ -> ]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?
(2022-07-06, 15:20)Max Murtazin Wrote: [ -> ]I'm not sure how this can be useful, any examples?
I'm not sure I even understand the question...
(2022-07-06, 15:20)Max Murtazin Wrote: [ -> ]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.
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.
(2022-07-06, 16:57)Orion Pobursky Wrote: [ -> ]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.
(2022-07-06, 16:43)Cam's Bricks Wrote: [ -> ]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
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.
(2022-07-06, 16:43)Cam's Bricks Wrote: [ -> ]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
(2022-07-06, 17:03)Cam's Bricks Wrote: [ -> ]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.
(2022-07-06, 16:43)Cam's Bricks Wrote: [ -> ]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)
(2022-07-06, 21:10)Roland Melkert Wrote: [ -> ]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.
(2022-07-06, 17:17)Philippe Hurbain Wrote: [ -> ]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?
(2022-07-06, 12:31)Cam's Bricks Wrote: [ -> ]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
).
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
(2022-07-06, 12:31)Cam's Bricks Wrote: [ -> ]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.
(2022-07-08, 16:07)Max Murtazin Wrote: [ -> ]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