Subject:
|
Re: Some Words To BFC
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 19 Apr 2000 01:38:13 GMT
|
Viewed:
|
2767 times
|
| |
|
|
Steve Bliss wrote on April 6th...
> In lugnet.cad.dev, Leonardo Zide wrote:
>
> > When it finds that any face of a primitive needs to be inverted. We
> > would have to fix the current primitives so that all faces are pointing
> > to the same direction. Take a look at the sphere primitive for example,
> > it has faces pointing inside and outside the sphere.
>
> The primitives should be the first thing fixed, in any case. :) I
> think it would be safe for the cleanup program to assume that primitives
> are BFC-ready. Which could be a help for automatic cleanup of part
> files.
The program should refuse to certify a part if not all subfiles are certified.
> > > Question #2: why is adding "pi\" preferable to substituting a different
> > > file name (so the inverted primitives are in the p\ directory) or
> > > inserting a 0 INVERTNEXT statement?
> >
> > I think the "pi\" dir was just an example, it could have any other
> > name. Adding a 0 INVERTNEXT would require more time to parse a file.
>
> Some technical points:
>
> Parsing and processing a 0 INVERTNEXT statement requires very little
> time. And each file should only be parsed once in a single rendering.
> Interactive viewers/editors should only reparse a file if it changes.
>
> Having extra primitive files would also slow down processing, because it
> would take slightly longer to locate the correct file on the disk. If
> all the extra primitives are in the ldraw\p directory, then each time
> *any* primitive is loaded, the file-find step takes longer, because the
> directory list if larger. If the inverted primitives are kept in a
> subdirectory, then locating the inverted primitives takes more time,
> because the OS would first have an extra step in the directory-tree
> search. But again, each file should only be loaded once in a single
> rendering.
>
> Using INVERTNEXT would take a few more bytes of storage than using
> mirrored primitive files.
>
> I don't think this issue (to INVERTNEXT or to clone primitive files)
> will be decided on technical issues.
>
> I think the key issue is which approach makes it easier to code DAT
> files, and maintain the parts library. Unfortunately, I don't have much
> of an opinion here, except that having extra files means parts authors
> have more to learn about p-files, and there would more files which would
> need to be maintained. From a language point of view, the difference
> between the two approaches is strictly syntactic. And if the cleanup
> program can detect inversion automatically, then neither approach puts
> any burden on the author.
Agreed!
We should not put any constraints on the authors.
They may scale/rotate/mirror primitives as they wish (not including zero scale :-).
They may switch between CW/CCW as they feel appropriate.
The clean-up program can (should) handle this.
And I sincerely don't think we should make another set of primitives
just to avoid INVERTNEXT.
/Lars
|
|
Message is in Reply To:
 | | Re: Some Words To BFC
|
| (...) The primitives should be the first thing fixed, in any case. :) I think it would be safe for the cleanup program to assume that primitives are BFC-ready. Which could be a help for automatic cleanup of part files. (...) Some technical points: (...) (26 years ago, 6-Apr-00, to lugnet.cad.dev)
|
61 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
