Hi all,

In the process of working on the language bindings for PolyVox, I found that due to the reliance of callbacks in the raycast functions, they were hard to wrap. To this end, I opened issue 22 where David and I discussed a simple API that should cover the most common usecases. The result of this is currently a commit in a feature branch.

The new function simply takes the volume pointer, a vector to define where the ray should start (usually the user's camera location), a vector to define the direction (probably either the camera direction of offset from that if doing mouse-picking) and finally a single value which represents what is an empty voxel.

This set-up only really makes sense for cubic style terrain but that is where this type of picking happens usually. For smooth terrain, doing mesh picking in your 3D engine is probably best since it's difficult to get right from the density field.

Really, I wanted to ask if anyone had any comments on this. For voxel picking on cubic meshes, is a single example of an empty voxel good enough for most cases? Any special cases we should think about?

The important files are Picking.h and Picking.inl.

_________________
Matt Williams
Linux/CMake guy

Thanks for working on this Matt, picking has caused some difficulty for people in the past and I think the new interface makes it a lot easier. Users can still fall back on the raycast functions if they need more flexibility, but I think pickVoxel() will handle 90% of their needs.

As for doing this on a smooth volume, I actually posted some code here which I copied from Cubiquity. It's quite easy to implement but not highly optimised. It will be fine for picking though (I'm sure you could do thousands of these each second).

Ok, I'll look into implementing that logic for smooth volumes. I'll continue this in the branch for now and merge it once it's all working. I'm sure it will be fast enough for picking, in most cases it's only done once per frame anyway.

_________________
Matt Williams
Linux/CMake guy

Sounds good! I wasn't necessarily expecting you to btw, I just posted that code for anybody who is interested. But you're welcome to work on it as you're in that area. I guess the interface can be made to match so that we have both cubic and smooth variations of both raycasting and picking? Have a think about it at any rate.



It's entirely up to you when you merge it across, but let me know when there is something in 'develop' and I'll merge across into the Cubiquity branch for testing the new API. This applies to both smooth and cubic variants.