[GSoC 2013 - accepted] Improve Progressive Mesh

Threads related to Google Summer of Code
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by PhilipLB » Mon Jul 08, 2013 3:10 pm

You'll need to invert a nasty matrix, too. That's the part I'm interested in. :)
0 x
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.

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Thu Jul 11, 2013 2:05 pm

Quadratic Error based reduction:
Image

Curvature based reduction:
Image

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
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Tue Jul 23, 2013 2:12 pm

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!

Image
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.
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

drwbns
Orc Shaman
Posts: 777
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by drwbns » Wed Jul 24, 2013 12:26 am

That's looking really good for a quick LOD-reduction flow. Nice job!
0 x

drwbns
Orc Shaman
Posts: 777
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by drwbns » Fri Aug 02, 2013 3:10 pm

How's everything going sajty? I noticed you haven't posted or pushed anything in awhile. Do you have any updates?
0 x

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Fri Aug 02, 2013 3:45 pm

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:
Image
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Thu Aug 08, 2013 7:27 pm

[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
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Wolfmanfx » Thu Aug 08, 2013 7:43 pm

Awesome work!
0 x

User avatar
Xavyiy
OGRE Expert User
OGRE Expert User
Posts: 847
Joined: Tue Apr 12, 2005 2:35 pm
Location: Albacete - Spain

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Xavyiy » Thu Aug 08, 2013 7:52 pm

Awesome!
0 x

JordanWeber
Gnoblar
Posts: 7
Joined: Fri Feb 01, 2013 1:18 pm

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by JordanWeber » Thu Aug 08, 2013 11:33 pm

Great work, I just want to let you know, progressivemesh was the reason why I upgraded to 1.9 beta :P
0 x

drwbns
Orc Shaman
Posts: 777
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by drwbns » Fri Aug 09, 2013 12:22 am

Awesome work! What's left in your project? Have you started August 5-August 26: Weighted outer wall (2 weeks) ?
0 x

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Fri Aug 09, 2013 6:29 am

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. :)
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Wolfmanfx » Fri Aug 09, 2013 7:55 am

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).
0 x

User avatar
Zonder
Gargoyle
Posts: 1079
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 3

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Zonder » Fri Aug 09, 2013 8:10 am

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).
That is a great idea.
0 x
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.This post is suspected as SPAM! If you feel otherwise contact a moderator.

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Fri Aug 09, 2013 8:40 am

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).
You can inherit from another LodConfig with copy constructor or operator=. I have used such inheritance in the editor on multiple locations.
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.
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

phobossion
Halfling
Posts: 45
Joined: Wed Jul 24, 2013 9:50 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by phobossion » Fri Aug 09, 2013 9:01 am

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 :D
0 x

User avatar
Zonder
Gargoyle
Posts: 1079
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 3

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Zonder » Fri Aug 09, 2013 12:56 pm

sajty wrote:
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).
You can inherit from another LodConfig with copy constructor or operator=. I have used such inheritance in the editor on multiple locations.
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.
I don't think it needs to be in a readable form.
0 x
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.This post is suspected as SPAM! If you feel otherwise contact a moderator.

PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by PhilipLB » Fri Aug 09, 2013 1:01 pm

Zonder wrote:I don't think it needs to be in a readable form.
:shock:

Really?
0 x
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.

User avatar
Zonder
Gargoyle
Posts: 1079
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 3

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Zonder » Fri Aug 09, 2013 3:15 pm

PhilipLB wrote:
Zonder wrote:I don't think it needs to be in a readable form.
:shock:

Really?
Always prefer fast loading. If I need to modify something I write an editor. :D
0 x
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.This post is suspected as SPAM! If you feel otherwise contact a moderator.

PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by PhilipLB » Fri Aug 09, 2013 4:18 pm

Sorry, I somehow thought you meant the actual source code of this GSoC. :lol:
0 x
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.

User avatar
Zonder
Gargoyle
Posts: 1079
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 3

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Zonder » Mon Aug 12, 2013 8:34 am

PhilipLB wrote:Sorry, I somehow thought you meant the actual source code of this GSoC. :lol:
my poor quoting :) talking about serialization.

source code should defiantly be readable !! :)
0 x
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.This post is suspected as SPAM! If you feel otherwise contact a moderator.

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Mon Aug 26, 2013 12:15 pm

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.
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
Contact:

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by masterfalcon » Tue Sep 17, 2013 5:21 am

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;
0 x

sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by sajty » Tue Sep 17, 2013 1:33 pm

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.
0 x
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: [GSoC 2013 - accepted] Improve Progressive Mesh

Post by Wolfmanfx » Tue Sep 17, 2013 4:14 pm

I think owen added a macro for using nullptr when its available
0 x

Post Reply