1-16chrd, an interesting idea...

[Philippe Hurbain]

Following Darats idea exposed here

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?

[Merlijn Wissink]

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?

[Magnus Forsberg]

What?!

How?

[Philippe Hurbain]

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

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).

[Damien Roux]

What about officilizing this?

[Magnus Forsberg]

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.

[Philippe Hurbain]

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.

[Chris Dee]

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.

[Santeri Piippo]

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?

[Philippe Hurbain]

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).

[Philippe Hurbain]

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.

[Santeri Piippo]

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.

[Philippe Hurbain]

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

[Santeri Piippo]

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

[Chris Dee]

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

[Steffen]

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...

[Steffen]

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

[Philippe Hurbain]

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

[Steffen]

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.

[Philippe Hurbain]

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

[Chris Dee]

I like this solution.

[Roland Melkert]

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.

[Steffen]

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.

[Philippe Hurbain]

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

[Chris Dee]

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

Does Roland's suggestion work in MLCad?

[Philippe Hurbain]

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)?

[Travis Cobbs]

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.

[Steffen]

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.cg...8/logo.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg.../logo2.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg.../logo3.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg.../logo4.dat
http://www.ldraw.org/cgi-bin/ptdetail.cg.../logo5.dat

[Damien Roux]

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

[Steffen]

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.cg...16chrd.dat

[Magnus Forsberg]

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.

[Damien Roux]

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

[Philippe Hurbain]

Now on PT...
http://www.ldraw.org/cgi-bin/ptdetail.cg...4ering.dat

[Magnus Forsberg]

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.

[Massimo Maso]

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

[Magnus Forsberg]

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

[Willy Tschager]

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.

[Willy Tschager]

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

Thanks

w.

[Philippe Hurbain]

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)?

[Willy Tschager]

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

It does: http://www.ldraw.org/cgi-bin/ptdetail.cg...769p0b.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.

[Philippe Hurbain]

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.

[Willy Tschager]

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.

[Philippe Hurbain]

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

Yup, should be there.

[Travis Cobbs]

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?

[Willy Tschager]

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.

[Travis Cobbs]

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).

[Willy Tschager]

+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.

[Travis Cobbs]

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.

[Willy Tschager]

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.

[Willy Tschager]

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.