Hi all,

With the latest version of Cubiquity now released, it's time to spend some more time on PolyVox :-) There are a variety of things which we'd like to work on but I think the first action point will be to transform PolyVox into a true header-only library.

PolyVox already consists mostly of header files because it is so heavily templatized. There are a few .cpp files containing things like the Marching Cubes tables but recent developments (e.g. C++11) should make it possible to eliminate these. As a result it will be much easier to use PolyVox in projects because there will be no build process required - just drop the headers into place and include them.

There are some downsides to being header-only, such as compile times and the difficulty in writing bindings to other languages. But we already have these issues, and to a large extent they are expected due to PolyVox making so much use of templates. So I'm not sure we'll really lose anything here.

This change only affects the core library - the examples and tests will continue to use Qt and OpenGL, and will continue to be built using CMake. But if you just want to use PolyVox and by-pass these extras it will be much easier to do so.

So, are there any thoughts on this? Any objections or reasons why it might be a bad idea? I'm not yet certain it's actually possible, but I'll take a good crack at it over the next week or so.

Nice to learn about this. I have no idea how Boost manages to go header-only for some things but... not a problem for me I already ended up dropping all CPPs into my project, and now, because I am refactoring the 0.2.1's Marching Cubes extractor, I thing that merging with Development branch of Polyvox will no longer be possible for me.

I have another question: Will polyvox's Marching Cubes extractor provide better mesh suitable for splatting? I still use old 3d-texture way of splatting but am in [again] research for how to texturize my terrain...

You should probably not try to merge at the moment at least, as lots might change in the coming weeks. PolyVox development tends to come in waves as we alternate it with work on Cubiquity.

I have no plans to change anything here, as I think the approach of extracting position, normal and then user-supplied data is working fairly well. Is there something else in particular you would want? The only thing I can imagine changing is to somehow separate different types of user-supplied data (rendering, physics, etc). But there are no real plans here - stuff like performance and threading are much more important.

I think that I will go in production with these 3d textures. Well, it's a voxel game after all

Ok guys, it looks like it worked. I've removed all the .cpp files in PolyVoxCore and moved the code into header files. All the examples (and Cubiquity) seem to work as before.

There's lots more tidying up to do. A lot of CMake stuff can now be reorganized as there was code for copying binaries, installing headers, and other stuff which isn't relevant anymore. I also notice that, now we don't have a PolyVoxCore target, the source files aren't showing up in Visual Studio any more. I'll have to look for a way around that. Perhaps I can define a target which doesn't actually get built.

There'll be more reorganization as well. You may have noticed we have a rather strange directory structure (.../PolyVoxCore/include/PolyVoxCore/...) which was the result of at one point wanting to allow example code to build against various precompiled SDK configurations. We won't be making an SDK now it's header only so this isn't needed any more. Also we never put anything in 'PolyVoxUtil', so I think we'll get rid of it and 'PolyVoxCore' will just become 'PolyVox'.

There'll be some changes needed in client code but probably just updating a couple of include paths, and removing PolyVoxCore from your linker settings. Overall it should be easier and simpler than it was before.

Anyway, it's not merged in yet, lots more experimenting to do.

Thinking about the CMake scripts some more, there's no reason for us to actually prevent a 'make install' type procedure. I mean, one of the nice fatures of a header only library is that you can just drop the headers into your project, but if you wanted to just install it once system-wide then that should be ok to. So perhaps I won't be quite so aggressive in cutting down the CMake scripts.

Right, just thinking out loud here in case someone objects (particularly Matt, as he knows the CMake stuff a ittle better). Matt, we also have this 'PolyVoxConfig.cmake.in' - is this for allowing people to find PolyVox with CMake once it is installed on their machine? I think this is still useful so I'll leave it intact. Though it makes some references to the PolyVoxCore_LIBRARY_INSTALL_DIRS which may no longer be relevant?

Generally speaking I'm still testing on Linux to make sure everything still compiles. But some of this installation stuff I'm not so familiar with so it may need tweaking afterwards. In general the CMake code will be getting simpler though.

All done! I've merged the changes into the develop branch and PolyVox is now header-only

As far as I know, there are only two changes you will need to make to your source when you upgrade (assuming you are coming from the old develop branch, not from master):

1. Replace all instances of '#include "PolyVoxCore/..."' with '#include "PolyVox/..."' where '...' is some PolyVox header. This is because we no longer have PolyVoxCore and PolyVoxUtil - everything is just PolyVox. Make sure the PolyVox include folder is in your include path, obviously.
   
2. Replace Region::MaxRegion and Region::InvertedRegion with calls to Region::MaxRegion() and Region::InvertedRegion() respectively. I doubt if this affects anyone to be honest, but I couldn't manage to declare these constant static members in the header file so I made them member functions instead.

If you have any problems with the new setup then do let us know!

Quoting in catch-up mode...

I agree. There can perhaps be some discussion of what we should be installing but at least it should be the headers.

Correct. The PolyVoxConfig.cmake file is installed to a standard location so that even if PolyVox itself is installed somewhere weird, users can still find it through the standard find_package magic.

I will have a look at this soon to check thorough to make sure all the old stuff still makes sense. I expect that there's quite a lot we can remove or reduce.

Overall this look great. It definitely seems to much cleaner overall and will make everyone's life easier. Along with the OpenGL 3 and Qt 5 updates you've made, it's all seeming much more modern and neat.

I'll have a look over the CMake Qt5 stuff as well as I think some of the ways I originally implemented it are non-optimal and there can be a lot of cleanup.

I have noticed that due to some CMake confusion (possibly due to a merge conflict), the DecodeOnGPU example is not being built and as a result you missed it when converting the code. You need to add "ADD_SUBDIRECTORY(examples/DecodeOnGPU)" to the list in the main CMakeLists.txt file and not the one in the examples directory (as that one currently does nothing -- though I am planning on changing that). I would fix the code myself but you were working on this more recently and so probably have a better idea about how it should work.

_________________
Matt Williams
Linux/CMake guy

If it's easy to install the tests and examples then it wouldn't hurt (as it shows that things work properly) but it's not essential. If they were being installed before then it's probably just a case of uncommenting the right lines.



Ok, well I didn't update this file so that probably needs doing, but the changes shouldn't be too great



You did the work here, I just merged the changes



I think we also have the option of updating to CMake 3 if it helps. I'm not saying we should, but it wouldn't affect users so much now the library is header only.

Also, I plan to split up the example code a bit more to make a simple Qt5 OpenGL demo framework which we can use elsewhere, particularly with Cubiquity and with the experimental voxel renderer I was working on over Christmas.



Yep, I'll get this fixed.