Live data from Hacker News

Native visionOS platform support

github.com

131–140 of 346 posts

Re: Native visionOS platform support

#131

This is surprising. From everything I've been hearing in the media, I got the impression Apple had mostly given up on their XR products and will keep them on life-support until the technology is ready for mass consumption.

The media loves to spin Apple things as failures right up until the point when they’re a success. See coverage of iPhone, Apple Pay, iPad, etc. Even “Apple faithful” media like MacRumors.com will be measured but pessimistic about Apple’s new efforts because negativity drives clicks more than positivity across the board.

Re: Native visionOS platform support

#132

Earlier quoted context omitted.

If they did the work, what’s wrong with that?

Maintainers have to review the PR, answer Apple's "Open Questions", and support their users who want to build with the new functionality long term. Laughably, it looks like the PR didn't even compile...[1] > When you try and bundle, it will fail. The library paths are incorrect. [1]: https://github.com/godotengine/godot/pull/105628#pullrequest...

Apple really are not sending their finest.

Re: Native visionOS platform support

#133
post #17

Earlier quoted context omitted.

And since Apple is here, please help adding support for Apple TV. Apple and Android TV support sometimes makes the difference when choosing an engine.

Apple TV for games is super niche, with very little market share in the big scheme of things. Even when it comes to TV, Apple realized they had to create an Apple TV+ app for other platforms to extend the reach of their investment in shows/movies beyond their own hardware.

> Apple TV for games is super niche

Order(s) of magnitude less niche than Apple Vision.

Re: Native visionOS platform support

#134
post #43

Earlier quoted context omitted.

OpenGL is quite dated for VR/AR. In the Apple ecosystem they supported OpenGL 4.1 for quite some time before moving to Metal, which was announced 2 years before Vulkan. If you spent the time developing an in house graphics API since open standards weren’t moving forward, why would you rewrite everything a second time just a few years later? Shouldn’t you expect to get a decade or two out of your existing API and only…

> why would you rewrite everything a second time just a few years later? Why is this the dichotomy? Why not support both?

Money

Re: Native visionOS platform support

#135

Earlier quoted context omitted.

There are however some games which thrive on apple tv. The virtual cycling game zwift is probably one of the most important apple tv games, it's the recommended system to get the game running on the cheap. So, if you're making an app that benefits from a big screen and your customers are willing to buy a cheap dedicated device to easily use your app on a big screen, supporting apple tv might be a very sensible choice…

> if you're making an app that benefits from a big screen and your customers are willing to buy a cheap dedicated device to easily use your app on a big screen, supporting apple tv might be a very sensible choice. Compared to other HDMI-connected devices (e.g. Google Streamer fka ChromeCast, Amazon FireTV, Roku) or major TV platforms like Android TV or Samsung and LG, the market share that Apple TV commands is dwarfe…

AppleTV is much more similar to a game console than the mentioned devices. It has a small set of powerful CPU/GPU/memory combos vs the menagerie of disparate and mostly much lower power hardware under the broad tent of “Google related tv platform” stuff.

Re: Native visionOS platform support

#136
post #114

Earlier quoted context omitted.

> cheap addition when you already have to support iOS and iPadOS devices. Presentation form factor and input modality is different on LRUD compared to touch, 10’ vs handheld. There’s an opportunity cost: it is better to improve the user experience on the vast majority of TV devices (eg Samsung or Android TV or Fire tv) than it is to support a tiny market share device like Apple TV that you now also need to keep up to…

arent all apps just expo react webui wrappers nowadays?

We are specifically talking about 3D games here.

Re: Native visionOS platform support

#137
post #106

Both users of visionOS are happy about this announcement.

This is sad but true.

I was so excited about the Vision and desperate to get one.

Finally my company has bought one for testing and I’m honestly not sure what to even use it for.

Maybe a big screen Mac? Is that it?

I think Apple has fallen into the same dead end they did with Apple TV: no controller = no games.

Both Apple TV and Vision Pro could have been filled with games from indie devs. But it’s impossible to play most games with a pinch or the worst TV control ever created.

Re: Native visionOS platform support

#139

Godot already supports VR via OpenXR. OpenXR is the Khronos-maintained industry standard for VR/AR devices—supported by SteamVR, Oculus, Vive, Pico, Windows Mixed Reality, Quest. Notably absent is visionOS / Vision Pro. I would insist Apple conforms to the industry standard. More scalable, open.

> I would insist Apple conforms to the industry standard

Insisting Apple conforms to anything is useless, unless you're in control of government regulations.

You can stick to Apple's ridiculous custom APIs, or you can release your software without Apple support. Luckily, VisionOS seems to have gone the way of the Apple Pippin, so I don't think many people will care much about Apple's headsets not being supported by VR games. Apple certainly doesn't.

If Godot wants VisionOS support, this is probably the way to do it. The question then becomes: is an alteration this heavy worth the maintenance cost, especially for hardware that expensive and uncommon? You don't want to end up in a situation where the one guy with such a headset falls ill and suddenly you can't test your engine anymore without spending a couple thousand on new hardware.

Re: Native visionOS platform support

#140

Earlier quoted context omitted.

I don’t know that that is relevant. In this context, what’s relevant is OpenXR. Apple’s visionOS does not natively support OpenXR, the open standard developed by the Khronos Group for cross-platform AR/VR development. Apple has not indicated any plans to adopt OpenXR, choosing instead to promote its proprietary frameworks such as ARKit, RealityKit, and PolySpatial for spatial computing on the Vision Pro. What Apple i…

You probably didn't see the comment I was replying to. I should have quoted: > Hell would freeze over before Apple conformed and contributed to an existing open standard. This is patently false given the fact I posted.

I don't see how you can say it's patently false. Do you have any proof that hell didn't freeze over before then?
Post reply on HN