Progressive Mesh Buffer / Mesh simplification

[mongoose7]

Well, I understood your previous remark anyway. I just don't believe that Irrlicht creates extra vertices. But you have explained why is doesn't remove duplicate vertices, which appears to be what is happening in this case.

So, I am at a loss as to why holes are being created. There is an error at Line 499 in ProgressiveMeshBuffer.cpp, so it could never detect duplicate edges. But fixing this doesn't fix the problem - holes start to appear around the wheel hubs of the car after removing 33% (or so) of the vertices.

[Lonesome Ducky]

Well if you don't believe it, check the obj file. There are only 5 vertices listed, but irrlicht says there are 12 in the mesh.

[RdR]

Lonesome Ducky, thanks for the case, haven't thought about this because it never occurred for me.

Problem can be improved (not completely fixed) by creating your own createMeshWelded() function to ignore the UV coordinates, normals etc.
But can give some weird texture results.

There is an error at Line 499 in ProgressiveMeshBuffer.cpp, so it could never detect duplicate edges.
But fixing this doesn't fix the problem - holes start to appear around the wheel hubs of the car after removing 33% (or so) of the vertices.

What error and how did you fixed it?

[mongoose7]

You pass 0 as the second parameter instead of 'e'. It is pretty obvious - you are trying to add an edge to a map but the insert doesn't contain the edge. But I didn't find it - VS2010 refused to compile it.

[mongoose7]

Well if you don't believe it, check the obj file. There are only 5 vertices listed, but irrlicht says there are 12 in the mesh.

I had a look at the code and the OBJ file loader reinterprets the file. I don't think this could be the case for the formats that support animation, though. But you were right, if you use the OBJ format, the loader can create extra vertices.

[RdR]

You pass 0 as the second parameter instead of 'e'. It is pretty obvious - you are trying to add an edge to a map but the insert doesn't contain the edge. But I didn't find it - VS2010 refused to compile it.

Hmmm I don' t have any compilation errors with GCC (Linux or MinGW) and doesn't matter for the effect of the edges, not checking by object but by the unique ID string of an edge.

But will change it when I get home, thanks for reporting.

[hybrid]

Also animated meshes create extra vertices. Animation is simply duplicated for those vertices.

[mongoose7]

Hmmm I don' t have any compilation errors with GCC (Linux or MinGW) and doesn't matter for the effect of the edges, not checking by object but by the unique ID string of an edge.

OK. I guess I didn't look closely. It was a bit scary when VS 2010 said there were 6 signatures and none matched. To prove it, it showed me Ty1, Ty2, Ty, ky, ... But it really seemed to be complaining that an integer ('0') does not match the type 'Edge *'. I was distracted because I was looking for more edges but, as Lonesome Ducky pointed out, those edges did not end on the vertex in question.

Here is the error. (The line number is different because I added some debugging to the code.)

Code: Select all

1>ClCompile:
1>  ProgressiveMeshBuffer.cpp
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\utility(163): error C2440: 'initializing' : cannot convert from 'int' to 'Edge *'
1>          Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
1>          C:\Program Files\Microsoft Visual Studio 10.0\VC\include\utility(247) : see reference to function template instantiation 'std::_Pair_base<_Ty1,_Ty2>::_Pair_base<irr::core::stringw&,_Ty>(_Other1,_Other2 &&)' being compiled
1>          with
1>          [
1>              _Ty1=irr::core::stringw,
1>              _Ty2=Edge *,
1>              _Ty=int,
1>              _Other1=irr::core::stringw &,
1>              _Other2=int
1>          ]
1>          ProgressiveMeshBuffer.cpp(537) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2>::pair<irr::core::stringw&,int>(_Other1,_Other2 &&)' being compiled
1>          with
1>          [
1>              _Ty1=irr::core::stringw,
1>              _Ty2=Edge *,
1>              _Other1=irr::core::stringw &,
1>              _Other2=int
1>          ]
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\utility(163): error C2439: 'std::_Pair_base<_Ty1,_Ty2>::second' : member could not be initialized
1>          with
1>          [
1>              _Ty1=irr::core::stringw,
1>              _Ty2=Edge *
1>          ]
1>          C:\Program Files\Microsoft Visual Studio 10.0\VC\include\utility(167) : see declaration of 'std::_Pair_base<_Ty1,_Ty2>::second'
1>          with
1>          [
1>              _Ty1=irr::core::stringw,
1>              _Ty2=Edge *
1>          ]
1>
1>Build FAILED.

Also animated meshes create extra vertices. Animation is simply duplicated for those vertices.

OK, thanks.

[REDDemon]

I figured now several ways to improve performance of your code alot. If I have time I implement test and post. (i think a x4 or more speed up factor is really possible). possible use for real-time also.

[ACE247]

Would be brilliant If you could share that one, REDDemon!
I'm kinda using this excessively to bake LOD meshes for simple environment geometry and batching a folder can take ages!

[RdR]

I figured now several ways to improve performance of your code alot. If I have time I implement test and post. (i think a x4 or more speed up factor is really possible). possible use for real-time also.

Oh nice, would like to see that aswell!
What do you intend to improve?

[REDDemon]

depend on the time I can spend on it. 1 new algorithm probably . std::vector is pretty slow. probably use a C style array wrapped as vector. no more.
using Std::vector<Vertex*> is 2 indirections for each vertex. Potentially slow and prone to cache misses. I will share it of course... when it's done

[RdR]

depend on the time I can spend on it. 1 new algorithm probably . std::vector is pretty slow. probably use a C style array wrapped as vector. no more.
using Std::vector<Vertex*> is 2 indirections for each vertex. Potentially slow and prone to cache misses. I will share it of course... when it's done

Ok nice, would like to see the numbers (especially for the high LOD bunny) when you have time to apply those fixes / changes

[wing64]

Opz code


Original code


Code Opz from idea REDDemon
http://www.4shared.com/rar/YwQkZvpi/Pro ... r_opz.html

[REDDemon]

oh thnanks. you preceeded me I already had to start writing.. Glad you used my idea . As previously supposed the speed up was of 4x (seems also to be up to 5x in certain case). I didn't thinked to be so precise.

Good work wing64!