Mesh Vertices only update when in cone of last created spotlight #38379

New Issue

solarlune · 2014-01-27T22:56:58+01:00

solarlune commented

2014-01-27 22:56:58 +01:00

System Information
Windows 7 64-bit AMD Radeon HD 7750

Blender Version
2.69.7 fbc7ab3 (built from scratch)
Worked: 2.69 Release

Short description of error
Manually updating vertices in Python (i.e. moving them, changing their UVs, etc) only works when physically placed in a spotlight, if a spotlight exists in the scene.

Exact steps for others to reproduce the error
Just press P in the example blend file to play the game. Notice the cube's vertices just rise one frame unless you place the cube at least to the point at which it intersects the spotlight's cone. Note that it has to be whichever spotlight was created last (i.e. duplicate the existing one, and the cube will no longer rise in the first spotlight. It now will only do so in the second).

Once the problematic object intersects the light, it's "good", so to speak from that point, regardless of whether it continues in the light or not.

This phenomenon doesn't appear with other kinds of lights, or with spotlights that have no shadow buffer.

VertTest.blend

**System Information** Windows 7 64-bit AMD Radeon HD 7750 **Blender Version** 2.69.7 fbc7ab3 (built from scratch) Worked: 2.69 Release **Short description of error** Manually updating vertices in Python (i.e. moving them, changing their UVs, etc) only works when physically placed in a spotlight, if a spotlight exists in the scene. **Exact steps for others to reproduce the error** Just press P in the example blend file to play the game. Notice the cube's vertices just rise one frame unless you place the cube at least to the point at which it intersects the spotlight's cone. Note that it has to be whichever spotlight was created last (i.e. duplicate the existing one, and the cube will no longer rise in the first spotlight. It now will only do so in the second). Once the problematic object intersects the light, it's "good", so to speak from that point, regardless of whether it continues in the light or not. This phenomenon doesn't appear with other kinds of lights, or with spotlights that have no shadow buffer. [VertTest.blend](https://archive.blender.org/developer/F75503/VertTest.blend)

solarlune commented

2014-01-27 22:56:58 +01:00

Changed status to: 'Open'

solarlune commented

2014-01-27 22:56:58 +01:00

Added subscriber: @solarlune

solarlune commented

2014-01-27 23:05:48 +01:00

This bug also shows up in the latest build of Blender from the BuildBot, so it's not my personal build that has an issue, either.

Adam Friesen commented

2014-01-28 00:08:03 +01:00

Added subscriber: @Ace_Dragon

Adam Friesen commented

2014-01-28 00:08:03 +01:00

Hi, the following attachment (which is an edited version of someone else's solution for Ocean Waves), works just fine in a VC build from the buildbot done at hash c0a4089
water_surface_1.1.blend

This utilizes manual movement of vertices through Python like what your report suggests is needed, but I don't see any bug here, you should probably download a buildbot build and double-check to make sure it's not an error on your end (like in your compiling process or settings), perhaps it's only not working in certain cases then?

Hi, the following attachment (which is an edited version of someone else's solution for Ocean Waves), works just fine in a VC build from the buildbot done at hash c0a4089 [water_surface_1.1.blend](https://archive.blender.org/developer/F75509/water_surface_1.1.blend) This utilizes manual movement of vertices through Python like what your report suggests is needed, but I don't see any bug here, you should probably download a buildbot build and double-check to make sure it's not an error on your end (like in your compiling process or settings), perhaps it's only not working in certain cases then?

Adam Friesen commented

2014-01-28 00:11:50 +01:00

Sorry, I didn't notice that you already tried a buildbot build, but the file I had that I tested still works okay.

I even quick tested with a spotlamp in the scene to see if that leads to it exhibiting the bug, but it's still bug-free for this case.

Sorry, I didn't notice that you already tried a buildbot build, but the file I had that I tested still works okay. I even quick tested with a spotlamp in the scene to see if that leads to it exhibiting the bug, but it's still bug-free for this case.

Adam Friesen commented

2014-01-28 00:14:34 +01:00

Dang it, I think I attached the wrong file, this was the one I was talking about
Wave_Script3.blend

Sorry for making a mess here, but there's no edit button.

Dang it, I think I attached the wrong file, this was the one I was talking about [Wave_Script3.blend](https://archive.blender.org/developer/F75511/Wave_Script3.blend) Sorry for making a mess here, but there's no edit button.

solarlune commented

2014-01-28 02:44:45 +01:00

(Hmm, it would appear I commented on the file, so I'll comment again here.)

It's fine; thanks for the blend file. It would appear that old meshes work fine, but new meshes have some sort of issue. That blend file works fine for me, until you:

Change the sun lamp to a spotlight,
Delete the original plane (not directly necessary) and spawn a new one,
Set it up to run the script in the blend file.
Move the spotlight away.

At that point, the new plane can be seen to stop updating.

(Hmm, it would appear I commented on the file, so I'll comment again here.) It's fine; thanks for the blend file. It would appear that old meshes work fine, but new meshes have some sort of issue. That blend file works fine for me, until you: 1) Change the sun lamp to a spotlight, 2) Delete the original plane (not directly necessary) and spawn a new one, 3) Set it up to run the script in the blend file. 4) Move the spotlight away. At that point, the new plane can be seen to stop updating.

Adam Friesen commented

2014-01-28 03:24:03 +01:00

In the build I'm using.

Changed the lamp to a spotlight; works
Move the spotlight away; works
Create a new plane; works as long you have the logic bricks and properties copied over
Spawn the plane from a hidden layer; works

Either this bug is extremely recent or it's simply tough to pin down why it occurs.

In the build I'm using. - Changed the lamp to a spotlight; works - Move the spotlight away; works - Create a new plane; works as long you have the logic bricks and properties copied over - Spawn the plane from a hidden layer; works Either this bug is *extremely* recent or it's simply tough to pin down why it occurs.

solarlune commented

2014-01-28 04:12:10 +01:00

Hmm, I see. Did you try a recent build bot version with my example file?

EDIT: The buildbot version I downloaded was from today, and I compiled my own build yesterday, it would seem.

Hmm, I see. Did you try a recent build bot version with my example file? EDIT: The buildbot version I downloaded was from today, and I compiled my own build yesterday, it would seem.

Patrick de Jong commented

2014-01-30 13:33:42 +01:00

Added subscriber: @rykounanba

Patrick de Jong commented

2014-01-30 13:33:42 +01:00

After some playing around I noticed you can work around it when you turn off the shadows on your glsl shaders or on the spotlight itself.

solarlune commented

2014-01-30 16:29:33 +01:00

@rykounanba - I mentioned turning off shadows fixes the issue in the bug report, but it's good to know that turning off shadows on the shader does it too. So it would appear that it has something to do with the shadows in particular for spot lights.

Patrick de Jong commented

2014-02-04 15:48:00 +01:00

after some more research I found out that because the meshModified within your mesh gets set to false it stops rendering. When you make sure it does not set the meshModified it will keep on rendering, and you can see it did not actually stop to update the object. How this relates to the shadows cast by the spotlight is still a mystery to me tough.

Patrick de Jong commented

2014-02-13 10:10:11 +01:00

I suspect it might be because the mesh deformer is not getting set. That seems to push the function trough a different render loop which does not update the Vertex Array but actually just renders the Vertex Array. When the deformer doesn't get set it doesn't list the display array as modified. When it does state it has been modified it actually forces a different loop that takes care of updating the vertex array and thus rendering the objects as suspected.

solarlune commented

2014-02-23 08:47:50 +01:00

Bumping (?) for more info. I just tried this in the recent Release Candidate for Blender 2.7, and the bug is still there.

Mitchell Stokes commented

2014-02-23 22:08:02 +01:00

Added subscriber: @Moguri

Mitchell Stokes commented

2014-02-23 22:08:02 +01:00

I did a build of 2.69, and it doesn't work there. Is there a typo in your summary?

solarlune commented

2014-02-24 18:17:04 +01:00

That's odd, I just downloaded a build from the buildbot (64-bit Windows), and the bug's still there.

When you start the game, if the cube is outside of the spotlight, all of its vertices move up one unit. If it's in the spotlight, the vertices continually move up, as the script is executing every frame.

The hash of the buildbot build is 01645cc, and it's from today, the 24th of February.

That's odd, I just downloaded a build from the buildbot (64-bit Windows), and the bug's still there. When you start the game, if the cube is outside of the spotlight, all of its vertices move up one unit. If it's in the spotlight, the vertices continually move up, as the script is executing every frame. The hash of the buildbot build is 01645cc, and it's from today, the 24th of February.

solarlune commented

2014-02-24 18:19:25 +01:00

So the bug is that the vertices visually don't update if there's a spotlight and the object isn't in its cone. You can print out the vertices' Z position and see the values rise, despite not updating visually in the game.

EDIT: Maybe Rykounanba can say what build / version of Blender he's using?

So the bug is that the vertices visually don't update if there's a spotlight and the object isn't in its cone. You can print out the vertices' Z position and see the values rise, despite not updating visually in the game. EDIT: Maybe Rykounanba can say what build / version of Blender he's using?

Mitchell Stokes commented

2014-02-25 02:21:44 +01:00

I can see the bug, I was just pointing out that it also exists in 2.69, so 2.69 isn't a working version.

solarlune commented

2014-02-25 02:35:11 +01:00

Ah, I see. I misunderstood you. It's odd, though; I must have tested it out in Blender 2.69 when I said that it worked then. However, when I tried it myself just now, the bug is still there in 2.69 release, as you mentioned. Very odd.

blender-admin commented

2014-05-13 08:13:27 +02:00

This issue was referenced by 2055e968df

This issue was referenced by 2055e968df654ade2a7a477dcc7c134b1f65dcb8

Mitchell Stokes commented

2014-05-13 08:15:39 +02:00

Changed status from 'Open' to: 'Resolved'

Mitchell Stokes closed this issue

2014-05-13 08:15:39 +02:00

Mitchell Stokes commented

2014-05-13 08:15:39 +02:00

Closed by commit 2055e968df.

Closed by commit 2055e968df.

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

Mesh Vertices only update when in cone of last created spotlight #38379