Subject:
|
Re: Implicit face winding (was: [Parts Tracker] More BFC Primitives)
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Fri, 12 Apr 2002 02:10:31 GMT
|
Viewed:
|
587 times
|
| |
|
|
Tony Hafner wrote:
> In lugnet.cad.dev.org.ldraw, Kyle McDonald writes:
>>
>>Well I don't know that I thought it would be 'minimal' effort. I'll
>>bet it would be a lot of work for parts that are already done. I
>>did think that it wouldn't be that bad for new parts, because I
>>figured the author knows best what he/she want when he writes the
>>line in the part file. But as I'm not a parts author either, I
>>could very well be wrong there.
>>
>
> I recently went over some old primitives and brought them up to BFC
> certification. I found it very handy to have the flexibility of doing it
> whichever way had more "correct" surfaces. It wouldn't be so bad if Notepad
> had the ability to reverse the winding automatically...
>
I aggree. I wasn't really discussing the winding of each polygon
anymore. I think we moved on a while back. Steve even aggreed that
once the winding of the polygons was known, converting the files
to a standard winding (if one were to be selected) would be relatively
easy. Most of the recent discussion has only been on the usage of
INVERTNEXT not about CW vs. CCW
> The renderers already have to check to see that the file is certified at all
> and take action accordingly. How much worse is it to see which direction
> the winding is intended? What kind of real-world performance savings are we
> talking about? If you really need the renderer to have this, you can simply
> reverse winding of each "backwards" part at load-time. That would be a
> (small?) hit at load time, but no problem on rendering.
>
Well, like I said in some message, I don't know the performance hit.
I haven't gotten that far yet. I do expect to handle this at load time
not run time so the end result performance shouldn't be affected much.
The problem with load time handling of this is that some subfiles
are included both inverted and non-inverted.
Again I just thought I'd point out that using the INVERTNEXT in a
slightly different manner might simplify the code logic somewhat,
and other than the work of redoing all the existing BFC parts,
and programs (which is probably enough work so that doing it is
not a good idea,) I didn't think the alternate usage would be
all that different for the parts author. But I will admit I don't
know that for afact as I've never written a part. I'll also
aggree that our overriding priority *should* be making part
creation as easy as possible.
> Something else just occurred to me... how hard would it be to write an
> auto-BFC program? Assuming that parts don't have holes, all interior
> surfaces *should* be sealed in. You could divide up the whole thing with a
> BSP tree and use that info to determine which faces should face which way.
> It wouldn't get all parts right, but would certainly hit a good chunk of
> them. And the program could at least flag most of the bad ones as such.
> You'd just run it once on the whole library (whole parts anyway- subparts
> aren't typically sealed) and then visually inspect the results.
>
Auto BFC? I've been working on that problem myself for a little while
now. I have an aquaintance who believes he may be able track down
some code from some gradstudent project he once knew of that he thought
attempted to solve that problem.
I haven't tried to code this up, but I think if you computed the true
'center coordinates of a part, then cast a 'ray' out from there towards
a polygon, then the first polygon you pass thru should face that
center, the next away from that center, the third toward that center,
etc. That is unless we have parts whose walls are modeled with only
a single polygon??
I need to read up more on this BSP stuff. I'm not sure how that would
work.
> Not that *I* could write the program, but the actual problem doesn't seem
> significantly different from one I've dealt with before. I used to make
> Quake levels, and they have a compile tool that determines what space is
> inside (and can be gotten to) versus what space is outside (such that you'd
> never be able to get there). I know a bit about the guts of this, and could
> possibly help someone who already knows how to code 3D processing stuff...
>
Like I said I'm trying to write code that can do this and other things
with the part geometry automatically right now. I'll let you know when
I have something, maybe you can beta test it?
Currently I'm focusing on searching the geometry for polygons that can
be transformed into 'polygon strips' Most 3D hardware and rendering
engines are designed to process strips of quads or triangles much
faster than they can handle single ones. I think I may have a good
handle on this problem already I just need to finish coding it up.
It may not be fast though, so I'm hoping to maybe get it to write
the .DAT files back out with '0 STRIP' hints. Would this group be
interested in having those types of hints in the parts library?
I'm guessing it would mean re-certifying every part in the library
again right? That seems like alot of work from what I've read here.
Another thing I'd like to do is write some code that can try to
automatically determine which polygons in a part are 'inside' it
and likely to be covered up by another part when they're connected.
That's a problem for another day though.
-Kyle
--
_
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald (o o)
|||||
\\\//
(o o) kmcdonald@BigFoot.COM
-------------------------------ooO(_)Ooo-------------------------------
|
|
Message has 1 Reply:
Message is in Reply To:
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
|
|
|
|
