Realize Instances lost Z rotation of Curve Line in certain situations #105578
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105578
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 527.56
Blender Version
Broken: version: 3.5.0 Beta, branch: blender-v3.5-release, commit date: 2023-03-01 10:15, hash:
ff89dfd6d283Worked: N/A, 3.4.1 is also affected
Short description of error
Discovered in Blender.chat, Realize Instances doesn't appear to passthrough some type of curve rotation, for example Z rotation on a (0,0,0) to (0,0,1) curve line is lost during the process.
Exact steps for others to reproduce the error
Hello. It's not a bug.
The instances provide their own space in which the curves can rotate as they please. But if you realize curves, their normals will be calculated with these rotations.
Apparently not the way you want.
But if you substitute the straight-line curve with a bended one, the rotation will be kept after realization.
So, for straight-line curves even the normal has been rotated and can't be told by eye, but the realization just throws the rotation.
Is it a bug/feature for just straight-line curve instances?
The problem is, that for a straight line the normals are not calculated using the instance rotation. That's exactly what this bugreport is about. It's not the curves that are rotated, it's the instances.
If you very very slightly tweak one endpoint of the instantiated curve so that it's not perfectly vertical, then suddenly the instance rotation is kept on realize.
Not sure how to fix this if it's a bug. The curve does not have a full transform attribute to store the rotation. Because of which, it's more of a feature request rather than a bug (mechanism of influencing the rotation attribute (I didn't go into the math of this, so it's just a superficial estimate that it would be difficult)).
Then how is it possible that everything works as expected with any curve which is not a perfectly vertical line?
It's definitely not a feature request. Because this just behaves weird. Try it. Change one of the endpoints of the instantiated curve and suddenly the instance rotation is preserved.
I'd think the 'instance rotation' is stored at the instance level, not at the cure level. The curve itself doesn't have any rotation/twist.
@Baardaap Yes, I saw. It is necessary to check the first point of the curve, if it belongs to a vertical segment, to refine the rotation matrix on it in order to get the curve Z angle. After that, depending on the type of curve normal, set a curve angle attribute.
There is a dependence on the type of normal of the curve. Also, the value of the attribute changes. Still seems very unreliable...
I have used GN for over 1 year now and I don't think I have ever realized this limitation: transform a curve line on Y axis over 90 degree gives you this. No instances involved, looks like curve line doesn't know its normal to begin with, it's reconstructed by guess work.
I think there are 2 path forward:
change the actual behaviour of curve line normal when transforming (we can introduce a new node for curve rotation that sets tilt automatically)
document this more thoroughly and tell users to compensate for the limit by set curve tilt if they want consistent normal direction over y-axis rotation.
@Zhen-Dai This is part of the topic of the report, but still do not go too far from us)
I don't think this helps. Because the tilt is added to the (parametrically calculated) normal. So you'll still get jumping on exactly vertical segments.
Based on experimentation: This is an extreme case with a fairly low chance of recurrence. It can be bypassed by capturing the correct normals beforehand and then rotating the curve to match them. But the implementation of this for all cases incurs more costs.
Yeah, I think it's best to call this a 'known limitation'. I think the best we could do is maybe document a bit better that the curve normals are procedural and not a real attribute .