 | | | | | | |
| |
|
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 think in an object oriented way.
----------------------------------------
So look at a .DAT file as a representation of an object, which by
"accident" is graphic object.
An object does not show how it works in the inside, it only shows to the
world a specific behaviour, how it is done in the inside does not matter.
So, what we have to do is to define the behaviour for this object, has
seen from the rest of the world.
So I will propose the following behaviour,
as seen from the world (the outside of the .DAT file):
----------------------
Remember
The .DAT is a closed object, we can't see inside it (just assume).
- 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.
This was the behaviour, as seen from the rest of the world.
This is what you have to keep in mind when you are referencing other
.DAT files.
For you, the other .DAT files are an external object,
so you are the world relative to them.
----------------- remember this song? ;)
Now what is the behaviour inside the object (.DAT)
Everything that is assumed by the rest of the world, must be the default
inside the object.
if inside, the object requires to do things diferently, it will issue meta
commands to accomplish this.
- 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 revising existent .DAT files or creating a new one, the rule to
follow is: "make it look to the outside as it is expect"
to optimize existent .DAT files, use the following rules besides the
previous one:
- Enable clipping at the head of the file (if not a flat object)
- If a given polygon is CW, then instead of putting a '0 WINDING CW'
before it, change the definition of the polygon, from 1,2,3 to 3,2,1
and avoid the meta command (prevents un-necessary state changes)
- if given polygon should never be clipped (i.e. belongs to a flat object)
disable clipping before these polygons/objects.
Group all objects of the same kind (clippable/unclippable) to minimize
clipping state changes. if you put the unclippable polygons/objects at
the end of the file you will change state only once, from ON (the
default) to OFF. so only "0 CLIPPING OFF" if needed (seldom used).
- Every polygon should face outwards/upwards as expected, so change them
accordingly, preventing always the WINDING meta command when possible,
by following a previous rule.
by following this simple object oriented rules the optimized files can be
as simple as:
0 CLIPPING ON
0 The winding is by default CCW
a lot of CCW polygons (tris/quads)
Now the INVERT problem:
because the drawing/editing ldraw compatible program will keep track of
matrix invertions, you will have only to INVERT a reference to a file, if
you don't want to use it in the normal sence.
for example, the 4-4cyli.dat
Should be used has facing outwards, but you want to model a technic
hose, with thichness, by defining a sub part like a small cylinder,
which can be built using a 4-4cyli.dat primitive for the outside an
another for the inside.
Since the outside, complies with the expect, you simply use the
4-4cyli.dat by reference with an eventual resize using the matrix
But the inside cylinder to be correctly done, with the 4-4cyli.dat,
must be inverted before using "0 INVERT", so that at the end the
outward normal point to the correct place
NOTE:
if you had a non simetrical object, you will probably need an invert
matrix (with a negative determinant), besides the INVERT meta command.
Resuming:
When you look to a .DAT file (i.e. when referencing it), it always looks
the same, CCW facing outwards/upwards with possible clipping.
inside the .DAT file, change what is need, so that when drawn the graphic
represents waht was expected by an outside reference.
Be my gests a comment!
Rui
---------------------------------------------------------------
| Rui M. S. Martins Software Engineer Rui.Martins@Link.pt |
|---------------------------------------------------------------|
| 351 1 3100063 There is no Place Like $HOME |
---------------------------------------------------------------
| | | | | | | | | | | | | | | | |
| |
|
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.
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Rui Martins wrote in message ...
> FIRST OF ALL
> my sugestion is that the CLIPPING, WINDING, INVERT are strictly local
> where they are used.
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. If you for some reason
want to turn clipping off for some subfiles, you should be able to do that.
If you are making a flag on a flag-pole, the flag-pole is solid and you
can use clipping. But the flag may be 2D and you would want to turn
clipping off for e.g. a reference to rect.dat.
A "CLIPPING ON" in rect.dat should not suddenly enable clipping.
> > 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.
Right, you can't see inside it. And the world doesn't care if it has
"CCW WINDING"! Only the orientation counts.
> On Mon, 18 Oct 1999, Steve Bliss wrote:
> > 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.
I believe WINDING UNKNOWN has its justification for temporarily disabling
clipping. And clipping state must be passed on! So disabling clipping in
a super-file overrides local CLIPPING ON statements.
Disabling clipping in a super-file should effectively turn off clipping for
the whole sub-tree.
/Lars
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Tue, 19 Oct 1999, Lars C. Hassing wrote:
> Rui Martins wrote in message ...
> > FIRST OF ALL
> > my sugestion is that the CLIPPING, WINDING, INVERT are strictly local
> > where they are used.
>
> I concur that WINDING is strictly local.
Great!
> It may be a struggle of words, but I wouldn't call INVERT *local* as it
> affects the behaviour all tris/quads in *subfiles*
It's local when you look at it in the .DAT where it is used.
It's effect is NOT local, when you are looking from the renderer
program's view, because it has to keep track of the current invert
state.
The INVERT meta-command only says, INVERT relative to the CURRENT invert
STATE.
A .DAT files does not know if it will be called, with an odd or even
invert state, so his infromation ofshould invert is local, but the
notion of the current GLOBAL state of invertion is GLOBAL but for the
renderer not the .DAT file.
Maybe this is a litle bit confusing, or I can't explain myself
correctly.
> And I don't see why clipping should be local. If you for some reason
> want to turn clipping off for some subfiles, you should be able to do that.
> If you are making a flag on a flag-pole, the flag-pole is solid and you
> can use clipping. But the flag may be 2D and you would want to turn
> clipping off for e.g. a reference to rect.dat.
> A "CLIPPING ON" in rect.dat should not suddenly enable clipping.
I should congratulate you, you found the only example, that I know of
that is against a local clipping.
But how often will this be done ?
BUT if this is required, when optimizing the rect.dat, just don't insert
a 0 CLIPPING ON on it.
Offcourse, someone will say, " And what about the files that use
rect.dat that would benefit from clipping the rectangle when possible ?"
For this I say:
Since this is for this (or other) special case then create a specific
S_rect.dat witch does NOT clip, or even,
since this problem only relates to paper thick surfaces, usually
simple, just include it's code in your part, and disable clipping for it.
NOTE: we should optimize for the general/common cases, not for the
specific anyway.
Rui Martins
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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. The state of
inversion is passed down the file-reference tree. 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). But it must know
the current state of inversion, in order to clip correctly.
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]
> > 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.
If you can't see inside it, then the rest of the world doesn't care what
the winding is.
> > 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.
> 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.
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.
2. Any file-references by a non-certified file must not clip.
> > 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"
Er, I actually *meant* "two-sided quad/tri". But you understood what I was
getting at.
> 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.
Yes, it would be reversed, but it should not be clipped, because it is
still visible (behind a transparent surface, anyway).
Steve
[1] If the WINDING setting from the super-file affected the assumed winding
of the sub-file, we wouldn't need an INVERT function, we'd just reverse the
winding before invoking the inverted file. Assuming we knew what the
winding was.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote in message <380b3366.9260126@lugnet.com>...
> > 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."
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 0 -4 0 4 0 0 0 4 0 0 0 4 4-4cyli.dat
0 INVERT ON
1 16 0 -4 0 6 0 0 0 4 0 0 0 6 4-4cyli.dat
0 INVERT OFF
See also http://www.lugnet.com/news/display.cgi?lugnet.cad.dev:2956
Apart from that I fully agree with Steve's comments to Rui.
/Lars
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Tue, 19 Oct 1999 13:25:53 GMT, "Lars C. Hassing" <lch@ccieurope.com>
wrote:
> Steve Bliss wrote in message <380b3366.9260126@lugnet.com>...
> > > 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."
>
>
> 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".
Yes the coded inversion is needed, for one big reason:
The clipping-ready parts library must be compatible with non-clipping
rendering programs, such as LDraw. So the inversions need to occur in the
real commands, not in the clipping-extension meta-commands.
Now, if you want to talk about having a special version of the parts
library just for clipping-ready renderers, let's go! But in a separate
thread, please.
> Apart from that I fully agree with Steve's comments to Rui.
Seems like there was an echo in here, eh? ;) My earlier reply looked a lot
like yours.
Steve
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Steve Bliss wrote...
> On Tue, 19 Oct 1999 13:25:53 GMT, "Lars C. Hassing" wrote:
>
> > Steve Bliss wrote in message <380b3366.9260126@lugnet.com>...
> > > > 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."
> >
> >
> > 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".
>
> Yes the coded inversion is needed, for one big reason:
>
> The clipping-ready parts library must be compatible with non-clipping
> rendering programs, such as LDraw. So the inversions need to occur in the
> real commands, not in the clipping-extension meta-commands.
But it *is* compatible with LDraw!
You left out my example (which BTW had the INVERT placed incorrectly :-),
so I'll repeat it. stud2.dat is the hollow stud used on technic bricks.
It uses two cylinders:
1 16 0 -4 0 6 0 0 0 4 0 0 0 6 4-4cyli.dat
0 INVERT ON
1 16 0 -4 0 4 0 0 0 4 0 0 0 4 4-4cyli.dat
0 INVERT OFF
The first cylinder is the outer wall. Let's assume that the orientation
of 4-4cyli.dat is outwards. This is what we want, so we use a normal matrix.
The second cylinder is the inner wall, the wall of the hole in the stud.
Here the orientation of 4-4cyli should be inverted, because we now want the
inner side of the cyli to be the outside. We still use a normal matrix,
it's easy and intuitive - and correct. If we had used an inverting matrix,
(which would also be correct to do) the rendering program would just
"cancel it out", as it would do when mirroring sub-models.
And LDraw merely draws ALL tris/quads as usual! The stud2.dat file has not
changed from LDraw's point of view, just a few comments were added.
There's no reason to use an inverting matrix for LDraw. You are welcome to
do it, and it will work too, because LDraw draws everything.
> Now, if you want to talk about having a special version of the parts
> library just for clipping-ready renderers, let's go! But in a separate
> thread, please.
No, no special versions, thank you. Backward compatibility with our
reference-renderer, LDraw, is very important.
> > Apart from that I fully agree with Steve's comments to Rui.
>
> Seems like there was an echo in here, eh? ;) My earlier reply looked a lot
> like yours.
Yeah, I'm glad we were so agreed :-)
/Lars
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Wed, 20 Oct 1999 22:09:42 GMT, "Lars C. Hassing" <lch@ccieurope.com> wrote:
> But it *is* compatible with LDraw!
> You left out my example (which BTW had the INVERT placed incorrectly :-),
> so I'll repeat it. stud2.dat is the hollow stud used on technic bricks.
> It uses two cylinders:
> 1 16 0 -4 0 6 0 0 0 4 0 0 0 6 4-4cyli.dat
> 0 INVERT ON
> 1 16 0 -4 0 4 0 0 0 4 0 0 0 4 4-4cyli.dat
> 0 INVERT OFF
You are right. Or more precisely, I was wrong. Matrix-based *inversions* are
not required. But matrix-based mirrorings will be necessary, for asymmetric
primitives, like 1-4cyls.dat.
> > Now, if you want to talk about having a special version of the parts
> > library just for clipping-ready renderers, let's go! But in a separate
> > thread, please.
>
> No, no special versions, thank you. Backward compatibility with our
> reference-renderer, LDraw, is very important.
I was thinking about some approach that would map standard primitives onto a
second set of primitives. Kind of like what LDraw does in 'fast stud' -FS mode:
it maps all files like stu?*.dat onto stu2*.dat. But in this case, the second
versions of the files would use LDLite extensions to first define all the
vertices in the file, and then use the vertices in the polygons. Seems like
that would be useful for meshed-based processing.
Steve
| | | | | | | | | | | | | | | | | |
Rui Martins wrote in message ...
> to optimize existent .DAT files, use the following rules besides the
> previous one:
> - Enable clipping at the head of the file (if not a flat object)
> - If a given polygon is CW, then instead of putting a '0 WINDING CW'
> before it, change the definition of the polygon, from 1,2,3 to 3,2,1
Part authors should define the tris/quad the way he finds best, easy and logical
- maybe sometimes CW and sometimes CCW.
Also when fixing old parts, just insert a lot of WINDING keywords in stead
of editing the existing 3- and 4-lines. This preserves the nice tabulating
seen in some parts, which is nice if you have to debug the parts later.
The rendering program can easily (and costless) switch the vertex sequence.
/Lars
| | | | | | | | | | | | | | | | | |
| |
|
On Tue, 19 Oct 1999, Lars C. Hassing wrote:
> Rui Martins wrote in message ...
> > to optimize existent .DAT files, use the following rules besides the
> > previous one:
> > - Enable clipping at the head of the file (if not a flat object)
> > - If a given polygon is CW, then instead of putting a '0 WINDING CW'
> > before it, change the definition of the polygon, from 1,2,3 to 3,2,1
>
> Part authors should define the tris/quad the way he finds best, easy and logical
> - maybe sometimes CW and sometimes CCW.
If by default you always use the same winding, then you can know the
orientation of the polygon on the fly.
IF you mix both you will have a hard time, because you are mixing or
reference.
> Also when fixing old parts, just insert a lot of WINDING keywords in stead
> of editing the existing 3- and 4-lines. This preserves the nice tabulating
> seen in some parts, which is nice if you have to debug the parts later.
That I agree! but my NOTE (suggestion) to pair the tris/quads, can be
easylly implemented by the drawing program, as someone already referred,
it's just an optimization!
> The rendering program can easily (and costless) switch the vertex sequence.
> /Lars
About the winding (vertex sequence), I don't agree with this, because:
- the reason I refered earlier (the orientation reference from winding)
- A pre processing program can do this for you (NOT in real time) after
yuo have finished your .DAT editing, And you would n't notice the
difference when looking to it.
P.S A good optimizer utility should keep the user comments and
layout.
Rui Martins
| | | | | | |
