vilya

Regarding open source drivers: Intel's Vulkan driver for Linux is open source. This page has details:

https://01.org/linuxgraphics/blogs/jekstrand/2016/open-sourc...

There's also an older open source driver developed by LunarG and shipped as part of the Vulkan SDK. It's for Intel GPUs too and is deprecated now.

I've never been able to get Assimp to successfully load anything other than .obj format models, despite what they claim in their docs. Last time I tried was about two years ago though, so maybe it's improved since then.

They do seem to have some Alembic support: they ship the libraries as part of the engine download, in their 3rdParty folder.

Alembic is an open 3D file format supported by pretty much all the major 3D modellers these days - including Blender, Modo, Houdini, Cinema4D and plenty of others besides the Autodesk tools.

Profile Guided Optimisation is the search term you're looking for. For one example: GCC does it (you may need to use gprof as well, can't really remember).

I still have a lingering distrust of Apple Maps, thanks to its disastrous launch. It's good to hear that it's getting better, because Google Maps - at least around London - seems to be getting worse. Some road names that used to be correct have been renamed incorrectly (e.g. Upper Richmond Road now shows up as South Circular Road) and others have changed to use a correct but uncommon name (the M25 - probably the busiest motorway in the whole of the UK! - shows up as "London Orbital Motorway", which is a name I don't think anyone has used for it since before Google even existed). I've reported all these of course, but as always there's no way of knowing if the bug report will ever be seen by a human. Maybe it's time to give Apple Maps a second chance.

I'm good! You? We should catch up for lunch sometime soon.

We'll hopefully be moving to compilers capable of supporting c++11 at work soon - maybe even in 2016 if we're lucky - but it'll probably be an even longer wait before we can start using c++11 features in our code. Still, a guy can dream...

You're right with your first point, but wrong with the second: a lot of new projects are still written in c++. Pretty much every non-indie video game, for example.

Using a framework is great as long as you only want to do the things it's designers planned for. As soon as you want to do something else, unless you're very lucky, it sucks. If you're using a library you generally have more options when you get into this situation.

As with anything, choose whatever's most appropriate for the job. But, as a single data point, every framework-based project I've worked on - literally every single one - has ended up in that situation.

Have you heard of PowerVR's raytracing chip? http://www.imgtec.com/powervr/raytracing.asp

The useful thing about a standard library is that it provides a common vocabulary for code, which is a great help for interoperability. For example: c++ doesn't have a 3D vector class in its standard library, so pretty much every 3D-related library invents its own & you end up having to write lots of useless glue code to convert from one to the other.

"Ah, but that might be a natural consequence of your design."

If a natural consequence of your design is a need to do something that fits the target environment so poorly, then it's a bad design & should be rethought. Software isn't a Platonic ideal, it needs to account for these things if it's to run well.

Ah I see I read the code too quickly - I didn't notice that not all of the functions were static. Thanks, I've learnt a bit about Swift by reading your code.

I don't understand why every result is stored into the same class-level variable. What's the aim behind that? It just seems like it would introduce unexpected behaviour without any gain, but I don't really know swift yet so maybe there's something I'm missing?

I admit I'm guilty of cherry picking my examples. :-) I wouldn't say it's bloat though, if it's something that most people end up having to re-implement. For what it's worth, I have my own little library of STL helpers too...

I think that sums up nicely why I don't particularly like the STL: it's that mindset. It's all well and good having a generic operation over an arbitrary collection of anything, but sometimes you just want to get stuff done. All that generality adds distance between your code and the problem you're trying to solve with it. It's obfuscation.

Edit: I hope that doesn't sound too combative - I'm just trying to explain myself, not saying that you're wrong.

Thanks, but I was just looking for a better way to convert a string to upper case, not an arbitrary collection of chars. I've never yet needed to upper-case anything other than a string and unless I get the urge to write a text editor (unlikely!) I doubt I ever will.

And yes it's trivial to wrap this in a function, but in my opinion it really shouldn't be necessary. It's such a simple and common-place operation, why isn't it in the standard library?

How do you define portable? If you mean the same code compiling and running out-of-the-box on Windows, Mac and Linux then actually my experience with Qt has been very positive in that regard. Those are the only platforms I develop for right now, so I can't ocmment about portability to e.g. iOS or Android (although I believe Qt ports are available for them).

Qt doesn't reuse the STL container types, it provides its own - which I find much more pleasant to work with than their STL counterparts. The STL puts a lot of effort into providing types of flexibility that are irrelevant or useless to me (e.g. allocators) and doesn't provide lots of simple things that I need every day (e.g. an indexOf method for std::vector, a contains method for std::set, or a toUpper/toLower method for std::string).

Sure, I was just giving my opinion. Take it for what it's worth... :-)

But if you'll indulge me for a moment, consider how you'd convert a string to uppercase using the STL vs using Qt. The STL code (taken from http://en.cppreference.com/w/cpp/algorithm/transform) looks like this:

   std::string tmp = s;
   std::transform(tmp.begin(), tmp.end(), tmp.begin(), std::ptr_fun<int, int>(std::toupper));
   return tmp;

Note the use of a temporary variable, because std::transform does a destructive update.

The equivalent Qt code looks like:

   return s.toUpper();

I'll let you draw your own conclusions.

By the way if there's a simpler way to do that using the STL, I'd love to hear about it.

The line that stood out to me was the quote from Stepanov, about C++ being the only language in which it was possible to implement the STL. To most people, that would have been a hint that perhaps the design of the STL was flawed...

I think the STL may have been the worst thing to have happened to C++. It could have been so much nicer if something like Qt (the core part) was adopted instead.

There's an article in Computer Graphics World about the procedural terrain and foliage generation in Pixar's Brave which apparently Inigo Quilez was behind:

http://www.cgw.com/Publications/CGW/2012/Volume-35-Issue-4-J...

It's a bit light on technical details, but pretty cool to read about.

How about WebCL? http://www.khronos.org/webcl/

I think that's more to do with closed source software usually being published under the name of a company, rather than the individuals behind it; so there's less opportunity for a closed-source developer to become famous.

There's also Orc: http://orc.csres.utexas.edu/

Regarding "not taking off": this model is actually very common in the vfx industry. Most high-end content creation tools (Nuke, Maya, Houdini, etc) have a node graph which you assemble in the tool, where the nodes define processing operations & are usually plugins written in c++ or something like it. It's not a language per-se and the semantics are tightly bound to the individual tools rather than being independently specified, but the underlying idea is the same.

That comes from targetting Matlab users...

I got the impression that's what the Clay language [1] was aiming for, but progress on it seems to have stopped around a year ago.

[1] http://claylabs.com/clay/

Seems like a good idea, but the wrong way to achieve it. The right way, as I understand it, would be to write it up as an RFC and submit it to the IETF; and to contribute code for it to some of the popular web servers (apache, nginx, etc). The site doesn't make any mention of either of those things.

Edit: oops, I was wrong. There is an RFC and it's linked from http://www.451unavailable.org/what-is-error-451/

That's pretty much exactly the idea behind the "Aireal" project from Disney Research:

http://www.disneyresearch.com/project/aireal/

Thanks for the link - it was exactly the prompt I needed. I've just joined up, with a monthly donation.

This sounds like a similar idea to JetBrains' MPS: http://www.jetbrains.com/mps/

The idea with that was that you could provide a structured description of a mini-language and it would be sufficient to generate not only a parser, but also a syntax-highlighting IDE with smart code completion, debugging and other neat features. It looks like they're still developing it too, which is a nice surprise: back when I was still interested in it, it never seemed to have taken off.

GPU Gems is available online for free, courtesy of Nvidia: http://developer.nvidia.com/object/gpu_gems_home.html