holy crap... I solved it!!



SEE I told you my picking worked


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.

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.

Great, I'm glad you got it working (and that the problem was not PolyVox :-) )

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.

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?

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:

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.

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!

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!!

approx 80ms debug

55 release

This is a 32x32x32 cube.

It was more at 64

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.