Subject:
|
Re: BFC: LITS 2
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Sun, 2 Apr 2000 23:16:54 GMT
|
Reply-To:
|
RUI.MARTINS@LINK.PTnomorespam
|
Viewed:
|
1642 times
|
| |
|
|
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 the compliance/non-compliance state will only affect the current
4 file. Subfiles will be affected indirectly, because it is not possible to
4 clip subfiles of non-BFC files, but the compliancy of the subfiles will not
6 be affected. That is, it is not possible to clip a BFC subfile when it is
6 referenced by a non-BFC superfile, but the same BFC subfile may be clipped
6 when referenced from a BFC superfile
...
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.
...
4 Clipping. It must be possible for a file to enable and disable clipping. But
4 even when clipping is enabled locally, it may not be possible to perform
4 clipping on the file in some circumstances. Any file will have clipping
4 applied only when the following conditions apply:
4 - All superfiles (in the current reference branch) are certified.
4 - The current file is certified.
4 - No superfile has disabled clipping prior to referencing this
4 subfile.
4 Unless all of these conditions are met at the time a subfile is rendered,
4 no clipping is possible.
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.
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.
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.
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.
spelling above, is somewhat erroneous to specify meaning correctly.
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.
7 Assumed inversions. Generally, it is not possible to assume that a subfile
7 is inverted or normal (which is the reason for the 0 BFC INVERTNEXT meta-
7 statement). One important special case is this: model files do not invert
7 part files. Parts are complex files which would be essentially useless if
8 they were inverted. Assuming part files are never inverted allows
9 the rendering engine to apply BFC-processing on these parts (assuming the
9 parts are certified), even if the calling files aren't certified.
7
7 No assumptions can be made about models which make direct use of primitives
7 or polygon commands, so a rendering engine should not simply treat uncertified
7 model files as certified.
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.
Also I would like to propose that the NOCERTIFY be removed, not need, just adds
clutter
and processing time.
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.
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.
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.
After all this it's obvious that the pseudo code does not represent my thoughts
about Ldraw Back Face Culling.
See ya
Rui Martins
|
|
Message has 1 Reply:
 | | Re: BFC: LITS 2
|
| (...) Unless we have a solution to the invert case, the document's assertion is correct. (...) 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 (...) (24 years ago, 7-Apr-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: BFC: LITS 2
|
| Second in a series, collect them all... (...) I believe the language around the 'defaults' has been cleared up sufficiently. (...) Hmm. I don't think there was much more discussion about whether every file should have an explicit 0 BFC CCW CLIP (...) (24 years ago, 31-Mar-00, to lugnet.cad.dev)
|
24 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
