Mostly directed at David.

I've been doing a lot of programming in C++ the since I first started using Polyvox, I think my programming skill is good enough now that I might be able to contribute in some small ways. I would just like a *pointer into where I can help out.

Regards.

Hi,

Well it's great to here that you are interested and we'd cetainly be interested in having some help. We've had some success in the past with ker's work on the LargeVolume and we still hope to integrate realazthat's work on the TVA algorithm. Any further contributions from yourself would also be welcome.

That said, you can probably see that work on PolyVox is slow at the moment and I don't want to switch back to focusing on it until things are wrapped up with Voxeliens (Linux port and online distributors). This means I'd rather you didn't work on anything too complex or 'core' (e.g. changes to the volume structure) as it requires too much thought for design decisions. It would be better to work on something standalone such as a new algorithm.

Do you have any particular ideas, perhaps related to a project you are working on? If not then you can have a look at the todo list to see what interests you. A 'PointListSurfaceExtractor' should be straightforward from the PolyVox point of view, though you will need to know basic geometry shaders (or some other approach to instancing) to take advantge of it.

Otherwise, something related to image processing might be interesting and shouldn't be too complex. Filters such as dilation, erosion, or even simple thresholding could be useful. Let me know if you would like me to expand on this.

I spent some time reading Polyvox's code so that I have a better idea how it all fits together, have to compliment you et. al. for the code readability.



I had a look at making the surfaceMesh functions virtual, but for the getVertices function it may pose problems since assuming that addVertex for example simply calls manualObject::position, there will be no way to read the vertex data directly until after manualObject::end is called. A solution would be to not just add a vertex to ogre, but to a member vector as well. This would however add more overhead and add more code for the user to implement when overwriting the functions. I'm also not sure if the overhead of virtual functions would be significant. This however might be something considered to be core. Opinions? [Edit] Woops, seems like template classes can't have virtual functions, will look into this a bit more.

In regards with the pointListExtractor, I wasn't able to find much information on this. It mostly seems that people are going the opposite route of point list -> voxels or directly to mesh. So I'm unsure how to implement this. My, not so thought through, implementation would be to create a rigid 3d grid, transverse it and look for points where it intersects the surface, then move the point to the interpolated position of the surface. Would this qualify as a point list surface extractor?

I'm basically trying to help out so that I can learn to be a better programmer/ get something on my resume. I'm only a first year uni student

There are basically two approaches which can be used here. The first is to have a base 'Mesh' class with subclasses for OpenGLMesh, OgreMesh, etc and virtual function for things like addVertex. The alternative approach is based on templates. For example, PolyVox volumes don't need to inherit from a common base class (though one is provided), they simply need to provide the required set of functions. The template based approch is often known as 'compile time polymorphism' or 'duck typing' if you want more info. Generally the second approach is better from a performance point of view.

This todo item was actually inspired by the TVA thread (viewtopic.php?f=2&t=338) in which realazthat talks about the use of OutputIterators. He does seem to know a little more about templates and STL/Boost than me, so it's worth looking into these. However, it may be that they are more/less than we need and I would like to make sure I can maintain any code that gets added to PolyVox.

In terms of requirements, it would be nice if the output could be std::vector, OpenGL, Direct3D, ManualObject, OpenMesh, and possibly others. We wouldn't actually include all of these in PolyVox though, it would be for users to write the required implementation.



I was thinking even simpler, in that it would be for the cubic (Minecraft) style surfaces. All it would have to output would be a list of solid voxels which are next to an empty voxel. User code would then render a cube for each voxel using instancing and/or the geometry shader (relevant Ogre code here). This is interesting for a couple of reasons:

• It should use less memory than a index/vertex buffer mesh (unless decimation is used?). It may also execute faster than the CubicSurfaceExtractor because it is simpler, so perhaps it is good for smaller but more dynamic volumes.
  
• Rather than just rendering cubes for each voxel, you could perhaps render a more interesting mesh. Not sure exactly what is possible here though.

A basic implementation should be very straightforward for the PolyVox part, but you could later make it more interesting with materials, support for transparency, and support for density fields (using interpolation as you suggest, but I'm not sure if this is useful).

Hmm, you are not talking about adding dependencies to Ogre/etc for the polyvox core library I suppose?

Because that would be very bad, for many reason.

Would you extend the base surfaceMeshExtractor from a surfaceOgreMeshExractor in the polyvox utils library (or similar)? That is what I would expect.

No, we will avoid that. It's nice to keep at least the core of PolyVox as low on depenancies as we can.



The actual surface extractor won't change, but it will be able to write to anything matching a required PolyVox::SurfaceMesh interface (at least that would be one design approach, but I prefer templates). Ogre users would then be able to to provide an implementation of this interface, but this would not be shipped as part of PolyVox. It could go in the wiki or as some kind of extension project.

Something I think would make things easier for ogre users (including myself) is if there would be an CMAKE flag to include POLYVOX_OGRE_UTILTIES or something similar when building polyvox.

And than I would expect some ogre specific things to be in the utils library.

The polyvox examples already have dependencies on QT so I had to disable them, I would expect to find similar utility function there, for example a future openGL/DirectX/Irrlich/<insert your favorite here>.

Basically I agree with you, though I think it's unlikely we'd actually include Ogre utilities in PolyVox. We'd probably draw the line at OpenGL or perhaps Direct3D as these are fairly standard, but the point is that the design should allow people to make Ogre versions if they want to.

Went camping (alone) for a week to run away from clouds and view the Venus transit, and am back now with exams on the next couple of weeks, so haven't made any progress.

In regards with the point list extractor

Ah yes, that could be very useful to some and easy to program, will work on that soonish. Will be very interested if the performance is actually acceptable via this method.

I was thinking in the lines of it being useful for fluid/lava simulations:


Using the surface point list extractor to create particle effects (emitter points) on smooth volumes. Could also possibly be used to compare the surface points to a previous versions points, destroy the points that are within a certain distance to its nearest (old version) neighbour. That way you have a list of surface points where the surface changed to create things such as dust particles/bubble particles for fluids or something along those lines.

Will leave looking at the custom mesh support for later.

Also that image was from a game called "from dust". Loved the games very non-static landscape, hopefully computing power will catchup and allow such awesomeness in true 3D worlds

I saw your image first, and then started reading 'Went camping (alone) for a week..." and for a moment I thought you'd been up a volcano of something



Is it also useful to you? I lose track of what projects people are working on, so I forget if you've been using the CubicSurfaceExtractor. If so then it would be a good thing for you to work on as the PolyVox part should be straight forward. But you should definitly work on something you can make use of yourself.



Now that I think of it, an alternative to this would just be to use the vertex positions which come out of the marching cubes extractor. The density of points might be too low so you may have to tesellate the mesh, but I suspect this still the faster option. Maybe a dedicated smooth point extractor isn't useful, but the marching cubes extractor could take a flag to turn off calculating the indices?

Also, consider whether the cubic and smooth point extractors should be seperate algorithms or a single unified algorithm. My gut feeling is that they should be seperate but I'm not sure.