T-Junctions and Y-scaled flat primitives in the Library Spec

[Orion Pobursky]

T-Junctions:
These are discouraged in the file format spec:

Where possible, abutting polygons should share common verticies.

I'd like to explicitly disallow in the library spec.

Y-scaled flat primitives:
These are not mentioned in the file format spec or the library spec.
I'd like to explicitly disallow in the library spec.

[Willy Tschager]

T-Junctions:
These are discouraged in the file format spec:


I'd like to explicitly disallow in the library spec.

Y-scaled flat primitives:
These are not mentioned in the file format spec or the library spec.
I'd like to explicitly disallow in the library spec.

+1

[Magnus Forsberg]

T-junctions
Might be necessary where 2 holes are close to eachother and using ndis is the better choise than tang prims.
But today we have tang, ndis and tndis, so avoiding T-junc is easier.

Flat primitives
It is wrong to call them "Y-scaled". It would be better to talk about "flat prims scaled in three dimensions".

[Max Murtazin]

I should mention that in some cases, for example axle primitives, T-Junctions are something that comes along with the way those primitives are made and how those are usually encased in other primitives. If we are going to get rid of any T-Junctions, major reworks have to be done. By the way, does it matter that much? Mostly T-Junktions might appear in places that are either sharp edges or flat geometry, and in both cases it doesn't matter at all if geometry is properly jointed or not

[Orion Pobursky]

T-junctions
Might be necessary where 2 holes are close to eachother and using ndis is the better choise than tang prims.
But today we have tang, ndis and tndis, so avoiding T-junc is easier.

I would say that it can always be avoided. It might not be 100% tri/quad efficient but efficiency isn't the goal, render accuracy/quality is.

Flat primitives
It is wrong to call them "Y-scaled". It would be better to talk about "flat prims scaled in three dimensions".

In their default, un-transformed state they lie on the X-Z plane. Therefore "Y-Scaled" isn't wrong. That said, if you have a better way to describe this state I'm happy to discuss it.

[Orion Pobursky]

I should mention that in some cases, for example axle primitives, T-Junctions are something that comes along with the way those primitives are made and how those are usually encased in other primitives. If we are going to get rid of any T-Junctions, major reworks have to be done. By the way, does it matter that much? Mostly T-Junktions might appear in places that are either sharp edges or flat geometry, and in both cases it doesn't matter at all if geometry is properly jointed or not

It not like we'll need to suddenly update the entire library. For the library spec (since it's a further restricted subset of the file format) if the spec changes the current, official parts are grandfathered in until they are updated for some other reason. A revision will only affect parts currently on the PT and and future submitted parts.

[Max Murtazin]

Thanks for clarification. Still tho, I don't see that much of a point in T-Junctions being disallowed by specs, because it demands change that doesn't affect basically anything as far as I'm aware.

[Max Murtazin]

It is wrong to call them "Y-scaled". It would be better to talk about "flat prims scaled in three dimensions

It is the best way we have. Mind that flat primitive actually have to be scaled in 3 dimensions any time it isn't aligned with cardinal directions (relatively to the global coordinates)

[Orion Pobursky]

Thanks for clarification. Still tho, I don't see that much of a point in T-Junctions being disallowed by specs, because it demands change that doesn't affect basically anything as far as I'm aware.

Here's a couple threads on why (including the one where Travis convinced me I was wrong):
https://www.ldraw.org/forums/thread-8595.html
https://www.ldraw.org/forums/thread-2352...l#pid32836


Maybe I should have written "explicitly disallow unless justification is given".

[Max Murtazin]

Okay, I see now. Minding this, getting rid of T-Junctions is certainly a good idea, but keep in mind that it brings in some unpleasant problems that would meet to be faced later.

[Travis Cobbs]

T-Junctions:
These are discouraged in the file format spec:


I'd like to explicitly disallow in the library spec.

Y-scaled flat primitives:
These are not mentioned in the file format spec or the library spec.
I'd like to explicitly disallow in the library spec.

I'm not sure about the best wording for "Y-scaled flat primitives". I would actually say that it should be more explicit: primitives where all Y values are 0.

