To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.dev.org.ldrawOpen lugnet.cad.dev.org.ldraw in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / Organizations / LDraw / 1918
1917  |  1919
Subject: 
Re: [Parts Tracker] More BFC Primitives
Newsgroups: 
lugnet.cad.dev.org.ldraw
Date: 
Sat, 6 Apr 2002 02:37:24 GMT
Viewed: 
444 times
  
Hello,

Comments below...

Travis Cobbs wrote:

> In lugnet.cad.dev.org.ldraw, Steve Bliss writes:
>
>>In lugnet.cad.dev.org.ldraw, Tony Hafner writes:
>>
>>>In lugnet.cad.dev.org.ldraw, Steve Bliss writes:
>>>
>>>>>Um... Not to stir the pot or anything but I was reading the BFC proposal on
>>>>>your website and noticed that the BFC specification says that all primitves
>>>>>must be certified CCW.  Did this get revised via discussion and not updated?
>>>>>
>>>For starters, I recently tried to track down the BFC specification but
>>>couldn't find it (on ldraw.org or on Steve's site).  Could someone post the
>>>link please?
>>>
>><http://www.geocities.com/partsref/bfc/>
>>
>>>>At this point, I'm as inclined to delete the clause from the spec as to
>>>>keep it (and modify the primitives specified as CW).
>>>>
>>>If it doesn't matter from a performance perspective, I vote you kill the
>>>clause.
>>>
>>I think the only way it would matter for performance is if we decided that
>>the *entire* library would be CW or CCW, and so rendering programs wouldn't
>>have to check the winding direction at all.  And that would be a very small
>>difference in speed.
>>
>
> Given the fact that they have to check whether or not a given file has been
> mirrored, I can't see that the directionality would make a large difference.
> If everything used CCW, then only mirrored ones would need to be reordered
> (assuming the renderer is going to reorder them).  In any event, I can only
> see this having an effect on load time, since I would expect a renderer that
> is making use of BFC information to reorder all BFC'd polygons to have the
> same winding, after taking mirroring into account.
>


I don't want to (re)open a can of worms. I have gone back and read
much of the original discussions, but I'd like to point out something
that I haven't seen mentioned so far. I know it late. And I know
much work has already been done. But I thought I'd throw this out
anyway.

I know for me (because I only give the geometry to the renderer) I
don't always have as many options as people who write there own.

First I'd like to suggest that *if* there is a 'standard' winding for
LDRAW parts that it be CW. I make this suggestion based on the following:

   1. Left Hand coordinate systems tend to standardize on CW windings.
      Right Hand coordinate systems tend to standardize on CCW windings.
      (That is given an engine that uses one coordinate system, those are
       likely to be the windings expected also)

   2. LDRAW uses a Left Hand coodinate system. Granted it is also rotated
      180 degrees around the Z axis, but it's still left handed.

   3. The additional fact that the transform needed to convert from a
      left hand system to a right handed one will *automatically* rewind
      the polygons from CW to CCW.

      Even the y*-1 transformation needed to convert from the LDRAW coords
      to a traditional RH coord. system  will convert the CW windings to
      CCW which most RH systems will be expecting.

(Though once the winding in the files is well documented, it should
   be trivial to programatically convert the files to a 'standard'
   winding. No?)

Second, on the subject of the 0 BFC INVERTNEXT meta command, I'd like
to make sure I understand the suggested usage, and possibly make an
argument for a change (If I understand it correctly)

It's my impression that you intend for programs to notice a 'mirroring'
matrix, and reverse the winding to undo the mirror, and then reverse
the winding again if the the INVERTNEXT is there because the author
wanted it. like this:

0 Include part without inverting or mirroring
1 <color> <non mirroring matrix> filename.dat

0 Include part without 'mirroring' but *do* invert the winding.
0 BFC INVERTNEXT
1 <color> <non mirroring matrix> filename.dat

0 Include part with mirroring, but *automatically undo* the winding
0 inversion that the mirroriing did.
1 <color> <mirroring matrix> filename.dat

0 Include part with mirroring, and *redo the automatically undone* inversion
0 that brings.
0 BFC INVERTNEXT
1 <color> <mirroring matrix> filenatme.dat

My problem with this method is that now I have to examine the
matrix watching for mirroring that I need to undo. Up until
now I've been able to pass the matrix from the .DAT file straight
on to the rendering engine, without examining the contents.
I'd prefer to be able to continue to do that.

Using INVERTNEXT like this would allow that:

0 Include part without inverting or mirroring
1 <color> <non mirroring matrix> filename.dat

0 Include part without 'mirroring' but *do* invert the winding.
0 BFC INVERTNEXT
1 <color> <non mirroring matrix> filename.dat

0 Include part with mirroring, but *undo* the winding inversion
0 that the mirroriing did.
0 BFC INVERTNEXT
1 <color> <mirroring matrix> filename.dat

0 Include part with mirroring, and accept the automatic inversion
0 that brings.
1 <color> <mirroring matrix> filenatme.dat

This way the program doesn't even need to know that the
subfile was mirrored.


I know I'm coming rather late on the scene here, and I understand
if it's too late to change some of these things. I just thought
I'd argue my case anyway.

I'm really loking forward to the BFC compliant parts release,
because I'm hoping it will allow the performance of my program
to at least become 'usable' :) So I really appreciate the work
everyone is doing. Thanks!

-Kyle




--
                                    _
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald                 (o o)
                                  |||||

                                  \\\//
                                  (o o)            kmcdonald@BigFoot.COM
-------------------------------ooO(_)Ooo-------------------------------



Message has 1 Reply:
  Re: [Parts Tracker] More BFC Primitives
 
(...) [snip] OK, sounds reasonable to me. (...) Yes. (...) [snip more] You understand the usage correctly. Except there's no special tie between a 'mirroring' subfile reference and the INVERTNEXT command. Authors won't explicitly use one to 'undo' (...) (22 years ago, 8-Apr-02, to lugnet.cad.dev.org.ldraw)

Message is in Reply To:
  Re: [Parts Tracker] More BFC Primitives
 
(...) Given the fact that they have to check whether or not a given file has been mirrored, I can't see that the directionality would make a large difference. If everything used CCW, then only mirrored ones would need to be reordered (assuming the (...) (22 years ago, 6-Apr-02, to lugnet.cad.dev.org.ldraw)

21 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