Most companies doing CGI work, both in games and movies, are quite open about their technical details. The whole industry relies on pooled research and development. While the actual code is typically confidential, publishing information serves multiple purposes for the work's publicity, the advancement of the field, the happiness of employees, and company prestige for recruiting people.
When LLMs predict the next token, they actually produce a distribution of the probability of each of the possible next tokens, and the sampler chooses one of them, and not necessarily the most likely one!
If instead you run LLM prediction and then encode the probability of the next token of the input text you want to encode (from the cumulative distribution, a number in [0, 1]) using arithmetic coding, you can run the same operation in reverse to achieve lossless compression.
The tricky part is ensuring that your LLM executes absolutely deterministically, because you need to make sure that the encoder and decoder have the same probability distribution map at each step.
Client-side frame extraction is far too slow to be usable for large volumes of data.
You want to precompute the contact sheets and serve them to users. You can encode them with VP9, mux to IVF format, and use the WebCodec API to decode them in the browser (2000B-3000B per 240x135 frame, so ~3MB/hour for a thumbnail every 4 seconds). Alternatively, you can make the contact sheets with JPEG, but there are dimension restrictions, reflow is slightly fiddly, and it doesn't exploit intra-frame compression.
I made a simple Python/Flask utility for lossless cutting that uses this to present a giant contact sheet to quickly select portions of a video to extract.
Actually, I started with the precomputing approach you mentioned. But I realized that for many users, setting up a backend to process videos or managing pre-generated assets is a huge barrier.
I purposely pivoted to 100% client-side extraction to achieve zero server load and a one-line integration. While it has limits with massive data, the 'plug-and-play' nature is the core value of VAM-Seek. I'd rather give people a tool they can use in 5 seconds than a high-performance system that requires 5 minutes of server config.
The "big" one is Llama3.3-70b on the cloud, right now. On GroqCloud in fact, but we have a cloud router that gives us several backups if Groq abandoned us.
We use a ton of smaller models (embeddings, vibe checks, TTS, ASR, etc) and if we had enough scale we'll try to run those locally for users that have big enough GPUs.
(You mean the voxel grid visibility from 2014?! I'm sure I did at the time... but I left MC in 2020 so don't even remember my own algorithm right now)
Yeah it's extremely difficult right now, especially for a Windows game that can't have players install Pytorch and the Cuda Toolkit!
ONNX and DirectML seem sort of promising right now, but it's all super raw.
Even if that worked, local models are bottlenecked by VRAM and that's never been more expensive. And we need to fit 6gb of game in there as well.
Even if _that_ worked, we'd need to timeslice the compute inside the frame so that the game doesn't hang for 1 second.
And then we'd get to fight every driver in existence :)
Basically it's just not possible unless you have a full-time expert dedicated to this IMO. Maybe it'll change!
About the voxel visibility: yeah that was awesome, I remember :) Long story short MC is CPU-bound and the frustum clippings' CPU cost didn't get paid off by the reduced overdraw, so it wasn't worth it. Then a guy called Jonathan Hoof rewrote the entire thing to be separated in a 360° scan done on another thread when you changed chunk + a in-frustum walk that worked completely differently, and I don't remember the details but it did fix the ravine issue entirely!
GGML still runs on llama.cpp, and that still requires CUDA to be installed, unfortunately. I saw a PR for DirectML, but I'm not really holding my breath.
Yeah, I researched this and I absolutely missed this whole part. To my defense I looked into this in 2023 which is ages ago :)
Looks like local models are getting much more mature.
Yes, this is the major challenge with solving them with SAT. You can make your solver check and reject these horseless pockets (incrementally rejecting solutions with new clauses), which might be the easiest method, since you might need iteration for maximizing anyways (bare SAT doesn't do "maximize"). To correctly track the flood-fill flow from the horse, you generally need a constraint like reachable(x,y,t) = reachable(nx,ny,t-1) ^ walkable(x,y), and reachable(x,y,0)=is_horse_cell, which adds N^2 additional variables to each cell.
You can more precisely track flows and do maximization with ILP, but that often loses conflict-driven clause learning advantages.
The site uses Answer Set Programming with the Clingo engine to compute the optimal solutions for smaller grids. Maximizing grids like this is probably NP-hard.
Note that traditional SAT and SMT solvers are quite inefficient at computing flood-fills.
The ASP specifications it uses to compute optimal solutions are surprisingly short and readable, and look like:
#const budget=11.
horse(4,4).
cell(0,0).
boundary(0,0).
cell(0,1).
boundary(0,1).
% ...truncated for brevity...
cell(3,1).
water(3,1).
% ...
% Adjacent cells (4-way connectivity)
adj(R,C, R+1,C) :- cell(R,C), cell(R+1,C).
adj(R,C, R-1,C) :- cell(R,C), cell(R-1,C).
adj(R,C, R,C+1) :- cell(R,C), cell(R,C+1).
adj(R,C, R,C-1) :- cell(R,C), cell(R,C-1).
% Walkable = not water
walkable(R,C) :- cell(R,C), not water(R,C).
% Choice: place wall on any walkable cell except horse and cherries
{ wall(R,C) } :- walkable(R,C), not horse(R,C), not cherry(R,C).
% Budget constraint (native counting - no bit-blasting!)
:- #count { R,C : wall(R,C) } > budget.
% Reachability from horse (z = enclosed/reachable cells)
z(R,C) :- horse(R,C).
z(R2,C2) :- z(R1,C1), adj(R1,C1, R2,C2), walkable(R2,C2), not wall( R2,C2).
% Horse cannot reach boundary (would escape)
:- z(R,C), boundary(R,C).
% Maximize enclosed area (cherries worth +3 bonus = 4 total)
#maximize { 4,R,C : z(R,C), cherry(R,C) ; 1,R,C : z(R,C), not cherry( R,C) }.
% Only output wall positions
#show wall/2.
Im over 35 years of age. I have 15+ years of programming experience. And I generally consider myself as someone who has good breadth of tech in general. Yet, this is the first time in my life I've heard of ASP. And gosh. I was completely blown away by this as I read more about it and went through some examples (https://github.com/domoritz/clingo-wasm/blob/main/examples/e...)
Therefore, like a good little llm bitch that I have become recently, I straight away went to chatgpt/sonnet/gemini and asked them to compile me a list of more such "whatever this is known as". And holy cow!! This is a whole new world.
My ask to HN community: any good book recommendations related to "such stuff"? Not those research kinds as I don't have enough brain cells for it. But, a little easier and practical ones?
Things I don't like include that it's more dense, doesn't use clingo examples (mostly math-style examples so you kind of have to translate them in your head), and while the proofs of how grounding works are interesting, the explanations are kind of short and don't always have the intuition I want.
I still think this is the authoritative reference.
The "how to build your own ASP system" paper is a good breakdown of how to integrate ASP into other projects:
The pre-machine-learning formulations of AI focused on symbolic reasoning through the dual problems of search and logic. Many problems can be reduced to enumerating legal steps, and SAT/SMT/ASP and related systems can churn through those in a highly optimized and genetic manner.
Apple had soldered DDR ram for a long time that was no faster than any other laptop. It's only with the Apple Silicon M1 that it started being notably higher bandwidth.
- THE FIRST GROUP of individuals exploited a Rainbow 6 Siege service allowing them ban players, modify inventory, etc. These individuals did not touch user data (unsure if they even could). They gifted roughly $339,960,000,000,000 worth of in-game currency to players. Ubisoft will perform a roll back to undo the damages. They're probably annoyed. I cannot go into full details at this time how it was achieved.
- A SECOND GROUP of individuals, unrelated to the FIRST GROUP of individuals, exploited a MongoDB instance from Ubisoft, using MongoBleed, which allowed them (in some capacity) to pivot to an internal Git repository. They exfiltrated a large portion of Ubisoft's internal source code. They assert it is data from the 90's - present, including software development kits, multiplayer services, etc. I have medium to high confidence this true. I've confirmed this with multiple parties.
- A THIRD GROUP of individuals claim to have compromised Ubisoft and exfiltrated user data by exploiting MongoDB via MongoBleed. This group is trying to extort Ubisoft. They have a name for their extortion group and are active on Telegram. However, I have been unable to determine the validity of their claims.
- A FOURTH GROUP of individuals assert the SECOND group of individuals are LYING and state the SECOND GROUP has had access to the Ubisoft internal source code for awhile. However, they state the SECOND GROUP is trying to hide behind the FIRST GROUP to masquerade as them and give them a reason to leak the source code in totality. The FIRST GROUP and FOURTH GROUP is frustrated by this
Will the SECOND GROUP leak the source code? Is the SECOND GROUP telling the truth? Did the SECOND GROUP lie and have access to Ubisoft code this whole time? Was it MongoBleed? Will the FIRST GROUP get pinned for this? Who is this mysterious THIRD GROUP? Is this group related to any of the other groups?
I used to work for Ubisoft, though not on Siege- I have met and had detailed conversations with their lead architect though; truthfully I remember little of those conversations.
Regarding the second group and access to source code; this is unlikely for a combination of four reasons.
1) The internal Ubisoft network is split between “player stuff” (ONBE) and developer stuff.
2) The ONBE network is deny by default, no movement is possible unless its explicitly requested ahead of time, by developers, in a formal request that must be limited in scope.
3) ONBE to “developer network” connections are almost never granted. We had one exception to this on the Division, and it was only because we could prove that getting code execution on the host that made connections would require a long chain of exploits. Of course that machine did not have complete access to all of the git repos.
4) Not a lot of stuff really uses git internally. Operations staff and web developers prefer git strongly; so they use Git. But nearly every project uses Perforce. Good look getting a flow granted from ONBE to a perforce server. That will never happen.
Siege, like The Division, worked against Ubisoft internal IT policies to make the product even possible. (IT was punishingly rigid) but some contracts were unviolatable.
The last I heard, Siege had headed to AWS and had free dominion in their tenant, but it would need Ubiservices (also in AWS) and those would route through ONBE.
I’m not sure if much changed, since a member of the board is former Microsoft and has mandated a switch to Azure from the top… But I am certain that these policies would likely be the last to go.
Nothing highlights how pointless e-sports items are more than a real dollar value for a player base of all of them. The entire global GDP is as an order of magnitude roughly $100 trillion. So this $340 trillion figure is 3.4 times planetary total economic output - meaning the theoretical value of Rainbow Six cosmetics exceeds what the entire human civilisation produces in a year. Multiple times over. You'd be valuing pixelated gun attachments higher than annual agricultural output across all nations, all manufacturing, all services, everything.
I bet it appears unchallenged at some point in a court (or insurance) document though.
While I understand what you're saying, it's pretty clear what is meant is "$X worth at the price they currently sell for". When there's a story about an object in space made of gold worth 100s of trillians of dollars, nobody believes it would really sell for that much if we captured it and mined all the gold; because the value of gold would plummet based purely on it's existence.
But I agree with you that it would be put into a court document as "it cost us this much" for the full amount, vs the amount they were likely to ever be able to sell (and can't, now that everyone got it for free, so the value is $0)
The market cap is unambiguous, a more correct estimate of "how much to buy all the shares?" is situational and would just distract from getting the point across.
Not really. If a company were to manufacture a substantially large number of shares out of nothing (no additional investment money or other value entering the company) then the market cap would not go up. It would stay the same and per-share value would go down.
The market is mostly reasonable about who can and will sell their shares. If a big mover does sell a lot of their shares at once, the price will fall. Most big holders will slowly sell off shares for this reason.
In the other direction, it’s also understood that the cost to acquire all shares of a company is more than the market cap of a company. This is why you see acquisition prices being significantly higher than the last funding round valuation, or public shares popping on announcement of an acquisition attempt.
The valuation is based on them hypothetically selling the same quantities that the hackers gave away at their retail prices, which of course no one believes they would ever actually sell that much.
> Will the SECOND GROUP leak the source code? Is the SECOND GROUP telling the truth? Did the SECOND GROUP lie and have access to Ubisoft code this whole time? Was it MongoBleed? Will the FIRST GROUP get pinned for this? Who is this mysterious THIRD GROUP? Is this group related to any of the other groups?
This read to me like the end of a soap opera. Tune in tomorrow to find out!
Can’t help but laugh a bit. Not a great day for Ubisoft. Hopefully this didn’t ruin the holidays for too many employees. That would absolutely suck to get a call in for this.
> Will the SECOND GROUP leak the source code? Is the SECOND GROUP telling the truth? Did the SECOND GROUP lie and have access to Ubisoft code this whole time? Was it MongoBleed? Will the FIRST GROUP get pinned for this? Who is this mysterious THIRD GROUP? Is this group related to any of the other groups?
Find out in the next episode of... Tales from Cyberspace!
> Players across PC and console are being urged by the community to stay offline, as reports continue to surface of accounts receiving billions of in game credits, rare and developer only skins, and experiencing random bans.
Regardless if this is true or not, and how it works exactly, I find it an interesting scenario.
For players: should I go online to maybe get gifted tons of ingame valuables while risking a ban? It turns playing into a gamble.
If I take on the hackers' view, I would find it exciting to dish out rewards and punishment at random on a large scale.
The attackers better hope they fully hid their tracks - this is a bold hack, and such an level of overt cybercriminality with financial damages will result in a decade in prison if caught.
The proprietary injector mechanism like for Mounjaro makes it really easy for users. Even compounded versions of it use tiny insulin needles that have near zero pain when injected into the subcutaneous portion of like the stomach while pinched.
Source: I took compounded Mounjaro and compounded Ozempic/semaglutide.
Similarly, I grabbed one of the over-the-counter CGM biosensors (Stelo) to gather some data for a couple of weeks and the initial fear of "holy hell, I'm slamming a needle into my arm with something stuck to it" goes away as soon as you slap the injector release.
Just one little clap sound, you feel a little pat on your arm, and the sensor's already made it where it needed to with no pain.
When you remove the sensor it's a little bit of a shock when you see the sensor wire and realize just how small it was and how you never felt it run around inside your arm for a couple weeks.
fyi: the impact is an intentional decision. if your nerve endings are signaling something else(hot, cold, movement, etc), a needle prick can get blurred with the rest or ignored altogether. I suspect the bang/clag CGM applicators produce are much the same.
and, for me, its always been the needle moving around thats been mentally disturbing. digging around vecause they missed for the blood draw, trying to hold a large vaccination dose steady as it needs to be injected over 20seconds. So, I suspect the speed itself reduces discomfort.
I stopped taking compound Mounjaro a year ago. I started semaglutide in Sept and stopped because it made me sick (throwing up, other non desirable GI effects). My body couldn’t handle semaglutide.
Type 1 insulin user. One the alcohol should dry before the needle goes in. Two faster is better, within reason. Three about one in a few hundred shots hits a nerve bundle. That really hurts, but resolves after a short while. Both insulin and these GLP-1 injections are subcutaneous not intravenous which once a patient gets the skill it becomes like riding a bike, in that it becomes easier than imagined.
The only man to successfully battle and defeat glp-1's in war. his getting fit series is genuinely motivational. But not for any of the right reasons, lol.
Insulin users would have better answers to this question, since they might inject multiple times a day, whereas GLP-1 users typically inject only weekly.
But in either case, the answer for subcutaneous injections using needles sized 29g and smaller is no.
Injection drug user here. We're advised to rotate injection sites but the largest issue is actually the insulin (most of it diffuses into the bloodstream but there is a local effect, usually taking the form of increased fat accumulation at sites of repeated injection), not the "making holes in the skin" part.
I don't know the pharmacokinetics of GLP-1 drugs but my guess is that they don't have the same sort of effects on SC tissue?
Before I had a CGM I did somewhere around 20,000 blood glucose tests over the course of a decade using about 1 cm^2 of forearm and the skin there is clearly not in great shape -- but it's worsened on the level of "looks like the skin of someone who is a decade older or spent too long in the sun" rather than anything medically problematic.
> I don't know the pharmacokinetics of GLP-1 drugs but my guess is that they don't have the same sort of effects on SC tissue?
They do, but nothing like insulin does. GLP-1 drugs are more centrally and viscerally active than subcutaneously active, so the effects locally are more related to the physics of injecting solutions subcutaneously than the drugs themselves. They're also much smaller doses than are needed for insulin in general, so the volume averaged over a week is pretty tiny.
Also, as a result of the relative lack of local activity, injection sites are basically unlimited (anywhere from above the knee to above the elbow, except the neck) without fear of lipohypertrophy in the local area.
I’ve been diabetic for 30 years, and for more than twenty of those I did multiple daily measurements by pricking my fingertips and multiple insulin injections per day. Now I wear a sensor that I replace every two weeks and a catheter (which I change about once a week).
I really don’t understand this phobia of needles at all. After two days with one system or the other, you get used to it—there’s no pain, it’s just a mental issue of “having to make the gesture.”
My friends used to laugh at how normal it was for me to inject insulin outside a restaurant, while walking, chatting, and smoking at the same time.
reply