 | | Re: Updated Part: 700.dat - Brick 10 x 20
|
|
(...) <SNIP> It looks like there could be significant use of stud4 groups as well. I'm also thinking that 1 x n rows of stud2 and stud 3 could be useful. Not as high in demand, but the stud4 groups would be really nice. (The version of 700.dat (...) (21 years ago, 17-Nov-03, to lugnet.cad.dat.parts.primitives)
|
| |
| | Re: Updated Part: 700.dat - Brick 10 x 20
|
|
(...) I've been thinking about groups of stud3 and stud4, but found it not too commonly used as the stud.dat. Baseplates for example have no bottom studs. There is also a little problem with the odd numbers - four top studs corresponds to three (...) (21 years ago, 17-Nov-03, to lugnet.cad.dat.parts.primitives)
|
| |
| | Re: Updated Part: 700.dat - Brick 10 x 20
|
|
(...) Well, that's 3 lines per instance. It takes 3 calls of a group of 4 to get to the same line savings as the group of 8. And 1 x 4 and 2 x 2 groups are common enough to get at least 7 lines saved. In the 700.dat you posted, just using 1 x 4 (...) (21 years ago, 18-Nov-03, to lugnet.cad.dat.parts.primitives)
|
| |
| | Re: Updated Part: 700.dat - Brick 10 x 20
|
|
(...) One other thought: every time you add a subfile, it takes time for the renderer to render it. So every call to your 4-stud primitive is going to process more slowly than the equivalent 4 lines encoded directly. So if an added subfile only (...) (21 years ago, 18-Nov-03, to lugnet.cad.dat.parts.primitives)
|
| |
| | Re: Updated Part: 700.dat - Brick 10 x 20
|
|
(...) Actually this might be faster for rendering. If you use a display list (or similar construct) for each subfile you'll be using less display list memory overall, which might lead to faster rendering. If your renderering time is constrained by (...) (21 years ago, 19-Nov-03, to lugnet.cad.dat.parts.primitives)
|
