Question about aring usage in library

[Travis Cobbs]

I am (finally) working on supporting the aring primitive in LDView's primitive substitution, and I have run into what I feel is a problem. The problem is that I believe that the aring can be used in two different ways:

1. To fill in the gap between a standard-resolution curved primitive and a 48-resolution curved primitive
   
2. To fill in the gap between 16-sided geometric curve and a 48-resolution curved primitive
   

I know that it is being used in situations that match option 1 above. I don't know if it is being used for option 2 or not. One (relatively minor) problem is that option 1 is incompatible with how LDView does primitive substitution when the curve quality is set to certain settings. I should be able to fix this. But there is no way for me to generate the primitive in a way that is compatible with both option 1 and option 2.

For option 1, the resolution of the inner part needs to track my primitive substitution curve quality, and the outer part needs to track the 48-resolution version of the same thing. When the quality is set to the default value, this would be 16 and 48. For the next notch on LDView's quality slider, the 16 becomes 24. Right now, the 48-resolution version remains 48 at that setting. (That would probably change. The next notch uses 32, and since 32 doesn't evenly divide into 48, that would have to change. Same for the next notch, which is 40. An easy solution is to use 64 and 80 for the 48-resolution version of those two notches.)

But if this primitive is used next to hard-coded 16-sided geometry, then the inner resolution would need to remain 16, no matter what the curve quality is set to. The current description for the aring primitive does specify that it interfaces between high-resolution primitives and normal-resolution primitives. So does this mean that interfacing with 16-segment geometry is not allowed? If so, I can make it work (although it will cause my primitive substitution to render more geometry for 48 curves when the curve quality is set to use 32 or 40 segment curves).

If it is used next to 16-segment geometry, then I feel that that needs to be forbidden, and a new primitive needs to be introduced to fill that (different) role.

Side note: for POV export, the first version of this primitive is no geometry at all. The second version is a chord.

[Travis Cobbs]

Replying to myself: 18909.dat uses 16-segment geometry against the inside of aring primitives. It seems almost certain that other parts do the same, but I have not verified this. As far as I can tell, there are 113 official parts plus 48 official subparts that use aring primitives.

[Philippe Hurbain]

I have the feeling that aring should be deprecated, as I no longer use it in recent part. But maybe I'm wrong... Can someone show me an example where an aring should be used because there is no other solution?

[Max Murtazin]

I have the feeling that aring should be deprecated, as I no longer use it in recent part. But maybe I'm wrong... Can someone show me an example where an aring should be used because there is no other solution?

10288 seems to be a case of that

[Gerald Lasser]

I initially wanted to use a 1-4aring on the (transparent) Belville door 33216 due to the indents on the curved top.

Due to the missing adaptation for primsubstitution on the  48 side, I used rotated 48\1-16chrds to avoid gapes when prim sunbstitution is done

THis is the current code to fit the torus

Code:

1 16 69.5 -55.5 -2.5 0 0 -69.5 -69.5 0 0 0 1 0 48\1-16chrd.dat
1 16 69.5 -55.5 -2.5 -26.596499 0 -64.209628 -64.209628 0 26.596499 0 1 0 48\1-16chrd.dat
1 16 69.5 -55.5 -2.5 -64.20966 0 -26.59626 -26.59626 0 64.20966 0 1 0 48\1-16chrd.dat
1 16 69.5 -55.5 -2.5 -49.144145 0 -49.144145 -49.144145 0 49.144145 0 1 0 48\1-16chrd.dat
1 16 69.5 -55.5 0 0 0 -69.5 -69.5 0 0 0 -69.5 0 48\tm04o0360.dat

This creates gaps towards the torus:

Code:

1 16 69.5 -55.5 -2.5 0 0 -69.5 -69.5 0 0 0 1 0 48\1-4aring.dat
1 16 69.5 -55.5 0 0 0 -69.5 -69.5 0 0 0 -69.5 0 48\tm04o0360.dat

so from this use case I would haveexpected the following when activating prim-substitution
#1: Inner curve: fixed at 16 sided
#2: outer curve: increase resolution to fit the torus.

As #2 was not being done, I went for the chrd solution

Concerning the use cases:
#1 between a 16/48 sided prim:
-> depending on the slider it has a "filler" purpose, but once both are at the highest resolution, it can be omitted

#2 between a 48 prim and 16 sided fixed one.
-> (my intended use case) this has always a filler purpose as the 16 sided geometry does not increase, only the 48 sided needs adaptation.

I thnk there need to be some more parts evaluated that use it.

[Rene Rechthaler]

Thanks for the discussion!

My two most "critical" uses are the curved bricks with curved top (5924, 8411). As they are intended to fit 85080 (with normal res inside and hi-res outside, I needed an aring to fit. (at the junction of two curved prims, cant use other prims)
For this use as a full prim-prim adapter, it should have an substitution behaviour inverted to the ering (aring as now when not substituted, empty.dat on subst).
For the other usecase (p16 polygons to p48 prims) we could use rotated 1-16 prims, but I still prefer a "new" complete prim.

(how does prim subst work exactly? is there like an table which to use for what situation?)

René

[Travis Cobbs]

(how does prim subst work exactly? is there like an table which to use for what situation?)

LDView's primitive substitution performs hard-coded primitive recognition based on recognizing patterns in p filenames. Once a file is recognized as being a primitive, the substitution happens in different ways depending on if it is being used for rendering or POV export.

For rendering, I have specialized code that generates the geometry (typically triangles) at the current primitive substitution quality level and based on information extracted from the filename. For aring primitives, the only data that needs to be extracted is the fraction, since they are always high-res (48). Since my initial work assumed that aring would be used next to 16-sided geometry, it just generates an appropriate set of chords. The other case will require me to figure out the appropriate geometry to adapt a low-resolution curved primitive to a high-resolution curved primitive. For curve quality above a certain threshold, both resolutions are the same, so there would be no generated geometry. Below that threshold, I have to figure out how to fill in the gap algorithmically.

For POV export, the goal is the same, but the details are different. Curved primitives in POV generally have to be created using constructive solid geometry with various POV geometric primitives. This is often more difficult to figure out, but the end result is the same. For an aring that adapts a low-resolution curved primitive to a high-resolution curved primitive in POV, there is no geometry, since POV curves don't use triangles. They are all logically infinite resolution. For the other case, it would need to generate the appropriate chords, except for my next paragraph.

Given what is being said, I think that aring should be forbidden to be used to adapt 16-sided geometry, and should only be used for primitive-to-primitive adaptation. Furthermore, if the proposed new primitive is created, it should be created using the existing chrd primitives. By doing it that way, no new primitive substitution code is needed in LDView to have it work. Existing parts that use aring to adapt 16-sided geometry would have to be updated to use the new primitive. (Or if it is decided that part authors should just use chrd primitives directly, then they should be update to do that. Personally, it seems like doing it that way introduces extra work for part authors.)

[Hageta]

Since there are two use cases there probably a way to descripe this relation in the model.
This could be done through new primitives that are basically shortcuts to the aring primitive, but there name descripes the usecase.
Could also be solved by a new meta command, but that is probably unecessary.