Subject:
|
Re: Object Orientation & DAT files & CLIPPING/WINDING
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 20 Oct 1999 11:25:12 GMT
|
Reply-To:
|
rui.martins@link.pt%Spamless%
|
Viewed:
|
612 times
|
| |
|
|
On Tue, 19 Oct 1999, Steve Bliss wrote:
> On Mon, 18 Oct 1999 17:17:44 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
>
> > FIRST OF ALL
> > my sugestion is that the CLIPPING, WINDING, INVERT are strictly local
> > where they are used.
> >
> > CLIPPING is strictly local
> > WINDING is strictly local
> > INVERT is strictly local
>
> <snipped stuff about INVERT>
>
> I think we're disagreeing about the meaning of 'strictly local'. As you
> describe the operation of INVERT, it is *not* local.
Yes it is.
> The state of inversion is passed down the file-reference tree.
The reference of the current GLOBAL state is passed down the
file-reference tree, YES.
> This is not a local operation. It is true that each file, while it is
> being rendered, has no information about which super-files inverted
> (or didn't).
Correct.
> But it must know the current state of inversion, in order to clip correctly.
NOT the FILE, but the RENDERING PROGRAM !
> Contrast this with WINDING: if a file declares WINDING CW, this will not
> imply that any subfiles invoked by that file will also be WINDING CW. The
> "state of winding" is only kept for the current file.[1]
Agreed.
> > > Each DAT-file has to establish its own WINDING.
By default would be CCW.
> > It can have its own winding, INTERNALLY, but to rest of the world its as
> > if it has CCW WINDING all over it.
> > remember you can't see inside.
>
> If you can't see inside it, then the rest of the world doesn't care what
> the winding is.
YES and NO.
The internal winding used, does not care, but the supposed winding
as seen (assumed) from the world must be a prefixed one (default is
best, CCW)
> > > The use for WINDING UNKNOWN would be primarily for existing files in the
> > > parts library, not new files.
> >
> > By what you said above WINDING UNKNOWN is not needed.
> >
> > Since all this stuff is backwards compatible, the existing files, don't
> > need to be changed, unless you want to optimize them.
> > --------------------------------
>
> What if I want to optimize *part* of a file? Remember, I want to avoid
> forcing the clipping state by hard-coding CLIPPING ON and CLIPPING OFF.
How do you want do do that, without enclosing the optimized part with
CLIPPING ON/CLIPPING OFF.
NOTE: You can check the file WINDING, and NOT turn on clipping, but then
you want gain any speed increase.
the rest of the .DAT file stays has it was before, unoptimized.
> > NO, the clipping state is not passed from file to file. It's LOCAL.
>
> This is the point we disagree on. I can see how to write files and
> subfiles to work with either assumption (either the clipping-state is local
> or it is passed into subfiles).
>
> IMO, it is better to pass the clipping-state through to subfiles. This
> requires fewer assumptions about the way files work together, and places
> fewer restrictions on the file author.
Can't agree with that.
- By your assumption, you could have all files optimized, but if the
first file in the reference tree, did not enable clipping, you wouldn't
benefit of all the optimization done on the leaf files.
- Worst, if you had a root (as in a reference tree) file, which enabled
clipping, and if along the way (tree-references), a non-optimized file
was referenced, it would be errouneously drawn, because, the renderer
was assuming that he could clip, but was using incorrect information
(incorrect or reversed winding) and would clip the wrong polygons, or
they would be drawn errouneously or not drawn at all.
> In at least two ways, the clipping must be enforced from higher-up in the
> file-reference tree (during rendering):
>
> 1. When the rendering program has an option to enable or disable clipping.
This will be done globally, by the rendering program, by ignoring or NOT
the CLIPPING commands.
> 2. Any file-references by a non-certified file must not clip.
WHY ? ? ?
That is only a restriction of your NON LOCAL CLIPPING assumption !
if the files are like objects, they are independent, the optimization of
one does not depend on WHO or WHERE it is used, after optimization, a
specific file is optimized by itself, does NOT depend on others.
this enables us, to optimized the files, as soon as we need or have the
time to. and every file using the just optimized file, will benefit.
Rui Martins
|
|
Message is in Reply To:
 | | Re: Object Orientation & DAT files & CLIPPING/WINDING
|
| (...) <snipped stuff about INVERT> I think we're disagreeing about the meaning of 'strictly local'. As you describe the operation of INVERT, it is *not* local. The state of inversion is passed down the file-reference tree. This is not a local (...) (25 years ago, 19-Oct-99, to lugnet.cad.dev)
|
13 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
