Incorrect curves transform on parented curve objects & instancing visibility problem #63379

New Issue

Acrivec Cevirca · 2019-04-08T02:22:05+02:00

Acrivec Cevirca commented

2019-04-08 02:22:05 +02:00

System Information
Operating system: W10
Graphics card: 980Ti

Blender Version
Broken: 2.80 19-04-07 00:42

Short description of error
Curves transformations are computed incorrectly while their parents are moved. It can be fixed just by trying to move them as independent (but still not removing the parent), and then cancel. They will recompute everything correctly and look OK.
Problem was present in 2.79 and I've been thinking it will be fixed in 2.8, but it's even worse now.
Due to changes in groups -> collections, a lot of stuff is being done in a wrong way if the source collection is invisible or in other locaiton than linked one.

Now look at this, in viewport I have 'fixed' the filament curve by simply moving the lightbulb while it's original collection was visible, then turned it off and I could move this lightbulb with source invisible - lightbulb was being updated correctly.
But after hitting render - picel.

Now it seems to be really connected to the viewport and render visibility. If something is invisible in viewport but visible in render and vice versa it can affect strange stuff.

Exact steps for others to reproduce the error
Set curve to have a parent, move parent - curve is placed incorrectly now. Try to move curve (you can cancel) - curve is now in right place.

In the attached .blend, when you open it - select rendered view, you'll see that filament is outside of the bulb, turn on view on "lightbulbs" (picrel):

Then expand "lighbulb on joined", select "Szklo.001" and try to move it (default G), you can move - or try to move and cancel.
Filament will jump back in the bulb in both source and instanced bulb. Picrel.

You can now turn off "Lightbulbs" colleciton view and move instanced bulb around - it will be continously correctly updated.

Looks good?
Yeah. Render it. Surprise.

.blend:
lightbulb.blend

**System Information** Operating system: W10 Graphics card: 980Ti **Blender Version** Broken: 2.80 19-04-07 00:42 **Short description of error** Curves transformations are computed incorrectly while their parents are moved. It can be fixed just by trying to move them as independent (but still not removing the parent), and then cancel. They will recompute everything correctly and look OK. Problem was present in 2.79 and I've been thinking it will be fixed in 2.8, but it's even worse now. Due to changes in groups -> collections, a lot of stuff is being done in a wrong way if the source collection is invisible or in other locaiton than linked one. Now look at this, in viewport I have 'fixed' the filament curve by simply moving the lightbulb while it's original collection was visible, then turned it off and I could move this lightbulb with source invisible - lightbulb was being updated correctly. But after hitting render - picel. ![FS0KErd- [x].png](https://archive.blender.org/developer/F6917927/FS0KErd_1_.png) Now it seems to be really connected to the viewport and render visibility. If something is invisible in viewport but visible in render and vice versa it can affect strange stuff. **Exact steps for others to reproduce the error** Set curve to have a parent, move parent - curve is placed incorrectly now. Try to move curve (you can cancel) - curve is now in right place. In the attached .blend, when you open it - select rendered view, you'll see that filament is outside of the bulb, turn on view on "lightbulbs" (picrel): ![4iKBPQE- [x].png](https://archive.blender.org/developer/F6917947/4iKBPQE_1_.png) Then expand "lighbulb on joined", select "Szklo.001" and try to move it (default G), you can move - or try to move and cancel. Filament will jump back in the bulb in both source and instanced bulb. Picrel. ![c6tyVpG- [x].png](https://archive.blender.org/developer/F6917952/c6tyVpG_1_.png) You can now turn off "Lightbulbs" colleciton view and move instanced bulb around - it will be continously correctly updated. ![vbLZ3Ct- [x].png](https://archive.blender.org/developer/F6917954/vbLZ3Ct_1_.png) Looks good? Yeah. Render it. Surprise. ![9may9Ir- [x].png](https://archive.blender.org/developer/F6917957/9may9Ir_1_.png) .blend: [lightbulb.blend](https://archive.blender.org/developer/F6917960/lightbulb.blend)

Acrivec Cevirca commented

2019-04-08 02:22:05 +02:00

Added subscriber: @Acrivec

Sebastian Parborg commented

2019-04-09 18:33:39 +02:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-04-09 18:33:39 +02:00

Could you create a minimal example file of the problem?

Preferably with just a curve object and a parent object. There is way too much going on in that file that doesn't seem relevant to this issue.

Could you create a minimal example file of the problem? Preferably with just a curve object and a parent object. There is way too much going on in that file that doesn't seem relevant to this issue.

Acrivec Cevirca commented

2019-04-10 00:57:39 +02:00

@ZedDB I'll try to create example, I hope I will have time for this in this week.

Also, I have been thinking about it before sleep and I think it happens because of transformations order.
When you move something in viewport by mouse you move it thousands of times in a second, but render does it just once - it has the end transformations values.
Therefore, if you have objects which are parented - they are moved in particular order, yes? first this object, then this, then this, then children etc..
Also we know that if you have a Curve and you want any object to follow it - their origin points MUST be at the same place - or else we have strange results.
So, in viewport - when we move "nested" stuff - we move thousands of times, so differences between transformations are minimal. But on render we do it once, so difference can be big if we move object far from 0x0x0.
If the order of transformations and curve computing is done anyhow wrong - for example first parent is moved first, then we move it's child, then we initialise curve (it's still on 0x0x0) and move the curve to meet it's parent - curve data is still based on 0x0x0 and just moved to the correct point - the curve shape (and therefore position too) is completly wrong.

