Sticker bottoms - Subfile or Primitive

[Max Martin Richter]

Hi there,

as written in our core group, I would like to suggest to create primitives for the sticker backsides, which are rectangular and have rounded corners (formed and unformed) So they can be used for different stickers.
For now we the same backside several times with different subfile names.

I made a little Excel sheet. Which is linked 
  Sticker Bottom List.xlsx (Size: 11.26 KB / Downloads: 6) to this post. Please note that sometimes the same sticker backside is mixed up with X and Z coordinates. This needs to be fixed in any case before the release. (Do we have rule, that stickers should be made in a way that Z x X contains a X value which is always equal or greater than Z (as we do for most of our bricks)?

Suggestion for the name:

flat sticker backsides: stickbs[Z]x[X]r[Radius of Corners]
Means: StickerBackSide[Z]by[X]radius[Radius of Corners]

formed sticker backsides: stickbsf[Z]x[X]r[Radius of Corners]p[Matching part without file extension]
Means: StickerBackSideFormed[Z]x[X]Radius[Radius of Corners](Matching)Part[Matching part without file extension]

Any thoughts on this?

/Max

[Orion Pobursky]

Do we have rule, that stickers should be made in a way that Z x X contains a X value which is always equal or greater than Z (as we do for most of our bricks)?

No and, per the spec, we should not. The sticker should be oriented "such that the top of the pattern aligns with the +Z axis." This means we could have a 1.5 x 3.5 sticker and a 3.5 x 1.5 sticker depending on the pattern.

[Orion Pobursky]

A couple of thoughts:
- I think subparts are a better location for these. Yes, I know about the documentation question but nothing is stopping us from have the same proposed naming convention.
- Regardless of the above, formed backs should always be subparts. The primitive folder should be kept as clean a possible and I don't want a bunch of obsolete prims because the part number changed.
- IRL all stickers have rounded corner but corners should only be modeled rounded if the rounding is more that the default.

[Philippe Hurbain]

A couple of thoughts:
- I think subparts are a better location for these. Yes, I know about the documentation question but nothing is stopping us from have the same proposed naming convention.
- Regardless of the above, formed backs should always be subparts. The primitive folder should be kept as clean a possible and I don't want a bunch of obsolete prims because the part number changed.
- IRL all stickers have rounded corner but corners should only be modeled rounded if the rounding is more that the default.

I agree with Orion (especially the last point!)

[Max Martin Richter]

A couple of thoughts:
- I think subparts are a better location for these. Yes, I know about the documentation question but nothing is stopping us from have the same proposed naming convention.
- Regardless of the above, formed backs should always be subparts. The primitive folder should be kept as clean a possible and I don't want a bunch of obsolete prims because the part number changed.
- IRL all stickers have rounded corner but corners should only be modeled rounded if the rounding is more that the default.

At least the last point is not correct.
Until the late 90s almost all stickers had sharp corners. Nowadays they are rounded.

[Orion Pobursky]

At least the last point is not correct.
Until the late 90s almost all stickers had sharp corners. Nowadays they are rounded.

Ok. My point stands. The very small rounding doesn't need to be modeled.

[N. W. Perry]

Ok. My point stands. The very small rounding doesn't need to be modeled.

Agreed, this should be left to the rendering software, the same as rounding the corners of regular bricks, for example.

By extension, in my ideal world even the sticker backside itself would be automatic—i.e., any part designated as a Sticker would be automatically drawn with the .25 LDU thickness, so all you'd ever need to model is the pattern itself.

(Beyond the scope, I know…but just in case someone ever searches the forum for ideas on LDraw 2.0…) 

[Max Martin Richter]

May I bring this thread back to focus as we are going to have some parts almost ready for admin cert I would really like to avoid to have identical subparts for several shapes.
Can we implement or pin the content of my excel chart as reference somewhere?

Concerning the round cornes.
As they were not present till some time and are now present, I think they should be modeled.

/Max

[Magnus Forsberg]

These are subfiles to me. Not primitives.
I like the idea. Having 5 files with the same content is not good/wrong.

I see some issues with the part names:

• Extremly long.
  
• I don't think having a . (point) in the name is a good idea, or accepted practice.
  

   

I used your excel sheet and made some examples.

[Max Martin Richter]

These are subfiles to me. Not primitives.
I like the idea. Having 5 files with the same content is not good/wrong.

I see some issues with the part names:

• Extremly long.
  
• I don't think having a . (point) in the name is a good idea, or accepted practice.
  

I used your excel sheet and made some examples.

If we use them as subfiles, we should avoid separate names (otherwise we would clutter up our /s folder with /p folder named files ;-) ). Instead we should have a list, where these subfiles are  listed.
We just need somebody who maintains the list (I could do that).
All in all this would be a simple table like attached to my initial post without the actual part numbers except of the number of initial file.

[Magnus Forsberg]

Here's an example that works for me:
https://www.ldraw.org/cgi-bin/ptscan.cgi?q=87080

[Max Martin Richter]

Here's an example that works for me:
https://www.ldraw.org/cgi-bin/ptscan.cgi?q=87080

Yes, just a subpart number is fine in my eyes.

Orion do we have a possibility to create a list for this maybe as subpage at the PT-tools?

[Willy Tschager]

Suggestion for the name:

flat sticker backsides: stickbs[Z]x[X]r[Radius of Corners]
Means: StickerBackSide[Z]by[X]radius[Radius of Corners]

I have an issue with the abbreviation. As we do no longer have a limitation on filenames I would prefer a "StickerBackSide" over some cryptic "stickbs".

w.

[Orion Pobursky]

Needs to be all lower case so I'd suggest "sticker-back-<...>"

[Magnus Forsberg]

Needs to be all lower case so I'd suggest "sticker-back-<...>"

Let's go with something very simple like "sticker-back-[partnumber]-[a-z].dat"
I don't think many parts will have a need for many backside shapes. Maybe [01-10] is enough, instead of [a-z]?

Or a simple suffix? Maybe [partnumber][b01-b09,b0a-b0z] where "b" stands for "back side"?

I see no reason having a full description of different details in the filename.  That belongs in the description of the subpart.

[Willy Tschager]

Let's go with something very simple like "sticker-back-[partnumber]-[a-z].dat"
I don't think many parts will have a need for many backside shapes. Maybe [01-10] is enough, instead of [a-z]?

Or a simple suffix? Maybe [partnumber][b01-b09,b0a-b0z] where "b" stands for "back side"?

I see no reason having a full description of different details in the filename.  That belongs in the description of the subpart.

So you would have to check the size of the an old part to see if that back suits your new sticker??? I've got that sticker for a Tile 2x2. Go aheay an tell me the right part number for my sticker.

The filename should tell you right away if this is the right back for your 1.9 x 1.9 sticker. If you wanna simply safe on the radius, as I presume that all 1.9 x 1.9 stickers for a Tile 2x2 come with the same radius. "sticker-back-1,9x1,9-rounded-corners.dat"

w.

[Max Martin Richter]

I updated the old table with auto generation of filenames.
Link to Google Docs

As there is already one case in the old table, where R = 3 (all others are 1.5) this variable is needed as well for the name.

I will update the table when we find a conclusion. (Of course we can discuss on this topic in April/May as well.)

/Max