To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 3128
3127  |  3129
Subject: 
Re: Object Orientation & DAT files & CLIPPING/WINDING
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 18 Oct 1999 16:34:50 GMT
Viewed: 
378 times
  
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.

[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?

- 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?

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.  Each DAT-file has to establish its own WINDING.

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."

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]

The use for WINDING UNKNOWN would be primarily for existing files in the
parts library, not new files.

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.

Steve

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.

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.

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?

4-Transparency causes the *rendering program* to disable clipping, and is
not (cannot) be handled within the DAT-code.



Message has 2 Replies:
  Re: Object Orientation & DAT files & CLIPPING/WINDING
 
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 (...) (25 years ago, 18-Oct-99, to lugnet.cad.dev)
  Re: Object Orientation & DAT files & CLIPPING/WINDING  [DAT]
 
Steve Bliss wrote in message <380b3366.9260126@lu...et.com>... (...) No, you don't need to bother with the matrix. Use the 0 INVERT to tell the renderer: "Hey, please turn the following subfiles inside-out". Remember the example from stud2.dat: 1 16 (...) (25 years ago, 19-Oct-99, to lugnet.cad.dev)

Message is in Reply To:
  Object Orientation & DAT files & CLIPPING/WINDING
 
There has been a great discussion, about the optimizing with clipping topic, but it seems IMHO that people are forgetting simplicity is the best. Now if you read the subject of this message, maybe you know what I am talking/writting about. we must (...) (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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR