Geometry Nodes: The UV of the UV Sphere are rotated for one extra segment #116809

New Issue

Open

opened 2024-01-04 23:57:03 +01:00 by Artem-Shakhov · 13 comments

Artem-Shakhov commented

2024-01-04 23:57:03 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce MX150/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 471.68

Blender Version
Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: 9be62e85b727
Worked: Never.

Short description of error
UV map of UV Sphere Mesh Primitive does not match other GN Mesh Primitive

The UV map is offset by one segment. So the problem can be solved by rotating the sphere by one segment. Therefore, this issue is not a big deal.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce MX150/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 471.68 **Blender Version** Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: `9be62e85b727` Worked: Never. **Short description of error** UV map of UV Sphere Mesh Primitive does not match other GN Mesh Primitive The UV map is offset by one segment. So the problem can be solved by rotating the sphere by one segment. Therefore, this issue is not a big deal.

GN_Mesh_Primitive_UV_Bug_01.blend

728 KiB

Artem-Shakhov added the

labels 2024-01-04 23:57:04 +01:00

Iliya Katushenock added

Nodes & Physics

Good First Issue

and removed

labels 2024-01-05 09:00:49 +01:00

Iliya Katushenock changed title from ~~GN. The UV of the UV sphere is not consistent with the rest of the Mesh Primitives.~~ to Geometry Nodes: The UV of the UV Sphere are rotated for one extra segment

2024-01-05 09:02:24 +01:00

Balázs Füvesi commented

2024-01-06 22:35:34 +01:00

Hi, I would like to try this as my first issue.

Hi, I would like to try this as my first issue.

Balázs Füvesi referenced a pull request that will close this issue

2024-01-07 00:46:40 +01:00

Fix #116809: Geometry nodes UV map of UV Sphere #116856

Balázs Füvesi commented

2024-01-07 00:58:39 +01:00

I made a fix where I moved the UV map.

I think the problem is caused by the order of the vertices, which is different in the case of UV Sphere compared to the other primitives.

I think a better fix would be to make the order of the vertices consistent, although this might break some node setups.

I made a fix where I moved the UV map. I think the problem is caused by the order of the vertices, which is different in the case of UV Sphere compared to the other primitives. ![Screenshot 2024-01-07 at 001741.png](/attachments/1545dfbf-8ba3-45ed-bb6c-2f1fddaa8729) ![Screenshot 2024-01-07 at 001808.png](/attachments/5510b0f9-2e50-4b16-8f09-59d2f08dbf16) ![Screenshot 2024-01-07 at 001754.png](/attachments/eca7ce34-f96a-41ab-b29c-cc875df6b710) I think a better fix would be to make the order of the vertices consistent, although this might break some node setups. ![Screenshot 2024-01-07 at 001754m.png](/attachments/d5f784ce-aee4-411f-b0ce-a36a806b18d5)

Screenshot 2024-01-07 at 001754.png

48 KiB

Screenshot 2024-01-07 at 001754m.png

48 KiB

Screenshot 2024-01-07 at 001808.png

59 KiB

Screenshot 2024-01-07 at 001741.png

55 KiB

Jacques Lucke commented

2024-02-27 15:18:20 +01:00

Member

I think we don't necessarily have to solve this. I'm not aware of a use-case where this inconsistency actually causes problems. We never made the guarantee that the nodes in geometry nodes output exactly the same geometry as the normal primitives in Blender. Would have been nice of course but changing it now does not seem worth it.

If people reeeally need this, I think it may also be ok to add a legacy option to the node so that we support both modes at the same time. The difference between both modes seems small enough that this doesn't add too much complexity.

I think we don't necessarily have to solve this. I'm not aware of a use-case where this inconsistency actually causes problems. We never made the guarantee that the nodes in geometry nodes output exactly the same geometry as the normal primitives in Blender. Would have been nice of course but changing it now does not seem worth it. If people reeeally need this, I think it may also be ok to add a legacy option to the node so that we support both modes at the same time. The difference between both modes seems small enough that this doesn't add too much complexity.

Iliya Katushenock commented

