(2023-12-01, 19:28)Rene Rechthaler Wrote: [ -> ]4-4 chrd would be 7 quads (14 triangles) instead of 16 triangles...
maybe less code and less render work...
Since the 2 files would be functionally identical, in the context of modern rendering, a 2 triangle savings isn't even worth the consideration or confusion on primitive usage.
(2023-12-01, 19:28)Rene Rechthaler Wrote: [ -> ]4-4 chrd would be 7 quads (14 triangles) instead of 16 triangles...
maybe less code and less render work...
IMO, the way that any given flat primitive is meshed is not intrinsic to the primitive definition. In other words, 4-4disc could internally be created with 14 quads and still be a perfectly valid 4-4disc. Note: I'm not suggesting it be updated, just that the way that it is meshed is an implementation detail.
Something's wrong with triangle.dat, because what in the name of Euclid is a "right angled isosceles triangle"?
(2023-12-02, 3:53)N. W. Perry Wrote: [ -> ]Something's wrong with triangle.dat, because what in the name of Euclid is a "right angled isosceles triangle"?
Thanks for the heads-up - renamed to isosceles right triangle.
w.
Cross-check before I move on to copy more content from the old side.
w.
(2023-12-01, 10:49)Willy Tschager Wrote: [ -> ][attachment=10491]
Let me know if these could work as thumbnails for the helix prims.
w.
Are you sure this is what the cylh primitives are supposed to look like past 1/4 turn? I would not expect the stair-stepping of the top that you have in your image. Since 1-4cylh.dat is the fullest circle currently in the library, it's not possible to be sure how it should continue. Having said that, I don't understand why you show it like you do. In order for me to support this in LDView's primitive substitution, I have to know how it should look, and how you have it in the picture is not how I would expect it to look. I would expect the top to be even all the way around.
(2023-12-02, 22:49)Travis Cobbs Wrote: [ -> ]Are you sure this is what the cylh primitives are supposed to look like past 1/4 turn? I would not expect the stair-stepping of the top that you have in your image. Since 1-4cylh.dat is the fullest circle currently in the library, it's not possible to be sure how it should continue. Having said that, I don't understand why you show it like you do. In order for me to support this in LDView's primitive substitution, I have to know how it should look, and how you have it in the picture is not how I would expect it to look. I would expect the top to be even all the way around.
Don't ask me. I didn't cook up this thing and I never used it. To me the most important thing is to point out that it is a helix and when pairing the prims to the edges this was the most logical thing to do. If you think there should be just one prim but at the same time showing the path I'm happy to use something like this:
[
attachment=10492][
attachment=10493]
Or a bit compressed:
[
attachment=10494][
attachment=10495]
w.
(2023-11-30, 6:47)Willy Tschager Wrote: [ -> ]I started copying the Curved primitives.
correct row:
r=1 : 1-16rin1, 1-8ring1, 3-16rin1, 1-4ring1, 3-8ring1, 7-16rin1, 2-4ring1, 5-8ring1, 3-4ring1, 7-8ring1, 4-4ring1
I think we shoud have some text explaining why there is a mix of "rin" and "ring" in the ring-primitives.
The correct nomenclature is to use the full word "
ring".
Due to the fact that too many files would be affected, it was decided to keep "rin" primitives in the library.
All files using "ri" has been moved, to use "ring".
(2023-12-03, 14:18)Magnus Forsberg Wrote: [ -> ]I think we shoud have some text explaining why there is a mix of "rin" and "ring" in the ring-primitives.
The correct nomenclature is to use the full word "ring".
Due to the fact that too many files would be affected, it was decided to keep "rin" primitives in the library.
All files using "ri" has been moved, to use "ring".
Good point. Added!
w.
some of the descriptions are now incorrect due to the new rendered pics, for example:
n-ftang.dat: "Note that the bounding circle in the image is for context only - only the grey segment is generated by the 1-4tang primitive."
(but the new pic has a dark grey ring and a black n-ftang)
The other images still show light grey faces, so maybe change the pic instead.
(2023-12-03, 14:40)Rene Rechthaler Wrote: [ -> ]some of the descriptions are now incorrect due to the new rendered pics, for example:
n-ftang.dat: "Note that the bounding circle in the image is for context only - only the grey segment is generated by the 1-4tang primitive."
(but the new pic has a dark grey ring and a black n-ftang)
The other images still show light grey faces, so maybe change the pic instead.
Corrected. Description for "Disc negative truncated" still needed. Anyone?
w.
(2023-12-03, 15:59)Willy Tschager Wrote: [ -> ]Corrected. Description for "Disc negative truncated" still needed. Anyone?
w.
"This suite of primitives pad their matching n-fdisc.dat primitives out to the bounding rectangle, spanning from x = 1 to the minimal x value of the matching primitive. They are used to integrate circular elements into rectilinear elements."
Best I can do. Sounds a bit messy tho
(2023-12-03, 11:55)Willy Tschager Wrote: [ -> ]Don't ask me. I didn't cook up this thing and I never used it. To me the most important thing is to point out that it is a helix and when pairing the prims to the edges this was the most logical thing to do. If you think there should be just one prim but at the same time showing the path I'm happy to use something like this:
Or a bit compressed:
w.
I meant that I would expect the higher fractions to look like this:
[
attachment=10499]
Note: coloring is just to split it up into quarters, and obviously wouldn't be possible with a higher fraction primitive.
Blue is 0 to 1/4, Green is 1/4 to 2/4, Cyan is 2/4 to 3/4, Red it 3/4 to 4/4.
(2023-12-03, 23:15)Travis Cobbs Wrote: [ -> ]I meant that I would expect the higher fractions to look like this:
Note: coloring is just to split it up into quarters, and obviously wouldn't be possible with a higher fraction primitive.
Blue is 0 to 1/4, Green is 1/4 to 2/4, Cyan is 2/4 to 3/4, Red it 3/4 to 4/4.
Given that it is a helix, I could also see omitting the geometry that brings everything up to y=0.
[
attachment=10500]
My point, though, is that when I implement the primitive in LDView, I want to support the whole reasonable range. One could argue that 48/1-48 to 1-4 is the whole reasonable range, in which case I can have LDView only support that. But if it makes sense to ever go past 1-4, I want the primitive description to indicate what that is supposed to look like so that whenever further primitives are added, their geometry will match whatever LDView generates.
(2023-12-04, 0:56)Travis Cobbs Wrote: [ -> ]Given that it is a helix, I could also see omitting the geometry that brings everything up to y=0.
So what is the difference between your image and mine? I'm happy to use your pic but I ask you to render a 3D image in 400x400 px.
w.
(2023-12-04, 0:56)Travis Cobbs Wrote: [ -> ]Given that it is a helix, I could also see omitting the geometry that brings everything up to y=0.
So what is the difference between your image and mine? I'm happy to use your pic but I ask you to render a 3D image in 400x400 px.
w.
(2023-12-04, 7:53)Willy Tschager Wrote: [ -> ]So what is the difference between your image and mine? I'm happy to use your pic but I ask you to render a 3D image in 400x400 px.
w.
My reason for asking this question has nothing to do with the pictures. I want to know how this primitive is expected to behave past one quarter turn, and so far nobody has given any indication that they are interested in having a discussion about this. Regarding your pictures, the kinks make it extremely difficult to understand what they are trying to convey. I created my own pictures in a different orientation due to the fact that the geometry makes it very difficult to understand what is going on in the standard orientation. I have no problem with generating a standardized picture once we can agree on what the geometry should look like. But doing so is pointless when I don't know what the geometry should look like.
I can state categorically that I'm not doing
any work to support this primitive in LDView until it either has an official definition beyond one quarter turn or it is stated to only be valid up to one quarter turn.
(2023-12-04, 17:46)Travis Cobbs Wrote: [ -> ]My reason for asking this question has nothing to do with the pictures. I want to know how this primitive is expected to behave past one quarter turn, and so far nobody has given any indication that they are interested in having a discussion about this. Regarding your pictures, the kinks make it extremely difficult to understand what they are trying to convey. I created my own pictures in a different orientation due to the fact that the geometry makes it very difficult to understand what is going on in the standard orientation. I have no problem with generating a standardized picture once we can agree on what the geometry should look like. But doing so is pointless when I don't know what the geometry should look like.
I can state categorically that I'm not doing any work to support this primitive in LDView until it either has an official definition beyond one quarter turn or it is stated to only be valid up to one quarter turn.
Maybe its usage in parts could shed some light on it?
https://library.ldraw.org/official/21587
Or ask Philo.
w.
Would something like this be possible to create and maintain in the wiki?
[
attachment=10502]
green = always accepted and needed/wanted
light green = possible to make from a 1-4 + a 90 degree rotated, shorter prim.
light red = should be avoided. Use shorter prims, rotate 90 degrees
red = impossible
A chart might be easier to read than having all the available prims in text strings.
How would the page be updated after each new release?
(2023-12-05, 23:33)Gerald Lasser Wrote: [ -> ]I like Magnus' overview, although a bit hard to read, over the last days I tried as well some layouts and came up with this:
Great work. I'll try to squeeze them into the chart.
w.
The axle prims should be complete:
https://wiki.ldraw.org/wiki/Primitives_R...primitives
I found out that the axlebeam.dat lists the axle sphere instead of the beam in the !HELP
0 !HELP to be used between a cylinder of 9 ldu radious and an axle primitive.
0 !HELP 1 16 0 0 -10 9 0 0 0 0 -9 0 20 0 2-4cyli.dat
0 !HELP 1 16 0 0 0 1 0 0 0 1 0 0 0 1 axlesphe.dat
0 !HELP 1 16 0 -20 0 1 0 0 0 10 0 0 0 1 axlehol8.dat
Fasttrack?
w.
(2023-12-05, 23:33)Gerald Lasser Wrote: [ -> ]I like Magnus' overview, although a bit hard to read, over the last days I tried as well some layouts and came up with this:
The box4 is not complete. How did you do this? Script, photoshop. Can it be updated with new prims without fiddling too much?
w.
(2023-12-06, 8:23)Willy Tschager Wrote: [ -> ]The box4 is not complete. How did you do this? Script, photoshop. Can it be updated with new prims without fiddling too much?
w.
I made a Powerpoint template and pasted your images there, then exported the slides as png.
Update is faily easy, could be done with a macro. But even the PPT template makes it smooth
I am looking into a workflow to update the page, respectively extract new primitives.
Like scanning the official library on the pc and entering the results in a DB, thus the next scan should give ou a delta that can be added to the prim-ref.
Ideally a macro is doing that spitting out code for the wiki or the images I did with PPT.
Thought on the pegholes:
I would propose to use the distance form the centre to the edge/corner in the discription in addition to "extended", "medium" or "short"
14 LDU applies for usage Bricks
10 and 9 LDU applies to the use in beams
(2024-01-01, 16:13)Gerald Lasser Wrote: [ -> ]Thought on the pegholes:
I would propose to use the distance form the centre to the edge/corner in the discription in addition to "extended", "medium" or "short"
14 LDU applies for usage Bricks
10 and 9 LDU applies to the use in beams
I don't understand. Care to explain?
Since I never got a satisfactory answer regarding what to do past one quarter circle for helical primitives, I will only be supporting up to one quarter circle. If higher fractions are created in the future, I may revisit and support them, but the initial support in the next LDView release will not substitute them at all past one quarter circle.
(2024-01-25, 8:28)Travis Cobbs Wrote: [ -> ]Since I never got a satisfactory answer regarding what to do past one quarter circle for helical primitives, I will only be supporting up to one quarter circle. If higher fractions are created in the future, I may revisit and support them, but the initial support in the next LDView release will not substitute them at all past one quarter circle.
For the helical cylis it doesn't make much sense above 1/4 because it becomes too wide. So limiting to 1-4 is fine!
(2024-01-26, 15:20)Willy Tschager Wrote: [ -> ]I copied all content from the former primref page and added the missing prims from the p folder. Suggestions? Corrections? have your say:
https://wiki.ldraw.org/wiki/Primitives_Reference
w.
PS. We have to decide on the thumb for the helix.
Thanks Willy for your huge contribution in building the new prims reference page, I really like it!
(2024-01-26, 15:20)Willy Tschager Wrote: [ -> ]Suggestions? Corrections? have your say:
I would like to see a different orientation on some of the tri primitive images. Not all surfaces and edges are visible.
I have to read and interpret the text to understand them.
(2024-01-26, 15:20)Willy Tschager Wrote: [ -> ]Suggestions? Corrections?
On the wiki page, I would like to see the "hide/unhide arrow" regarding the name of each primitive.
(2024-01-28, 15:45)Magnus Forsberg Wrote: [ -> ]I would like to see a different orientation on some of the tri primitive images. Not all surfaces and edges are visible.
I have to read and interpret the text to understand them.
I regenerated them. Let me know if it suits you?
w.
(2024-01-28, 20:00)Javier Orquera Wrote: [ -> ]On the wiki page, I would like to see the "hide/unhide arrow" regarding the name of each primitive.
I have no idea what you are talking about? Please elaborate.
w.
(2024-01-29, 17:51)Javier Orquera Wrote: [ -> ]As example: https://en.m.wikipedia.org/wiki/Lego_Bricktales
It's the dropdown arrow at the left of "Game", "Development and release", etc.
That's a feature of Wikipedia's mobile skin and is not installed on the LDraw wiki.
(2024-01-30, 12:33)Willy Tschager Wrote: [ -> ]All I can do is using an inbuild java script. Check the [Collaps] button on the right border of:
https://wiki.ldraw.org/wiki/Primitives_R...primitives
w.
Javier,
I'm still waiting if the [Collaps] button is what you were looking for. I would than add it to the rest of the page or delete it.
w.
(2024-02-09, 9:19)Willy Tschager Wrote: [ -> ]Javier,
I'm still waiting if the [Collaps] button is what you were looking for. I would than add it to the rest of the page or delete it.
w.
Willy, the link goes into edit mode on the wiki...
(2024-02-09, 21:46)Gerald Lasser Wrote: [ -> ]Willy, the link goes into edit mode on the wiki...
Fixed.
w.
(2024-02-09, 9:19)Willy Tschager Wrote: [ -> ]Javier,
I'm still waiting if the [Collaps] button is what you were looking for. I would than add it to the rest of the page or delete it.
w.
Apollogize for late answer: yes, it serves the purpose (the arrow icon made it more "elegant" but not needed). Go for it.