Really? Why such an obscure engine? Why not UDK or Unity?

I'd also like to point out that whilst finding the most slim and fast solution is of course always preferable, I for one would much rather sacrifice some speed for a much more limitless system. It always saddens me to see technology such as this fall short because the bar wasn't raised high enough.

At this time, I work with a slightly customized version of PhyreEngine 2, keeping also an eye on the version 3.
How about yours ?



You are right, in the second chunk, the fragment needs material IDs for each vertices and a hint on their pos to have the right blending angle (which and where a material is on top of others).
But there is no clear way to give the vertice's position to fragment, without buffer objects or like in the wiki through texcoords. If it was a sacrifice to do, this second draw call would still be small.

You are right about GS, I know it is slowly time to, but then you cut straight to SM4 (which is quite ok because even a fridge has a GS capable gpu for its display) ? GS puts a lot more of possibilities. The Geiss's(from NVidia) MC efforts are just brilliant, with our good old smoothed MC's, BTW.

You might have fore sure already visited his code yet(open). If not and if you want to dive in GS for MC terrains,this is definitely a piece of code you need to check out. Even is there is no engine code, he gives most of his shaders.

I inspected it few months ago but did not really stick first because of the gpu's payload(at this time).

I don't think UDK allows you to call code in an external C++ library. Unity does allow this but only if you shell out money for the professional version.

For Voxeliens we used Ogre, but for future projects we'd like a more complete game engine to build on. It has to be at least cheap and ideally open source. Panda3D was another good contender but Gameplay had the advantage of supporting mobile platforms as well (we are still interested in bringing Voxeliens to mobile). I do agree that there is some risk with a young and unproven engine though.

But remember, this doesn't affect PolyVox at all. PolyVox will continue to be independant of specific engines or rendering APIs. It's just a question of what we integrate PolyVox into for any future games.



Unfortunatly there's still no sign of GS support for mobile hardware (I had hoped that OpenGL ES 3 would bring this but apparently not) but at least we have a CPU fallback for this hardware.



Actually I wasn't refering to implementing Marching Cubes in the GS (that is also intresting but outside of PolyVox - we could consider using OpenCL though). When applying multiple materials, both my article and also the code in the Wiki rely on duplicating some triangles and I was thinking this could be done in the geometry shader. It can probably also calculate the alpha values as required. This would mean that the vertices which are stored in memory are quite small but get inflated by the geometry shader if the additional material/alpha information is needed. But I don't know if it's possible yet.

There is GS support for mobile hardware with everything over SGX(IPad, Iphone4, galaxy s/tab, etc..)but no GS support for all mobile software/OSes. I agree it is a total shame that only dx10 can support SM4 for now. This will hopefully be addressed soon for ES.


GS has been specifically introduced for rendering to multiple images and output mesh transforms to reusable buffers, but is mostly used in real life for exactly what you want to do. Access and modify the topology on the hardware rather than let rasterize exactly the same amount of polys coming from the vertex pipe.
I am sure you will find something. You need to figure out a good data structure.

Interesting, I didn't know that. So the hardware is already available but we can't use it. Hopefully this gets addressed by an OpenGL ES extension at some point...

The situation is likely locking out both IOS and android from GS, so I guess we can decently expect something soon.
I am not 100% sure but once ES ready, your possible (OpenGL 3.2) GS efforts will hopefully run at least on SGX gpu's.

Hi David and DJDD,

It was just to let know that I found an open source implementation of DMC's.

I am not sure about its efficiency but builded / tested their example(just tested by reconstructing - with ssd_recon - from their example point cloud provided in ply format and checked the ply mesh result in meshlab) here and it apparently rocks.
Careful because from what I see of the generated surface, it looks like they are not handling sliver elimination as described in Schaefer and Warren's paper, but modifying their source to do so should be possible.
They provide an according octree proposal in their solution.

Their licence look pretty ok too / not restrictive.

Looks like an interesting find. With DJDD's original post and also this one we now have links to both Dual Contouring and Dual Marching Cubes implementations for anyone who wants to try and implement them into PolyVox.

The license appears to be the New BSD License. I must say, I'm not exactly sure about the implications of including code with this license in PolyVox. If someone does make use of it then it might be worth asking the authors to relicense it under the zlib license (they are pretty similar). Otherwise we've talked in the past about having a seperate 'PolyVoxExtras' library for code which we can't include directly for various reasons.