LDraw.org Discussion Forums
1-16chrd, an interesting idea... - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: 1-16chrd, an interesting idea... (/thread-14500.html)

Pages: 1 2

1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-09

Following Darats idea exposed here
Quote:I wasn't able to use chrd primitives cause there's no 1-16chrd.
So it doesn't look really nice with primitives substitution.
...I made a quick try: I copied 48/1-16chrd to p folder, removed the only quad it contains and inserted the file into Homer donut.
Here is the result with primitive substitution (1-16chrd was added only on top).
   
Comments?

Re: 1-16chrd, an interesting idea... - Merlijn Wissink - 2014-11-09

Looks really nice. I've been so annoyed by those little gaps on the 1x1 tile (those are the only parts I've made prints for yet).
Would it be easy to fix all the other 1x1 round tiles?

Re: 1-16chrd, an interesting idea... - Magnus Forsberg - 2014-11-09

What?!

How?

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-09

Quote:Would it be easy to fix all the other 1x1 round tiles?
Yes, just add the attached file to your p folder, and following code to your part
Code:
1 16 0 0 0 9 0 0 0 1 0 0 0 9 1-16chrd.dat
1 16 0 0 0 8.31492 0 -3.44415 0 1 0 3.44415 0 8.31492 1-16chrd.dat
1 16 0 0 0 6.36396 0 -6.36396 0 1 0 6.36396 0 6.36396 1-16chrd.dat
1 16 0 0 0 3.44415 0 -8.31492 0 1 0 8.31492 0 3.44415 1-16chrd.dat
1 16 0 0 0 0 0 -9 0 1 0 9 0 0 1-16chrd.dat
1 16 0 0 0 -3.44415 0 -8.31492 0 1 0 8.31492 0 -3.44415 1-16chrd.dat
1 16 0 0 0 -6.36396 0 -6.36396 0 1 0 6.36396 0 -6.36396 1-16chrd.dat
1 16 0 0 0 -8.31492 0 -3.44415 0 1 0 3.44415 0 -8.31492 1-16chrd.dat
1 16 0 0 0 -9 0 0 0 1 0 0 0 -9 1-16chrd.dat
1 16 0 0 0 -8.31492 0 3.44415 0 1 0 -3.44415 0 -8.31492 1-16chrd.dat
1 16 0 0 0 -6.36396 0 6.36396 0 1 0 -6.36396 0 -6.36396 1-16chrd.dat
1 16 0 0 0 -3.44415 0 8.31492 0 1 0 -8.31492 0 -3.44415 1-16chrd.dat
1 16 0 0 0 0 0 9 0 1 0 -9 0 0 1-16chrd.dat
1 16 0 0 0 3.44415 0 8.31492 0 1 0 -8.31492 0 3.44415 1-16chrd.dat
1 16 0 0 0 6.36396 0 6.36396 0 1 0 -6.36396 0 6.36396 1-16chrd.dat
1 16 0 0 0 8.31492 0 3.44415 0 1 0 -3.44415 0 8.31492 1-16chrd.dat
Quote:What?! How?
Magic of LDView primitive substitution... The empty file is replaced with a mathematically defined arc (just as 48\1-16chrd does at 48 level).

Re: 1-16chrd, an interesting idea... - Damien Roux - 2014-11-09

What about officilizing this?

Re: 1-16chrd, an interesting idea... - Magnus Forsberg - 2014-11-09

Truly magic.

Why does it only work correctly if I have the 'curve quality' slider set on an even value, 2, 4, 6..?
Odd values give the 4-4-torus and the 1-16chrd different number of 'corners'.

I usually have it set on 3.

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-09

Mmhhh... a bit annoying. Substitution polygon is level times 8, and the trick works only for multiple of 16 since main structure is 16-sided. Hence the need for even substitution level.

Re: 1-16chrd, an interesting idea... - Chris Dee - 2014-11-09

Could someone please check how MLCad copes with this empty file. I seem to recall that last time I tried something similar with an obsoleted part, MLCad whinged.

Otherwise, yes.

Re: 1-16chrd, an interesting idea... - Santeri Piippo - 2014-11-09

I'm not too sure what I think of this. I had to remove 'unnecessary' conditional lines from some of my shield parts because they only catered for LDView's smooth shading results so why should we have something like this around?

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-09