Having said that, I disagree with disallowing it in the case where the scale matrix scales X, Y and Z equally. It's true that the Y portion of the scale would be ignored, but I personally feel that a uniform scale in all three axes is preferable to one where only the X and Z axes are scaled, while Y scaling is set to 1. I feel that forcing them to use a different scale matrix just because the thing they are scaling happens to be in the X-Z plane add unnecessary complexity to the part authors' jobs, and doesn't accomplish anything useful.

[N. W. Perry]

Here's a couple threads on why (including the one where Travis convinced me I was wrong):
https://www.ldraw.org/forums/thread-8595.html
https://www.ldraw.org/forums/thread-2352...l#pid32836


Maybe I should have written "explicitly disallow unless justification is given".

What would be the practical effect of disallowing, as far as the part submission and review process?

[Max Martin Richter]

T-junctions
Might be necessary where 2 holes are close to eachother and using ndis is the better choise than tang prims.
But today we have tang, ndis and tndis, so avoiding T-junc is easier.

Flat primitives
It is wrong to call them "Y-scaled". It would be better to talk about "flat prims scaled in three dimensions".

I write in my review either "flat prim is scaled in 3rd dimension" or "2D prim ist scaled in 3rd dimension".

(Actually only as a comment as it is no hold reason for now.)

[Philippe Hurbain]

Having said that, I disagree with disallowing it in the case where the scale matrix scales X, Y and Z equally. It's true that the Y portion of the scale would be ignored, but I personally feel that a uniform scale in all three axes is preferable to one where only the X and Z axes are scaled, while Y scaling is set to 1. I feel that forcing them to use a different scale matrix just because the thing they are scaling happens to be in the X-Z plane add unnecessary complexity to the part authors' jobs, and doesn't accomplish anything useful.

I also strongly disagree to enforce unscaling of flat primitives in flat direction. It imposes a completely needless burden on part author, with absolutely 0 benefit.
Moreover, besides useless, it's actually impossible to enforce:
- Consider a scaled cylc primitive... the built in edges and disc are de-facto scaled in the result file.
- How do you define scale for slanted flat primitives???

[Philippe Hurbain]

I would say that it can always be avoided. It might not be 100% tri/quad efficient but efficiency isn't the goal, render accuracy/quality is.

I am of course less definitive for T-junction as they _sometimes_ cause visual problems, but why not rely on common sense of part author? Show me a visual problem caused by one of the gazillion of T-junction I made and we'll discuss again... Actually I sometimes introduced T-junctions precisely to avoid some visual issues!!!

but efficiency isn't the goal,

Wow. I still learn something everyday...

[Max Murtazin]

What would be the practical effect of disallowing, as far as the part submission and review process?

Needing to check not only for proper shaping and use of primitives, but also for mesh defects. Generally, only benefit is shading being easier to deal with, meanwhile requiring changes on side of primitives, and more work from author

[N. W. Perry]

Needing to check not only for proper shaping and use of primitives, but also for mesh defects. Generally, only benefit is shading being easier to deal with, meanwhile requiring changes on side of primitives, and more work from author

This seems to be the effect already, as reviewers will generally hold for T-junctions.

[Max Murtazin]

This seems to be the effect already, as reviewers will generally hold for T-junctions.

They don't always do, but with this being an official standard they likely will always hold T-Junctions

[Orion Pobursky]

They don't always do, but with this being an official standard they likely will always hold T-Junctions

Since it's officially discouraged in the file format, I'll hold unless justification is given. I want to codify this so that there's consistency in reviews.

[Orion Pobursky]

Ok, you've convinced me. I retract the 3D scaled 2D primitive proposal.

[N. W. Perry]

They don't always do, but with this being an official standard they likely will always hold T-Junctions

Since it's officially discouraged in the file format, I'll hold unless justification is given. I want to codify this so that there's consistency in reviews.

Yeah, some reviewers will hold, others will leave a novote comment and just await the fix, which has basically the same effect as a hold. So I think maybe codifying the justification is the important part—that way, if it's given, you have standing to remove the hold and/or vote to certify.