1-16chrd, an interesting idea...


1-16chrd, an interesting idea...
#1
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?
Reply
Re: 1-16chrd, an interesting idea...
#2
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?
Reply
Re: 1-16chrd, an interesting idea...
#4
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).


Attached Files
.dat   1-16chrd.dat (Size: 317 bytes / Downloads: 0)
Reply
Re: 1-16chrd, an interesting idea...
#3
What?!

How?
Reply
Re: 1-16chrd, an interesting idea...
#6
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.
Reply
Re: 1-16chrd, an interesting idea...
#7
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.
Reply
Re: 1-16chrd, an interesting idea...
#5
What about officilizing this?
Reply
Re: 1-16chrd, an interesting idea...
#8
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.
Chris (LDraw Parts Library Admin)
Reply
Re: 1-16chrd, an interesting idea...
#9
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?
Reply
Re: 1-16chrd, an interesting idea...
#11
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.
Reply
Re: 1-16chrd, an interesting idea...
#12
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.
Reply
Re: 1-16chrd, an interesting idea...
#13
Not exactly, that's a problem with LDView implementation, as explained here by Travis.
Reply
Re: 1-16chrd, an interesting idea...
#14
Ah, alright then. Thanks for clarifying, carry right on.
Reply
Re: 1-16chrd, an interesting idea...
#10
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).


Attached Files
.dat   1-16chrd.dat (Size: 339 bytes / Downloads: 0)
Reply
Re: 1-16chrd, an interesting idea...
#15
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
Chris (LDraw Parts Library Admin)
Reply
Re: 1-16chrd, an interesting idea...
#16
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...
Reply
Re: 1-16chrd, an interesting idea...
#17
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
Reply
Re: 1-16chrd, an interesting idea...
#18
well, one problem is that it shows when all condlines are displayed. A bit nnoying for debug.
Reply
Re: 1-16chrd, an interesting idea...
#19
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.
Reply
Re: 1-16chrd, an interesting idea...
#20
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
Reply
Re: 1-16chrd, an interesting idea...
#21
I like this solution.
Chris (LDraw Parts Library Admin)
Reply
Re: 1-16chrd, an interesting idea...
#22
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.
Reply
Re: 1-16chrd, an interesting idea...
#23
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.
Reply
Re: 1-16chrd, an interesting idea...
#24
You mean that 1-16.chrd should reference an empty.dat ? Why not ... (though I don't foresee much more usages of empty file...)
Reply
Re: 1-16chrd, an interesting idea...
#25
Yes, I agree with Steffen. Isn't there a lo-res stud somewhere that is empty?

Does Roland's suggestion work in MLCad?
Chris (LDraw Parts Library Admin)
Reply
Re: 1-16chrd, an interesting idea...
#26
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)?
Reply
Re: 1-16chrd, an interesting idea...
#27
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.
Reply
Re: 1-16chrd, an interesting idea...
#28
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
Reply
Re: 1-16chrd, an interesting idea...
#29
What about naming it 4-4ering (like "emptyring")
Reply
Re: 1-16chrd, an interesting idea...
#30
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
Reply
Re: 1-16chrd, an interesting idea...
#31
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.
Reply
Re: 1-16chrd, an interesting idea...
#32
Yes, it was an answer to Philo's question!
Reply
Re: 1-16chrd, an interesting idea...
#33
Now on PT...
http://www.ldraw.org/cgi-bin/ptdetail.cg...4ering.dat
Reply
Re: 1-16chrd, an interesting idea...
#34
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.
Reply
Re: 1-16chrd, an interesting idea...
#35
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
Reply
Re: 1-16chrd, an interesting idea...
#36
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
Reply
RE: 1-16chrd, an interesting idea...
#37
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.
LEGO ergo sum
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)