Indeed, this causes problems with MLCad. No whinge, but complete part is reduced to a single dot. It does work by adding a zero-sized triangle (attached) but this can perhaps cause issues with other programs (though I don't expect it).

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-09

You have a point, but this is not a viewer specific trick, but a feature specific one. Any program that performs primitive substitution should behave correctly.

Re: 1-16chrd, an interesting idea... - Santeri Piippo - 2014-11-09

I'd imagine any viewer with smooth shading would've also benefitted from the extra conditional lines too. I see where you are coming from though.

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-09

Not exactly, that's a problem with LDView implementation, as explained here by Travis.

Re: 1-16chrd, an interesting idea... - Santeri Piippo - 2014-11-09

Ah, alright then. Thanks for clarifying, carry right on.

Re: 1-16chrd, an interesting idea... - Chris Dee - 2014-11-09

Hmm. If I open this in LDView (4.1) it is a little confused because the tree view shows:
3 16 0 0 0 0 0 0 0 0 0
3 16 0 0 0 0 0 0

Re: 1-16chrd, an interesting idea... - Steffen - 2014-11-22

can we construct a condline whose condition is always false?

this would be IMHO the least problematic way of getting rid of this problem,
because I fear that zero sized triangles, lines or quads always produce 1 dummy pixel and/or
a math crash in other programs (when these e.g. try to compute normals or similar).

if they are programmed without catching this special case, they can crash or make other undefined bad things.
of course, such flaws are comparable to MLCad's.

I'm not happy to see that we have to workaround a nearly trivial MLCad bug here which could be fixed with a single line of code...

Re: 1-16chrd, an interesting idea... - Steffen - 2014-11-28

is this maybe a solution? a conditional line which is never visible? isn't this one such?:
5 24 0 0 0 10 0 0 5 -10 0 5 10 0

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-11-28

well, one problem is that it shows when all condlines are displayed. A bit nnoying for debug.

Re: 1-16chrd, an interesting idea... - Steffen - 2014-12-04

yeah, but I consider that a smaller issue than having a zero size triangle or line or quad because that always will show as 1 pixel.

the condline however will only be visible during debugging which is a special case.

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-12-05

Yeah, seems workable. Your BIG condline does show prominently in MLCad (though it should not), but a very short one does not
Code:
5 24 0 0 0 0.0001 0 0 0.0001 -0.0001 0 0.0001 0.0001 0


Re: 1-16chrd, an interesting idea... - Chris Dee - 2014-12-06

I like this solution.

Re: 1-16chrd, an interesting idea... - Roland Melkert - 2014-12-06

What would happen (in mlcad) if you use a con line with control point(s) identical to (one of) the line point(s). That way the line wouldn't cause problems in other software as it should be filtered out being invalid and all.

Re: 1-16chrd, an interesting idea... - Steffen - 2014-12-17

once we have decided how to implement a dummy empty contents, we should put it to P\empty.dat or
P\nothing.dat and reference that file from wherever we need an empty content.

this way the dummy implementation is centrally located in a single file and can be adjusted when necessary.

otherwise, it would be repeated in multiple files. this is something which we should avoid.

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-12-17

You mean that 1-16.chrd should reference an empty.dat ? Why not ... (though I don't foresee much more usages of empty file...)

Re: 1-16chrd, an interesting idea... - Chris Dee - 2014-12-17

Yes, I agree with Steffen. Isn't there a lo-res stud somewhere that is empty?

Does Roland's suggestion work in MLCad?

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2014-12-18

Quote:Does Roland's suggestion work in MLCad?
Yes it does. But I got another idea: if we prefix the line with 0 MLCAD HIDE, it makes MLCad happy (tested) and for sure will be invisible from anything other program, either because it will treat line as a comment, or if it knows about MLCad meta, make it hidden.
Code:
0 MLCAD HIDE 5 24 0 0 0 0.0001 0 0 0.0001 -0.0001 0 0 0 0
Otherwise...
I made more tests with 1x1 round tile. My first idea was to include the 1-16chrd primitives at subpart level, but then I get an overlap with the 4-4disc of plain tile (with primitive substitution enabled). Not so annoying because they have the same color, but it would be an issue for a colored primitive ring. So they must be used at main part pattern level. To avoid the chore of using 16x 1-16chrd primitives for each and every round tile pattern, I propose to create a new primitive for this, a 4-4 adapter ring. Question, how to name it (there is already a 48\4-4aring)?

Re: 1-16chrd, an interesting idea... - Travis Cobbs - 2014-12-18

While that violates official library restrictions, I think I prefer it, to the point of saying that perhaps an exception should be added to the official library restrictions. Even if programs don't spit out a warning that the conditional line is invalid, it's hard to argue against such a warning being good.

Re: 1-16chrd, an interesting idea... - Steffen - 2014-12-18

that's a nice solution.

I think we should allow this as an exception to the rules to make the empty file possible
AND not break MLCad.

Once a fixed version of MLCad [at some fine day] is out, we can replace the empty file's contents
to be really empty, and/or remove the references to it.

I need that empty file as well (my suggestion to name it in fact is P\empty.dat).
These low-res implementations of the LEGO logo need to be empty in low-res:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/8/logo.dat
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/8/logo2.dat
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/8/logo3.dat
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/8/logo4.dat
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/8/logo5.dat

Re: 1-16chrd, an interesting idea... - Damien Roux - 2015-01-03

What about naming it 4-4ering (like "emptyring")

Re: 1-16chrd, an interesting idea... - Steffen - 2015-01-05

the file is already present on the PT as "empty.dat":
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/empty.dat

I do not like your suggestion of "empty ring", because
I cannot imagine what an "empty ring" should be.
And if this would be an empty ring, then wouldn't it also be an "empty sphere"?
Empty is empty. Alternative names could be "nothing" or "nil" etc.

I also now uploaded the 1-16chrd.dat to the PT:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/1-16chrd.dat

Re: 1-16chrd, an interesting idea... - Magnus Forsberg - 2015-01-05

I think '4-4ering' is an answer to Philo's question above.

I like that suggestion.
One file, containing a set of 16 x 1-16chrd, to be use once in a round tile.

Re: 1-16chrd, an interesting idea... - Damien Roux - 2015-01-06

Yes, it was an answer to Philo's question!

Re: 1-16chrd, an interesting idea... - Philippe Hurbain - 2015-01-06

Now on PT...
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=p/4-4ering.dat

Re: 1-16chrd, an interesting idea... - Magnus Forsberg - 2015-01-10

I think we could use this primitive to prevent gaps around any 16-sided, non-primitive based, design.
I tried adding a 4-4ering to the recently changed Rims 93595p01-p03 and it works fine.

If a pattern, or subfile, made of non circular primititves, is placed inside a ring or ndis primitive there will always be gaps around it, in primititve substitution mode.
This idea, the 1-16chrd and any X-Xering, will close that unwanted gap if placed correctly. It could even be used to add differently coloured areas.

Re: 1-16chrd, an interesting idea... - Massimo Maso - 2015-02-14

I'm not able to visualize the 4-4ering primitive, so can you give me the correct insturction to be included, soas to complete the four parts 93595?

Massimo

Re: 1-16chrd, an interesting idea... - Magnus Forsberg - 2015-02-14

You need to add this to the front of the rim, sometimes coloured depending on the pattern.
1 16 0 0 -8 13 0 0 0 0 13 0 1 0 4-4ering.dat

and this to the subfile s\93595s01.dat
1 16 0 0 -5 0 0 13 -13 0 0 0 -1 0 1-16chrd.dat

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-03-18

None of this is in the specs or the PT restrictions nor has it been ratified by the LSC. I do not expect reviewers to hold a part for mere suggestions in the forum.

w.

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-11-15

WOULD THE PEOPLE WHO COOKED UP THIS HACK PLEASE PUT IT IN AN OFFICIAL SPEC AND ADD IT TO THE PT RESTRICTION.

Thanks

w.

RE: 1-16chrd, an interesting idea... - Philippe Hurbain - 2018-11-15

(2018-11-15, 9:53)Willy Tschager Wrote: WOULD THE PEOPLE WHO COOKED UP THIS HACK PLEASE PUT IT IN AN OFFICIAL SPEC AND ADD IT TO THE PT RESTRICTION.

Thanks

w.
Is this really necessary, since it concerns a single, already official file (empty.dat)?

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-11-15

(2018-11-15, 11:59)Philippe Hurbain Wrote: Is this really necessary, since it concerns a single, already official file (empty.dat)?

It does: http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/14769p0b.dat

And I guess this is the right place for: http://www.ldraw.org/article/512

A comment in 1-16chrd.dat with a link back to this discussion is not the way to document things.

w.

RE: 1-16chrd, an interesting idea... - Philippe Hurbain - 2018-11-15

I agree these special primitives would need some documentation, but I see that as a wiki entry, rather than as modification of specification! This is just a trick, not something essential.

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-11-15

(2018-11-15, 18:43)Philippe Hurbain Wrote: I agree these special primitives would need some documentation, but I see that as a wiki entry,  rather than as modification of specification! This is just a trick, not something essential.

What about http://www.ldraw.org/library/primref/ then?

w.

RE: 1-16chrd, an interesting idea... - Philippe Hurbain - 2018-11-16

(2018-11-15, 20:04)Willy Tschager Wrote: What about http://www.ldraw.org/library/primref/ then?
Yup, should be there.

RE: 1-16chrd, an interesting idea... - Travis Cobbs - 2018-11-16

(2018-11-16, 15:15)Philippe Hurbain Wrote:
(2018-11-15, 20:04)Willy Tschager Wrote: What about http://www.ldraw.org/library/primref/ then?
Yup, should be there.

I see that 1-16chrd is already documented to exist in the primitives reference, but there is no special note describing why it should be used (and the fact that it is empty). Presumably, documentation for empty.dat and n-fering.dat should also be added.

On a somewhat related note, does the library need a 48/1-48chrd?

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-11-17

(2018-11-16, 18:26)Travis Cobbs Wrote: I see that 1-16chrd is already documented to exist in the primitives reference, but there is no special note describing why it should be used (and the fact that it is empty). Presumably, documentation for empty.dat and n-fering.dat should also be added.

+1

w.

RE: 1-16chrd, an interesting idea... - Travis Cobbs - 2018-11-17

(2018-11-17, 19:23)Willy Tschager Wrote:
(2018-11-16, 18:26)Travis Cobbs Wrote: I see that 1-16chrd is already documented to exist in the primitives reference, but there is no special note describing why it should be used (and the fact that it is empty). Presumably, documentation for empty.dat and n-fering.dat should also be added.

+1

w.

FYI, as far as I know, I no longer have the ability to edit those files. I used to, but there aren't any "edit" links any more (and probably haven't been for years).

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-11-18

(2018-11-17, 22:19)Travis Cobbs Wrote:
(2018-11-17, 19:23)Willy Tschager Wrote: +1

w.

FYI, as far as I know, I no longer have the ability to edit those files. I used to, but there aren't any "edit" links any more (and probably haven't been for years).

