Subject:
|
Re: BFC: LITS 2
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 7 Apr 2000 20:49:19 GMT
|
Viewed:
|
2458 times
|
| |
|
|
In lugnet.cad.dev, Rui Martins wrote:
> I read the current proposal, and I have this to say:
>
> I don't agree with the following paragraph when an entire branch has to have
> cliping on
> to be able to be culled, don't think so.
> ( I know about the invert case, solution required )
Unless we have a solution to the invert case, the document's assertion
is correct.
> 4 for file authors. Setting winding to unknown is one way to prevent specific
> 4 polygons from being clipped.
>
> This is a bad use of winding statement, that's why I don't like the "unknown",
> people should use NOCLIP, instead of this trick, maube remove "unkown" from the
> spec
> would be better.
> if required a comment can be put in cases that an author wan'ts to specifcally
> state
> that winding is uncheck/unknown, and he will disable clippig in that section.
I think you are correct that NOWIND/UNKNOWN is not important/needed.
For now, let's proceed assuming that decorations will be handled by
using NOCLIP or some other technique that doesn't impact the BFC
meta-language.
BUT, I reserve the right to later ask for consideration for DOUBLESIDED,
if it turns out that would be a good option to have. I am not
advocating for DOUBLESIDED right now, but I think we've got issues to
settle in regards to rendering decorations.
> I don't agree with the previous paragraph when an entire branch has to have
> cliping on
> to be able to be culled.
>
> taling the above paragraph spec, the following shouldn't be needed:
>
> 4 If the clipping state is modified, it will only affect the clip-state of the
> 4 local file. When subfiles are referenced, they will receive a flag indicating
> 4 the accumulated clipping state, but there is no sense of a global clipping
> 4 mode.
How is 'accumulated clipping state' different from 'global clipping
mode'? Unless you mean that a 'global clipping mode' would persist even
after a subfile is finished/exited. If that is your understood meaning,
then I agree with you: the CLIP/NOCLIP setting does not persist after
the file containing the statement is ended.
> The second following paragraphs contradicts the first:
>
> 4 A second way to specify a file as compliant is to use any option, except for
> 4 the NOCERTIFY option, on a 0 BFC meta-statement, before the first operational
> 4 command-line. This is an acceptable alternative, but the 0 BFC CERTIFY
> 4 method is recommended and prefered.
> 4
> 4 If a file has no 0 BFC statement at the beginning, then the file will be
> 4 treated as if a 0 BFC NOCERTIFY was given.
They don't contradict each other. The first paragraph says that the
statements:
0 BFC CW
0 BFC CLIP
0 BFC CERTIFY CCW NOCLIP
[etc]
would all mark the file as being BFC-certified, and the statement
0 BFC NOCERTIFY
marks the file as not being BFC-certified.
The second paragraph that if the file doesn't have *any* BFC statement,
then the file is *not* BFC-certified.
> What do you mean by the following ?
>
> 4 If no CLIP or NOCLIP option is specified for a file, then the local clip-state
> 4 is set to enabled (CLIP) for that file.
Is it better like this?
|10 If neither the CLIP nor NOCLIP option is specified in a file's leading 0 BFC
|10 statement, then the local clip-state is set to enabled (CLIP) for that file.
> Others NO NO paragraphs (contradiction)
>
> 9 The typical method of determining that an orientation matrix is inverted is
> 9 to calculate the determinant of the matrix. If the determinant
> 9 is negative, then the matrix has been inverted. This document does not
> 9 attempt to address the details of 3D graphics algorithms and issues.
> 9
> 9 The rendering engine should *not* try to determine if a subfile inversed by
> 9 checking the sign of the determinant of the orientation matrix.
You're right, that does look odd. I've rearranged most of this section,
please check the posted file to see if it is more clear. I'll post the
file before 04:00 GMT.
> The following is just plain bad for performance, NO checking should be done, if
> user is smart,
> the file is BFC compatible, if NOT bad luck, let's NOT inder performance in
> every case.
That's funny, I've read just the opposite argument: it shouldn't be
necesary to flag every single (older) model file, just so they can
benefit from BFC processing.
> The following is just annoying, for non-compliant files, and it won't make any
> difference,
> because as stated in the proposal, if no BFC CERTIFY is given, then assume it's
> NOT.
>
> 1 New parts will not be required to be compliant with this extension. They
> 1 will be required to carry a 0 BFC tag, indicating either compliance
> 1 or non-compliance.
Whatever. I'd rather have things explicitly spelled out where possible,
with a fallback default that can be used where needed.
> Also I would like to propose that the NOCERTIFY be removed, not need, just adds
> clutter
> and processing time.
See my comment above. As the parts-update guy, I'm likely to add notes
to non-compliant files, so they might as well be functional notes.
> I would also like to propose the CERTIFY to be in another command, because
> certify
> is too general, and could mean exactly that file has been accepted by the lego
> comunity,
> as free of errors and complient with what ever is the rule at the moment, NOT
> BFC.
> And also because this info is NOT required to render correctly, it's just info
> for
> users, renderers will only rely on BFC directly related parameters(options).
> We could speed up the rendering, if we didn't have to parse this info.
Let me reiterate my position on parsing issues: each file should be
loaded and parsed *exactly* one time during rendering. If there are too
many files for the rendering engine to cache them in memory, the user
has bigger problems than the microseconds it takes to parse a command.
> so something like 0 CERTIFY BFC should be more correct and general. Also since
> it's
> user info, programs can ignore it or NOT it's up to them.
I'm not against having a 0 CERTIFY BFC command. Then again, I also like
having all BFC-related stuff on a single meta-command.
> please add "Should assume the default, and not state CCW directly", to the
> following
> paragraph, just because it's faster, and primitives are drawn many times.
>
> 1 It is desirable for all files to use the same winding. When possible, files
> 1 should use counter-clockwise winding. The actual winding for any part is
> 1 left to the file author. Primitives should always use CCW winding.
If files without certification are assumed to be non-BFC'able, as the
spec is currenctly written, and the renderer doesn't look at the 0
CERTIFY command, and the winding isn't stated, then what *should* be at
the head of the file? Oh, wait, we've still got 0 BFC CLIP.
> After all this it's obvious that the pseudo code does not represent my thoughts
> about Ldraw Back Face Culling.
I was getting that distinct impression. Care to put out some alternate
pseudo-code?
Steve
|
|
Message is in Reply To:
 | | Re: BFC: LITS 2
|
| I read the current proposal, and I have this to say: I don't agree with the following paragraph when an entire branch has to have cliping on to be able to be culled, don't think so. ( I know about the invert case, solution required ) 4 Control of (...) (25 years ago, 2-Apr-00, to lugnet.cad.dev)
|
24 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
