Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

[Solved] Another Irrlicht + Polyvox Help Thread
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=593		 Page 3 of 3
Author:  Midnight [ Tue May 27, 2014 12:55 am ]
Post subject:  Re: Another Irrlicht + Polyvox Help Thread
:shock: holy crap... I solved it!! :D

Image

SEE I told you my picking worked 8-) :lol: ;)


I'll post the fix and code later once I've had a chance to clean it up. :)

The problem was not polyvox at all, it was Irrlicht.

I didn't know you needed to clear the mesh. it was fixed with a simple mesh->clear() when recalculating the mesh. I had thought removing the irrlicht scenenode would do that for me but apparently not. Irrlicht uses a reference count, so it also has ->drop() functions which I had tried.

That stupid duplicate vertices/indices thing is unrelated though. No clue what's causing that as I'm not even using the same function to convert the mesh anymore.
Author:  Midnight [ Tue May 27, 2014 1:28 am ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
Thank you so much David for being patient and helpful.

Some of the credit goes to you for the debugging ideas, you helped get me going in the right direction which allowed me to figure this out.

Thanks everybody. I will make a new thread for the working version. I want to maintain an irrlicht demo for the current polyvox versions.
Author:  David Williams [ Tue May 27, 2014 9:17 am ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
Great, I'm glad you got it working (and that the problem was not PolyVox :-) )
Author:  Midnight [ Thu Jun 26, 2014 5:09 pm ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
So I thought I'd update a smidge... The duplicate console msg bug was actually my fault.

I was running the function from my event system. In other words it wasn't part of the procedural chain of function calls. So it took a little bit to notice. But the point is I eventually fixed that as well.

I never did release the code because it doesn't actually work.. well it works but it's not useful without multithreading or modifying the mesh extractor.

On my system it takes about 700ms or approx 3/4 of a second just to extract a 64x64x64 cube, I think I even tried smaller volumes with little improvement. The problem with this is you'd need to separate it into another thread so the rendering isn't affected by the long freeze up.

Many people know this already, have formed their own solutions, and there is little to no information about it easily available. :ugeek:

I've read a bit about moore neighborhoods. I'm kind of confused why extraction doesn't use them. Or polyvox at all for that matter. Care to shed some light on that?
Author:  David Williams [ Fri Jun 27, 2014 1:09 pm ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
Midnight wrote:
On my system it takes about 700ms or approx 3/4 of a second just to extract a 64x64x64 cube...

That doesn't sound right - any chance you are running a debug build? I just modified the BasicExample (which uses a 64x64x64 volume) to print out timings:
Code:
Timer timer;
auto mesh = extractCubicMesh(&volData, volData.getEnclosingRegion());
std::cout << "Extracted in " << timer.elapsedTimeInMilliSeconds() << std::endl;

The result I got are:

Debug mode: 370ms
Release mode: 14 ms

So release mode is about 25 times faster. I think we use smaller sizes in Cubiquity (maybe 16x16x16 or 32x32x32 - I forget exactly) and I'm sure the extractor could be further optimized, but it should be better than you are seeing.
Midnight wrote:
I've read a bit about moore neighborhoods. I'm kind of confused why extraction doesn't use them. Or polyvox at all for that matter. Care to shed some light on that?

I'm not particularly familiar with Moore neighbourhood or how/why PolyVox would make use of them. Can you elaborate?
Author:  Midnight [ Mon Jun 30, 2014 11:15 pm ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
David Williams wrote:
Midnight wrote:
On my system it takes about 700ms or approx 3/4 of a second just to extract a 64x64x64 cube...

That doesn't sound right - any chance you are running a debug build? I just modified the BasicExample (which uses a 64x64x64 volume) to print out timings:
Code:
Timer timer;
auto mesh = extractCubicMesh(&volData, volData.getEnclosingRegion());
std::cout << "Extracted in " << timer.elapsedTimeInMilliSeconds() << std::endl;

The result I got are:

Debug mode: 370ms
Release mode: 14 ms

So release mode is about 25 times faster. I think we use smaller sizes in Cubiquity (maybe 16x16x16 or 32x32x32 - I forget exactly) and I'm sure the extractor could be further optimized, but it should be better than you are seeing.
Midnight wrote:
I've read a bit about moore neighborhoods. I'm kind of confused why extraction doesn't use them. Or polyvox at all for that matter. Care to shed some light on that?

I'm not particularly familiar with Moore neighbourhood or how/why PolyVox would make use of them. Can you elaborate?


Debug build? Yes David, I sure am! :D

Even though I've read about this, I didn't even consider that helping so much. However, even at half a second or less that's far too slow not to be running it in a separate thread or at least a time splitting pseudo thread of some sort. The problem is that with irrlicht it locks up rendering/the mouse control. So it's definitely not minecraft-like enough in that example. I agree that this should be known however, for rough calculation purposes.


https://en.wikipedia.org/wiki/Moore_neighborhood

WOW omg I should have read past the first question... Looks like I'll be playing with polyvox again tonight!! ;)
Author:  Midnight [ Tue Jul 01, 2014 1:59 am ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
Image


approx 80ms debug

55 release :shock:

This is a 32x32x32 cube.

It was more at 64
Author:  David Williams [ Sun Jul 06, 2014 5:14 am ]
Post subject:  Re: [Solved] Another Irrlicht + Polyvox Help Thread
Yes, release vs. debug mode can make a huge difference. Actually I think it makes a bigger difference with PolyVox than with other applications, and I suspect this is because PolyVox involves a lot of memory accesses which then need to be validated when in debug mode. For any real benchmarking you need to be running in release mode.

Also, how are you doing the time measurements? On Windows you should find that the PolyVox::Timer class gives fairly good precision as shown in my previous code snippet.

I expect performance can be improved but we haven't had much need for it so far - it's running nicely in Cubiquity and allowing real-time sculpting and destruction of the environment. A thread-safe volume is still on the horizon, but in the meantime you should (I think) still be able to run PolyVox in a separate thread (just not from two threads at once).

As for the Moore neighbourhood, it seems it just refers to the specific set of voxels which are considered to be the neighbours of a given voxel. It doesn't seem to be a technique or algorithm which you 'use' as such.
Page 3 of 3 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/