Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

Polyvox API (one more about SWIG)
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=14&t=276		 Page 1 of 2
Author:  shd [ Thu Oct 13, 2011 4:43 pm ]
Post subject:  Polyvox API (one more about SWIG)
Because of there are enough people that are using PolyVox with different languages - probably via SWIG - and it would make my D code cleaner (i'm so selfish :))... I'm bringing this topic on.

How about:
a) modifying current API to be less templated
b) making additional C-API for polyvox?

It would stop all this problems with interfacing, make library usable from like 20 languages, and stop my eyes bleed because of not seeing things like CubicSurfaceExtractorWithNormalsSimpleVolumeMaterialDensityPair44 :D

EDIT: changed to another real-life unwinded template
Author:  beyzend [ Thu Oct 13, 2011 6:05 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
D 8-) (deal with it?)
Author:  shd [ Thu Oct 13, 2011 6:14 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
http://d-programming-language.org/
:)
Author:  milliams [ Thu Oct 13, 2011 8:32 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
Regardless of whether you're using D or not ( :)), David and I have talked before about the best way to provide language bindings to PolyVox and indeed creating a C-style wrapper around all the functionality seemed to be one of the simplest ways. Unfortunately it hasn't happened yet since it could be a lot of work and maintenance as it is very easy to let it stop working when API changes are made to PolyVox.

There is little chance that PolyVox will be made less templated (at least in the areas you're talking about) since templates are essentially required to be able to give the kind of flexibility we have (at least while keeping the code sane and maintainable). To provide that same flexibility (or at least the same range of options) in any wrapper or C-interface necessarily requires those long, unwrapped class names you mentioned. Each user of the wrapper probably only uses one volume type so you can always typedef it away at your end.

In the world of wrapping SWIG is pretty much the only one-to-many wrapper generator out there and unfortunately it's not looking like the healthiest project out there and it still struggles with complex templates. I'm still waiting for someone to come along and write a wrapper generator with a proper C++ parser like clang but I'm not hearing much news on this front.

Providing usable wrappers is definitely something we want to provide but since neither David nor I are currently using them we appreciate use-cases and feature requests like this.
Author:  David Williams [ Thu Oct 13, 2011 9:44 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
I agree with the general sentiment of your post, in that PolyVox is a little complex to use. Templates can be confusing and ugly and they do cause issues for SWIG. However, they are also very powerful and bring a lot of flexibity.

shd wrote:
a) modifying current API to be less templated


Not really, I think use of templates is generally very beneficial. Actually, I think the use of template template parameters in the surface extractors (where you have to pass a volume type and a voxel type) might have gone too far, and I will look at allowing the voxel type to be retrieved from the volume instead. But apart from that I'm happy with them.

shd wrote:
b) making additional C-API for polyvox?


Would a simplified C++ wrapper be sufficient instead? A simplified C++ wrapper is easier to create because it's basically just some typedefs and simple wrappers for the most important classes.

But as milliams says, the long class names result from us trying to expose everything, and needing a unique name for each of the different classes. I think a simpified wrapper will only be useful if it exposes a reduced feature set. Perhaps we choose one volume type (SimpleVolume) and one voxel type (MaterialDensityPair88) and just expose this as a class called 'Volume'. Then simple 'extractSmoothSurface' and 'extractCubicSurface' functions to avoid messing around with the surface extractor classes.

I am quite in favour of this, but I don't want to write the SWIG part. If someone else can volenteer then great, but even without that it would be useful for less experienced C++ programmers. I will add it to the todo list...
Author:  David Williams [ Thu Oct 13, 2011 10:49 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
Ok, I was feeling inspired so I tried making a simplified C++ wrapper. In principle it does work, and it makes the example code simpler and more readable. So I like this idea so far.

But I don't yet know what to do about the seperation of code. I could just add the new simplified classes to the PolyVox namespace, but then the new Volume class is in the same library as SimpleVolume, LargeVolume etc whereas it's actually quite different. And extractCubicSurface coexists with the CubicSurfaceExtractor, which is confusing.

I currently have three ideas:

1) Make a new PolyVoxBasic namespace for the simplified interface. Does this mean the existing classes should be moved to PolyVoxAdvanced, or just stay in PolyVox? The Region class will be needed by both simplified and normal code so where should this go? Should a user of PolyVoxBasic also have to include the normal/advanced namespace to access Region?

2) Maybe it should be a seperate library. But this doesn't actually solve the previous question, and is making the user build another library counter to the aim of making it simpler?

3) Perhaps some header/#define magic? Like you have to #define POLYVOX_BASIC or POLYVOX_ADVANCED and this controls what gets exposed. Both would be built into the library, and perhaps you can define both if you want. Region would be available if either was defined. Or maybe POLYVOX_BASIC is always defined, and POLYVOX_ADVANCED is required for more advanced functionality.

