Hathaway honestly blew me away the first time I saw it. One of the few movies I've watched 3-4 times now. It's exactly like you say, you can really _feel_ the weight and scale of mobile suits. It's honestly a fantastic start to this new era of UC.
Also lol @ kshatriya being called bell pepper. It's probably my favorite non-gundam mobile suit. I wish they'd make an MG kit for it despite how massive it is.
The original 0079 and then on (Zeta, ZZ, CCA) is the strongest and best way to understand Gundam, its themes, and its legacy. I'd also argue that Unicorn is a strong entry and puts a nice cap on that era of UC but typically people don't group it with the original 4.
Yeah, I work professionally as a gpu/graphics programmer and even I have trouble sometimes wrapping my head around some of the fancy shadertoy one-liners. Most of the stuff I work with is conceptually much more simple. The math if any is all generally really straightforward and derived from a handful of commonly used algorithms or PBR models. The more common work is performance tuning and scaling across multiple architectures/platforms. You might run into this stuff more if working with SDFs though.
To elaborate on this, Vulkan is an open _standard_ whose many implementations (user mode driver) may or may not be open source. Vulkan is just a header file, it's up to the various independent hardware vendors (IHVs) to implement it for their platform.
Also a small correction: Vulkan actually _does_ run Apple platforms (via Vulkan-to-Metal translation) using MoltenVK and the new KosmicKrisp driver, and it works quite well.
That too kinda depends on where you draw the line, the spec text is freely available but all development happens behind closed doors under strict NDA. From an outsiders perspective it doesn't feel very open to get completely stonewalled by Khronos on the status of a feature that debuted in DirectX or CUDA well over a year ago, they won't even confirm whether it's on their roadmap.
Sure, that's true and a pretty valid criticism of the system.
My definition of open is that Khronos doesn't restrict (as far as I know) what platforms Vulkan can be implemented on. The same cannot be said for DX12 or Metal.
DirectX 12 headers seem to now be published under the MIT license, so I don't see a real difference from a "who is allowed to implement it" perspective.
> Also a small correction: Vulkan actually _does_ run Apple platforms (via Vulkan-to-Metal translation) using MoltenVK and the new KosmicKrisp driver, and it works quite well.
I think, since they mentioned some enterprise deployments on Windows won't have Vulkan drivers preinstalled, that drivers merely being available is not enough for GP to count them as Vulkan "running". I think GP is only counting platforms (and circumstances) where you can reasonably expect Vulkan support to already be present.
Fair enough! In my humble opinion those specific circumstances outlined are a bit overly-pedantic for the target audience of this article and for general practical purposes. The average Windows user can reasonably expect that they'll be able to write a Vulkan application without much fuss ( until you run into the driver bugs of course ;) ).
It actually requires translation everywhere. GPUs have their own internal API that Vulkan, OpenGL, DirectX, etc. translate into. That is what drivers do.
That's being disingenuous. Of course a high level api has to be implemented in terms of hardware specifics, but you're implying, hopefully unintentionally, that that hardware interface is Metal, and it's not.
You can run Vulkan on Apple Silicon as natively as you can run Metal, even if some parts of it don't map too nicely to the hardware.
We only seriously say translate when we go from one high level API to another, just like we call some compilers transpilers even though literally everything is a compiler for something.
Not really! The difference is MoltenVK (and now KosmicKrisp) is officially supported and funded by Khronos itself.
DXVK, vkd3d on the other hand is propped up by dozens of passionate open-source contributors.
I'm drawing my lines not based on technicalities, but on the reality of the situation when it comes to how much the "controlling entity" of each API cares about supporting your platforms. And the fact is, Khronos has put time and money into supporting more platforms than Microsoft has.
There was a big interface rehaul for 2.80, and I suspect upcoming versions will continue to improve as interest in porting to platforms like iPad increases.
Learning the shortcuts is really the way to go though. Initially painful but 100x more productivity in the long run, and really the way Blender is meant to be used. Honestly just doing a single basic tutorial will have you learning all of them in no time.
Maybe obsolete in the sense of feature to price ratio (infinite in Blender's case), but Maya is still very much used for the sole reason that entire studio pipelines are likely built around it. Years of tools programmers and artist knowledge build-up don't go away just like that. Licensing costs are a drop in the bucket compared to all the other overhead. Of course that's mainly concerning big productions, there's obviously no reason hobbyists or indies should be using anything except Blender. I will say w.r.t to sculpting specifically ZBrush is still king mostly due to how its technology is fundamentally unique in its ability to easily handle huge poly counts. Blender is still not quite there in the high-fidelity regime.
I suspect in general "big companies" and the ecosystems they operate in are the main reason adoption (and subsequent investment and development) hasn't happened. The Microsoft Office suite is a good example, since many companies likely run the full Office + Teams + Outlook stack. It all "seamlessly" (not really lol) works together, and it's attractive to sell corporate solutions like that.
This has long been the aspect I've struggled with, having spent some time implementing various temporal solutions in the past 2 years. We can try and pull out all sorts of classic metrics like SSIM, but the truth is a lot of these effects are really hard to objectively evaluate using some sort of metric. Moreover the same technique can have vastly different outcomes depending on the content, and user perception is subjective as well. Many days were spent thinking I had solved a visual issue, only for another edge case to come up under specific conditions. Many of these techniques are fairly difficult to reason about from first-principles and adding ML into the mix only makes that harder.