2024-03-06 16:03:50 +01:00

Member

I'm not aware of a use-case where this inconsistency actually causes problems

I think example file of this report is actually use case with demonstration of problem.

We never made the guarantee that the nodes in geometry nodes output exactly the same geometry as the normal primitives in Blender

Yes, that is no strict rule, but that is visible inconsistency and i think would be good to fix that.

If people reeeally need this, I think it may also be ok to add a legacy option to the node so that we support both modes at the same time

Unnecessary complexity. This is just rotation of mesh on really small angle. Mesh looks the same as in older versions.
Yeah, this will be visible for files which is depends on indices, but we should not use this as reason to do not fix or make the fix more complicated. Users should not depend on indices, and we even have utils to check if that is so.

The difference between both modes seems small enough that this doesn't add too much complexity

For small resolution, difference can be as 0.333-size step of UV shift.

> I'm not aware of a use-case where this inconsistency actually causes problems I think example file of this report is actually use case with demonstration of problem. > We never made the guarantee that the nodes in geometry nodes output exactly the same geometry as the normal primitives in Blender Yes, that is no strict rule, but that is visible inconsistency and i think would be good to fix that. > If people reeeally need this, I think it may also be ok to add a legacy option to the node so that we support both modes at the same time Unnecessary complexity. This is just rotation of mesh on really small angle. Mesh looks the same as in older versions. Yeah, this will be visible for files which is depends on indices, but we should not use this as reason to do not fix or make the fix more complicated. Users should not depend on indices, and we even have utils to check if that is so. > The difference between both modes seems small enough that this doesn't add too much complexity For small resolution, difference can be as 0.333-size step of UV shift.

Jacques Lucke commented

2024-03-08 18:52:37 +01:00

Member

Users should not depend on indices, and we even have utils to check if that is so.

Well, there are cases when indices are supposed to be stable, and primitive nodes generally are such a case (unless otherwise noted by a call to debug_randomize_*).

> Users should not depend on indices, and we even have utils to check if that is so. Well, there are cases when indices are supposed to be stable, and primitive nodes generally are such a case (unless otherwise noted by a call to `debug_randomize_*`).

Iliya Katushenock commented

2024-03-08 18:57:05 +01:00

Member

I would like to be able to change the indexes of primitive nodes, there is always a way to do something faster by changing the topology model.

I would like to be able to change the indexes of primitive nodes, there is always a way to do something faster by changing the topology model.

Jacques Lucke commented

2024-03-08 18:59:13 +01:00

Member

Yes, but in some cases that will actually need an option in the node so that the old behavior can be preserved. Without this, it's hard to impossible to create certain selections on procedural primitives.

Yes, but in some cases that will actually need an option in the node so that the old behavior can be preserved. Without this, it's hard to impossible to create certain selections on procedural primitives.

Iliya Katushenock commented

2024-03-08 19:04:11 +01:00

Member

I agree that line primitive indices should always match the step factor. But this doesn't seem to be a good method for selecting, for example, a sphere or a cube part. Indices don't always just match the right side if you need it (x>0 and y>0 for the same geometry). Then you have to do complex mod() or /x_indices_num, be deep into topology details, and so on. So, users just have to use positions as a more trivial alternative.

I agree that line primitive indices should always match the step factor. But this doesn't seem to be a good method for selecting, for example, a sphere or a cube part. Indices don't always just match the right side if you need it (x>0 and y>0 for the same geometry). Then you have to do complex mod() or /x_indices_num, be deep into topology details, and so on. So, users just have to use positions as a more trivial alternative.

Hans Goudey commented

2024-03-08 22:45:56 +01:00

Member

I sort of agree that we shouldn't necessarily guarantee the indices of the cube or sphere primitives, they're quite arbitrary and their may be benefits to changing the indices to be more spatially coherent, for example. But it's also not a huge deal if we have to support the old indexing in the future if that happens. For this change in particular I have basically the same opinion-- I'm not sure we need to maintain the old behavior, but it's not really a big deal to do that either.

