Progressive Mesh improvements

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am
x 50

Progressive Mesh improvements

Post by sajty »

Hi!
I have started integrating my algorithm into Ogre.
I have already created a thread about the technology here: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=74798
This thread is about merging the changes into Ogre3D.
I have also created a sample showing all features.
Sorry, that it took so long to get it into Ogre. University, real life and other projects stole my time for this!

Major improvements in the fork:
-Generating Lod in background with Ogre::WorkQueue. (Optional)
-More customizable interface by passing LodConfig structure.
-Autoconfig: Lod config which works on any mesh. Zoom out in the sample and see the triangle count dropping!
-Much better quality. It seems that Ogre 1.8+ implementation has very bad quality. 1.7 had much better quality.
-Slightly faster. 1.8+ implementation had caught up in performance, but mine is still a bit faster.

Whats reused?
I have rewritten everything with new architecture except computeEdgeCollapseCost function (where 65% of the time is spent), which is based on Ogre 1.7 with major improvements.
I have also used lot of ideas from Ogre 1.7 and 1.8 implementations. For example the SmallVector usage, which gave nice speedup.

Whats missing? (Feel free to help out)
-Test for requested vertex count vs resulting vertex count differences. I have never tested this.
-edgeData: We don't use stencil shadows, so its not tested.
-Coding style fixes.
-I have renamed it to ProgressiveMeshGenerator. If thats ok, we should remove ProgressiveMesh.
-Thumb image for sample.
-Test it on all platforms.

Where are the sources?
I'm new to bitbucket and mercurial, so I have done it on git, then copied to mercurial.
https://github.com/sajty/ember/tree/ogre-merge
https://bitbucket.org/sajty/ogre/commits/branch/v1-9

Win32 sample binaries: http://sajty.elementfx.com/progressivem ... Sample.zip

Finally some images from the sample in the case you can't try it out for some reason:
Image
Image
Image

Update 1: Updated the 'Whats missing?' list.
Last edited by sajty on Thu Feb 07, 2013 5:08 pm, edited 1 time in total.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: Progressive Mesh improvements

Post by TheSHEEEP »

One word: wow. :shock:

I've got a question though. What does the reduction value actually mean?
I think a percentage value would be more intuitive.
My site! - Have a look :)
Also on Twitter - extra fluffy
sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am
x 50

Re: Progressive Mesh improvements

Post by sajty »

Yes, That would be better name for it. :)
Thanks for the idea.
Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm
x 2

Re: Progressive Mesh improvements

Post by Knotanalt »

Good work.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Progressive Mesh improvements

Post by bstone »

Thanks for pushing this back to Ogre!

About the shadow buffers. I didn't have the time to look at your code to see how exactly the buffers are used but a shadowed buffer can be considered thread-safe for reading in a background thread as long as no other threads write to it (which is the case in most apps). Writing to a shadowed buffer from a background thread is definitely a no go because as soon as you unlock it after changing its data it will update the related hardware buffer. The latter will trigger a fatal call to the render system on the background thread.

So it all boils down to the way you use the shadowed buffers. If you only need to read them and can get the no-write guarantee from the other threads then it should be safe.
sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am
x 50

Re: Progressive Mesh improvements

Post by sajty »

Currently it works like this:
1. When a mesh is loaded, we call Lod generation.
2. Lod generation allocates a copy of vertex and index buffers and passes it to PMWorker.
3. PMWorker generates and allocates the Lod index buffers and passes it to PMInjector.
4. PMInjector injects the Lod on main thread into the mesh at frameEnd event.

Currently PMWorker is not accessing the mesh at all. We have even copies of bounding sphere radius and mesh name.
If you can guarantee that in the future it will always be safe to read from shadow buffers, I can optimize 2. step in the above list.
Officially Ogre::Mesh is not thread safe. We have discussed this with my gsoc mentor here:
https://github.com/sajty/ember/commit/5 ... 5a3c#L2R77

Edit: Also if I would read it directly from shadow buffer, would it pass the static analyzer tools? Since in theory a user could write to it while I'm reading it.
Last edited by sajty on Sat Feb 02, 2013 12:07 pm, edited 1 time in total.
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Progressive Mesh improvements

Post by bstone »

I think the best option would be providing a compile time decision for the user. The simplest would be checking if something like _PROGRESSIVE_MESH_SHADOWBUFFERS is defined and using the optimized code path if it is.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: Progressive Mesh improvements

Post by masterfalcon »

Great work. Keep it up and perhaps we can merge it into 1.9.

EDIT: BTW, have you checked out the OpenSubDiv project? There could be some helpful code in there.
sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am
x 50

Re: Progressive Mesh improvements

Post by sajty »

I think the best option would be providing a compile time decision for the user. The simplest would be checking if something like _PROGRESSIVE_MESH_SHADOWBUFFERS is defined and using the optimized code path if it is.
That would make the code very messy, so I think I will stay with current safe way and if somebody wants to optimize it, then he can go for it.
Threading bugs can get very hard to debug.
EDIT: BTW, have you checked out the OpenSubDiv project? There could be some helpful code in there.
If I understand subdivision correctly, its about increasing polygons when the camera gets near to object.
What I'm doing is to reduce polygons, when the camera gets far from object.
So it's some kind of opposite of what this is.
Increasing polygon count is easier then reducing polygon count. :)
Google Summer of Code 2013 Student
Topic: "Progressive mesh improvements"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Murat Sari
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: Progressive Mesh improvements

Post by bstone »

sajty wrote:That would make the code very messy
Not necessarily at all, but okay - maybe somebody else would do that when he needs the extra bit of performance/memory gain.
hksuifeng
Gnoblar
Posts: 3
Joined: Thu Aug 29, 2013 3:48 am

Re: Progressive Mesh improvements

Post by hksuifeng »

Can you put the source code of your demo program?
My mailbox is: <removed_by_mod>!
Thank you for your help! :o
Last edited by spacegaier on Tue Dec 17, 2013 10:34 am, edited 1 time in total.
Reason: Publicly posting mail addresses is not so smart
sajty
Google Summer of Code Student
Google Summer of Code Student
Posts: 47
Joined: Tue Sep 27, 2011 9:26 am
x 50

Re: Progressive Mesh improvements

Post by sajty »

Answered in other topic, please only ask in one topic next time.
http://www.ogre3d.org/forums/viewtopic. ... 96#p499996
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
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Progressive Mesh improvements

Post by Klaim »

sajty, awesome work! I'll try it as soon as 1.10 is close to stabilisation.

I have a question (I'm in the middle of reading the wiki): is it possible to combine mesh lod generation and manual mesh lod?
I'm thinking about my case that is similar to the game Homeworld: from close and not so close I should see meshes, with progressive lod, but after some far distance I should see another mesh or sprite, a symbolic view of something very distant, instead of a bunch of unreadable pixels.
So using your lod generator I would generate lod for close and near to far distances, but lod should switch to another mesh/decal when the camera is far and farest.

Should I be ok with the current implementation?

EDIT: OK I see the answer to my question in the first programming example :oops:
So the answer is YES it's exactly perfect for what I want. :D
Post Reply