Live data from Hacker News

A browser plugin for Unity

blog.mozvr.com

31–40 of 40 posts

Re: A browser plugin for Unity

#31
post #26
post #17

Earlier quoted context omitted.

Ok, we've changed the title to what the article says. " Please use the original title, unless it is misleading or linkbait; don't editorialize. " https://news.ycombinator.com/newsguidelines.html

Whilst I understand the motivation behind this guideline, it seems to be applied with little regards for it's usefulness. Post titles need more context than the original article title because posting to HN strips out most of that original context.

agreed.

this policy applied as dogma does more harm than good on a frequent basis here. especially given the clear nature of this article where there's no debatable nuance.

Re: A browser plugin for Unity

#32
post #25

Earlier quoted context omitted.

We posted this: https://medium.com/@vrchat/security-update-web-panels-4699fa... It was severe enough that I ripped them out, though we were unable to find any evidence of the vulnerability in use.

But what was the vulnerability? It's not mentioned in the post.

It's been a few years, and I can't recall the specifics with certainty. It was a serious Chromium SVE that was unpatched in the middleware we were using.

Re: A browser plugin for Unity

#33
For anyone else looking to embed a modern browser in their Windows/macOS/Linux* C++ application, you might consider Dullahan: source: https://bitbucket.org/lindenlab/dullahan/src/master/ and example screenshot: https://bitbucket.org/lindenlab/dullahan/raw/master/docs/web...

I recently updated it to use Chromium 81 and would have updated it to the most recent version (84) if there weren't some non-trivial changes needed to make video/audio streaming work again.

It's what we use in Second Life and would welcome other users' comments to help improve it.

Re: A browser plugin for Unity

#34
I'm sure having a browser in game as a million uses but ...

Oculus Rift has in game browser built into their OS. In any game and any time I can pull up a browser in VR (or any desktop app). Pin a walkthru up. Pin up video chat with a friend.

It seems like browser in VR would be better served at an OS level. The OS could provide a way for the app to request VR be placed in the scene. Ideally it happens in a way the app can't look at the screen since a game shouldn't be able to look at the contents of your browser window.

Re: A browser plugin for Unity

#35
>As we do not have control over the binding of the texture and the Unity context, the current design for updating this texture uses a blit (copy) via Servo’s surfman-chains API

I don't think this is necessary. You should be able to make Texture objects that ref existing native textures in Unity and I've been able to use OES_EGL_image_external extensions to sample Android decoded video textures sampled from Unity shaders.

Its not the most widely available option but the perf is much better.

Re: A browser plugin for Unity

#36
post #19

I remember when this sort of functionality arrived in Second Life. It enabled a lot of easy 'shared experiences'. eg: Watching a live video stream of an event with people, or group presentations etc.

Per callumprentice, Second Life uses Dullahan[0].

[0]: https://bitbucket.org/lindenlab/dullahan/src/master/

Re: A browser plugin for Unity

#37
post #26
post #17

Earlier quoted context omitted.

Ok, we've changed the title to what the article says. " Please use the original title, unless it is misleading or linkbait; don't editorialize. " https://news.ycombinator.com/newsguidelines.html

Whilst I understand the motivation behind this guideline, it seems to be applied with little regards for it's usefulness. Post titles need more context than the original article title because posting to HN strips out most of that original context.

You probably have that perception because cases that you dislike stand out like sore thumbs, while all the other title edits escape notice. If you think about it, that pretty well guarantees the feeling "it seems to be applied with little regards for its usefulness"—because all the "useful" edits are by definition excluded.

You can use petercooper's title edit tracker to see some of them: https://hackernewstitles.netlify.app/. It doesn't show all of them, and it doesn't distinguish between edits by submitters and edits by mods. Probably we should just publish the official list—I feel like title editing is the most consistent and easily defensible thing we do.

Re: A browser plugin for Unity

#38
post #37
post #26

Earlier quoted context omitted.

Whilst I understand the motivation behind this guideline, it seems to be applied with little regards for it's usefulness. Post titles need more context than the original article title because posting to HN strips out most of that original context.

You probably have that perception because cases that you dislike stand out like sore thumbs, while all the other title edits escape notice. If you think about it, that pretty well guarantees the feeling "it seems to be applied with little regards for its usefulness"—because all the "useful" edits are by definition excluded. You can use petercooper's title edit tracker to see some of them: https://hackernewstitles.net…

Thanks for the reply.

What do you feel would be the harm if the policy was modified to

> "Please use the original title, unless it is misleading or linkbait or lacks sufficient context; don't editorialize."

It just seems like there's frequently times when the original title is completely baffling out of situ.

Re: A browser plugin for Unity

#39
post #35

>As we do not have control over the binding of the texture and the Unity context, the current design for updating this texture uses a blit (copy) via Servo’s surfman-chains API I don't think this is necessary. You should be able to make Texture objects that ref existing native textures in Unity and I've been able to use OES_EGL_image_external extensions to sample Android decoded video textures sampled from Unity shad…

The issue is not access to an external texture, it's access to an external texture on the right thread in the right GL context. We did look at writing a new backend for surfman to integrate directly, but it's a bit of work and not at all cross-platform, so this was not a goal of the project at this stage. I'd like to find a way to avoid the blit though, so I'm continuing to experiment in this direction.

Re: A browser plugin for Unity

#40
post #38
post #37

Earlier quoted context omitted.

You probably have that perception because cases that you dislike stand out like sore thumbs, while all the other title edits escape notice. If you think about it, that pretty well guarantees the feeling "it seems to be applied with little regards for its usefulness"—because all the "useful" edits are by definition excluded. You can use petercooper's title edit tracker to see some of them: https://hackernewstitles.net…

Thanks for the reply. What do you feel would be the harm if the policy was modified to > "Please use the original title, unless it is misleading or linkbait or lacks sufficient context; don't editorialize." It just seems like there's frequently times when the original title is completely baffling out of situ.

The issue there is that sometimes a little bafflement is a good thing. Not too much, not too often, but enough to make readers work a little: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que.... It slows the mind down and makes it engage a bit in figuring-things-out mode, which is good for curiosity. I think it's a valuable mechanism for interrupting the internet reflex brain, with its rapid reactions to literally everything, that mostly governs us online.
Post reply on HN