I hope you understand a bit my thinking.
I had this problem when I've been creating a teddy bear - I used curves for his eye threads. When I moved him from pose to pose (so, a jump - not thousands of updates) threads were in correct place, but were reaaaallyy messed up - bigger, flipped out, etc. When I just touched teddy bear position - they 'jumped back' to the correct position.

So for now forget any connection to collections - I really think it's transformation / initialisation of curves related.

@ZedDB I'll try to create example, I hope I will have time for this in this week. Also, I have been thinking about it before sleep and I think it happens because of transformations order. When you move something in viewport by mouse you move it thousands of times in a second, but render does it just once - it has the end transformations values. Therefore, if you have objects which are parented - they are moved in particular order, yes? first this object, then this, then this, then children etc.. Also we know that if you have a Curve and you want any object to follow it - their origin points MUST be at the same place - or else we have strange results. So, in viewport - when we move "nested" stuff - we move thousands of times, so differences between transformations are minimal. But on render we do it once, so difference can be big if we move object far from 0x0x0. If the order of transformations and curve computing is done anyhow wrong - for example first parent is moved first, then we move it's child, then we initialise curve (it's still on 0x0x0) and move the curve to meet it's parent - curve data is still based on 0x0x0 and just moved to the correct point - the curve shape (and therefore position too) is completly wrong. I hope you understand a bit my thinking. I had this problem when I've been creating a teddy bear - I used curves for his eye threads. When I moved him from pose to pose (so, a jump - not thousands of updates) threads were in correct place, but were reaaaallyy messed up - bigger, flipped out, etc. When I just touched teddy bear position - they 'jumped back' to the correct position. So for now forget any connection to collections - I really think it's transformation / initialisation of curves related.

db commented

2019-04-10 02:39:34 +02:00

Added subscriber: @browneggz

db commented

2019-04-10 02:39:34 +02:00

This sounds similar to what I was seeing in #61389 - but in my case it was an Array modifier used inside a collection instead of parenting. Perhaps it's the same root cause though?

Some things I noticed in my case:

While Cycles was broken, Eevee and Workbench were fine
If the source collection was inside the default Collection, everything worked ok

This sounds similar to what I was seeing in #61389 - but in my case it was an Array modifier used inside a collection instead of parenting. Perhaps it's the same root cause though? Some things I noticed in my case: - While Cycles was broken, Eevee and Workbench were fine - If the source collection was inside the default Collection, everything worked ok

Acrivec Cevirca commented

2019-04-10 02:42:10 +02:00

@browneggz Yes, I think it's connected.

Sebastian Parborg commented

2019-04-10 15:11:50 +02:00

I think that the root cause it probably the same, so I'll go ahead and merge this one in. We can always reopen this if it turns out to be a different problem.

Sebastian Parborg commented

2019-04-10 15:12:11 +02:00

Closed as duplicate of #61389

Sebastian Parborg closed this issue

2019-04-10 15:12:11 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Incorrect curves transform on parented curve objects & instancing visibility problem #63379