It's absolutely mind boggling to see claims of model distillation being theft, a class of attack, and all sorts of claims all the while Meta is in court for copyright violation, anthropic has had to settle a case with authors. With distillation "attacks" at least they paid API fees.
I think it depends on the depth of the summary, and the purpose. You can do quite an indepth analysis as part of educational material for example, which is one of the tests of fair use.
I think a key thing to remember when assessing your own liability is fair use is a defense, not an automatic guaranteed right for blanket uses.
Leaking spoilers of unpublished works can definitely cause market harm, and serves no wider good for the market the same way educational material would.
I wouldn't like to be on the receiving side of this lawsuit. At the very least it's going to be expensive to defend against.
I understand your thoughts. I've had similar motivation problems about blogging since the release of ChatGPT. Feels like you are writing for a machine rather than readers. Definitely seen a decline in readers since December 2023 on older articles that previously had steady traffic for years.
Also, I just purchased LazyVim For Ambitious Developers. I've used the online edition a number of times in recent months. Thanks for your work!
Excellent deep dive and explanation of the process of tracking down and fixing it. Thanks for sharing it, it was a fun read. Will definitely keep this in mind next time I fire up farcry for some nostalgia!
Nanite is a lot more than just a continuous lod system. The challenges they needed to solve were above and beyond that. Continuous lod systems have been used for literal decades in things like terrain. The challenges for continuous lod for general static meshes are around silhouette preservation, UV preservation and so on. One of nanites insights was that a lot of the issues around trying to solve automatic mesh decimation without major mesh deformation/poor results just disappear when you are dealing with triangles that are just a few pixels (as little as single pixel triangles) in size. The problem with small triangles is a problem called quad overdraw, where graphics cards rasterize triangles in blocks of 2x2 pixels, so you end up over drawing pixels many times over which is very wasteful. So the solutions they came up with in particular were:
- switch to software rasterization for small triangles. This required a good heuristic to choose between whether to follow the hardware or software path for rasterization. It also needed newer shader stages that are earlier in the geometry pipeline. These are hardware features that came with shader models 5&6.
- using deferred materials which drastically improves their ability to do batched rendering.
It's actually the result of decades of hardware, software and research advancements.
The 2 solutions posted in recent days seem heavily focused on just the continuous lod without the rest of the nanite system as a whole.
Also yes, there were also challenges around the sheer amount of memory for such dense meshes and their patches. The latest nvme streaming tech makes that a little easier, along with quantizing the vertices which can dramatically lower memory usage at the expense of some vertex position precision.
- software rasterization for small single pixel triangles which reduces quad overdraw
- deferred materials (only material IDs and some geometry properties are written in the geometry pass to the gbuffers, which things like normal maps, base colour, roughness maps, etc being applied later with a single draw call per material)
- efficient instancing and batching of meshes and their mesh patches to allow arrows of objects to scale well as object count grows
- (edit, added later as I forgot) various streaming and compression techniques to efficiently stream/load at runtime and reduce runtime memory usage and bandwidth like vertex quantization etc.
These claims aren't isolated. I think it's a bad look for Google to repeatedly make mistakes when they are currently under multiple investigations for monopolistic behavior.
I've been working on an automatic sky tracking telescope over the past few months. I'm a few weeks behind on blogging but making solid progress. V1 is nearing completion. Then I want to rework some of the electronics to design and get a custom PCB printed. Also the physical design needs a complete redesign to make it more sturdy for long exposures and solve some wiring pains.
The software allows the platform to automatically align to north and working on accounting for imperfect leveling (such as placing it on a slanted surface) through software and accelerometers.
Next challenges I want to solve in software is focus detection and then automatic image stack and post processing.
Primary goals of the project is a deep dive into robotics and electronics, along with brushing up on webdev which I don't touch too frequently being in the gamedev world. Also allowing me to explore things like digital signal processing.
I'm not sure how that's entirely relevant. Success of another platform doesn't imply failure of another platform. It's also relatively common for different regions of the world to settle into different social media networks and messaging systems. See: Whatsapp vs iMessage, VKontakte, WeChat, telegram and so on.
There's plenty of metrics to support the fact that Threads is a successful launch.
I'd personally be worried publishing this due to potentially also being classified as gaining unauthorized access to a computer system. It may temporarily be a publically accessible and poorly secured API, but that doesn't mean it's intended for public consumption when you have poked around the app to work out the API and then bypassing payment mechanisms.
I'm pretty interested in how companies are exploring how to properly monetize or compensate for scraped content to help keep a strong ecosystem of quality content. Id love to see more efforts like this.
According the Lady Ada from Adafruit relatively few will run into it, but if you are affected it can be worked around by adding an extra resistor for the affected pins into your circuit.
So it seems it's an annoyance rather than a killer. A revised chip would be nice though.
Good article! When I was first learning to produce some tutorials I knew sound was an important aspect but it was quite a lot to learn. This level of depth was good. I especially struggled with the advice of "just use your ears".
I also heard the advice of "point the microphone at the source, not the source at the microphone", so you kind of speak at a 45 degree past the microphone which definitely helped with pops.
If you ever get around to another one, would love a similar level of guide into a subtle EQ tune to improve sibilance etc.
Yeah it will be the default in the future. They laid out their roadmap a while go. It's a long roadmap to allow libraries to update. IIRC it would be default by 3.16 at the earliest. I think there was even a stage where there would be GIL and GILless distributions.