Page MenuHome

CustomDataLayer with type CD_MLOOPUV in Mesh::ldata::layers sometimes points to different memory than Mesh::mloopuv
Closed, DuplicatePublic

Description

CustomDataLayer with type CD_MLOOPUV in Mesh::ldata::layers sometimes points to different memory than Mesh::mloopuv, even when only one set of uv coordinates is present. The data pointer in the layer sometimes changes from null to an adress when making slight changes (to irrelevant objects in the file) and resaving the file.

this wasn't the case in 2.74 and earlier where the pointers where always equal.

Psy-Fi mentioned that this data should be the same also.
<psy-fi> hmmm...it's possible that there was some confusion with the recent looptriangle commit
<psy-fi
> in any case, they should be the same

Event Timeline

Joey Ferwerda (TheOnlyJoey) raised the priority of this task from to 90.
Joey Ferwerda (TheOnlyJoey) updated the task description. (Show Details)
Joey Ferwerda (TheOnlyJoey) edited a custom field.
Bastien Montagne (mont29) lowered the priority of this task from 90 to 30.Aug 26 2015, 9:11 PM

The problem with that report is that there is absolutely no way to reproduce it… How do you check those data, in which context, how do you reproduce that mismatch, etc?

I will try adding a blend file that has the issue tomorrow as I am not at the office currently.

We have found the issue when loading the blend file and getting the information from the mesh struct.
We used gdb to print the information.

The corruption seems not to happen always, but I have not found what the condition would be.

EDIT: Also, the corruption is not visible in Blender itself which makes it a bit hard to see, but in our own blendloader the corruptions are directly visible since we handle loading a bit different, but printing the data in gdb is the definite way to find the corruption regardless of loader.

Hey Joey, make sure to include the blender version hash as well to make sure we are on the same page.

Just providing .blend file with corruption is not really enough. It's sort of really important to be able to reproduce the issue in order to solve it..

Attached are all the information we could find on the issue, we found a reproduction case as well.

The attached blendfiles are the same scene, one saved with 2.74 and one with 2.75. the version from 2.75 has the corruption already.
If there are still issues with reproduction, we are ok with dropping by the institute to help reproducing and bugfixing.

Reproduction case:

  1. open 274-ParticleTest in Blender 275a
  2. rename scene to 275ParticleTest
  3. wiggle the viewport camera a little, select a few objects to mark the file dirty
  4. save file as 275ParticleTest.blend

This does now trigger it 100% of the time, but after repeating steps 3 and 4 a few times it eventually happens
Also, this report applies to the data as it is stored in the raw .blend, no processing has happened to the data after it's been placed in the structs when we print the data

In the original file: (blender 2.74 Hash: 000dfc0)
MECylinder

		mloopuv has the same adress as ldata.layers[whatever layer has type CD_MLOOPUV].data
		ldata.layers also contains vertex data in a layer with type CD_MLOOP

MESuzanne

		mloopuv is null
		ldata.layers only contains one layer of type CD_MLOOP, with different data as cylinder

In the resaved file: (blender 2.75a Hash: c27589e)
MECylinder

		no change

MESuzanne

		no change to mloopuv
		ldata.layers is now identical to MECylinder->ldata.layers

I used the following gdb command to print the mesh data
m_bmesh is the Blender::Mesh* in our program
namespace of the struct may be different in Blender so adjust accordingly for the cast

command
print m_bmesh->id.name
print m_bmesh->mloopuv
print (Blender::CustomDataLayer[5]) *m_bmesh->ldata.layers
end