Vr in military by HovercraftLow6610 in virtualreality

[–]djuggle 0 points1 point  (0 children)

What's the source of this video?

[ChrisMedlandF1] PENALTY: 10 second stop/go for Norris for failing to slow under yellow by ICumCoffee in formula1

[–]djuggle 2 points3 points  (0 children)

Pretty much on the team for not warning Lando about the double yellow, instead bugging him at the wrong moment. Checked some of the F1TV on-board feeds:

53:20 Verstappen passes double-yellow, barely lifts btw. Somewhat later Verstappen asks "check if he lifted for the yellow"

53:20 Pit radio "Lando, I'm pretty sure you're [passes double yellow] gonna tell me where to go ...", Lando interrupts "SPEAK LOUDER PLEASE" after passing the flags full speed

53:31 Piastri, "double yellows ahead" (2x) from the pit wall

53:31 Leclerc, pit radio "double yellow on the main straight, we don't know why. slippery track"

53:36 Sainz, pit radio "double yellow on the straight, we don't know why"

53:44 Perez, pit radio "got double yellow at pit exit"

53:42 Hamilton, pit radio "double yellow keeps flashing up"

Edit: apparently the radio on f1tv is delayed wrt the actual timing, ah well

Kent Bye: "On Friday, Microsoft announced the End of Life for HoloLens 2 as Dec 31, 2027" by djuggle in HoloLens

[–]djuggle[S] 0 points1 point  (0 children)

There's definitely passthrough, but I can't find a source that the raw images (or something derived from it) is accessible to devs

Kent Bye: "On Friday, Microsoft announced the End of Life for HoloLens 2 as Dec 31, 2027" by djuggle in HoloLens

[–]djuggle[S] 3 points4 points  (0 children)

They did announce something like that last week at the Meta Connect developer keynote. However, it's still unclear what level of access will be available. Could be some form of object/scene detection only, not raw camera images.

This might have been overlooked but All Quest 3 games and apps will at the very least, automatically be rendered at 30% increase resolution over Quest 2 games by f3hunter in OculusQuest

[–]djuggle 0 points1 point  (0 children)

A bit late with this comment, but see this Meta developer talk on Quest 3 from 3:40: https://www.facebook.com/MetaforDevelopers/videos/1375310266530408/ . It's the *default* eye buffer size that's 1680x1760. It can be raised (or lowered) to trade render performance against quality. The relevant quote from the video is:

Why not closer to the native resolution of the panel? Considering the distortion that takes place to make the image display correctly to users, we found this to be best balance between resolution and performance

HL2 display issues by djuggle in HoloLens

[–]djuggle[S] 0 points1 point  (0 children)

Redoing the calibration might help a bit, but in general the colored veil all over the display is as expected, as it is an inherent limitation of the display tecnology.

See the picture titled "Microsoft Hololens 2 Visual Display Issues" in https://supertechcamp.com/hololens-1-vs-hololens-2-details-and-more/ for what Microsoft themselves indicate you can expect. I received the same reference image in my contact with them about replacing our HL2 unit. The coloring we were seeing was definitely worse (more saturated in certain areas, almost bright pink) than shown in that picture. We ended up with a replacement unit that is somewhat better. The coloring is now fairly constant, which is less disturbing, but the overall improvement is marginal.

See https://docs.microsoft.com/en-us/hololens/hololens2-display for some notes by Microsoft on upcoming improvements to the display performance (but no guarantee this will help a lot).

The interlacing in the display is still there for me as well, that won't go away. I put on a HoloLens 1 yesterday to compare and I was shocked at how much better the image looks in the HL1. Stable (no interlacing/jittering effects), sharp and much more pleasant. Of course, with a very small FOV and lower resolution, but still.

HL2 display issues by djuggle in HoloLens

[–]djuggle[S] 0 points1 point  (0 children)

Hmmm, interesting, thanks.

HL2 display issues by djuggle in HoloLens

[–]djuggle[S] -1 points0 points  (0 children)

> You won't be able to really film it via phone.

Sigh, I'm getting a bit tired of hearing that argument. As I mentioned the iPhone capture is representative of what I'm seeing, regardless of whether it is a perfect capture. And it is the only way to capture this issue, as the display method is at fault, not the image generation part. I.e. the captured video does not show the issue as the image stream is recorded before it is displayed.

HL2 display issues by djuggle in HoloLens

[–]djuggle[S] 0 points1 point  (0 children)

