Hi!

PolyVox technology is exactly what I was looking for.
But java is another perfect way to create Apps.

I am looking for something may be like ODE (Open Dynamics Engine) that have a compiled library with java binds, so we can use it in java (that libs can be compiled on linux, windows and MacOSX afaik).

So, in the same way above, is there any java PolyVox around that I couldnt find?

Hi, glad to here of your interest! There are currently no language bindings for PolyVox, though I would be very interested in seeing some created as it expands the potential user base. So if you want to do it I'll help where I can

If I ever do it myself, I'll use something like SWIG as this would open it up to other languages besides Java.

Just as a note, I'm planning on starting work on generating SWIG bindings for PolyVox now. I'll probably aim for Java, C# and Python bindings to be done before a 1.0 release. Don't expect anything too fancy at first as this will be my first forray into SWIGing a whole C++ project.

As soon as there is anything testable in SVN I'll post a message on this forum to see if anyone wants to test but, until then, consider any SWIG/binding stuff in SVN untested and experimental.

_________________
Matt Williams
Linux/CMake guy

Excellent! But just a heads up that joschka12 already had a look at this, and found that there were some classes which were not easily exposed due to a lack of default constructors. So there might be some tweaking to be done here. Also, the POLYVOX_API macro apparently caused SWIG to choke and I don't know what to do about this yet.

More generally, be aware that lots of refactoring changes are taking place. Entire classes and functions are being renamed and moved, so don't spent time typing that kind of stuff in. But I guess that is the idea of SWIG anyway.

Yes, I'm not going to be at all thorough yet. I'm simply going to be looking to see how it could all be bound and making sure the build/packaging system is in place to do it.

About the POLYVOX_API visibility support, that is a known problem in SWIG and it should be work aroundable.

As for default constructors, for those classes that need one and it doesn't break logic to have one I believe I can add the constructor manually to the SWIG proxy class. I'll have a go anyway

_________________
Matt Williams
Linux/CMake guy

Hey Matt, you may have noticed the PolyVoxImpl folder? I'm trying to hide in this folder all of the classes that are part of the implementation rather than the interface. You'll see classes like BlockData will move from the core to this PolyVoxImpl folder. It should make people realise that they are not suposed to use them directly, and it also means you won't need to wrap these ones with SWIG. I'll put them in their owen namespace too.

Ah, I was wondering what that was for. That makes things a little bit easier. I guess I should exclude that from folder Doxygen too?

_________________
Matt Williams
Linux/CMake guy

You're right, there's no need to include it in Doxygen.

Also, I notice you have wrapped PolyVoxCStdInt.h - I have now removed this file. Basically it was just providing fixed size integer types but it makes more sense to try and use the ones from C++0x/boost. So these are now defined in the CPlusPlusZeroXSupport.h file in PolyVoxImpl.

Let me know if these is a problem. For example, for the purposes of wrapping it might be best to have them in a seperate file (like they were before...) and it might be better to have them in the PolyVoxCore folder, rather than the PolyVox Ipl folder (like they were before!). Sorry if I've broken something here... Let me know and I will fix it.

I know all this refactoring makes it hard for you!

It's alright, you haven't broken anything (too much ). The only reason I was wrapping them is so that when I create instantiations of templates, it can resolve the names. It's all a work in progress so it's all changing still for me anyway.

_________________
Matt Williams
Linux/CMake guy