 | | Re: Line in the Sand —Steve Bliss
|
| | | Sorry this is so long. I've tried to err on the side of quoting too much of Lars' message, rather than too little. Also, I've tried to be thourough in my replies. In related news, I've added a 'Current Issues' section at the top of the v4 document. (...) (25 years ago, 5-Dec-99, to lugnet.cad.dev)
|
| | | |
| | | | | Re: Line in the Sand —Steve Bliss
|
| | | | | (...) Seems Geocities is having some trouble, and the shortcut URLs won't work. Try these instead: (2 URLs) Steve (25 years ago, 6-Dec-99, to lugnet.cad.dev)
|
| | | | | |
| | | | | | | Re: Line in the Sand —Jacob Sparre Andersen
|
| | | | | | [ Still discussing (URL) ] Steve: You can also put them on ldraw.org now that you have an account here. Here comes a commented/edited version. Lines starting with "#" are my comments and lines starting with "J" are my changes/additions. ---...--- (...) (25 years ago, 12-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | | | (...) It's an admin role vs. personal role thing. I took it upon myself to write up a spec, I didn't want to imply that it was endorsed by the group at large. (...) Hmmm. You're right. Inversion is no more global than accumulated clipping. They are (...) (25 years ago, 14-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Jacob Sparre Andersen
|
| | | | | | [ Still discussing (URL) ] Steve: (...) That makes sense. (...) I'll reuse the notation. ---...--- (...) # Fine. (...) # I'll try a complete reformulation: 4 INVERTNEXT J This option is used to swap the definitions of "inside" and "outside" (i.e. J (...) (25 years ago, 14-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | | | (...) I like your explanation better, but I think we're both missing the point: this paragraph is supposed to be about INVERTNEXT, not inversion. Fewer details are appropriate at this point. More details should go in (1) the explanation of inversion (...) (25 years ago, 15-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Jacob Sparre Andersen
|
| | | | | | [ Still discussing (URL) ] Steve: [...] (...) Correct. (...) J subfile command line, and it only influences the immediately J following subfile command. I don't think the "and nowhere else" is that important. You already have written "only". (...) (...) (25 years ago, 16-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | | | | (...) In lugnet.cad.dev, Jacob Sparre Andersen wrote: [about INVERTNEXT] (...) OK. Steve (25 years ago, 17-Dec-99, to lugnet.cad.dev)
|
| | | | | | | |
| | | | | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | | | Jacob Sparre Andersen wrote... (...) (snip) (...) Why? Are you thinking about 1 16 -4 0 0 0 0 0 0 0 4 1-4disc.dat The determinant is zero, which BTW causes POVRay to halt ("singular matrix"). L3P has to fix these matrices or POVRay would not render (...) (25 years ago, 20-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | | | (...) Matrix-inversions are not evil. But for some reason, using them to actually invert subfiles is evil (as opposed to using INVERTNEXT to invert subfiles). If I reallly needed an answer to this, I'd go read past messages. But I *do* remember: a) (...) (25 years ago, 21-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | | | | Steve Bliss wrote ... (...) Is this a joke? You argue very well in "Inversion" in "Language Extension Functionality" about the 3D tube ;-) /Lars Sorry if I missed a pun. (25 years ago, 21-Dec-99, to lugnet.cad.dev)
|
| | | | | | | |
| | | | | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | | | | | (...) Nope, not a joke. I seriously didn't remember the reason(s) why other approaches wouldn't work as well as INVERTNEXT. I poked around old messages a little bit, I think I remember better now. Let me (attempt to) explain: When this whole BFC (...) (25 years ago, 22-Dec-99, to lugnet.cad.dev)
|
| | | | | | | | |
| | | | | | | | Re: Line in the Sand —Rui Manuel Silva Martins
|
| | | | | | (...) I do, it's because of those cases like an hollow cylindir DAT file is referenced by another DAT file. Since the cylinder is supposed to be define outwards, but you can use it to make the inside/outside of a stud (for example) and the if the (...) (25 years ago, 21-Dec-99, to lugnet.cad.dev)
|
| | | | | | |
| | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | Steve Bliss wrote... (...) OK. The pseudo-code reflects this now. (...) I meant "The fact that 0 BFC CERTIFY implies 0 BFC CLIP and 0 BFC CCW should be stated explicitly in the CERTIFY section in Language Extensions". The code was clear enough. (...) (25 years ago, 6-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | (...) Sometimes, transparent parts have decorative printing. And the LDraw library should be written so that modelers can use any part in any color, even if LEGO hasn't released that part/color combination yet. Decorations on transparent parts shows (...) (25 years ago, 8-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | Steve Bliss wrote in message ... (...) Remember BFC must be disabled for transparent parts. That's what If 32 <= Color And Color <= 47 Then AccumClip = FALSE takes care of. Frankly I can't think of any situations where double-sided sections are (...) (25 years ago, 10-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | (...) Hmm. that makes me wonder if the logic of turning of BFC clipping when a part's color is transparent will really work. Because a part may have the main color as 16, and some sections are hard-coded to a transparent color. In this case, the (...) (25 years ago, 10-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | Steve Bliss wrote... (...) If IsTransparent(Color) Then AccumClip = FALSE takes care of solid non-16 colors (decorations) in parts used transparently. And a similar check added to BFC() can take care of transparent non-16 colors in parts used as (...) (25 years ago, 14-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | (...) Yes, it would render correctly, but it would also disable clipping more often than is required, in the case of mixed solid and transparent sections. Think of a submodel where the author used color 16, and the person using the submodel renders (...) (25 years ago, 14-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | Steve Bliss wrote... (...) I think this is a possible, but rare case. It can, however, be circumvented by regarding DAT files from PARTS as special. (...) Why not? Any information you can gather by simply analysing a DAT file should not be required (...) (25 years ago, 20-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Steve Bliss
|
| | | | (...) In that case, why are we wiggling about with this BFC extension stuff? Rendering programs can figure out what order vertices should be put in, and they can figure out which way a polygon is facing. They don't need all this extra effort from us (...) (25 years ago, 21-Dec-99, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Line in the Sand —Lars C. Hassing
|
| | | | Steve Bliss wrote... (...) :-) Jean-Pierre's analyzer is not a "simple analysis" and may not work 100% correctly without human intervention. /Lars (25 years ago, 21-Dec-99, to lugnet.cad.dev)
|
| | | | |
