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 / 4292
4291  |  4293
Subject: 
Re: BFC: LITS 2
Newsgroups: 
lugnet.cad.dev
Date: 
Sun, 2 Apr 2000 23:43:19 GMT
Reply-To: 
rui.martins@linkSPAMLESS.pt
Viewed: 
1734 times
  
Fourth in the series, starting with message #41 in the "Line in the
Sand" thread.  Notice that I scanned past a number of messages before I
got another 'open issue' hit.  This posting covers up to & through
message #83, the end of the thread.

In <http://www.lugnet.com/cad/dev/?n=3517>, Lars points out:

1 16  -4 0 0  0 0 0  0 0 4  1-4disc.dat
The determinant is zero, which BTW causes POVRay to halt
("singular matrix"). L3P has to fix these matrices or POVRay
would not render many parts at all!
As part of certifying a DAT file I believe this kind of subfile
reference should be fixed as well, like into
1 16  -4 0 0  0 1 0  0 0 4  1-4disc.dat
"L3P -check -w3" will help spot the problems.

This point hasn't been discussed since, I believe.  This is very valid,
these "singular transformation matrices" should be fixed.

  I believe that the only problem is that these matrixes can't be inverted !
  I'not sure if placing a one on the specific place has exactly the
same graphic behaviour ?
can someone confirm ?

BTW, this gives the CERTIFY tag something to define besides clipping and
winding.  In order to cleanly certify a file, it should *not* have any
subfile commands with singular matrices.

Even so, CERTIFY is still functionally redundant...

Use my proposal:
0 CERTIFY BFC MTX

where MTX is Matrix, correct non singular matrices

------------------------------------------------------------------------
One other thing.  Starting somewhere around message #3424
<http://www.lugnet.com/cad/dev/?n=3424>, Lars and I got to discussing
what purpose would be served by intentionally disabling clipping within
a file (via the NOWIND option, if that one is preserved in the spec,
otherwise using NOCLIP).

I contended that decorations will need to be flagged as double-sided, so
that they will show through the part when it is used as transparent.

Lars responded that no clipping can be performed on transparent
quads/tris, because some renderers will need to use the backside objects
to provide more depth to the transparent areas, so the spec should
explicitly require that BFC be disabled when rendering a
transparent-colored part.

I replied that that was an unreasonable solution because a part-file may
have hard-coded transparent sections, even though the reference to the
file is a solid color.  Think of rendering <part:2634> in white.  The
renderer would have to prescan the file, to find the hard-coded
transparent sections.  And then the entire file would have BFC disabled.

Nope, the hardcoded transparent sections should have cliiping disabled,
for a BFC certifyed part/piece.

Lars pointed out that we should not require parts-authors to code
anything that the rendering engine can figure out for itself.

And that was the end of intelligent discussion on that point.

Not always, but let's assume yes.

------------------------------------------------------------------------
A side issue of that discussion: can transparent surfaces be clipped?

To be correct NO, but that can be left has an option to the user.
There is not TOO much difference, and while editing would be a nice feature
(clipping), because of speed increase, for final drawing don't disable
trasnparent clipping.

see ya

Rui Martins



Message has 1 Reply:
  Re: BFC: LITS 2
 
(...) Actually, the problem is that their determinant is 0, neither positive nor negative. So the renderer would have to disable BFC processing for any file with this kind of reference. Another problem (that L3P handles in most cases) is that (...) (25 years ago, 7-Apr-00, to lugnet.cad.dev)

Message is in Reply To:
  Re: BFC: LITS 2
 
Fourth in the series, starting with message #41 in the "Line in the Sand" thread. Notice that I scanned past a number of messages before I got another 'open issue' hit. This posting covers up to & through message #83, the end of the thread. In (...) (25 years ago, 31-Mar-00, to lugnet.cad.dev)  

24 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