Language suggestions for me to port OpenVDB to

[Joshua Olson]

As someone who wants to make an advanced 3D game, I am interested in implementing something like OpenVDB in a more modern programming language. In order of consideration:

Swift (new but may run on Windows someday)
Julia (immature but some Intel efforts to compile to C)
Haxe (C++ backend isn't the best but can compile for Unity)
Nim (immature and tiny dev team but targets C++, C, Objective-C, and JS)

Would ports to any of these interest anybody?

Or Go, Rust... please no.

[edward]

I'm not very familiar with those languages you list but it seems that you would want something that aims to generate highly performant code. Personally, Nim looks good from what little I've read.

-Edward

[Joshua Olson]

Until Nim(rod) matures and stops claiming to be elegant, I think Haxe will offer the most benefits. I would welcome suggestions for other C++ or faster languages in the meantime, especially if they are transpiled and have a decent job market presence.

[Joshua Olson]

However, I will probably use Haxe (or Go since it has its own assembler and IDEs) with Intel's Embree instead, as per a sparse voxel raytracer's advice and this thread.

[jono]

In an academic sense, I think seeing an implementation of OpenVDB in a language other than C++ would be interesting. However, it's hardly a practical choice. OpenVDB is very performance-critical and you are extremely unlikely to beat the current implementation - and if you are indeed writing an advanced 3d game with real-time ray-tracing of volumes, you are probably writing lots of C/C++ anyway for performance reasons. 

Rather than implementing OpenVDB in something like Haxe, you probably just want to expose the current implementation to it.

--jono

 

[Joshua Olson]

Is it trivial to compile OpenVDB for Windows? Whether or not an independent implentation would match this one in performance, I'm fine with merely competitive if it broadens platform ability and encourages adoption by open source projects.

[Joshua Olson]

Nevermind with Embree, by the way. They recommend an Intel hack of C called ISPC and/or their proprietary compiler, have a bunch of readme typos, don't seem to understand that C derivatives need to die, can't settle on a BVH implementation that's portable, and tout the API's flexibility over contributing.

[Joshua Olson]

And my last post in this thread I PROMISE. I chose Nim over Haxe as summarized here (the responses were very helpful):

http://forum.nim-lang.org/t/1880