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 / 3424
3423  |  3425
Subject: 
Re: Line in the Sand
Newsgroups: 
lugnet.cad.dev
Date: 
Mon, 6 Dec 1999 23:21:38 GMT
Viewed: 
2067 times
  
Steve Bliss wrote...
By de-emphasizing CERTIFY, and not requiring it, but still keeping it in the
standard, we could agree to allow some redundancy for the sake of getting a
standard published.  And give authors some leeway to choose their approach.

It's not an ideal approach to a solution, but better than wrangling over
non-functional details forever.

OK. The pseudo-code reflects this now.


The pseudo-code doesn't reflect this. It always requires a 0 BFC CERTIFY.
And this implies 0 BFC CLIP and 0 BFC CCW. (which should be added)

The p-code already specifies default values for LocalClip and Winding.  I
altered the verbiage (changed = to Initial) to make this a bit more clear:

I meant "The fact that 0 BFC CERTIFY implies 0 BFC CLIP and 0 BFC CCW
should be stated explicitly in the CERTIFY section in Language Extensions".
The code was clear enough. Sorry.


*In the (probably) rare cases of double-sided sections, the part-author
*can temporarily use 0 BFC NOCLIP and then 0 BFC CLIP. Both local
*polygons and subfiles in that section are not clipped.

Double-sided sections won't be very rare.  They'll be needed for all decorated
parts.

Huh? please explain why.


Can you rewrite the pseudo-code to accommodate both uses
or must we choose?

I'm not sure what you mean by "both uses".  Could you clarify?

I just meant to accommodate both "your way with CERTIFY" and
"my way without it". And you already have!


4 {deleted invalid paragraph about assuming part-files are always right-side-out}
Hey, what did you do that for?
I think it is perfectly alright to assume that files in the ldraw\parts
directory are right-side out, (and therefore clippable) even though
not all superfiles are certified.

It *is* reasonable to assume that ldraw\parts files are right-side out.  But
there is no simple way for the rendering engine to exploit this assumption.
Some problems:

1. Winding = NOWIND for the part-file.  Both because quads could be bowtied, and
because there's way to know (for sure) which polygons face which direction.  So
no local BFC clipping can be performed.
2. There's no flagging of inversion for subfiles, so it's not possible to allow
BFC clipping of subfiles.

Those two limitations severly limit any advantages of knowing that part-files
are always right-side out.

Sorry, I didn't make myself clear. I am NOT going to begin clipping
non-BFC parts. It is of course not possible. But I WOULD like to clip
BFC parts, even if the superfiles are not certified, i.e. let old
model files (=non-BFC files) benefit from BFC-parts.

"All DAT files are equal, but some are more equal than others" :-)

Parts are objects with obvious orientation. You are not in doubt what is
inside/outside of a part!
However, consider the 4-4cyli.dat. Even if its orientation was defined
and it was certified, you could not use that info for clipping
if it was not referenced from a certified part, i.e. a part that have
gone through considerations whether to use INVERTNEXT or not.

Because the orientation of parts is natural and intuitive, certified
parts would be the right place for enabling clipping.
And it would be safe and legal to do so, because rendering programs
keep track of transformation-inversions, i.e. you can safely use
mirrorred submodels.

See also last 5 paragraphs of http://www.lugnet.com/cad/dev/?n=3084
and http://www.lugnet.com/cad/dev/?n=3102


4            RenderFile Command.Subfile,
4                       (AccumClip and LocalClip and Certified),
4                       (AccumInvert xor InvertNext)
                        TransformMatrix * Command.TransformMatrix

TransformMatrix could be renamed to AccumTransformMatrix like the other
parameters to RenderFile.

You added AccumTransformMatrix as a parameter to RenderFile but forgot the
AccumTransformMatrix * Command.TransformMatrix in the two calls to RenderFile.

Actually the color should also be a parameter to RenderFile. A transparent
file cannot be clipped. If you add
  Color integer // current color

as a parameter, then you can add this before "OpenFile(ModelFile)":
   If 32 <= Color And Color <= 47 Then AccumClip = FALSE

and this after "Get Next Command":
   If Command.Color = 16 Then
      Command.Color = Color
   Else
      If Command.Color = 24 Then
         Command.Color = EdgeColor(CurColor)

and add Command.Color in the two calls to RenderFile.
Feel free to rename/recode, I hope you get the idea.


BTW, "CERTIFY" - shouldn't it be "CERTIFIED" ?

I can go either way on this.  The document is currently consistent, it only uses
CERTIFY, not a mix of the two, and the other options are all present tense: CLIP
NOCLIP NOWIND INVERTNEXT.  So I'm not going to change CERTIFIED to CERTIFY right
now, but if it becomes an issue, I will.

It's not important, it just stroke me that CLIP INVERTNEXT are commands/orders
(imperative), CERTIFIED is a state (adjective).


Maybe we can get this finalized before the end of the year.  Well, a guy can
dream, right? ;)

Yes, it would be nice (and necessary) to get opinions/approval/consent
from more part authors and programmers.

Yes.  Especially the programmers.  Michael has pinged me once or twice about
this.  When we get a fairly final document, I'll ping Michael back.

I sincerely hope part authors will support the BFC. They are the ones to do
the hard work. I hope Jean-Pierre PARIS's program will be a great help.

I wouldn't worry too much about programmers though, it's pretty easy and
you have alreay provided pseudo-code.
/Lars



Message has 1 Reply:
  Re: Line in the Sand
 
(...) Sometimes, transparent parts have decorative printing. And the LDraw library should be written so that modelers can use any part in any color, even if LEGO hasn't released that part/color combination yet. Decorations on transparent parts shows (...) (24 years ago, 8-Dec-99, to lugnet.cad.dev)

Message is in Reply To:
  Re: Line in the Sand
 
Sorry this is so long. I've tried to err on the side of quoting too much of Lars' message, rather than too little. Also, I've tried to be thourough in my replies. In related news, I've added a 'Current Issues' section at the top of the v4 document. (...) (24 years ago, 5-Dec-99, to lugnet.cad.dev)

85 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