[GSoC 2013 - accepted] Improve Progressive Mesh
-
- Google Summer of Code Student
- Posts: 550
- Joined: Thu Jun 04, 2009 5:07 pm
- Location: Berlin
- x 108
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
You'll need to invert a nasty matrix, too. That's the part I'm interested in.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Quadratic Error based reduction:
Curvature based reduction:
I have expected better performance from it.
If I would add optimizations for symmetric matrices and optimize 4x4 matrix operations for specific CPU, I think you can get 1.5x-2x speedup compared to curvature based reduction. However quality-wise its 2x worse.
I don't provide benchmark results, because it can be further tuned and it wouldn't be realistic (Currently it has same generation time).
code: https://bitbucket.org/sajty/ogre/commit ... ca222d3bb5
Curvature based reduction:
I have expected better performance from it.
If I would add optimizations for symmetric matrices and optimize 4x4 matrix operations for specific CPU, I think you can get 1.5x-2x speedup compared to curvature based reduction. However quality-wise its 2x worse.
I don't provide benchmark results, because it can be further tuned and it wouldn't be realistic (Currently it has same generation time).
code: https://bitbucket.org/sajty/ogre/commit ... ca222d3bb5
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Hi!
I want to show the current state of profiling.
Currently seam corners, where multiple seams are joining together are handled as normal seams borders, but they cause more artifacts then that.
This case is currently not handled (but it's on my todo list).
To fix this with profiling you just need to track down which reduction it was and press the keep vertex button and it's fixed!
For example in this image, reducing 279 vertices do not have the artifact on the shoulder, but reducing 280 has!
So you move to 280 and press the keep vertex button and it's fixed! You can now reduce the mesh even further with nice shoulders!
Using mesh serializer for exporting and loading external resources into the editor is not ready yet.
Also I will make a video about how to improve the quality a lot in just few minutes with profiling.
I want to show the current state of profiling.
Currently seam corners, where multiple seams are joining together are handled as normal seams borders, but they cause more artifacts then that.
This case is currently not handled (but it's on my todo list).
To fix this with profiling you just need to track down which reduction it was and press the keep vertex button and it's fixed!
For example in this image, reducing 279 vertices do not have the artifact on the shoulder, but reducing 280 has!
So you move to 280 and press the keep vertex button and it's fixed! You can now reduce the mesh even further with nice shoulders!
Using mesh serializer for exporting and loading external resources into the editor is not ready yet.
Also I will make a video about how to improve the quality a lot in just few minutes with profiling.
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- Orc Shaman
- Posts: 788
- Joined: Mon Jan 18, 2010 6:06 pm
- Location: Costa Mesa, California
- x 24
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
That's looking really good for a quick LOD-reduction flow. Nice job!
-
- Orc Shaman
- Posts: 788
- Joined: Mon Jan 18, 2010 6:06 pm
- Location: Costa Mesa, California
- x 24
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
How's everything going sajty? I noticed you haven't posted or pushed anything in awhile. Do you have any updates?
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Hi, sorry for not updating more often.
Quiet lot of development is going on.
The problem with the profiler was that you could only export 1 Lod level, because there was no level control.
To support multiple Lod levels and transform it into a full Lod Editor, I have completely refactored the sample.
Changes:
-Completely refactored the sample.
-Support muliple Lod levels in the sample.
-LodConfigSerializer: the editor will keep all info persistent for each mesh. So if you restart the editor the profile and all other configs are not lost.
-You can add your own models through resources.cfg into the editor, so you don't need to recompile to add models.
-Fixed a crash with compression when the last Lod level was skipped, because the last-1 level had the same vertex count.
-Fixed select menu widget, if you have removed the selected item, then it was still the active label.
-Much more smaller fixes.
There are some issues remaining with the GUI, but all the functionality is working. After that I will create a video.
Here is a sneak peak image of the editor:
Quiet lot of development is going on.
The problem with the profiler was that you could only export 1 Lod level, because there was no level control.
To support multiple Lod levels and transform it into a full Lod Editor, I have completely refactored the sample.
Changes:
-Completely refactored the sample.
-Support muliple Lod levels in the sample.
-LodConfigSerializer: the editor will keep all info persistent for each mesh. So if you restart the editor the profile and all other configs are not lost.
-You can add your own models through resources.cfg into the editor, so you don't need to recompile to add models.
-Fixed a crash with compression when the last Lod level was skipped, because the last-1 level had the same vertex count.
-Fixed select menu widget, if you have removed the selected item, then it was still the active label.
-Much more smaller fixes.
There are some issues remaining with the GUI, but all the functionality is working. After that I will create a video.
Here is a sneak peak image of the editor:
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
[vimeo]71983497[/vimeo]
Here is the video as promised.
I just recorded reducing ninja once and then cut it together to make it shorter so sadly there are lot of scene swaps in the video.
Also I don't have mentioned, that autoconfig uses the profile if available and you can save autoconfig to mesh too.
So a faster work pipeline would be to profile the model, then export with autoconfig.
The music is from BRBachman and it is under creative commons license.
https://soundcloud.com/brbachman/room-r ... d-memories
Here is the video as promised.
I just recorded reducing ninja once and then cut it together to make it shorter so sadly there are lot of scene swaps in the video.
Also I don't have mentioned, that autoconfig uses the profile if available and you can save autoconfig to mesh too.
So a faster work pipeline would be to profile the model, then export with autoconfig.
The music is from BRBachman and it is under creative commons license.
https://soundcloud.com/brbachman/room-r ... d-memories
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
-
- OGRE Expert User
- Posts: 847
- Joined: Tue Apr 12, 2005 2:35 pm
- Location: Albacete - Spain
- x 87
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Awesome!
Creator of SkyX, Hydrax and Paradise Sandbox.
Looking for Ogre3D consulting services?
Follow me: @Xavyiy
Looking for Ogre3D consulting services?
Follow me: @Xavyiy
-
- Gnoblar
- Posts: 7
- Joined: Fri Feb 01, 2013 1:18 pm
- x 1
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Great work, I just want to let you know, progressivemesh was the reason why I upgraded to 1.9 beta
-
- Orc Shaman
- Posts: 788
- Joined: Mon Jan 18, 2010 6:06 pm
- Location: Costa Mesa, California
- x 24
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Awesome work! What's left in your project? Have you started August 5-August 26: Weighted outer wall (2 weeks) ?
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
I'm just starting Weighted outer walls, however I have already made a prototype in the bonding period.
At midterm, my mentor suggested that I should refactor the code to make it more readable.
I'm still thinking how (so some of this may not get into the new design!), but I would do it like this:
-Create a separate plugin to reduce OgreMain binary size, but Lod buffers inside the mesh would still work without the plugin.
-There would be a central class, where you can pass the LodConfig. Everything else would work behind the scenes (just like now).
-Adding threading/non threading selection into LodConfig too.
-Separate the reduction algorithm (curvature or quadric error) from the collapsing/baking code.
-Profiling could be a wrapper of the reduction algorithm.
If you have any ideas/suggestions/wishes for a new design, then please share it.
At midterm, my mentor suggested that I should refactor the code to make it more readable.
I'm still thinking how (so some of this may not get into the new design!), but I would do it like this:
-Create a separate plugin to reduce OgreMain binary size, but Lod buffers inside the mesh would still work without the plugin.
-There would be a central class, where you can pass the LodConfig. Everything else would work behind the scenes (just like now).
-Adding threading/non threading selection into LodConfig too.
-Separate the reduction algorithm (curvature or quadric error) from the collapsing/baking code.
-Profiling could be a wrapper of the reduction algorithm.
If you have any ideas/suggestions/wishes for a new design, then please share it.
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
I like the plugin idea maybe you could create a seperate component for progressive mesh stuff like the overlay / rtss.
LodConfig is great if you can override it per mesh so the user can create a default lodconfig but the user can provide a seperate one per mesh (like CSS rules).
LodConfig is great if you can override it per mesh so the user can create a default lodconfig but the user can provide a seperate one per mesh (like CSS rules).
-
- Ogre Magi
- Posts: 1172
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 76
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
That is a great idea.Wolfmanfx wrote:LodConfig is great if you can override it per mesh so the user can create a default lodconfig but the user can provide a seperate one per mesh (like CSS rules).
There are 10 types of people in the world: Those who understand binary, and those who don't...
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
You can inherit from another LodConfig with copy constructor or operator=. I have used such inheritance in the editor on multiple locations.Wolfmanfx wrote: LodConfig is great if you can override it per mesh so the user can create a default lodconfig but the user can provide a seperate one per mesh (like CSS rules).
If you meant that I should create something like materials, where the config can be stored in readable text file (like css), then there is a problem explained bellow.
At the beginning the algorithm creates a mesh grid by merging vertices with exact same position.
So in profiling the unique identifier of a vertex is the position. After merging the vertices there is a vector, where I could use the vertex id, but the order is implementation dependent.
Also you don't profile a vertex, but an edge with a given destination position, so the vertex may still be collapsed on a different edge. You can even profile edges, which are not existing at the beginning.
Now the problem is if you would convert the float into string and back, then you would loose the bit-by-bit float match and profiling would not work. Thats the reason why I choose Ogre::Serializer to keep the LodConfig persistent in the editor.
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- Halfling
- Posts: 45
- Joined: Wed Jul 24, 2013 9:50 am
- x 3
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Good work, looking forward to using it! make sure you provide a nice and clean API for editors, so that users can tweak their mesh LOD progression using few sliders. Make it easy to integrate and it will be integrated, they say
-
- Ogre Magi
- Posts: 1172
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 76
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
I don't think it needs to be in a readable form.sajty wrote:You can inherit from another LodConfig with copy constructor or operator=. I have used such inheritance in the editor on multiple locations.Wolfmanfx wrote: LodConfig is great if you can override it per mesh so the user can create a default lodconfig but the user can provide a seperate one per mesh (like CSS rules).
If you meant that I should create something like materials, where the config can be stored in readable text file (like css), then there is a problem explained bellow.
At the beginning the algorithm creates a mesh grid by merging vertices with exact same position.
So in profiling the unique identifier of a vertex is the position. After merging the vertices there is a vector, where I could use the vertex id, but the order is implementation dependent.
Also you don't profile a vertex, but an edge with a given destination position, so the vertex may still be collapsed on a different edge. You can even profile edges, which are not existing at the beginning.
Now the problem is if you would convert the float into string and back, then you would loose the bit-by-bit float match and profiling would not work. Thats the reason why I choose Ogre::Serializer to keep the LodConfig persistent in the editor.
There are 10 types of people in the world: Those who understand binary, and those who don't...
-
- Google Summer of Code Student
- Posts: 550
- Joined: Thu Jun 04, 2009 5:07 pm
- Location: Berlin
- x 108
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Zonder wrote:I don't think it needs to be in a readable form.
Really?
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
-
- Ogre Magi
- Posts: 1172
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 76
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Always prefer fast loading. If I need to modify something I write an editor.PhilipLB wrote:Zonder wrote:I don't think it needs to be in a readable form.
Really?
There are 10 types of people in the world: Those who understand binary, and those who don't...
-
- Google Summer of Code Student
- Posts: 550
- Joined: Thu Jun 04, 2009 5:07 pm
- Location: Berlin
- x 108
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Sorry, I somehow thought you meant the actual source code of this GSoC.
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst
Volume GFX, accepting donations.
-
- Ogre Magi
- Posts: 1172
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 76
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
my poor quoting talking about serialization.PhilipLB wrote:Sorry, I somehow thought you meant the actual source code of this GSoC.
source code should defiantly be readable !!
There are 10 types of people in the world: Those who understand binary, and those who don't...
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Hi, last week I was working on the outside detection, which I have already introduced a prototype some time ago.
Changes compared to prototype:
-You can change the walk angle too.
-You can generate the convex hull as manual mesh instead of DynamicRenderable.
-I have fixed a very hard problem, the floating point rounding issues in the convex hull algorithm. So cases, where 4+ vertices are on the same plane will work perfectly. Situations like same plane, same line and same point can have an mEpsilon=boundingSphereRadius * std::numeric_limits<Real>::epsilon() * 4.0 error, which seems to work on all tested meshes.
-I have also reduced the algorithm complexity of convex hull calculation from O(n*h) to O(n log n), however the memory usage increased from O(n) to O(n log h) where n=vertex count and h=hull triangle count. On some meshes it was a bit faster, but in average it was slower. So I have reverted all the changes.
Changes compared to prototype:
-You can change the walk angle too.
-You can generate the convex hull as manual mesh instead of DynamicRenderable.
-I have fixed a very hard problem, the floating point rounding issues in the convex hull algorithm. So cases, where 4+ vertices are on the same plane will work perfectly. Situations like same plane, same line and same point can have an mEpsilon=boundingSphereRadius * std::numeric_limits<Real>::epsilon() * 4.0 error, which seems to work on all tested meshes.
-I have also reduced the algorithm complexity of convex hull calculation from O(n*h) to O(n log n), however the memory usage increased from O(n) to O(n log h) where n=vertex count and h=hull triangle count. On some meshes it was a bit faster, but in average it was slower. So I have reverted all the changes.
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Just a note, the code doesn't currently build with GCC/clang.
Code: Select all
OgreMain/src/OgreQueuedProgressiveMeshGenerator.cpp: In member function virtual void Ogre::PMWorker::bakeMergedLods(bool):
OgreMain/src/OgreQueuedProgressiveMeshGenerator.cpp:392:76: error: no matching function for call to max(size_t&, unsigned int)
Code: Select all
OgreMain/src/OgreOutsideMarker.cpp:85:26: error: use of undeclared identifier 'nullptr'
CHVertex* vertex[4] = { nullptr, nullptr, nullptr, nullptr };
^
OgreMain/src/OgreOutsideMarker.cpp:85:35: error: use of undeclared identifier 'nullptr'
CHVertex* vertex[4] = { nullptr, nullptr, nullptr, nullptr };
^
OgreMain/src/OgreOutsideMarker.cpp:85:44: error: use of undeclared identifier 'nullptr'
CHVertex* vertex[4] = { nullptr, nullptr, nullptr, nullptr };
^
OgreMain/src/OgreOutsideMarker.cpp:85:53: error: use of undeclared identifier 'nullptr'
CHVertex* vertex[4] = { nullptr, nullptr, nullptr, nullptr };
^
OgreMain/src/OgreOutsideMarker.cpp:199:29: error: use of undeclared identifier 'nullptr'
CHVertex* furthestVertex = nullptr;
-
- Google Summer of Code Student
- Posts: 47
- Joined: Tue Sep 27, 2011 9:26 am
- x 50
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
Thanks, I will fix them. I wrote the prototype in C++11, because it's cleaner, but when I was merging it upstream, I have forgotten to remove nullptr.
Update of progress:
I have already implemented the mixing of manual Lod levels. For each LOD level in LodConfig, you can set the manualMeshName to the mesh, which you want to use for the given level. By default it's empty, which means the original mesh is used.
I have also moved it to a component, which makes it an optional feature instead of a core feature.
Currently I'm working on refactoring/cleaning the code.
Update of progress:
I have already implemented the mixing of manual Lod levels. For each LOD level in LodConfig, you can set the manualMeshName to the mesh, which you want to use for the given level. By default it's empty, which means the original mesh is used.
I have also moved it to a component, which makes it an optional feature instead of a core feature.
Currently I'm working on refactoring/cleaning the code.
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: [GSoC 2013 - accepted] Improve Progressive Mesh
I think owen added a macro for using nullptr when its available