Subject:
|
Re: Object Orientation & DAT files & CLIPPING/WINDING
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 18 Oct 1999 17:17:44 GMT
|
Reply-To:
|
RUI.MARTINS@LINKstopspam.PT
|
Viewed:
|
419 times
|
| |
|
|
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
INVERT only means see referenced file as inverted.
if INVERT is used cascaded,example:
0 file1
0 INVERT
0 reference to file 2
--------------------
0 file2
0 INVERT file 3
--------------------
then it means:
for file1:
see file 2 as inverted
for file:
see file 3 as inverted twice, so no invertion
because, this works like a stack of invertions, in context
of file 2, it is already inverted, when referenced from file1,
so file 3 will be referenced inverted twice.
if file2 is referenced from another file that does not invert,
than file 3 will inverted only once.
-----------------
KEEP on READING
-----------------
On Mon, 18 Oct 1999, Steve Bliss wrote:
> On Mon, 18 Oct 1999 12:51:59 GMT, Rui Martins <Rui.Martins@link.pt> wrote:
>
> > - A .DAT file is CCW
> > - A .DAT file is possibly optimized for clipping (not realy relevant) • --------
> > - A .DAT file is always oriented outwards or upwards as applicable,
> > this information is to be used, when you want to INVERT a file.
>
> These are all assumptions/specifications which *should* be agreed upon by
> the L-CAD community, especially parts-authors and rendering
> program-writers. Agreement is only needed if we want to re-wire the parts
> library, to encourage clipping-enabled rendering programs.
They should be agreed, of course, I'm just making a sugestion.
A well tough sugestion! IMHO.
> [repeating]
> > - A .DAT file is possibly optimized for clipping (not realy relevant)
>
> When you say 'optimized for clipping', do you mean the file is
> checked/written so that quads/tris are CCW, and subfiles aren't
> unecessarily inverted?
YES,
CHECKED, QUADS/TRIS written as CCW, and THIS subfile is not inverted.
------- ---------- --- ----
The subfiles do not matter, they will be addressed according
with their normal proposed state (NOT inverted).
remember This works like a stack of invertions!
(can be optimized with a toggle flag, since 2*n invert = 0 invert)
> > - The following Meta commands scope is local to the file where it is used
> > 0 CLIPPING ON/OFF
> > 0 WINDING ON/OFF
> > 0 INVERT
> > (this last one is usefull only when referencing other .DAT files)
> > (Drawing/Editing program should keep track of matrix inversions)
>
> When you say "scope is local", do you mean the meta-commands affect
> subfiles referenced by the current file, but the settings loses effect
> after the end of the current file?
NO, see beginning of mail!
> I would agree with this definition for CLIPPING and INVERT, but WINDING
> should be strictly local: it only affects quads/tris in the same file. Not
> subfiles.
Should be local for all, see beginning of mail.
> Each DAT-file has to establish its own WINDING.
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.
> > Now the INVERT problem: • [snip]
> > NOTE:
> > if you had a non simetrical object, you will probably need an invert
> > matrix (with a negative determinant), besides the INVERT meta command.
>
> You'll always need to specify the inversion in the matrix, whether the
> subfile is asymmetrical or not. The matrix specifies the exact inversion
> to perform. The 0 INVERT is just a flag to the renderer, which says "Hey,
> rendering program! The next statement intentionally turns the subfile
> inside-out, so don't correct it."
You know what I mean ! :)
> > Be my gests a comment!
>
> OK. Going on about a possible 0 WINDING UNKNOWN option. In
> <http://www.lugnet.com/cad/dev/?n=3122>, Rui wrote:
>
> > I see no usefulness, for WINDING UNKNOWN, it is either CCW or CW, if
> > it's NOT one of this than it is incorrect (possibly bow-ties), should be
> > drawn erroneously so that peoplw would correct them
>
> Agreed that new files should be written correctly, and not rely on flags to
> say that they aren't compliant.[1] [2]
Great !
> 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.
--------------------------------
> My goal with WINDING UNKNOWN is to have a statement which can temporarily
> disable clipping[3], without overwriting the existing clipping state.
> This is because the clipping state is passed in from super-files, so the
> current file should avoid making hard-assignment of the clip-state.
>
> An alternative to WINDING UNKNOWN would be to define the operation of 0
> CLIPPING ON|OFF such that disabling clipping in a super-file overrides
> local CLIPPING ON statements.
NO, the clipping state is not passed from file to file. It's LOCAL.
> 1-Note that nearly all of the part-files I've authored recently say 'not
> CW-compliant'. If anyone thinks I'm being two-faced, allow me to point out
> that right now, there isn't any clipping-tag standard or expectation. And
> in some cases, there is a significant effort-saving in writing DAT-commands
> in a non-CW format. The non-compliant file header is just providing
> potentially useful information for the future.
Great! That is obviosly usefull until a clipping standard is agreed.
After the standard, every polygon marked Clipping compatible or
whatever, is complaint, every other is non-complaint, which will be
backwards compatible with your marking/tagging.
> 2-OTOH, I don't think new files should be rejected from ldraw.org
> part-updates because they are not clippable. It *should* be a requirement
> that new files are correctly marked up: they should either be formatted for
> clipping, or they should have the agreed-upon flag to say they aren't
> clippable. This is a volunteer effort, and unecessary restrictions should
> be avoided.
No one said that they would be rejected !
That's not the ideia. The reason beeing all this is to provide a faster
rendering/drawing to a program that supports this.
if the program or the .DAT file does not support this, you want be able
to take advantage of this feature. but everything will work, slower but
it will work.
the old Files / already in existence, are OK, they are just not
optimized.
> 3-The only reasons I can think of to disable clipping in the DAT-code[4],
> are (a) the code is not clipping-compliant, (b) the code is for a two
> object, such as a printed decoration. Are there any other?
I am assuming that by a "two object" you meant a
"2D object" or
"Planar Object" or
"Non Solid Object"
and by object I understand as any group of one or more tris/quads.
Than YES. but I don't think that a printed decoration, should be
non clipping, because if you see it from beeind the decoration would be
reversed.
(By decoration I assume : a planar group of polygons, or a polygon with
a texture on it)
> 4-Transparency causes the *rendering program* to disable clipping, and is
> not (cannot) be handled within the DAT-code.
Correct! this as already been said, not a long time ago.
Rui Martins
|
|
Message has 2 Replies:
 | | Re: Object Orientation & DAT files & CLIPPING/WINDING
|
| Rui Martins wrote in message ... (...) I concur that WINDING is strictly local. It may be a struggle of words, but I wouldn't call INVERT *local* as it affects the behaviour all tris/quads in *subfiles* And I don't see why clipping should be local. (...) (25 years ago, 19-Oct-99, to lugnet.cad.dev)
| | | 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)
|
Message is in Reply To:
| | Re: Object Orientation & DAT files & CLIPPING/WINDING
|
| (...) These are all assumptions/specifications which *should* be agreed upon by the L-CAD community, especially parts-authors and rendering program-writers. Agreement is only needed if we want to re-wire the parts library, to encourage (...) (25 years ago, 18-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
