LDraw.org Discussion Forums

Full Version: T-Junctions and Y-scaled flat primitives in the Library Spec
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
T-Junctions:
These are discouraged in the file format spec:

Quote: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.
(2022-05-04, 18:59)Orion Pobursky Wrote: [ -> ]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
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 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
(2022-05-04, 20:46)Magnus Forsberg Wrote: [ -> ]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.

(2022-05-04, 20:46)Magnus Forsberg Wrote: [ -> ]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.
(2022-05-04, 20:51)Max Murtazin Wrote: [ -> ]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.
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.
(2022-05-04, 20:46)Magnus Forsberg Wrote: [ -> ]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)
(2022-05-04, 21:24)Max Murtazin Wrote: [ -> ]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".
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.
(2022-05-04, 18:59)Orion Pobursky Wrote: [ -> ]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.
(2022-05-04, 21:40)Orion Pobursky Wrote: [ -> ]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?
(2022-05-04, 20:46)Magnus Forsberg Wrote: [ -> ]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.)
(2022-05-04, 22:15)Travis Cobbs Wrote: [ -> ]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???
(2022-05-04, 21:00)Orion Pobursky Wrote: [ -> ]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!!!

Quote:but efficiency isn't the goal,
Wow. I still learn something everyday...
(2022-05-05, 0:24)N. W. Perry Wrote: [ -> ]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
(2022-05-05, 11:17)Max Murtazin Wrote: [ -> ]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.
(2022-05-05, 13:15)N. W. Perry Wrote: [ -> ]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
(2022-05-05, 13:46)Max Murtazin Wrote: [ -> ]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.
Ok, you've convinced me. I retract the 3D scaled 2D primitive proposal.
(2022-05-05, 13:46)Max Murtazin Wrote: [ -> ]They don't always do, but with this being an official standard they likely will always hold T-Junctions

(2022-05-05, 14:25)Orion Pobursky Wrote: [ -> ]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.