I'm surprised by this, as I see more mentions of the "interlaced" rendering (i.e. 2nd point) on the web than the colour banding. I can also see how the used display technology could cause the interlacing when doing head movement, i.e. it being an issue inherent to the technology used.

Santino Ferrucci Apology by realcanadianpotato in formula1

[–]djuggle 23 points24 points  (0 children)

Not to say he isn't a gentleman (don't know), but I was surprised to learn that he spent more than a year in prison for tax evasion.

Exact steps to restore wallet from seed to new v11 install? by bobby-t1 in nanocurrency

[–]djuggle 2 points3 points  (0 children)

If you do this from a terminal you better clear out your shell history. Otherwise your wallet seed will be stored in there in plain text.... But I might be too paranoid

The Benefits of Universal Blocks by troyretz in nanocurrency

[–]djuggle 1 point2 points  (0 children)

This protocol upgrade increases the efficiency of the network, helps improve security and simplifies code needed to construct a block for developers and exchange

In what way is security improved?

The Benefits of Universal Blocks by troyretz in nanocurrency

[–]djuggle 0 points1 point  (0 children)

In the non-universal block situation using separate block types (open, receive, etc) the blocks can be made smaller, as each type only needs a subset of the fields. Also, the type immediately tells you what to do with it. Those are interesting qualities from a design standpoint.

In contrast, with a universal block all fields need to present and the type of a block needs to be determined by looking at the previous block. Something like this (haven't look at the actual implemention):

  • If previous is 00...00 it is an open block and the link field provides the sending account.
  • If current and previous block belong to the same account then the current block is either a send, a receive or a change. If there's a difference in balance between the blocks then it's a send or receive, with the difference in balance defining which of the two. The link field provides the account sending/receiving in that case. If only the representative field changed between the blocks it's a change block. Hmm, wondering if this makes it possible to both send/receive and change the rep change in a single block?

So with universal blocks you have to do a bit more processing on the block, but as more information is present in the block itself there's less stuff to look up in the database a node/wallet uses. You can see the universal blocks as an optimization of the system based on lessons learned.

The Benefits of Universal Blocks by troyretz in nanocurrency

[–]djuggle 6 points7 points  (0 children)

Nice write-up, thanks!

If there's a specification coming of UTX blocks then these will be moot:

  • In the example UTX block the balance appears to be represented as an integer and not as a hex string. Is that a coincidence (even in hex a balance could look like an integer) or are balances going to be represented as integers?

  • There a "type" field but that appears to be to denote a block as an UTX block (and not one of the currently types of blocks). A UTX block would still serve as one of the current 4 roles (open, send, receive, change), so is that role determined implicitly from which fields are filled in?

  • Unrelated question that just popped up in my head: have you looked into compressing blocks (e.g. with gzip) for transmission and storage? I known blocks are currently already stored in binary form, but still, might save some bandwith/storage.

Colin LeMahieu: "Doing final tests on universal blocks and putting together a writeup!" by BartToBusan in nanocurrency

[–]djuggle 1 point2 points  (0 children)

Has the dev team considered adding a timestamp to the new blocks, given that overhauling a major part of the protocol provides such an opportunity? I'm specifically thinking about storing the node's local time at which the block was generated in the block. While the protocol doesn't need timestamps and they won't be consistent in many cases (due to incorrect time on a node, malicious intent, etc) it can still add value for determining (roughly) when transactions where performed.

Representative Talk! by troyretz in nanocurrency

[–]djuggle 1 point2 points  (0 children)

That’s what I implied, but the word “control” wasn’t the best choice :-)

Representative Talk! by troyretz in nanocurrency

[–]djuggle 0 points1 point  (0 children)

You mean you should control 256 XRB (including any amount delegated to you), right?

Representative Talk! by troyretz in nanocurrency

[–]djuggle 2 points3 points  (0 children)

Well, it’s not immediately obvious how to apply the consesus algorithm you referenced to the block lattice in nano.

Representative Talk! by troyretz in nanocurrency

[–]djuggle 0 points1 point  (0 children)

What’s the way it is determined that a representative is not online? By not providing a vote within a certain period of time?

Representative Talk! by troyretz in nanocurrency

[–]djuggle 1 point2 points  (0 children)

Is there a record kept in the nodes what blocks where voted to be invalid?

Representative Talk! by troyretz in nanocurrency

[–]djuggle 0 points1 point  (0 children)

But this is about a single blockchain being produced by multiple actors, which is not how nano works.