You sum it up here and post it to Chris, or ask Chris to fix the privileges - it has probably to do with the server shift.

w.

RE: 1-16chrd, an interesting idea... - Travis Cobbs - 2018-11-19

(2018-11-18, 19:58)Willy Tschager Wrote:
(2018-11-17, 22:19)Travis Cobbs Wrote: FYI, as far as I know, I no longer have the ability to edit those files. I used to, but there aren't any "edit" links any more (and probably haven't been for years).

You sum it up here and post it to Chris, or ask Chris to fix the privileges - it has probably to do with the server shift.

w.

I don't think I'm the best person to describe things. To be clear, LDView's handling of this situation is basically a happy accident. I didn't intentionally program it to work this way. Someone else (I'm not sure who) discovered the behavior and decided to take advantage of it.

As for permissions, I don't see any links on the main ldraw.org site to sign in. So, presumably the editing of content on the site is (intentionally) hidden from normal site visitors.

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-11-26

(2018-11-19, 2:18)Travis Cobbs Wrote: I don't think I'm the best person to describe things.

To be honest I don't care who does the job ... you guys came up with it, now take it home.

w.

RE: 1-16chrd, an interesting idea... - Willy Tschager - 2018-12-02

(2018-11-26, 12:55)Willy Tschager Wrote:
(2018-11-19, 2:18)Travis Cobbs Wrote: I don't think I'm the best person to describe things.

To be honest I don't care who does the job ... you guys came up with it, now take it home.

w.

You can do this guys! How about a commune effort, working together here in the forums.

w.