I sort of agree that we shouldn't necessarily guarantee the indices of the cube or sphere primitives, they're quite arbitrary and their may be benefits to changing the indices to be more spatially coherent, for example. But it's also not a huge deal if we have to support the old indexing in the future if that happens. For this change in particular I have basically the same opinion-- I'm not sure we need to maintain the old behavior, but it's not really a big deal to do that either.

Jacques Lucke commented

2024-03-10 12:54:09 +01:00

Member

But this doesn't seem to be a good method for selecting, for example, a sphere or a cube part. Indices don't always just match the right side if you need it (x>0 and y>0 for the same geometry).

Obviously, you wouldn't depend on indices for position dependent selections. It's more useful for selecting e.g. every second vertex in a specific edge loop. I'm quite sure that people are doing this kind of stuff already and I think it's ok for primitives. Note that we explicitly excluded ico spheres from that list so far, which supports index randomization.

> But this doesn't seem to be a good method for selecting, for example, a sphere or a cube part. Indices don't always just match the right side if you need it (x>0 and y>0 for the same geometry). Obviously, you wouldn't depend on indices for position dependent selections. It's more useful for selecting e.g. every second vertex in a specific edge loop. I'm quite sure that people are doing this kind of stuff already and I think it's ok for primitives. Note that we explicitly excluded ico spheres from that list so far, which supports index randomization.

Iliya Katushenock commented

2024-03-10 13:14:59 +01:00

Member

Obviously, you wouldn't depend on indices for position dependent selections. It's more useful for selecting e.g. every second vertex in a specific edge loop

For this kind of staff, user still need to be deep in to details of how topology of primitive are built. And this still can be done via positions or by using more specific nodes, like Edge Rings.

Note that we explicitly excluded ico spheres from that list so far, which supports index randomization.

Glad that ico sphere can be excluded from the list of disputed nodes, but i have plans about merge all super-ball meshes. Cube, UV sphere, Cone, Cylinder, Circle, all of them is pretty similar meshes, and to share a lot of topology code, code related to positions and uvs, them can be changed. There is still ability to add options for different fill modes for top and bottom planes (grid, fan, n-gon, lines, star, ...) for all of this primitives at the same time. And also there is ability to make it possible to use weak users for attributes of primitives with trivial settings to cache them. There is still a lot other things that is not covered by so detailed steps for me now, and all of them required to be able to change indices.

> Obviously, you wouldn't depend on indices for position dependent selections. It's more useful for selecting e.g. every second vertex in a specific edge loop For this kind of staff, user still need to be deep in to details of how topology of primitive are built. And this still can be done via positions or by using more specific nodes, like Edge Rings. > Note that we explicitly excluded ico spheres from that list so far, which supports index randomization. Glad that ico sphere can be excluded from the list of disputed nodes, but i have plans about merge all super-ball meshes. Cube, UV sphere, Cone, Cylinder, Circle, all of them is pretty similar meshes, and to share a lot of topology code, code related to positions and uvs, them can be changed. There is still ability to add options for different fill modes for top and bottom planes (grid, fan, n-gon, lines, star, ...) for all of this primitives at the same time. And also there is ability to make it possible to use weak users for attributes of primitives with trivial settings to cache them. There is still a lot other things that is not covered by so detailed steps for me now, and all of them required to be able to change indices.

Jacques Lucke commented

2024-03-10 13:22:46 +01:00

Member

I'm not against more functionality, but we need to remain compatible unless there is a strong reason not to. So far I'm not aware of why we can't stay compatible. Obviously, if new features are added, the indices can be different if those new features are used. I don't think there is a high cost to keeping existing files compatible.

I'm not against more functionality, but we need to remain compatible unless there is a strong reason not to. So far I'm not aware of why we can't stay compatible. Obviously, if new features are added, the indices can be different if those new features are used. I don't think there is a high cost to keeping existing files compatible.

Iliya Katushenock commented

2024-03-10 13:29:57 +01:00

Member

Hm, actually, we can use Sort Elements to change indices as part of versioning today i guess

Hm, actually, we can use `Sort Elements` to change indices as part of versioning today i guess

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

5 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#116809

No description provided.