Update Instance Transform sets rotation to 0/0/0

I’ve attempted to reproduce this several times and so far I’ve been unable to get your results. You said this was a blueprint only project, correct? You haven’t made any code changes?

I set the Transform Variable’s location and scale values to something other than default but I leave the rotation value at 0,0,0. Each time I ‘Update the Instance Transform’ the rotation always reads 0,0,0.

were you able to reproduce it now?

So far I haven’t been able to reproduce it. Each time it prints out the correct values that I’ve input. It maybe something specific to your project. If you would like (and if the project is small enough), feel free to send me a download link for you project and I’ll look into it further. You can do this by private message on the forums.

I tried it in a new project and there it also works for me. I will send you my normal project in the forums. Is uploading on mega ok?

Google drive or is preferred, but you can try Mega. I’ll let you know if I can get it, sometimes our firewall will block downloads from there.

There is definitely some kind of instancing error happening. When the second LTransform is set, the rotation should not be effected.

I did notice that changing the GrowState values to larger increments made the rotation stay the same. This maybe something that you would want to test further

Default value: 10

Add amount: 1

Less than: 100

I don’t know the exact cause but I believe it is because the ForLoop is handling so much data that things are getting crossed. You may want to think about making the LTransform into it’s own array and/or handling the Scale value separately.

Take a look at this tutorial that one of our technicians made. It has a Grass Growing section this is very similar to what you are doing here.

Thanks for testing this out. I guess for now I could just scale the whole instanced static mesh instead of the individual instances, since they are all scaled with the same speed. But for more realism I may would want to add individual growing (scaling) speeds for each instance later.
Will you (or other Epic guys) further investigate why this problem occurs? I would like to hear something like “I added this as a bug on out internal bug list and our software engineers will try to find the issue when they find time for that” or something like this ^^

I guess a fix wont make it into 4.7, what’s about 4.8? I just want to hear that it will be fixed in some future release, I just had this issue again at another place. And now I cannot simply bypass this issue since I really need to scale every instance individually. And it really looks ugly that suddenly all the rotations of the instances is 0/0/0.

Hi ,

I’m still investigating the issue and I’m trying to dig a little deeper to find the exact cause. I’ll post back here as soon as I have something.

Ah great thanks :slight_smile:

Here you go, it seems that the LTransform variable being set twice was the cause of the issue. It would get the initial rotation at the loop start but it would then reset the rotation to the ‘Out Instance Transform’.

Take a look at this setup and see if it works for you. I added the NewTransform as a ‘non-local’ variable so I could set a default value for it. Version 4.6 doesn’t allow a local variable to have it’s default value set in this way (however that has now been fixed internally).

Thanks, but I have changed the whole way this growing works a lot so I cannot simply edit the function to test this. But I don’t really find the difference you made there? And I am completely sure the issue was not the LTransform variable, because I only added it for debugging, I had the issue before it existed. I normally don’t want to use any variable, I just want to get the old transform and update the transform without any intermediate variable.

I think I found what is causing the problem. I told you I have the same problem in another place, and it seems the rotation gets set to 0/0/0 only if the scale is set to 0/0/0. If I set the scale to 1/1/1 the rotation does not get affected. If I set the scale to 1/1/0 rotation gets affected. If I set it to .01/.01/.01 rotation does not get affected. So if one value in the scale vector is 0, rotation gets reset to 0.
So the rotation bug may get caused this. Is this plausible?

That was something that I noticed about the original Grow Plants function in the project you sent me. When the GrowState variable was set to 0.0 the rotation would zero out, but if a higher value was input instead, the rotation would stay the same. I’m unsure of the exact reason for that but the changes I made to the function I pictured above fixed that issue.

I’m not able to enter this is a bug report because I haven’t been able to reproduce this behavior in a new project.

Here is a screenshot of your original Grow Plants function if you would like it for reference to see what changes I made.

I think it’s obvious why your changed graph “works”. You don’t get the rotation from the instance, but from the NewTransform variable. The rotation is only set to 0/0/0 the first time the function is called (since only the first time GrowState is 0).

But the first time the function is called, the rotation is get from NewTransform, and directly again set to NewTransform. Then the instance transform is updated (and rotation get’s set to 0). But since the scale is 0, you are not able to see the changed rotation in the game (since you don’t see the plants at all).

The second time the function is called, the old rotation is still get from the NewTransform node (which has NOT been set to 0). Then the instance transform is updated, and since GrowState is not 0, scale also is not 0 and so the rotation get’s set as it should.

In my original GrowPlants function I have directly set the LTransform variable from the “Get instance transform”, so since the rotation was once set to 0 there, it always was 0 afterwards.

By the way, I can easily reproduce this in a new project. I was not able to do it before because there I have not set the scale to 0/0/0. If I create an actor with an instanced static mesh component and update the transform, I get the same bug as in my real project.

http://puu.sh/eWqc7/476813d389.png

Output is 0/55/0 and then 0/0/0.

Am I allowed to say I am not 100% satisfied with the support? It’s awesome that you are willing to look at bugs and even download my whole project for this, but really, you know how much time I have spent writing here and trying to find out how to bypass this bug? I don’t know exact numbers, but I guess this bug has cost me ~7h of time I would have been able to spend on “productive” things.
I don’t really want to criticize you because I know it really doesn’t go without saying that I even get support at all, Unity devs would probably not have helped me at all and fixed it in some release 2 years later.
I don’t know what exactly you could make better, I just wanted to say I am not 100% satisfied, and I hope you can understand that :slight_smile:

were you able to reproduce it now?

any update?

Hi ,

It took some time to track this one down. It has nothing to do with the Update Instance Transform & Get Instance Transform nodes, but it’s the InstancedStaticMesh component itself. It can’t hold a rotation value if the Scale is set to zero. You can test this by entering the values directly in the components Element.

I’ve entered this as JIRA UE-9021 in our tracking software and our developers will be investigating it further.

Cheers,

TJ

Hi ,

I’m the engineer who’s assigned this issue.

The basic problem you’re running into is that InstancedStaticMesh is intended to render lots of instances as fast as possible, and in order to do that it stores the transform as a Matrix which can be directly used by the GPU.

Unfortunately a Matrix stores the translation, scale and rotation in a combined form so that the various numbers depend on each other, and as you’ve seen zeroing out the scale zeroes out the rotation.

I can change the representation for each instance to actually store an FTransform object with independent translation/rotation/scale, but that will slightly slow down every addition or modification operation because the transform will need to be converted to a Matrix when regenerating the rendering data.

Version 4.7 adds support for millions of foliage instances all using InstancedStaticMesh, so I’m going to have to test that making this change doesn’t make the foliage painting tool noticeably slower when working with large numbers of instances. 4.7 is now in release testing, so it’s too late to get this change in for that, but if I can make this change without much impact, it will be in 4.8.

As a workaround, about the only option in Blueprint is to store the existing transform in a local variable before setting the scale to 0 and restoring it afterwards.

If you guys are using source code, I would be happy to send your programmers a small patch that makes the change to use an FTransform and will fix this for you guys. Please let me know if you are interested in that.

Cheers