[fixed]OCTREE deform geometry with lightmaps.

[christianclavet]

Here, discovered a bug with the OCCTREE calculation that seem to deform the geometry with meshes that contain Vertices that are Ligtmapped.

Here is the original thread:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=23822

If the surface is completely shaded with Lightmaps for all the surfaces, no deformation occur.

This happen only if some surface of the object have Vertex Lightmapping. Also it happen when Gile[s] save a surface with "No Lighting" attribute applied on a surface.

I was thinking first that the loader didnt supported Vertex Lightmap. It load correctly as a IANIMATED mesh. It's when try to use it as OCCTREE that the problem occur.

[bitplane]

I can see this here now I'm loading as an OctTree, thanks for sharing your mesh
Looks like a problem with the B3D loader, it has memory leaks when loading your file.

[christianclavet]

Thanks Bitplane.

But if you load the mesh as a standard mesh or animated mesh, it doesnt corrupt at all (I should have done this first) . It's when the mesh it converted in Occtree that the corruption appear.

So now, my big "noob" theory, should be that the corruption start in the loader that affect the meshbuffer, then, it "crash" the Occtree calculation?

For the moment, I have 2 methods to bypass the problem :

Workaround 1:
- Load the mesh as save it as .B3D (Before light calculation).
- Calculate the mesh with Vertex Lighting and Lightmaps. Save it as a second mesh.

- Load the first mesh as Occtree (hide it)
- Load the second mesh with the lightmaps and vertex lighting as Animated Mesh.

It will work, but the disavantage will be that, 2 meshes will have to be produced (Will have to create 2 meshes, also not efficient for the memory, but will have the full mesh display quality). One for the display, one for the collision.

Workaround 2:
- Simply render your mesh with only Lightmaps for all surfaces (This is not efficient for the detailed parts of the mesh(quality), but it will load only one mesh, display properly(with less quality in detailed parts), and will able to support collision (I'm a little lazy, so this is the method I have chosen for my level)

It would be nice, that 1.4 would be able to convert to Occtree without having mesh corruption. Thanks to you and Luke for helping me find out the problem. I know now that I can have workaround on this problem. I was stuck.

[hybrid]

Ok, finally fixed. Code in SVN/trunk is corrected now and should work for most meshes now.