Ok, I'm really just brain storming now so sorry for rambling on...
Author:  shd [ Fri Oct 14, 2011 8:17 am ]
Post subject:  Re: Polyvox API (one more about SWIG)
David Williams wrote:
Not really, I think use of templates is generally very beneficial.

I like templates too, but because they're absolutely not portable between languages they are pain in the ass when it's the only way to use functionality.

David Williams wrote:
Would a simplified C++ wrapper be sufficient instead?

For me? sure! For most of people here too, so it might be the way.

David Williams wrote:
I think a simpified wrapper will only be useful if it exposes a reduced feature set. Perhaps we choose one volume type (SimpleVolume) and one voxel type (MaterialDensityPair88) and just expose this as a class called 'Volume'. Then simple 'extractSmoothSurface' and 'extractCubicSurface' functions to avoid messing around with the surface extractor classes.

Actually, I've been thinking about another way. Abandon the need of templates by making additional untyped methods/functions + some c-style callbacks. It won't look good, nor it won't be easy to use, but it would let to be flexible, and portable in the same time.

About method you proposed, I would have to use current API anyway, but for some people it might help.

David Williams wrote:
I am quite in favour of this, but I don't want to write the SWIG part. If someone else can volenteer then great, but even without that it would be useful for less experienced C++ programmers. I will add it to the todo list...

I don't really understand SWIG usage, maybe because i had no time to read complete manual. I just made it work for me, and i'm trying to keep away from it, so i cannot offer my help here :(

David Williams wrote:
1) Make a new PolyVoxBasic namespace for the simplified interface. Does this mean the existing classes should be moved to PolyVoxAdvanced, or just stay in PolyVox? The Region class will be needed by both simplified and normal code so where should this go? Should a user of PolyVoxBasic also have to include the normal/advanced namespace to access Region?

Definitely alternative ways shouldn't be mixed, so PolyVoxBasic would better for me. IMO, current namespace shouldn't be touched. I see nothing wrong in having PolyVox and PolyVoxBasic, which keeps using PolyVox.

And i think this solution would be best of three mentioned because of 2) just no, lol :) 3) i think it would add some mess.
Author:  David Williams [ Fri Oct 14, 2011 9:04 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
shd wrote:
Actually, I've been thinking about another way. Abandon the need of templates by making additional untyped methods/functions + some c-style callbacks. It won't look good, nor it won't be easy to use, but it would let to be flexible, and portable in the same time.


I must say, I don't kow exactly how to do this. I know you can use void* and c-functions to emulate generic behaviour but I'd have to do some research here, and I don't want to take that on at the moment. But we could add this in the future if anyone wants to look into it.

I guess the advantage would be that you could then interface with other languages without going through SWIG? Actually I quite like SWIG - it's a powerful tool but I just don't know much about it.

shd wrote:
About method you proposed, I would have to use current API anyway, but for some people it might help.


Can you elaborate on why? If it's the choice of volume or voxel types then I imagine this could be configured when compiling PolyVox. You would only get one type of volume and voxel type exposed though the simple interface, but at compile time you could choose which type it would be.

shd wrote:
Definitely alternative ways shouldn't be mixed, so PolyVoxBasic would better for me. IMO, current namespace shouldn't be touched. I see nothing wrong in having PolyVox and PolyVoxBasic, which keeps using PolyVox.

And i think this solution would be best of three mentioned because of 2) just no, lol :) 3) i think it would add some mess.


I've changed my mind... I don't think it's so bad if they sit side by side. They don't interfere with each other and it's just two ways of doing the same thing. So at least for now I'll just stick the typedefs and wrappers in the same namespace and in SimpleInterface.h. Let's see how it works out...
Author:  shd [ Sat Oct 15, 2011 1:48 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
David Williams wrote:
shd wrote:
About method you proposed, I would have to use current API anyway, but for some people it might help.


Can you elaborate on why? If it's the choice of volume or voxel types then I imagine this could be configured when compiling PolyVox. You would only get one type of volume and voxel type exposed though the simple interface, but at compile time you could choose which type it would be.

I got mixed feelings but great, it's good enough, thanks.
Author:  David Williams [ Sun Oct 16, 2011 9:43 pm ]
Post subject:  Re: Polyvox API (one more about SWIG)
Ok, I've added SimpleInterface.h/cpp to Git. They just contain a couple of typedefs and wrapper functions to simplify C++ code and make access by SWIG easier. I've updated the BasicExample to use this interface and it does appear more friendly. This SimpleInterface can be expanded in the future, but for anything complex users will be expected to use the real PolyVox API.

I'm not adding a C API at this point, basically because I don't want to take on the work on writing and maintaining it. There's just other priorities. Maybe in the future though, if someone volunteers to do this.
Page 1 of 2 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/