I don't like the idea of unofficial libraries, since we could inadvertently break them with changes to the official library.
Currently we have three "officially supported" levels of rendering, which are only applied to studs (a high polygon count component of large models/scenes):
- regular 16-agonal stud primitives - p/stud.dat, p/studn.dat and studnn.dat
- low-res (fast-draw) octagonal stud primitives - p/stu2.dat, p/stu2n.dat and stu2nn.dat
- a zero-res (superfast-draw) primitive - p/studline.dat (although I'm not sure if any tool since ldraw.exe has supported this)
The p/4864 folder also gives LDView (at least) the ability to provide on-the-fly hi-res substitution of primitives that it recognises. This folder also serves as a primitive resource for large parts that benefit from the additional polygon count.
We could extend the "official support" for stud rendition to four levels and use this to incorporate the baseplate underside details:
- Create hi-res stud*.dat primitives in ldraw/p/4864 - these could be an official sanction of the "LEGO" logo studs.
- Define a new "studNN" for the baseplate underside dimple. In ldraw/p this would just be a 20LDu x 20LDu quad, but in ldraw/p/4864 it would be a complete modelling of the dimple. The increased polygon count of rectangles could be overcome by defining "stud groups" for the common multiples. These would just be large quads (rather than a matrix of studNN.dat) and would thus have minimal impact on polygon count at regular resolution.
This proposal does depend on implementation support in the rendering tools. So LDView, for example, would need to used stud primitives from the ldraw/p/4864, if found, rather than substituting at the 4-4cyli, 4-4disc level.
At the same time, it might be wise to straighten out the anomoly of low-res studs being identified by a naming convention by creating a ldraw/p/8 folder and moving existing stu2*.dat primitives to ldraw/p/8/stud*.dat .
Comments welcome.
Currently we have three "officially supported" levels of rendering, which are only applied to studs (a high polygon count component of large models/scenes):
- regular 16-agonal stud primitives - p/stud.dat, p/studn.dat and studnn.dat
- low-res (fast-draw) octagonal stud primitives - p/stu2.dat, p/stu2n.dat and stu2nn.dat
- a zero-res (superfast-draw) primitive - p/studline.dat (although I'm not sure if any tool since ldraw.exe has supported this)
The p/4864 folder also gives LDView (at least) the ability to provide on-the-fly hi-res substitution of primitives that it recognises. This folder also serves as a primitive resource for large parts that benefit from the additional polygon count.
We could extend the "official support" for stud rendition to four levels and use this to incorporate the baseplate underside details:
- Create hi-res stud*.dat primitives in ldraw/p/4864 - these could be an official sanction of the "LEGO" logo studs.
- Define a new "studNN" for the baseplate underside dimple. In ldraw/p this would just be a 20LDu x 20LDu quad, but in ldraw/p/4864 it would be a complete modelling of the dimple. The increased polygon count of rectangles could be overcome by defining "stud groups" for the common multiples. These would just be large quads (rather than a matrix of studNN.dat) and would thus have minimal impact on polygon count at regular resolution.
This proposal does depend on implementation support in the rendering tools. So LDView, for example, would need to used stud primitives from the ldraw/p/4864, if found, rather than substituting at the 4-4cyli, 4-4disc level.
At the same time, it might be wise to straighten out the anomoly of low-res studs being identified by a naming convention by creating a ldraw/p/8 folder and moving existing stu2*.dat primitives to ldraw/p/8/stud*.dat .
Comments welcome.
Chris (LDraw Parts Library Admin)