 | | Re: Line in the Sand
|
|
(...) I would. This is WAY better than most of the crap requirements I have to rationalize into some semblance of something to keep paying customers happy. Very nice work, Steve. Written in a way that made it understandable to someone that doesn't (...) (25 years ago, 20-Oct-99, to lugnet.cad.dev)
|
| |
| | Line in the Sand
|
|
OK, we've been discussing how to best extend the LDraw language to allow rendering engines to do backface-culling. We've got a pretty good agreement on most of what is needed. I think it would be productive, at this point, to work from a complete (...) (25 years ago, 20-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote... (...) Good idea, it's hard to discuss in so many threads. (...) Thank you for the well-written summary. Well-written because I agree with 99% of it ;) (...) Yes, too bad I'm off for an Internet-free :( 4-day week-end at the sea (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote in message <380e2b8e.12563517@l...et.com>... (...) An orientation matrix doesn't contain enough information to invert an asymmetrical part; if you assume it does, this would result in a part with a mirrored shape. I propose that (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Gary Williams wrote in message ... (...) a (...) Well, what I meant to say is: Matrices with negative determinants may be used for mirroring a part, BUT the matrix should never be assumed to perform the actual inversion. If a matrix has a negative (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Thanks. (blushing) Can that be translated into paying work? (...) That's because it's written by someone who keeps the matrix-math reference material very close at hand whenever he's got to actually go under the hood. (...) Issue 1: should the (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Yes. How are you on travel? :-) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
The proposal has been updated, with changes from Lars and Gary, some additional definitions, and a new section of parts guidelines. See it at (URL). The revision marks (along the left margin) will be maintained until we've got a final document, (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Sometimes, life just sucks. ;) Have a great weekend! (...) OK. (...) Both of these. (0 CERTIFY with no tags would be a syntax error, IMO.) (...) Define necessary. ;) CERTIFY is not absolutely required, but it is logical and useful. The other (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
On Thu, 21 Oct 1999 01:07:30 GMT, "Gary Williams" <graywolf@pcpros.net> wrote: [clipped good stuff] (...) You are making sense, it is a valid issue, I've been missing the boat on inversion for awhile now, and I'll update the document. Should there (...) (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Much better than I used to be. Steve "Never trust anything that can think for itself, if you can't see where it keeps its brain." (25 years ago, 21-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) Good work. I have one comment/clarification/question: (...) has disabled clipping at the "calling point" for this subfile. The current wording _could_ be interpreted as "somewhere in the file". Play well, Jacob ---...--- -- E-mail: (...) (25 years ago, 22-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Good catch. I've been wondering how to describe/differentiate the "calling point" or "current environment" idea. I'll put your update in the doc. Steve "Never trust anything that can think for itself, if you can't see where it keeps its (...) (25 years ago, 22-Oct-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) There hasn't been any discussion on this in almost two weeks. Does everyone like this spec? Any issues? Are you programmers willing to implement this? Is it ready to go to press? Steve (25 years ago, 4-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) I haven't had time to reply, hope to have soon. (...) NO ! It's not quite done iet ! 8) (...) Rui Martins (25 years ago, 5-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) I think it is ready, but I will print out a copy, and check it tonight. Play well, Jacob ---...--- -- E-mail: sparre@cats.nbi.dk -- -- Web...: <URL:(URL) -- ---...--- (25 years ago, 5-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) As I said it is not ready iet. The questions (options) that where up in the air, are still there, no one as discussed them, after this spec file was created. I don't have much time now, but here are several problems. Examples: check the (...) (25 years ago, 5-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: I have a small linguistic correction, but except for that, I consider the document finished: There will be a few requirements placed on the design of rendering programs, in order to achieve correct renderings. Any program should may violate (...) (25 years ago, 6-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Agreed, it's logical. Should is too strong ! not like must, but strong anyway. (...) of course, but all files start on one root, if that is no BFC certified, than no acceleration. (...) but a certified part can have sub parts not certified ! (...) (25 years ago, 8-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
[ Still discussing (URL) ] Rui: (...) Yes, but generally it is no big deal to certify a model file - and there is the suggested option for the renderers mentioned further down for the lazy. (...) Yes, but we aren't all that stupid. We will of cause (...) (25 years ago, 9-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Yes, and 'may' is more more correct than 'should', since the "Rendering Engine Requirements" section really is included just to provide a framework for the language extensions. The document specifies the input, and we have a general (...) (25 years ago, 9-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) You'll pardon me if I use an abbreviated notation, and skip the " characters. (...) It's hard to argue with that. Steve (25 years ago, 9-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Yes. WINDING UNKNOWN allows a DAT author to specify what is happening in the file more precisely than CLIPPING OFF. Adding WINDING DOUBLE-SIDED would allow even more author-precision, but there is no practical difference between DOUBLE-SIDED (...) (25 years ago, 9-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) As Jacob said, this is why the specification suggests that rendering programs allow the user to select the option of defaulting CLIPPING to on or off. (...) Huh? In that case, the uncertified primitive is not back-face-culled, but the (...) (25 years ago, 9-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) I'll make these changes. I think all your points have been discussed in follow-up messages, so I'll make my responses (if there are any) to those later messages. Steve (25 years ago, 9-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote... (...) the (...) allow (...) OFF (...) they (...) reference (...) CLIPPING (...) Good point! (...) Or you could write: 0 CERTIFY BFC | 0 CERTIFY NOBFC 0 WINDING CW | 0 WINDING CCW | 0 WINDING UNKNOWN (I don't think "0 WINDING" (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) Yes. (...) The argument against should be that it complicates the rendering significantly, but I don't think it does. Play well, Jacob ---...--- -- E-mail: sparre@cats.nbi.dk -- -- Web...: <URL:(URL) -- ---...--- (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand [DAT]
|
|
(...) Strange sentence, CLIPPING is OFF by default, you can change that by including a CLIPPING ON. And this was not what was beeing discussed. See below. (...) Look at this two trees root root C N / \ / \ C N C N /| |\ /| |\ C N C N C N C N 1 2 3 4 (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) ---...--- (...) Don't take this so personally, it's not worth it. I am only trying to contribute to a worthy cause (LEGO). Everyone can have different opinions. I don't need to jump on the other guys traught. Anyway, I apologise if I have (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) In our case, it makes sense to make a single trip to the store for ingredients (primitives). Once we've got the ingredients on-hand, we can start baking the cakes. Steve No, this didn't really add to the discussion. I just liked the analogy. (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand [DAT]
|
|
On Wed, 10 Nov 1999 00:44:17 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote: Still discussing (URL) (...) Yes, but the 0 CERTIFY ( BFC | NOBFC ) format is more common. And it emphasizes that is one statement with various parameters. And it's less (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
See (URL) There is a serious weakness in this document, 'certification' is not clearly defined. This definitely needs to be addressed. Currently, the only definition of certification is: (...) ... which is a bit of a typo. My definition of certified (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) I don't think I understand you here. Do you mean that it is strange to let the user and/or programmer of the rendering program set the initial CLIPPING value? [clipped nice rendering-process tree] (...) It's not too complicated. A rendering (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote... (...) But it *does* imply CLIPPING ON. Otherwise clipping would be off. Remember, CLIPPING ON cannot turn clipping on if turned off in a superfile. If you render the part alone (just to view the single part) the CERTIFY should (...) (25 years ago, 10-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
I think we should drop the CERTIFY as it is superfluous and apparently adds more confusion than it clarifies! Why not settle for: 0 WINDING (CCW|CW|UNKNOWN) This defines the winding of the following polygons and means that the file is "certified", (...) (25 years ago, 11-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
[ Still discussing (URL) ] Steve: (...) [...] (...) "INVERTNEXT" is good. It makes the effect much more clear. (...) It gets much too messy when you mix the states of a parameter and the setting of that parameter. CERTIFY BFC does imply CLIPPING ON, (...) (25 years ago, 11-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) [...] (...) ...with the inversion status. (...) Yes. You might want to change "INVERT" to "INVERTNEXT". Play well, Jacob ---...--- -- E-mail: sparre@cats.nbi.dk -- -- Web...: <URL:(URL) -- ---...--- (25 years ago, 11-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) OK, I'll change this in the document. Changes from the last few days will be uploaded to GeoCities in the next hour or so. Steve (25 years ago, 12-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) I'd like to hear from other people about this before deciding to keep it or drop it. I'll give my reasons to keep CERTIFY below. But first ... (...) Why not use: 0 CLIPPING (YES|NO) CLIPPING addresses the core issue (can the current file be (...) (25 years ago, 12-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Did you mean you=Steve or you=anyone? (...) I agree, the sequence should be illegal. My point was, does CERTIFY BFC change the value of the internal local_clipping variable, or not? My intention was that it does not. From a practical (...) (25 years ago, 12-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) I _don't_ think CERTIFY should be dropped, but we might want to change it to "EXTENSIONS", since it is intended for listing which extensions to the LDraw language the file contains. (...) Yes. Play well, Jacob ---...--- -- E-mail: (...) (25 years ago, 13-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
[ Still discussing (URL) ] Steve: (...) You=anyone (kind of - English is a very imprecise language - "on" in French, "man" in Danish, ...) (...) That depends on how the program is written. You could imagine that the variable "local_clipping" isn't (...) (25 years ago, 13-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote ... (...) I think your pseudo-code delivers a fine evidence why the CERTIFY is unnecessary ;-) /Lars (25 years ago, 13-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote... (...) But it's not used! (...) But it's not used! (...) But it's not used! Why would future extensions use the CERTIFY statement if we don't have a use for it today? I agree WINDING may not directly make you think about BFC, but (...) (25 years ago, 14-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Oops! Forget a few important details in the psuedo-code! (...) The last line above should be: (AccumClip and LocalClip and (Winding != UNKNOWN) and Certified), (...) And the line above should be: If AccumClip and LocalClip And Certified Then (...) (25 years ago, 15-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote in message ... (...) No, WINDING is local! It does not affect subfiles, this is the very reason why we have invented the CLIPPING command. /Lars (25 years ago, 15-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Argh. You are correct, sir. Serves me right, trying to post quickly. Here's a correction: (...) Steve (25 years ago, 15-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) 0 WINDING (CW|CCW) as the 'certify statement', rather than 0 CLIPPING ON ? Winding is local. Certification is sort-of local -- only the local file is certified, but the local setting affects whether subfiles (in the same reference branch) are (...) (25 years ago, 15-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote in message ... (...) I think it is nice to have the winding state expressed explicitly. IMO part authors should be allowed to whatever winding they find most natural to work with (though you say CCW is desirable). It is perfectly (...) (25 years ago, 15-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Actually, I was thinking of CERTIFY, like a enable of the specific new metacommands. Example: If you have a 0 CERTIFY BFC would mean Enable or take into account the GFC related commands. besides the fact that it certifies that file has beeing (...) (25 years ago, 16-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) I forgot to add that you can have a file that is 'certified', but due to its nature (the lego part/sub-part) no clipping is applicable, but it can have correct point order (no bowties) and a defined winding (the default, or some expecifically (...) (25 years ago, 16-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Still discussing (URL). Here's another syntactical approach to BFC. Like it, hate it, let us know what you think. Have a single 0 BFC statement, which allows specifications of various options/settings. Something like: 0 BFC ( CERTIFY | NOCERTIFY | (...) (25 years ago, 17-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) [...] It is definitely a useable option. How will the specification document look then? If it is easier to read that way, then you have one proponent for that solution. Play well, Jacob ---...--- -- E-mail: sparre@cats.nbi.dk -- -- (...) (25 years ago, 19-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) There are two possibilities for updating the document with this approach: 1. Just change the syntax expressions, and modify any syntax-specific references. This would be the low-impact approach, with only cosmetic changes. 2. Rework the (...) (25 years ago, 19-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
In lugnet.cad.dev, Steve Bliss wrote: Still discussing (URL). I posted a new version, with the short-form syntax, to (URL) Comments? Steve (25 years ago, 25-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) My comments/changes will be preceded by a "J". [...] Subfile. A DAT file referenced from another file, via a linetype 1 command. Or any file which is lower in the file-reference tree than the current file. J Or any file which is the (...) (25 years ago, 25-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) Er, OK. I'll put that in, but it seems redundant. (...) It means that I stuffed in the pseudo-code without rewriting the syntax-specific sections. :( Steve (25 years ago, 27-Nov-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Still discussing: (URL) and now (URL) I posted an update to the v4 spec just now. It includes the changes suggested by Jacob. Things have been quiet lately, so I want to throw out a couple of questions: Does anyone have an opinion on whether it (...) (25 years ago, 2-Dec-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
Steve: (...) I kind of like the newer approach. Play well, Jacob ---...--- -- E-mail: sparre@cats.nbi.dk -- -- Web...: <URL:(URL) -- ---...--- (25 years ago, 3-Dec-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) at first i misread that as: (...) and thought to myself "wow, Steve's in a really cynical mood".. hehe.. guess i'm just projecting my own cynicism... J (25 years ago, 3-Dec-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
(...) I had originally written "before the end of this millenium", but I thought that sounded too pessimistic. And I didn't want to give anyone an opening for the 2000/2001 diatribe. Steve Personally, I just care when the odometer rolls over. (25 years ago, 3-Dec-99, to lugnet.off-topic.fun)
|
| |
| | Re: Line in the Sand
|
|
(...) If the academics are right, it may have rolled over in 1993/94; so many problems are associated with just when we started counting, not to mention whether it's 2000 or 2001 years! best, LFB (25 years ago, 3-Dec-99, to lugnet.off-topic.fun)
|
| |
| | Re: Line in the Sand
|
|
Steve Bliss wrote... (...) I prefer the newer with only one new meta-statement. This easily identifies commands related to BFC. However, the syntactical change doesn't solve the discussion about the CERTIFY option, see later. I have some suggestions (...) (25 years ago, 4-Dec-99, to lugnet.cad.dev)
|
| |
| | Re: Line in the Sand
|
|
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
|
|
(...) 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
|
|
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
|
|
(...) 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
|
|
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
|
|
(...) 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
|
|
[ 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 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
|
|
(...) 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
|
|
(...) 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
|
|
[ 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
|
|
(...) 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
|
|
[ 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
|
|
(...) 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
|
|
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 [DAT]
|
|
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
|
|
(...) 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
|
|
(...) 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
|
|
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 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)
|
| |
| | Re: Line in the Sand
|
|
(...) 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
|
|
(...) 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)
|
