It doesn't say Toyota anywhere on the page and they don't have a link to a repo or anything like that, so I was a little confused. But it is from /that/ Toyota (well, a subsidiary that is making 3d software for their displays) and there was a talk at FOSDEM about it: https://fosdem.org/2026/schedule/event/7ZJJWW-fluorite-game-...
Funny how “game engines” are now car parts in 2026.
Can I just have an electric car that’s a car and nothing else? Seats, wheels pedals, mirrors, real buttons, no displays just a aux jack. I’d buy it, hell I might even take the risk and pre-order it
In the US, no. Backup cameras are required by federal law as of 2018. The intent of the law was to reduce the number of children killed by being backed over because the driver couldn't see them behind the car.
It is crazy how many things are downstream of the structural issue where US regulations favor ginormous SUVs and pickups where this is a problem, but if we introduced legislation to fix this we would end up ruining US automakers which have pivoted almost entirely to this segment alone
While I agree with you that the issue is far worse with larger vehicles, I do find that backing up in my wife's 2011 camry (without a backup camera) feels significantly less safe than I feel backing up my 2017 accord with a backup camera. I'm all for fixing the structural issue you are referring to, but I think the requirement for those cameras is sane in an age where the added cost to the manufacturer is miniscule.
I have to agree. Backing up my Tundra (8' bed) feels substantially safer since I can see immediately behind the vehicle than any pre-regulation vehicle I've driven. That doesn't even account for the convenience with lining up for towing, hauling, etc. (It's no replacement for GOAL—Get Out And Look—but it definitely helps!)
I bought a new car last year (my first actual _new_ car, vs pre-owned) and one of my most important features was a 360 camera. That extra visibility is just amazing for safety.
Another was a HUD. Being able to see how fast I'm going, what the speed limit is, and other info; all while keeping my eyes on the road... is safer.
Give me a backup camera without a screen and then we’ll talk. Doubly so because once you’ve got that screen, no automaker will resist making it do other things.
My SO's Buick Enclave has a screen behind the rearview mirror that can be set to show the backup camera. Works okay, but I prefer the actual mirror and just use the dash display. That said, vision issues, so not driving since around this time last year.
I think it was a Dodge Neon from the early 00s that had the worst rear view I'd experienced. My Challenger was close, but the backup camera and blind spot sensors helped a lot. You could hide a bus in the blind spot on a Challenger, not to mention the passenger seat headrest blocks most of the corner/A window.
Its not just the added cost, its the supply chain. Putting cameras into cars requires processors, ram, all manner of chips and compnents that a car didnt need before.
There was the chip shortage during covid which held car production back becasue the auto makers couldnt source their chips fast enough. I am waiting to see if the current supply issue for ram chips modules will produce a similar effect.
> Putting cameras into cars requires processors, ram, all manner of chips and compnents that a car didnt need before.
Was there a single mass market consumer car sold in the United States in this millennium that didn’t already have processors and RAM in them?
I would be absolutely shocked if there was a single car for which the relatively recent backup camera requirement required them to introduce processors and RAM for the first time.
oh yeah. I've once bought a $10ish one on Amazon out of curiosity.
There's the yellow composite plug, a 12V input, and a small bit of wire to be cut to rotate image 180 degrees, at the other end of a 30ft cable from the camera. The composite goes into the existing infotainment. There would be a wire from shifter to infotainment that switches the display to external composite video when the gear lever is in reverse. I think it even came with a miniature hole saw in size of the camera module.
$10 and one afternoon later, I could have upgraded a dumb car to have one, complete with auto switch to backup on reverse. No software hacking needed. It's fundamentally an extremely simple thing.
I believe that in some vehicles the backup camera actually runs on a separate (possibly real time, otherwise certainly heavily nice'ed) system. Tesla has a recall where they had to nice the backup camera software. The problem was if the display freezes or is delayed, then the driver is backing up and not aware that he doesn't see where he is going (he thinks that what he sees is representative of the area around the car currently).
In Hyundai and Renault I've seen it first hand that it's a separate subsystem that works even when the infotainment is dead/unresponsive/glitchy (it's like that probably everywhere, these two are just the sample I have).
I mean you can buy add-on 3rd party backup cameras for like $20. They don't have any cost excuses for including backup cameras, camera sensors and display screens are literally cheaper than dirt.
Legacy automakers still use these for upselling trims.
It's so silly when they make some "Advanced Technology Package" with a VGA camera and a 2-inches-bigger infotainment screen that's still worse than junk from Aliexpress, and charge $3000 extra for it.
I know it's just a profit-maximizing market segmentation, but I like to imagine their Nokia-loving CEO has just seen an iPad for the first time.
That's great for cars built before the regulation were put into place. Without that regulation, you'd then be dependent on the end user purchasing an after market part and installing it. The vast majority of them won't. So if it is so important to have, you make it part of the car. They did not leave seat belts up to the owners to install after market versions.
My point is that if a 3rd party manufacturer can produce and sell a combination screen and camera for $20 for a profit, an automotive manufacturer has no reason to complain about the "expense" of such a setup. It is even cheaper for them than a 3rd party addon supplier since they buy in larger bulk and can integrate mounts for those devices into the car, rather than trying to devise some sort of one-size-fits-all mounting system that the addon manufacturers need.
They might as well be complaining about the costs of a rear view mirror, it is nonsense from the start. If a $20 gadget breaks the bank on a $30,000 minimum vehicle, they are a shitty business to start with and we should all be clapping our hands when they go out of business.
The 3rd party guy isn't paying someone $40/hour to install the $20 unit. The $20 unit will not be as integrated into the car and will have the look of an after market part. Does the $20 part only come on when the car is in reverse, or is it on all the time? There's a lot of reasons the after market thing can be $20 and a lot of reasons the auto manufacturer's is not. It's not all down to greed
Was it ever a problem to get the kind of phone SoC or camera chips you'd need for a backup camera if you were willing to pay an extra $20? I thought the issue was more specialized things. And you need one gigabyte of ram or less.
You shouldn’t need any dedicated RAM. A decent microcontroller should be able to handle transcoding the output from the camera to the display and provide infotainment software that talks to the CANbus or Ethernet.
And the bare minimum is probably just a camera and a display.
Even buffering a full HD frame would only require a few megabytes.
Pretty sure the law doesn’t require an electron app running a VLM (yet) that would justify anything approaching gigabytes of RAM.
I just went on Amazon and a 1GB stick of DDR3 ram is about 30% cheaper than a 128mb stick of RAM. Why would any RAM company make tiny RAM chips when they can make standard-sized chips that work for every application that needs less?
I really feel like a lot of the people objecting in this thread are people who have just written web apps in Python whose closest experience with the audio-visual space is WebRTC.
Tech for cars is “standard-sized”. Not everything revolves around datacenters and tech, the car industry easily predates the computer industry and operates on a lot tighter margins and a lot stricter regulations.
So having a smaller, simpler chip that ultimately costs less physical resources at scale and is simpler to test is better when you’re planning on selling millions of units and you need to prove that it isn’t going to fail and kill somebody. Or, if it does fail and kill somebody, it’s simpler to analyze to figure out why that happened. You’ve also got to worry about failure rates for things like a separate RAM module not being seated properly at the factory and slipping out of the socket someday when the car is moving around.
Now - yes, modern cars have gotten more complex, and are more likely to run some software using Linux rather than an RTOS or asic. But the original complaint was that a backup camera adds non-negligible complexity / cost.
For a budget car where that would even make sense, that means you’re expecting to sell at high volume and basically nothing else requires electronics. So sourcing 1GB RAM chips and a motherboard that you can slot them in would be complete overkill and probably a regulatory nightmare, when you could just buy an off-the-shelf industrial-grade microcontroller package that gets fabbed en masse, dozens or hundreds of units to a single silicon wafer.
I simply refuse to believe the cost difference between a CPU with hundreds of megs of DRAM is cheap enough to be an appealing choice over the same chip with a gig of RAM. We're not talking about a disposable vape with 3kb of RAM, this is a car that needs to power a camera and sensors and satellite radio and matrix headlights or whatever. If it's got gigahertz of compute, there's no reason it's still got RAM sized for a computer from 30 years ago.
The original comment was complaining about backup cameras seemingly adding significant electronics requirements.
In practice, you’re not going to tie intimate knowledge of the matrix headlights into the infotainment system, that’s just bad engineering. At most it would know how to switch them on and off, maybe a few very granular settings like brightness or color or some kind of frequency adjustment, not worrying about every single LED, but I can’t imagine a budget car ever exposing all that to the end user. Even if you did, that would be some kind of legendarily bad implementation to require a gigabyte of RAM to manage dozens of LEDs. Like, is it launching a separate node instance exposing a separate HTTPS port for every LED at that point?
Ditto for the satellite radio. That can and probably is a separate module, and that’s more of a radio / AV domain piece of tech that’s going to operate in a world that historically hasn’t had the luxury of gigabytes of RAM.
Sensors - if this is a self-driving car with 3D LIDAR and 360-degree image sensors, the backup camera requirement is obviously utterly negligible.
Remember, we had TV for most of the 20th century, even before integrated circuits even existed, let alone computers and RAM. We didn’t magically lose the ability to send video around without the luxury of storing hundreds of frames’ worth of data.
Yeah, at some point it makes more sense to make or grab a chip with slightly more RAM so it has more market reach, but cars are manufactured at a scale where they actually are drivers of microcontroller technology. We are talking about a few dollars for a chip in a car being sold for thousands of dollars used, or tens of thousands of dollars new.
There is just no way that adding a backup camera is an existential issue for product lines.
Back in the mists of time, we used to do realtime video from camera to display with entirely analog components. Not that I'm eager to have a CRT in my dashboard, but live video from a local camera is a pretty low bar to clear.
Yeah, I cannot understand why people are thinking a gigabyte of RAM in this context save for their context being imagining what this would take with a python HTTPS server streaming video via WebRTC to an electron GUI running out of local docker containers or something. Because that ought to be enough memory for a hour of compressed video.
It’s like saying your family of four is going to take a vacation, so you might need to reserve an entire Hyatt for a week, rather than a single room in a Motel 6.
> I cannot understand why people are thinking a gigabyte of RAM in this context save for their context being imagining what this would take with
Who's people? It isn't me, I was rounding to the nearest positive integer. And bastawhiz is arguing in the abstract about RAM prices so I don't see how they fit this complaint either.
> It’s like saying your family of four is going to take a vacation, so you might need to reserve an entire Hyatt for a week, rather than a single room in a Motel 6.
From my point of view, it's more like each room only holds one person so you can't just say "a room" (megabyte), and renting a whole hotel would only be 0.1% of the total vacation budget, so I simplify it and just say "rent a hotel" (gigabyte). It doesn't mean I think it's necessary, it means I'm pointing out how cheap it is and don't need to go deeper.
I tried to think of a wording that wouldn't get this response, I guess I failed. Ram is generally bought in gigabytes, "1 or less" is as low as numbers go without getting overly detailed.
So what microcontroller do you have in mind that can run a 1-2 megapixel screen on internal memory? I would have guessed that a separate ram chip would be cheaper.
But mostly it’s the fundamental problem space from an A/V perspective. You don’t need iPhone-grade image processing - you just need to convert the raw signal from the CMOS chip to some flavor of YUV or RGB, and get that over to the screen via whatever interface it exposes.
NTSC HD was designed to be compatible with pretty stateless one-way broadcast over the air. And that was a follow-on to analog encodings that were laid down based on timing of the scanning CRT gun from dividing the power line frequency in an era where 1GB of RAM would be sci-fi. We use 29.97 / 59.94 fps from shimming color signal into 30 fps B&W back when color TV was invented in the early-mid 1900s, that’s how tight this domain is.
That board has a DDR3 chip on it. Is there one with HDMI that doesn't?
> But mostly it’s the fundamental problem space from an A/V perspective. You don’t need iPhone-grade image processing - you just need to convert the raw signal from the CMOS chip to some flavor of YUV or RGB, and get that over to the screen via whatever interface it exposes.
> NTSC HD was designed to be compatible with pretty stateless one-way broadcast over the air. And that was a follow-on to analog encodings that were laid down based on timing of the scanning CRT gun from dividing the power line frequency in an era where 1GB of RAM would be sci-fi. We use 29.97 / 59.94 fps from shimming color signal into 30 fps B&W back when color TV was invented in the early-mid 1900s, that’s how tight this domain is.
If you're getting a signal that's already uncompressed TV-like then you probably don't need a processor at all. But I didn't want to assume you're getting that, running a multi-Gbps signal over a wire in a very hostile environment.
The more generic solution needs the ability to hold a couple frames in memory. Which probably means a ram chip. Please don't focus so hard on the way I rounded the number. The point was that it's a negligible number of dollars. And you can use a much smaller chip than a gigabyte, but that doesn't save a proportional amount of money and the conclusion is the same, negligible amount of dollars.
I guess I could have said "gigabit". Anything that got into specific numbers of megabytes would have been pointless detail. And it's megabytes minimum if there's a frame buffer.
As someone who can only afford cars that are 10+ years old, i've never owened a car with a backup camera. And in a way-- good. That part of my brain, let it continue to develop. I am much better at "feeling out" where a car is than my friends who rely on back up cameras.
I understand your skepticism 100%, but I suspect you might change your mind if you, say, rented a car with it for a week. It's definitely a net positive for safety, and it probably costs the auto maker less than the seat belts (literally).
I've owned cars with backup cameras since about 2014. I still mostly back up the old fashioned way, and really only use the camera for very tight situations where a few inches matter.
ive owned two cars. the modern backup camera means the new one has small "stylish...." rear windows. it is wayyyy more dangerous than the older one with no sensors
i only have those two data points; but give me an older car with larger windows every. single. time.
like a vehicle touching a body in a speed of 3/4 km/h and the kid shouting or stepping away? or worst case your motion sensor beeping?
how much the conversation diverts on a commentary about someone not wanting a car shipped with an OS capturing telemetry even of farts on the right back seat
I used to be ornery about this but having a camera mounted on the back of the trunk that can see all the way down both ways of the aisle is actually a huge boon when backing out of a spot. Especially if I am parked next to something that is taller than my golf, which is most vehicles.
This is what changed my mind too. I was firmly in the “can’t you just learn to drive?” camp before.
I can use my eyes and look around but I can’t see through objects.
The camera and sensors have an incredibly wide view. I only have to get my rear end out a few inches to be able to see everything I couldn’t before. Pray and pull out isn’t very safe.
Backup camera are insanely nice. Modern cars give you things that even great awareness won't give you. The bird's eye view you get with multiple cameras is sheer magic.
It's not just ginormous SUVs with this problem, though, right? You're not going to see a 18 month old out the back window of your compact hatchback if they're too close to your car. Especially now that windows seem to be tinier than they used to.
No, it's common to all vehicles. You can't see small children behind a small passenger car, either.
Blaming trucks and SUVs for everything is a favorite pasttime of internet comments, but all vehicles benefit from backup cameras and collision detection sensors.
The US averages 23 pedestrian deaths per million people per year. The EU averages 8. The US fatalities have increased by 50% since 2013, while in the EU have decreased by 25% in the same time frame.
While I think it's more because of the speed difference in cities. In EU you just can't drive fast, because it's crowded. In the USA you have way more space to drive speed limit
> The US averages 23 pedestrian deaths per million people per year. The EU averages 8.
Americans drive significantly more miles per year, and larger/more comfortable cars are in part needed because Americans spend far more time in their cars than Europeans.
Euro governments are also increasingly anti-car, which means citizens are loosing their freedom to travel as they wish and unreasonably taxed, policed, and treated like cash cows for the "privilege" of driving.
> which means citizens are loosing their freedom to travel as they wish
Most of my European friends brag about how they can get anywhere via train and how much more comfortable it is to travel that way. When I visit Europe I have to agree. Just haven't really seen this viewpoint, though I do think I would feel this way as an American if I moved to Europe to some extent (though I'd be extremely happy to have viable mass transit).
Collision detection sensors do the job just fine without a screen though.
I have a 2016 vehicle with no console screen and they have saved me from hitting all sorts on things, and are sensitive enough to detect minor obstacles like long grass.
I think the difference is that a 3 year old barely-walking child tends to wander behind moving cars far less often than an 8 year old playing football.
Right, backup cameras make sense even for sedans and other small cars. The high-hood trucks and SUVs in the US are the reason we'll probably get mandatory front cameras eventually as well.
It's a little ironic that the truck that diverged from the trend for high butch looking hood lines for no real reason is... Cybertruck. We kill pedestrians in the name of macho.
The front camera is the best thing I added to my 2004 Prius. The hood on that car is very good for visibility, but with the birds eye cameras I can roll it up within centimeters of things in front of me (there's a slight risk that you can absolutely poke the nose under stuff but at that point it's quite obvious out the windshield too).
Why are infants materialising out of nowhere behind cars? There must be something else going on here.
When I reverse, there can't possibly be something behind my car, because I've just driven forwards over that area. When I begin to reverse, I'm looking all around behind and I'll be able to see if an infant, or dog or whatever, runs into the path I intend to take.
A lot of people tend to drive forwards into parking spaces then reverse out. I've no idea why, because it's far easier to reverse in then drive forwards out. And I reckon much safer too. If people are sitting in their cars for extended periods then beginning to drive in reverse, I can see this being a problem. But there are also vehicles that you wouldn't be able to see an infant in front of the car either.
Personally I don't own a huge SUV, but I feel backup cameras are a godsend. You're so much better off looking from the point of the actual back of the car to judge the distance to the car parked behind you.
The perk of not having to twist your body around while steerins is also pretty nice.
This is ultimately the thing that needs to be fixed. The exemption for small trucks was stupid, and it should have been reserved for literal farm equipment (as that was intended). The fact that SUVs slip by on this now has created such a dumb market.
The OBBB Act passed by Congress last year eliminated the financial penalties associated with violations of CAFE standards, so there’s presumably no reason why automakers have to abide by them anymore, except possibly for concerns about future legislation.
It wouldn’t be HN without a commenter shoehorning the topic of a thread into proof of their pet problem. See also any topic even remotely tangential to city planning.
Backup cameras do contribute significantly to safety, to the point that I installed one in my 2002 vehicle with a cheap aftermarket head unit. The important thing to realize is that all the modern conveniences can be decoupled from the drivetrain. My $50 Android head unit does basically all the things that the OEM head unit on our 2018 vehicle does. It even does many things better.
The problem with modern cars is that everything is so heavily integrated and proprietary. If I swapped out the OEM touchscreen, apparently I would also lose the ability to set the clock on my instrument cluster. Now that this has become normalized, automakers have realized they can lock Android Auto/CarPlay behind a paywall and you’ll have no recourse but to buy one of those tablets that you stick on your dashboard and plug into the aux port. If your car still has an aux port.
I’m excited for the Slate, but unfortunately I have the feeling that the people who buy new cars aren’t the same people that want the Slate. The rest of us who keep our 20+ year old vehicles reliably plugging along don’t make any money for automakers.
> buy one of those tablets that you stick on your dashboard and plug into the aux port
Every single car I have been in in the last 5 years or so has Bluetooth. No need for aux ports in this day and age, especially when devices dont have headphone jacks anymore.
I still use headphone jacks on my phone, I wouldn't buy one without it. It is just more garbage to manage and more stuff to fix when it doesn't work. It takes half a second to plug in a cable and I don't gotta run around broadcasting a bluetooth signal which drains battery when not in use and takes as long to disable as pulling out a plug. Plus it is often lower quality than the cord.
Bluetoothing to your car is to me the same energy as using "wireless" charging stands for your phone. You are just replacing a physical tether with a less efficient digital tether of higher complexity for no actual gains.
I thought the same until my latest pixel refused to use the headphone jack to the car because it detected the hands free communications in the steering wheel as a microphone and decided to block audio out with notifications telling me to set up Google Voice Assistant first (get fucked).
Backup cameras are great for people who wear glasses. My visual cone is narrower, so I effectively have to turn my head 180° to see accurately enough, otherwise it's just a blur.
When I'm 5'11" and I often see trucks and SUVs whose hoods come nearly to my shoulder, it just boggles my mind. Of all the regulations around vehicles, I don't understand why "being able to see the road five feet in front of the vehicle" isn't one of them.
Because trucks are extremely popular, and frankly there is a cultural identity associated with them. Most people don't haul things with their truck, and if they do, it's very infrequently. BUT in American fashion, the optionality to do this partially drives purchasing decisions.
Ah sorry, I quickly edited that out of my comment! I had the video playing while posting, they were talking about a precursor project for embedded Flutter which this in some ways builds on, /that/ is running on the new RAV4.
One of the example uses given in the talk is 3D tutorials, which I could imagine being handy. Not sure I'd want to click on the car parts for it but with the correct affordances I could imagine a potentially useful interface.
I feel like "game engine" is a misnomer for what we're actually dealing with here. It's more like an "ECS-based scene rendering engine, which can be used for games or for advanced UI". But that doesn't have a succinct label yet.
A Toyota Corolla starts at $23K. I think the "Under 20" and "Under 30" price points (a la the original Model 3 goal) are simply a thing of the past for any volume car with reasonable demand.
What you get for that $23k is now quite substantial though.
Power windows are standard. 169hp. Automatic climate control, central locking and key fobs, Automatic emergency braking and other radar based features. Digital gauge cluster. Modern infotainment. Modern crash safety, which is really good compared to 20 years ago.
That's a lot of car for $10k in 1996 dollars.
That's ignoring the $3k in fees, taxes, and whatever scam the dealer runs.
The reason we don't see more of it is that selling one $23k Corolla to one value minded shopper can't make line go up as much as selling one $60k MEGATRUCK to one easily influenced shopper. The new car market is exclusively for people who buy new cars regularly, and are therefore willing to get very bad deals for cars. The market is driven by people who self select for bad ability to parse value.
Yup. The expectations are set higher and to a point since cars are bigger for safety reasons (crumple zones, airbags) and have more pedestrian safety features like spring loaded hoods, it invited incremental additions until the new price points were set. A spartan 19K car isn’t going to sell as well as a CarPlay equipped 23K car.
> Can I just have an electric car that’s a car and nothing else? Seats, wheels pedals, mirrors, real buttons, no displays just a aux jack. I’d buy it, hell I might even take the risk and pre-order it
You can buy a tubular frame chassis for Beetle-based kit cars from a factory in the south of England, that's been adapted to take modern coilover suspension and an MGF or MGTF engine and gearbox, because Beetles are so rare that anyone wants to put the engine back into a Beetle.
I reckon with a minor amount of fettling you could squeeze a Nissan Leaf transaxle and a sufficient amount of batteries in, and still drop your Manx beach buggy shell over the top. Or any other shell you like.
You'd be running around in a solar-powered beach buggy. THAT is the future.
Part of what has made modern EVs successful in the wider market is the connected navigation system that knows your battery level, current consumption, planned navigation route, and what charging stations are available along the way.
To have a decent travel experience in an EV you'd likely at least need this data ported out to your phone via an OBD adapter or CarPlay / Android Auto integration with an in-car infotainment display.
Connecting via ODB? Come on. The car does not need any of that built into it. You can connect an app on your phone to handle all of that and just use the screen as a display. There is no need for a car to have a cellular connection just to give this functionality. That would also prevent the car from being able to communicate with the mother ship. If there's an update, have the app do that as well.
Funny, my phone can provide accurate routing data with out the car. What data from the car does the phone need to be able to accurately route? I'm at my desk no where near my car and it is working just fine
Current battery level and consumption, so that it can tell you whether you will make it to your destination with adequate charge left or insert charging stops where needed.
Ol' Dirty Bastard? I jest, but I think the theory behind wanting an 'On-board Diagnostics' [1] connection would be to get data from the vehicle. You can get cheap bluetooth OBD-II adapters to transmit that info to your phone, it's not a given. I don't know much about electric cars, but if you want your phone to know the fuel level in an ICE vehicle then you'd need this kind of connection.
I make typos like that lot. The one that is most common for me is CVS instead of CSV. No, this isn't a list of things to get from the drug store ::facepalm::
> Funny how “game engines” are now car parts in 2026.
Seems almost inevitable. Game engines end up supporting user interface elements and text with translations, but with an emphasis on simplicity, performance, and robustness. Many currently trending user interface stacks readily generate bursts of complexity, have poor performance even with simple usage, and are buggy and crash prone.
Flat plane or cross plane? Cross plane cranks necessitate an asymmetric firing order, which produces the wonderful burble from US V8s. Flat plane is more common in Europe - think Ferrari - and has a symmetric firing order that produces a toneless metallic howl.
Real buttons are more expensive than electronic. Not sure if you care, but people make that mistake more generally.
Game engines are probably trivially cheap to produce in 2026. You forget that Toyota sells 10M cars per year. In 3 years thats 30M cars. What does it cost each buyer for the game engine? 30 cents?
I can buy a 104 key mechanical keyboard for under $75 retail. That's 104 switches, 104 labelled button caps, a circuit board, controller and USB interface, with reliability likely much better than any other moving part found on an automobile.
That is very factually wrong. The reliability will be worse. That $75 keyboard is going to be used be hundreds of thousands of people, not millions. There is no safety involved. No one is testing to see how sunscreen and 50 other liquids interact with it. Dump a sugary drink on your car buttons, they will still work. Do that on your keyboard and it wont.
This only makes sense if touchscreens are reliable. They are not. You should look at the fault rates. Cheaper isn't better. In any case, we had cheap and good analogue before so let's not pretend like it's not possible. It might have been more expensive than a keyboard, but it wasn't dramatically different or we would have never had it. They just found a way to 1) reduce cost by going digital and 2) charging a premium for going digital as it was perceived as an upgrade by a majority of the market. They sold it to us, it's what they're good at. It doesn't mean it was a good idea.
> Real buttons are more expensive than electronic.
It might add up to a lot of money for the manufacturer who is cranking out thousands or millions of vehicles, but to the consumer buying one car it isn't a meaningful difference.
This is 10 year old outdated, but 10 years ago 1 button was ~1.00. Probably closer to $1.20 or $1.30. But sometimes buttons had 2 buttons on them, Those would go for $2.10-$2.30.
Then you had wiring each button wire I believe was $1. This wasnt 1 wire, but a few wires, power, ground, signal. Each button had them. This wasnt my job, so I didn't follow this price too much, but I asked the question at the time. I think going into the ECU, there is also a cost associated with it.
Anyway, you could assume 10 years ago, each button was $2. A car has 40-70 buttons? So its probably like $100 a car. Maybe $150 or $200 in today's money.
Also buttons and wires break, causing warranty problems.
At the time these vehicles were selling for under $20k at the bottom, and $40k at the top. So 1% of costs were buttons.
This doesn't even include the cost of hiring ~20 engineers to handle the buttons. ~6 people to check appearance and do testing... It doesn't include the assembly costs on the line. That 1% was just the cost of button + wire.
> This doesn't even include the cost of hiring ~20 engineers to handle the buttons. ~6 people to check appearance and do testing... It doesn't include the assembly costs on the line. That 1% was just the cost of button + wire.
That doesn't make sense. $1 uninstalled might make sense for a fancy custom-molded button, even if it's too much for a generic button. (I'd rather have some generic buttons with labels than use a touchscreen, by the way.) But there's no way a few feet of signal wire and the proportional share of power wires get anywhere near $1 uninstalled.
Also I can find entire car stereo units with 15 buttons on them for $15? That kind of integrated button is cheap, has been common in cars for a long time, and can control things indirectly like a touch screen button if that's cheaper than direct wiring.
You are underestimating the quality you are getting with a car. The light colors match perfectly with science and experts. Its wild how much effort goes into it.
Your after market has not been tested to react with sunscreen.
But the whole argument was that it's too expensive. If impeccable color matching is too expensive then give me the cheapest button that won't break. Needing the touchscreen to adjust the A/C is more ugly than the worst looking button.
But also that kind of button doesn't need dedicated wires.
Touchscreen controls are crappy. They're less nice than ugly buttons.
(And of course people still buy cars with flaws. An entire car is an amalgamation of so many features that's it's hard to use purchases to measure people's reaction to the vast majority of specific changes. And features like controls often take longer than a test drive to evaluate, too.)
> Anyway, you could assume 10 years ago, each button was $2. A car has 40-70 buttons? So its probably like $100 a car. Maybe $150 or $200 in today's money.
I have a late 90s Range Rover. It has about 12 buttons on the dashboard, most of which I never have to bother with (they do things that turn on and off the fog lamps, which I don't need to use, or adjust the air suspension, which I rarely need to use). I turn the lights off and on, and I switch the heating from "normal" to "BLAST EVERYTHING ON, FRONT AND REAR DEMIST ON, SEAT HEATERS ON, EVERYTHING ON, EVERYTHING ON, EVERYTHING UP FULL, WE'RE AN AIR FRYER NOW" mode.
From looking at some new car options lately, it seems like you're lucky if you can get floor mats for $200. This doesn't take away from your point - I suppose I'm just griping.
I don’t care. I want a simple car with simple parts that I can fix. Not this spaceship that we get now days.
The 12v battery on my partners car had to be replaced, apparently it had to be “paired” in the shop and was not user serviceable wtf!?
The "pairing" probably makes sense if you deep-dive into the technical details. My guess is that the battery has software on it to improve performance, total life, whatever.
The real problem is that the whole is not designed to be user-servicable.
The last car that I remember being just an engine and seats was the Dodge Viper. I think some K class Japanese domestic vehicles are also likewise basic.
I loved the Viper, but its spartan interior and features list were its detriment.
Given how many cars have Carplay or Android Auto, but also have their own e.g. Toyota app that you need to/ought to install, it feels as though this isn't that far off from how things basically are.
Personally, I'd be happy with some kind of situation where:
1. You have a small in-dash touchscreen, as most small sedans have these days, as the basic level of "backup camera and radio view"
2. Everything the car does has a physical button so you don't NEED to use the touchscreen
3. The car has a USB-C port that can power a tablet and which provides a standardized interface that e.g. iOS and Android can interface with, so that users don't have to worry about their new OS doesn't support the not-updated app, or the app doesn't support their not-updated device
4. Sell an optional tablet mount that attaches to the dash the way a built-in one would be
5. Sell an optional 'tablet' that does nothing but interface with the USB-C port and provide what it needs, in case someone wants a larger screen without having to buy an iPad Pro
Then again I don't drive, so I'd be happy with none of this also.
Honestly, I'd be okay with this, and then you can upgrade / replace said tablet if you wanted to. In an Alternate Universe, your iPad drives your car, your iPad Pro drives your car through hell and back, or whatever.
do you know about the slate truck? give it a search. it doesn't even come with speakers. or electric windows. or paint. it does have a backup camera afaik.
No because more basic cars have much lower profit margins while requiring higher volume and investors/capitalists will not accept that. Why earn 5% on their investment selling a million cars and building brand name when they can instead earn 20% on selling 100,000 cars at the expense of a brand name they never cared about maintaining in the first place? Brand tarnishment is something other smucks will have to deal with down the road, not the guys making these decisions right now who get performance "bonuses" and not the shareholders that want large returns.
dawg idk how you have a car that's "electric" and also "basic." everything in an electric car is _necessarily_ mediated by software. if you want a simple car, you want combustion.
Basic does not mean "no software" it means "no cellular modem" and "no 15 inch tablet" and "no subscription based features"
There is functionally no difference between the powertrain of an electric road car and a brushless drill. How much software is there in your brushless drill? More than zero, far less than an electric road car.
Dear god do I not want to be trying to deal with an interactive user manual when pulled over on the side of the road trying to look up the lift point to jack the car up.
I think they do mean game console. The phrase "console-grade" appears right next to the word "game" (in "console-grade game engine") and the title "Console-grade 3D Rendering" on the page appears next to a selection of 3D scenes that seem like overkill for a car console.
For others who were curious like I was: The website doesn't mention "open" or "source" anywhere, but they did give a talk at FOSDEM 2026 about it.
There was a passing comment about "when we open up the GitHub repository" in the talk. So it's not open yet, but they've suggested it might be in the future.
The combination of Flutter + Claude Code makes cross-platform app development really, really fast. I've been impressed with how well Clause handles prompts like, "This list should expand on the web, but not on iOS." I then ask it (Claude) to run both a web instance and an iOS simulator instance. Can usability test in-tandem.
I recently (as in, last night) added WebSockets to my backend, push notifications to my frontend iOS, and notification banner to the webapp. It all kinda just works. Biggest issues have been version-matching across with Django/Gunicorn/Amazon Linux images.
You don't, and as long as you're comfortable with that you keep prompting to dig yourself out of holes.
The problem is unless your ready to waste hours prompting to get something exactly how you want it, instead of spending those few minutes doing it yourself, you start to get complacent for whatever the LLM generated for you.
IMO it feels like being a geriatric handicap, there's literally nothing you can do because of the hundreds or thousands of lines of code that's been generated already, you run into the sunk cost fallacy really fast. No matter what people say about building "hundreds of versions" you're spending time doing so much shit either prompting or spec writing that it might not feel worth getting things exactly right in case it makes you start all over again.
It's literally not as if with the LLM things are literally instantaneous, it takes upwards or 20-30 minutes to "Ralph" through all of your requirements and build.
If you start some of it yourself first and you have an idea about where things are supposed to go it really helps you in your thinking process too, just letting it vibe fully in an empty directory leads to eventual sadness.
This. I find bringing in the LLM when there is a good structure already in place is better. I also use it sparingly, asking it for very specific things. Write me tests for this, or create me a function that does this or that. Review this, extend that etc.
They are pretty good at "scaffold this for me" and you adapt as a second step.
That is one of the three uses I give them.
The other two are: infra scripting, which tends to be isolated: "generate a python script to deploy blabla with oarameters for blabla...". That saves time.
The third use is exploring alternative solutions, high level, not with code generation, to stimulate my thinking faster and explore solutions. A "better" and more reasoned search engine. But sometimes it also outputs incorrect information, so careful there and verify. But at least it is successful at the "drop me ideas".
For big systems, generating a lot of code that I have no idea of what I end up with, that when I get bugs is going to be more difficult to modify, understand and track (Idk even the code, bc it outputs too much of it!).
Or for designing a system from zero, code-wise is not good enough INHO.
oh, a fourth thing it does well is code review, that one yes. As long as you are the expert and can quickly discard bs feedback there is always something valuable.
And maybe finding bugs in a piece of code.
Definitely, for designing from scratch it is not reliable.
Yes, I agree on all points. Also, I keep finding new use cases all the time. So, going all poetic; part of me laments the death of my craft, and the other rejoices at the superpowers of what rises from the ashes...
This reminds me of how some famous artists would paint via their studios wherein assistants put most of the pant on the canvas, under the direction / modeled off an example, and with the signature / embellishments of the named artist.
LLMs would not be popular if "spending those few minutes doing it yourself" part was true. In actuality it can be hours, days, or weeks depending on the feature and your pickiness. Everyone acts as if they are the greatest developer and that these tools are subpar, the truth is that most developers are just average, just like most drivers are average but think of themselves as above average. All of the sudden everyone that was piecing together code off of stackoverflow with no idea how to build the damn thing is actually a someone who can understand large code bases and find bugs and write flawless code? Give me a break.
To the degree that those same people are now writing 10-100x more code...that is scary, but the doom and gloom is pretty tiring.
The SO copy-pasting is actually quite accurate. The same folks are now just blindly generating code. That's why most software in the world is shit, and will continue to be in the future. There might just be more of it.
There will most definitely be much more of it, maybe machines are doing this on purpose to increase dependency on them haha. Ultimately, wagging a finger at someone will have no outcome, allowing someone to make real mistakes while vibe coding will be a much better learning experience. Someone that drops a prod database using Claude will have a very lasting memory of that(not saying that should be the goal, critical thinking obviously matters A LOT). Cars didn't used to have seatbelts, a lot of people died, then they got seatbelts and now the world is a better place.
The problem is maintenance and understanding code in the presence of bugs.
It looks very productive at first sight but when you start to find problems it is going to be a lot of fun on a production system.
Because basically you cannot study all the output that the LLM throws line by line if what you want is speed.
Which leaves reliability compromised.
Also, sometimes LLMs throw a lot of extra and unncessary code making things more barroquw than if you had sat down and thought a bit about the problem a bit.
Yes, you can deliver faster code with LLMs, maybe. But it is going to be good enough for maintenance and bug fixing?
I never said anything against using LLMs. You're projecting.
Any engineer worth their weight will always try to avoid adding code. Any amount of code you add to a system, whether is written by you or a all knowing AI is a liability. If you spent a majority of your work day writing code it's understandable to want to rely heavily on LLMs.
Where I'd like for people to draw a line on is not knowing at all what the X thousand lines of code are doing.
In my career, I have never been in a situation where my problems could be a solved by piecing together code from SO. When I say "spend those few minutes doing it yourself" I am specifically talking about UI, but it does apply to other situations too.
For instance, if you had to change your UI layout to something specific. You could try to collect screenshots and articulate what you need to see changed. If you weren't clear enough that cycle of prompting with the AI would waste your time, you could've just made the change yourself.
There are many instances where the latter option is going to be faster and more accurate. This would only be possible if you had some idea of your code base.
When you've let an agent take full control of your codebase you will have to sink time into understanding it. Since clearly everyone is too busy for that you get stuck in a loop, the only way to make those "last 10%" changes is *only* via the agent.
I didn't say anything about your beliefs in AI, my statement was general. You're projecting.
It is still possible to write code with AI AND educate yourself on what the codebase architecture is. Even better, you can educate yourself on good software engineering and architecture and build that into making better specs. You can understand what the code is doing by having good tests, observability, and actually seeing it work. But if you're after peeping what every character is doing, I am not going to stop you!
LLMs are not reliable to fix bugs and when they do they often introduce new ones in my experience.
In fact, humans do targetted bug fixing reasonably well and knowing they did not change the structure of other code better than LLMs currently do in my experience.
I do not find them reliable enough TBH to leave such delicate tasks in a production system in their hands.
Yeah… I wonder how you write complex software without something that looks like a spec, other than slowly. It seems like the prep work is unavoidable, and this contrarian opinion you are offering is just that.
Writing the spec is becoming the default for pet projects. Which would be a good thing if the spec wasn't also partly written by an LLM.
You can already see people running into these issues, they have a spec in mind. They work on the spec with and LLM, the spec has stuff added to it that wasn't what they were expecting.
And again, I am not against LLMs but I can be against how they're being used. You write some stuff down, maybe have the LLM scaffold some skeleton for you. You could even discuss with the LLM what classes should be named what should they do etc. just be in the process so the entire code base isn't 200% foreign to you by the time it's done.
Also I am no one's mother, everyone has freewill they can do whatever they'd like. If you don't think you have better things to do than to produce 3-5 pieces of abandonware software every weekend then good for you.
Same as any other software team? You keep an eye on all PRs, dive deep on areas you know to be sensitive, and in general mostly trust till there's a bug or it's proven itself to need more thorough review.
I've only ever joined teams with large, old codebases where most of the code was written by people who haven't been at the company in years, and my coworkers commit giant changes that would take me awhile to understand so genAI feels pretty standard to me.
I love using AI and find it greatly increases my productivity, but the dirty little secret is that you have to actually read what it writes. Both because it often makes mistakes both large and small that need to be corrected (or things that even if not outright wrong, do not match the style/architecture of the project), and because you have to be able to understand it for future maintenance. One other thing I've noticed through the years is that a surprising number of developers are "write only". Reading someone else's code and working out what it's doing and why is its own skillset. I am definitely concerned that the conflux of these two things is going to create a junk code mountain in the very near future. Humans willing to untangle it might find themselves in high demand.
And, as well as noticing actual semantic issues, it's worth noting where they've mixed up abstractions or just allowed a file to grow to an unsustainable size and needs refactoring. You can ask the AI agent to do the refactoring, with some guidance (e.g. split up this file into three files named x, y, z; put this sort of thing in x, ...). This helps you as a human to understand their changes, and also helps the AI. It also makes you feel in control of the overall code design, even though you're no longer writing all the details.
They'll often need a little final tuning afterwards (either by hand or ask the AI again) e.g. move this flag from x to y. As is often the case, it's just like you have an enthusiastic and very fast but quite junior dev working for you.
I loved learning Computer Engineering in college because it de-mystified the black box that was the PC I used growing up. I learned how it worked holistically, from physics to logic gates to processing units to kernels/operating systems to networking/applications.
It's sad to think we may be going backwards and introducing more black boxes, our own apps.
I personally don't "hate" LLMs but I see the pattern of their usage as slightly alarming; but at the same time I see the appeal of it.
Offloading your thinking, typing all the garbled thoughts in your head with respect to a problem in a prompt and getting a coherent, tailored solution in almost an instant. A superpowered crutch that helps you coast through tiring work.
That crutch soon transforms into dependence and before you know it you start saying things like "Once you vibe code, you don't look at the code".
I think a lot of people, regardless of whether they vibe code or not are going to be replaced by a cheaper sollution. A lot of software that would've required programmers before can now be created by tech savy employees in their respective fields. Sure it'll suck, but it's not like that matters for a lot of software. Software Engineering and Computer Science aren't going away, but I suspect a lot of programming is.
I've been around for a while. The closest we ever got was probably RPA. This time it's different. In my organisation we have non-programmers writing software that brings them business value on quite a large scale. Right now it's mainly through the chat framework we provide them so that they aren't just spamming data into chatGPT or similar. A couple of them figured out how to work the API and set up their own agents though.
Most of it is rather terrible, but a lot of the times it really doesn't matter. At least most of it scales better than Excel, and for the most part they can debug/fix their issues with more prompts. The stuff that turns out to matter eventually makes it to my team, and then it usually gets rewritten from scratch.
I think you underestimate how easy it is to get something to work well enough with AI.
I assume he’s mostly joking but… how often do you look at the assembly of your code?
To the AI optimist, the idea of reading code line by line will see as antiquated as perusing CPU registers line by line. Something do when needed, but typically can just trust your tooling to do the right thing.
I wouldn’t say I am in that camp, but that’s one thought on the matter. That natural language becomes “the code” and the actual code becomes “machine language”.
And you could say that the difference is that high-level languages are deterministically transformed down, but in practice the compiler is so complex you'd have no idea what it's doing and most people don't look at the machine code anyway. You may as well take a look at the LLM's prompt and make an assumption of the high-level code that it spits out.
Honestly I'm not so strongly opiniated now as I was a few weeks ago. I'm in a huge questioning phase about my work/craft/hobby.
I've worked places where junior made bad code that was accepted because the QA tests were ok.
I even had a situation in production where we had memory leaks because nobody tried to use it for more than 20 minutes when we knew that the app is used 24/7.
We aim for 99% quality when no-one wants it.
No-one wants to pay for it.
Github is down to one 9 and I haven't heard them losing many clients, people just cope.
We've reached a level where we have so much ram that we find garbage collection and immutability normal, even desired.
We are wasting bandwidth by using json instead of binary because it's easier to read when have to debug, because it's easier to debug while running than to think before coding.
I built a system that can hold 40,000 concurrent users with hardly 2 GiB of RAM, a bit of bandwidth (with a 300 Mbps connection it works great) using Capnproto and that I am scaling horizontally.
A server with 6 cores can hold at least 3 of these services. Now think of customers. How much you are going to save in operations? Loooooots! For backend efficiency and quality is still a critical metric, especially when operations are so cheap (tens of dollars per month).
The trick is to separate your codebase into "code I care about that I give the AI a fixed API and rarely let the AI touch" and "throwaway code I don't give one iota of damn about and I let the AI regenerate--sometimes completely from scratch".
For me, GUI and Web code falls into "throwaway". I'm trying to do something else and the GUI code development is mostly in my way. GUI (especially phone) and Web programming knowledge has a half-life measured in months and, since I don't track them, my knowledge is always out-of-date. Any GUI framework is likely to have a paroxysm and completely rewrite itself in between points when I look at it, and an LLM will almost always beat me at that conversion. Generating my GUI by creating an English description and letting an AI convert that to "GUI Flavour of the Day(tm)" is my least friction path.
This should be completely unsurprising to everybody. GUI programming is such a pain in the ass that we have collectively adopted things like Electron and TUIs. The fact that most programmers hate GUI programming and will embrace anything to avoid that unwelcome task is pretty obvious application of AI.
Man, people say this kind of thing, and I go… really? …because I use Claude code, and an iOS MCP server (1) and hot damn I would not describe the experience as “just works”.
What MCP and model are you using to automate the testing on your device and do automated QA with to, eg. verify your native device notifications are working?
My experience is that Claude is great at writing code, but really terrible at verifying that it works.
What are you using? Not prompts; like, servers or tools or whatever, since obviously Claude doesn’t support this at all out of the box.
Claude set up my whole backend on AWS. That includes a load balancer, web server, email server, three application servers, and a bastion server to connect to their VPN.
It configured everything by writing an AWS Terraform file. Stored all secrets in AWS as well.
Everything I do is on the command line with Claude running in Visual Studio Code. I have a lot of MacOS X / Ubuntu Linux command line experience. Watching Claude work is like watching myself working. It blew my mind the first time it connected through the bastion to individual AWS instances to run scripts and check their logs.
So yeah, the same Claude Code instance that configured the backend is running inside a terminal in VS Code where I’m developing the frontend. Backend is Django/Python. Frontend is Flutter/Dart. Claude set up the WebSocket in Django/Gunicorn and the WebSocket in Flutter.
It also walked me through the generation of keys to configure push notifications on iOS. You have to know something about public/private key security, but that amounts to just generating the files in the right formats (PEM vs P12).
I'd like to know too! I feel like many people are playing a whole different AI game than me, and I don't think I've written a single line of code since December (team experiment to optimize the vibe coding process)
The UI toolkits in game engine usually suck hard, so here they started from a good UI toolkit and made it possible to make relatively performant games.
Filament is not a console grade renderer, not even close. It's architectured around GL. Yes, it can use Vulkan but it's not in any way optimized like a console engine.
GL is way more optimized then Vulkan style rendering on most devices today. If you speed test WebGL2 with WebGPU on a mobile device the difference is huge for rendering a simple PBR model.
This is a very interesting but also frustrating comment. If you're right that it's not a console grade renderer (not that I know what that even means) then that's really interesting - but why not? And could it be in future or is it fundamentally impossible for some reason?
Maybe they mean like the golden era of Xbox 360 rendering. Where the CPU and GPU could run together in one region of unified 512MB of memory with crazy fast rendering bandwidth. I wish there was a VR headset designed like that.
I understand what your intent is in saying this, and I agree with the intent, but for onlookers, you don't really need a lot to make a good game and this would likely be just fine. I don't actually know if it's possible to ship GL games on modern consoles now that it's in-fashion to have your own proprietary graphics library. That said, the way Google has factored the back-end of the renderer, it won't take a PhD to target one of those GPU APIs.
Aside: GL is still a good practical choice for games built by small teams.
I guess it depends. There's no reason to promote this as "console grade" unless "console grade" means something more than, plain old 3d object renderer.
Certainly, you could define a console as an NES and the claim "console grade" but I'm guessing they are claiming "console grade" means, competitive with the renderer in games like Battlefield 6, Elden Ring, Horizon Forbidden West, etc.. Filiment is not up to those tasks.
Yes, you can make great games without the features of top console game graphics engines. But again, there's no reason for the hyperbole of putting "console grade" in the description then.
Yeah, it’s salesmanship. My feeling is that some amount of salesmanship is fine. This pales in comparison to a lot of promotion we see today. I mean this genuinely; maybe my standards have fallen too low? Perhaps I’m getting numb to it.
I wonder if a slightly broader search for existing solutions - for instance, https://defold.com - would have shown that quick-startup, 3d-capable, c-integrable, low-end-hardware performant game engines could have been grabbed off the shelf.
That said, this is cool and I would have probably celebrated a similarly fun project in their shoes. Perhaps the real accomplishment here is getting Toyota to employ you to build a new, niche game engine.
Toyota complained about poor performance on all of Unity, UE and Godot, but also about long startup times with Godot.
I don't know how bloated Godot is, but AFAIK libgodot development started as part of Migeran's automotive AR HUD prototype so I'm surprised to hear it has poor startup time for a car.
Godot is pretty lightweight (especially considering how powerful it is), generally about a second or less. But maybe they are looking for a fast enough startup time that the engine can be started when showing something onscreen and torn down when not visible. In which case, I can see the startup time being an issue.
The fact that they tried other engines seems to imply that non Flutter options were... Options.
If literally the only option was an embedded flutter view, then there was never more than one viable solution and looking into unity etc was wasted effort.
It’s possible to integrate other things into Flutter.
However, it’s not easy. I think their options were either a popular mainstream library or a custom solution, not investing into something more obscure and less popular.
Having used both, the experience of building actual UI with Flutter is a breeze compared to building UI in any game engine. I can imagine that most of the usage of Flutter is leveraging the huge amount of work that was already done to get efficient and capable UIs done with just a stack of widgets.
The places where it poses challenges in my experience are high quality typesetting/rich text, responsive UI that requires a wide range of presentations (i.e. different layout structures on mobile vs desktop), and granular control over rendering details.
But for functionality-oriented UI, it's hard to beat its simplicity and scalability, particularly when you want to develop on one platform (e.g. computer) and have everything "just work" identically on other form factors (web/tablet/etc.).
For example, Godot's editor is bootstrapped/built in Godot, and runs natively on Web, Android, and Quest XR among other platforms.
but if they're targeting embedded systems, maybe they haven't prioritized a public web demo yet. If the bulk of the project is actually in C++, making a web demo probably involves a whole WASM side-quest. I suspect there's a different amount of friction between "I wanna open source this cool project we're doing" and "I wanna build a rendering target we won't use to make the README look better."
I'm guessing its used for some of their in-car UIs - unreal engine has found a market (Rivian, Volvo, Ford...) for embedded automotive use now that so many cars display an interactive 3d model to the driver for things like tapping to unlock corresponding door or trunk etc etc.
Why is a full game engine needed to display a GUI for unlocking a door? There are endless simpler solutions. The apps I use every day don't use game engines (except games).
A game engine is sort of just a UI toolkit for interacting with 3d objects. If you want a 3d model you can interact with, you call that a game engine. Should they invent something new because they dislike the word "game"?
Worked for a shop that had the hardest time grasping this. We had to tell them UE4 was a "3D Rendering Engine" because they couldn't get over the term "game engine" in planning meetings...
I feel like Nvidia Omniverse's main innovation is that they call themselves an 'industrial metaverse platform' even though their product is practically not much different from a game engine.
Because you need and want all the fancy features such as
- fancy HDR rendering with reflection planes,atmospheric effects, tone mapping, camera effects, all kinds of animations for doors opening, lights turning on off etc
- content pipelines to get all this data from digital creation tools into packages deployable on target
When everything is said and done this is the same bread and butter what game engines use so the industry has pushed to leverage those and spread to these markers. Both unity and epic have tried with but not without issues.
Game engines, UI frameworks, desktop environments, and web browsers all share a lot of features. The Arcan project is my favorite piece of software running with this idea rn
it'actually Toyota Connected North America, Toyota Motor Corporation's subsidiary founded in collaboration with Microsoft for working on in-vehicle software, AI, and related tech initiatives.
So basically the same sort of thing Samsung does with its corporate subsidiary. At least that's the first one I think of. But I know there others who leverage the brand all the way down the ladder.
I don't think anyone's seriously using Bevy's 3D renderer, only the ECS. The only successful 3D game made with Bevy so far seems to be Tiny Glade, which used its own renderer.
I'm surprised Toyota even used something as new-ish as Flutter. Carmakers usually are the last to adopt anything.
Bevy is the opposite of an old boring solution. It's a cool engine, but I imagine a manufacturer would like to have long-term support with 15-year timelines. Bevy doesn't offer that, and even trying to have that wouldn't be good for Bevy.
(was this meant to be a reply to one of the other Godot comments?)
The page says that it's "Powered by Google's Filament renderer" which is written in C++, and that Fluorite itself has "a data-oriented ECS (Entity-Component-System) architecture ... written in C++".
Also, although Flutter/Dart applications can run on web (compile to WASM or transpile to Javascript) and so can Filament, the Fluorite FOSDEM page says target platforms are "mobile, desktop, embedded and console platforms" so it's not clear Fluorite even cares about running in browser.
I was learning it and having a great time with it. Unfortunately the job market for it is abysmal. And in 2026 with the current state of the job market I didn't want to focus my time on something that wouldn't help me to get a job. But still the most fun I have had with a language.
It is interesting to see players other than Google invest in it.
Makes me wonder if you might eventually see the OG Flutter team move to a shop like Toyota, the same way the original React team moved to Vercel. It's nice to see open source projects be portable beyond the companies that instigated them.
Rust based ECS game engine, with 3,000 word diatribes about what decentralized, federated social media presence it should have, woefully incomplete, full of bugs, with no consideration of how any actual games are written other than Factorio, because that's the game that programmers who write open source game engines and not games play: "Aww, you're sweet"
Something about games authored by a giant company that will presumably actually ship in some products: "Hello, human resources?"
I've been burned by using closed source game engines before. There's just too many edge cases and nuances that come up when debugging physics or graphical issues. I strongly recommend against using this until they become at the very least source-available.
I was impressed with how well flutter took function/react style and married it with OO, the rendering seemed to make anything possible and clean. Dart is good, just the threading model seemed awkward. Can't say I dove too deep though.
This trend of "complexity == moar gooder" makes me itchy. Why does a vehicle display system need a whole-ass game engine? I want my high-speed death box to have utilitarian, well-tested and well-written software, not fucking Unity.
Please stop, all this does is introduce new ways for things to break.
It doesn't say Toyota anywhere on the page and they don't have a link to a repo or anything like that, so I was a little confused. But it is from /that/ Toyota (well, a subsidiary that is making 3d software for their displays) and there was a talk at FOSDEM about it: https://fosdem.org/2026/schedule/event/7ZJJWW-fluorite-game-...
> They use this game engine in the 2026 RAV4
Funny how “game engines” are now car parts in 2026.
Can I just have an electric car that’s a car and nothing else? Seats, wheels pedals, mirrors, real buttons, no displays just a aux jack. I’d buy it, hell I might even take the risk and pre-order it
> no displays
In the US, no. Backup cameras are required by federal law as of 2018. The intent of the law was to reduce the number of children killed by being backed over because the driver couldn't see them behind the car.
It is crazy how many things are downstream of the structural issue where US regulations favor ginormous SUVs and pickups where this is a problem, but if we introduced legislation to fix this we would end up ruining US automakers which have pivoted almost entirely to this segment alone
While I agree with you that the issue is far worse with larger vehicles, I do find that backing up in my wife's 2011 camry (without a backup camera) feels significantly less safe than I feel backing up my 2017 accord with a backup camera. I'm all for fixing the structural issue you are referring to, but I think the requirement for those cameras is sane in an age where the added cost to the manufacturer is miniscule.
I have to agree. Backing up my Tundra (8' bed) feels substantially safer since I can see immediately behind the vehicle than any pre-regulation vehicle I've driven. That doesn't even account for the convenience with lining up for towing, hauling, etc. (It's no replacement for GOAL—Get Out And Look—but it definitely helps!)
I like it because I can see kids, no matter what vehicle I’m in.
I have unusually good spatial skills. I have parallel parked and reverse parked perfectly every single time for over 5 years…
…but no matter what, I cannot see behind my bumper. No mirror on any car points there.
The law was passed due to sustained lobbying from a man, Greg Gulbransen, who ran over his child
What an absolute tragedy it must be to go through that. Hopefully he finds peace knowing this law will save many other children.
What an amazing piece of information in a thread about a game engine, thanks for sharing this.
I bought a new car last year (my first actual _new_ car, vs pre-owned) and one of my most important features was a 360 camera. That extra visibility is just amazing for safety.
Another was a HUD. Being able to see how fast I'm going, what the speed limit is, and other info; all while keeping my eyes on the road... is safer.
I agree. Going back to a car without a 360 camera is unthinkable now that I've gotten so used to it...
This makes my wife's Tesla seem very outdated. It only gets a rear camera when backing up, and a side camera when activating a turn signal.
Give me a backup camera without a screen and then we’ll talk. Doubly so because once you’ve got that screen, no automaker will resist making it do other things.
My 2010 Tacoma has a 2 inch square in the rear view mirror that works wonderfully.
I actually like that a lot. Does the job without providing a (practical) target for infotainment. TIL.
You piqued my interest. What is the alternative output for a camera without a screen?
These days I guess we could do gpt with voice out to recite a poem about the kid you're about to hit?
Haha... I think gp meant touch-screen, but thanks for the chuckle :)
My old F150 had a screen in the rear view mirror. I miss that.
My SO's Buick Enclave has a screen behind the rearview mirror that can be set to show the backup camera. Works okay, but I prefer the actual mirror and just use the dash display. That said, vision issues, so not driving since around this time last year.
I think it was a Dodge Neon from the early 00s that had the worst rear view I'd experienced. My Challenger was close, but the backup camera and blind spot sensors helped a lot. You could hide a bus in the blind spot on a Challenger, not to mention the passenger seat headrest blocks most of the corner/A window.
Its not just the added cost, its the supply chain. Putting cameras into cars requires processors, ram, all manner of chips and compnents that a car didnt need before.
There was the chip shortage during covid which held car production back becasue the auto makers couldnt source their chips fast enough. I am waiting to see if the current supply issue for ram chips modules will produce a similar effect.
> Putting cameras into cars requires processors, ram, all manner of chips and compnents that a car didnt need before.
Was there a single mass market consumer car sold in the United States in this millennium that didn’t already have processors and RAM in them?
I would be absolutely shocked if there was a single car for which the relatively recent backup camera requirement required them to introduce processors and RAM for the first time.
I’m pretty sure that you can buy aftermarket backup cameras. The car can be a dumb bunny, and still have a good camera.
Yeah, my 2005 beater has both CarPlay and a backup camera. Cost me $40 and an hour of labor.
oh yeah. I've once bought a $10ish one on Amazon out of curiosity.
There's the yellow composite plug, a 12V input, and a small bit of wire to be cut to rotate image 180 degrees, at the other end of a 30ft cable from the camera. The composite goes into the existing infotainment. There would be a wire from shifter to infotainment that switches the display to external composite video when the gear lever is in reverse. I think it even came with a miniature hole saw in size of the camera module.
$10 and one afternoon later, I could have upgraded a dumb car to have one, complete with auto switch to backup on reverse. No software hacking needed. It's fundamentally an extremely simple thing.
I believe that in some vehicles the backup camera actually runs on a separate (possibly real time, otherwise certainly heavily nice'ed) system. Tesla has a recall where they had to nice the backup camera software. The problem was if the display freezes or is delayed, then the driver is backing up and not aware that he doesn't see where he is going (he thinks that what he sees is representative of the area around the car currently).
In Hyundai and Renault I've seen it first hand that it's a separate subsystem that works even when the infotainment is dead/unresponsive/glitchy (it's like that probably everywhere, these two are just the sample I have).
Stability control, pre-collision braking, lane departure warnings, the complexity is pretty inevitable as we improve the safety of vehicles.
> Putting cameras into cars requires processors, ram, all manner of chips and compnents that a car didnt need before.
Call me old fashioned but in my opinion, processors/ram/chips/components are a good trade-off versus squished children
All cars have required "chips" since OBDII was mandated in the early 90s. That ship has sailed around the world, returned to port, and sailed again.
All of that is worth the extra safety.
I mean you can buy add-on 3rd party backup cameras for like $20. They don't have any cost excuses for including backup cameras, camera sensors and display screens are literally cheaper than dirt.
Legacy automakers still use these for upselling trims.
It's so silly when they make some "Advanced Technology Package" with a VGA camera and a 2-inches-bigger infotainment screen that's still worse than junk from Aliexpress, and charge $3000 extra for it.
I know it's just a profit-maximizing market segmentation, but I like to imagine their Nokia-loving CEO has just seen an iPad for the first time.
That's great for cars built before the regulation were put into place. Without that regulation, you'd then be dependent on the end user purchasing an after market part and installing it. The vast majority of them won't. So if it is so important to have, you make it part of the car. They did not leave seat belts up to the owners to install after market versions.
My point is that if a 3rd party manufacturer can produce and sell a combination screen and camera for $20 for a profit, an automotive manufacturer has no reason to complain about the "expense" of such a setup. It is even cheaper for them than a 3rd party addon supplier since they buy in larger bulk and can integrate mounts for those devices into the car, rather than trying to devise some sort of one-size-fits-all mounting system that the addon manufacturers need.
They might as well be complaining about the costs of a rear view mirror, it is nonsense from the start. If a $20 gadget breaks the bank on a $30,000 minimum vehicle, they are a shitty business to start with and we should all be clapping our hands when they go out of business.
The 3rd party guy isn't paying someone $40/hour to install the $20 unit. The $20 unit will not be as integrated into the car and will have the look of an after market part. Does the $20 part only come on when the car is in reverse, or is it on all the time? There's a lot of reasons the after market thing can be $20 and a lot of reasons the auto manufacturer's is not. It's not all down to greed
Was it ever a problem to get the kind of phone SoC or camera chips you'd need for a backup camera if you were willing to pay an extra $20? I thought the issue was more specialized things. And you need one gigabyte of ram or less.
A gigabyte!?
You shouldn’t need any dedicated RAM. A decent microcontroller should be able to handle transcoding the output from the camera to the display and provide infotainment software that talks to the CANbus or Ethernet.
And the bare minimum is probably just a camera and a display.
Even buffering a full HD frame would only require a few megabytes.
Pretty sure the law doesn’t require an electron app running a VLM (yet) that would justify anything approaching gigabytes of RAM.
I just went on Amazon and a 1GB stick of DDR3 ram is about 30% cheaper than a 128mb stick of RAM. Why would any RAM company make tiny RAM chips when they can make standard-sized chips that work for every application that needs less?
I really feel like a lot of the people objecting in this thread are people who have just written web apps in Python whose closest experience with the audio-visual space is WebRTC.
Tech for cars is “standard-sized”. Not everything revolves around datacenters and tech, the car industry easily predates the computer industry and operates on a lot tighter margins and a lot stricter regulations.
So having a smaller, simpler chip that ultimately costs less physical resources at scale and is simpler to test is better when you’re planning on selling millions of units and you need to prove that it isn’t going to fail and kill somebody. Or, if it does fail and kill somebody, it’s simpler to analyze to figure out why that happened. You’ve also got to worry about failure rates for things like a separate RAM module not being seated properly at the factory and slipping out of the socket someday when the car is moving around.
Now - yes, modern cars have gotten more complex, and are more likely to run some software using Linux rather than an RTOS or asic. But the original complaint was that a backup camera adds non-negligible complexity / cost.
For a budget car where that would even make sense, that means you’re expecting to sell at high volume and basically nothing else requires electronics. So sourcing 1GB RAM chips and a motherboard that you can slot them in would be complete overkill and probably a regulatory nightmare, when you could just buy an off-the-shelf industrial-grade microcontroller package that gets fabbed en masse, dozens or hundreds of units to a single silicon wafer.
Your CPU's L4 cache is normally DRAM, and it's cheaper to shove some RAM into a microprocessor than to have a separate chip.
I simply refuse to believe the cost difference between a CPU with hundreds of megs of DRAM is cheap enough to be an appealing choice over the same chip with a gig of RAM. We're not talking about a disposable vape with 3kb of RAM, this is a car that needs to power a camera and sensors and satellite radio and matrix headlights or whatever. If it's got gigahertz of compute, there's no reason it's still got RAM sized for a computer from 30 years ago.
The original comment was complaining about backup cameras seemingly adding significant electronics requirements.
In practice, you’re not going to tie intimate knowledge of the matrix headlights into the infotainment system, that’s just bad engineering. At most it would know how to switch them on and off, maybe a few very granular settings like brightness or color or some kind of frequency adjustment, not worrying about every single LED, but I can’t imagine a budget car ever exposing all that to the end user. Even if you did, that would be some kind of legendarily bad implementation to require a gigabyte of RAM to manage dozens of LEDs. Like, is it launching a separate node instance exposing a separate HTTPS port for every LED at that point?
Ditto for the satellite radio. That can and probably is a separate module, and that’s more of a radio / AV domain piece of tech that’s going to operate in a world that historically hasn’t had the luxury of gigabytes of RAM.
Sensors - if this is a self-driving car with 3D LIDAR and 360-degree image sensors, the backup camera requirement is obviously utterly negligible.
Remember, we had TV for most of the 20th century, even before integrated circuits even existed, let alone computers and RAM. We didn’t magically lose the ability to send video around without the luxury of storing hundreds of frames’ worth of data.
Yeah, at some point it makes more sense to make or grab a chip with slightly more RAM so it has more market reach, but cars are manufactured at a scale where they actually are drivers of microcontroller technology. We are talking about a few dollars for a chip in a car being sold for thousands of dollars used, or tens of thousands of dollars new.
There is just no way that adding a backup camera is an existential issue for product lines.
Not all of those systems will be running from the same hardware controllers.
Back in the mists of time, we used to do realtime video from camera to display with entirely analog components. Not that I'm eager to have a CRT in my dashboard, but live video from a local camera is a pretty low bar to clear.
Yeah, I cannot understand why people are thinking a gigabyte of RAM in this context save for their context being imagining what this would take with a python HTTPS server streaming video via WebRTC to an electron GUI running out of local docker containers or something. Because that ought to be enough memory for a hour of compressed video.
It’s like saying your family of four is going to take a vacation, so you might need to reserve an entire Hyatt for a week, rather than a single room in a Motel 6.
> I cannot understand why people are thinking a gigabyte of RAM in this context save for their context being imagining what this would take with
Who's people? It isn't me, I was rounding to the nearest positive integer. And bastawhiz is arguing in the abstract about RAM prices so I don't see how they fit this complaint either.
> It’s like saying your family of four is going to take a vacation, so you might need to reserve an entire Hyatt for a week, rather than a single room in a Motel 6.
From my point of view, it's more like each room only holds one person so you can't just say "a room" (megabyte), and renting a whole hotel would only be 0.1% of the total vacation budget, so I simplify it and just say "rent a hotel" (gigabyte). It doesn't mean I think it's necessary, it means I'm pointing out how cheap it is and don't need to go deeper.
I tried to think of a wording that wouldn't get this response, I guess I failed. Ram is generally bought in gigabytes, "1 or less" is as low as numbers go without getting overly detailed.
So what microcontroller do you have in mind that can run a 1-2 megapixel screen on internal memory? I would have guessed that a separate ram chip would be cheaper.
https://wiki.st.com/stm32mpu/wiki/How_to_display_on_HDMI
But mostly it’s the fundamental problem space from an A/V perspective. You don’t need iPhone-grade image processing - you just need to convert the raw signal from the CMOS chip to some flavor of YUV or RGB, and get that over to the screen via whatever interface it exposes.
NTSC HD was designed to be compatible with pretty stateless one-way broadcast over the air. And that was a follow-on to analog encodings that were laid down based on timing of the scanning CRT gun from dividing the power line frequency in an era where 1GB of RAM would be sci-fi. We use 29.97 / 59.94 fps from shimming color signal into 30 fps B&W back when color TV was invented in the early-mid 1900s, that’s how tight this domain is.
> https://wiki.st.com/stm32mpu/wiki/How_to_display_on_HDMI
That board has a DDR3 chip on it. Is there one with HDMI that doesn't?
> But mostly it’s the fundamental problem space from an A/V perspective. You don’t need iPhone-grade image processing - you just need to convert the raw signal from the CMOS chip to some flavor of YUV or RGB, and get that over to the screen via whatever interface it exposes.
> NTSC HD was designed to be compatible with pretty stateless one-way broadcast over the air. And that was a follow-on to analog encodings that were laid down based on timing of the scanning CRT gun from dividing the power line frequency in an era where 1GB of RAM would be sci-fi. We use 29.97 / 59.94 fps from shimming color signal into 30 fps B&W back when color TV was invented in the early-mid 1900s, that’s how tight this domain is.
If you're getting a signal that's already uncompressed TV-like then you probably don't need a processor at all. But I didn't want to assume you're getting that, running a multi-Gbps signal over a wire in a very hostile environment.
The more generic solution needs the ability to hold a couple frames in memory. Which probably means a ram chip. Please don't focus so hard on the way I rounded the number. The point was that it's a negligible number of dollars. And you can use a much smaller chip than a gigabyte, but that doesn't save a proportional amount of money and the conclusion is the same, negligible amount of dollars.
I guess I could have said "gigabit". Anything that got into specific numbers of megabytes would have been pointless detail. And it's megabytes minimum if there's a frame buffer.
As someone who can only afford cars that are 10+ years old, i've never owened a car with a backup camera. And in a way-- good. That part of my brain, let it continue to develop. I am much better at "feeling out" where a car is than my friends who rely on back up cameras.
Sure, and you may as well walk around with a blindfold on to develop your "spidey" senses too.
I understand your skepticism 100%, but I suspect you might change your mind if you, say, rented a car with it for a week. It's definitely a net positive for safety, and it probably costs the auto maker less than the seat belts (literally).
I've owned cars with backup cameras since about 2014. I still mostly back up the old fashioned way, and really only use the camera for very tight situations where a few inches matter.
ive owned two cars. the modern backup camera means the new one has small "stylish...." rear windows. it is wayyyy more dangerous than the older one with no sensors
i only have those two data points; but give me an older car with larger windows every. single. time.
Being good at driving doesn’t fix the huge blind spot you have behind your car
unless you're Yoda or Luke Skywalker, you're not "feeling" a 4-year old walking behind you in your blind spot.
If they are feeling it, the worst scenario has happened.
like a vehicle touching a body in a speed of 3/4 km/h and the kid shouting or stepping away? or worst case your motion sensor beeping?
how much the conversation diverts on a commentary about someone not wanting a car shipped with an OS capturing telemetry even of farts on the right back seat
This is one of those proverbial regulations that are written in blood. So no, that's not the worst case.
I used to be ornery about this but having a camera mounted on the back of the trunk that can see all the way down both ways of the aisle is actually a huge boon when backing out of a spot. Especially if I am parked next to something that is taller than my golf, which is most vehicles.
This is what changed my mind too. I was firmly in the “can’t you just learn to drive?” camp before.
I can use my eyes and look around but I can’t see through objects.
The camera and sensors have an incredibly wide view. I only have to get my rear end out a few inches to be able to see everything I couldn’t before. Pray and pull out isn’t very safe.
Backup camera are insanely nice. Modern cars give you things that even great awareness won't give you. The bird's eye view you get with multiple cameras is sheer magic.
It's not just ginormous SUVs with this problem, though, right? You're not going to see a 18 month old out the back window of your compact hatchback if they're too close to your car. Especially now that windows seem to be tinier than they used to.
No, it's common to all vehicles. You can't see small children behind a small passenger car, either.
Blaming trucks and SUVs for everything is a favorite pasttime of internet comments, but all vehicles benefit from backup cameras and collision detection sensors.
The US averages 23 pedestrian deaths per million people per year. The EU averages 8. The US fatalities have increased by 50% since 2013, while in the EU have decreased by 25% in the same time frame.
https://www.cdc.gov/mmwr/volumes/74/wr/mm7408a2.htm
What does this have to do with the comment you're replying to?
The US was ahead of the EU in requiring backup cameras on new vehicles.
The majority of pedestrian accidents aren't involved with backup cameras.
Are you just trying to turn this into a US vs EU argument?
i think they're talking about the types of cars popular in the us vs. the eu.
They're talking about pedestrian accidents. If they had some deeper connection to make, it wasn't communicated.
While I think it's more because of the speed difference in cities. In EU you just can't drive fast, because it's crowded. In the USA you have way more space to drive speed limit
What’s really crazy was Trump forcing the UK to change road safety rules so they could sell more American pick up trucks in the UK.
So pedestrian deaths would start rising again.
I'm having trouble imagining American pickup trucks fitting on the road in the UK. Aren't the lanes and the cars all much narrower?
You’d think people would buy cars that fit the streets. And yet I see more than a few people with American pickup trucks on the streets.
> The US averages 23 pedestrian deaths per million people per year. The EU averages 8.
Americans drive significantly more miles per year, and larger/more comfortable cars are in part needed because Americans spend far more time in their cars than Europeans.
Euro governments are also increasingly anti-car, which means citizens are loosing their freedom to travel as they wish and unreasonably taxed, policed, and treated like cash cows for the "privilege" of driving.
> which means citizens are loosing their freedom to travel as they wish
Most of my European friends brag about how they can get anywhere via train and how much more comfortable it is to travel that way. When I visit Europe I have to agree. Just haven't really seen this viewpoint, though I do think I would feel this way as an American if I moved to Europe to some extent (though I'd be extremely happy to have viable mass transit).
Collision detection sensors do the job just fine without a screen though.
I have a 2016 vehicle with no console screen and they have saved me from hitting all sorts on things, and are sensitive enough to detect minor obstacles like long grass.
I think the difference is that a 3 year old barely-walking child tends to wander behind moving cars far less often than an 8 year old playing football.
1-4 year olds are the age group most likely to be injured in this type of incident.
https://www.cdc.gov/mmwr/preview/mmwrhtml/mm5406a2.htm
I suspect older children are more likely to be able to be aware of their surroundings and have better gross motor skills to react.
That could be true but the 8 year old gets out of the way. I can remember two incidents on the news where a toddler was killed in a driveway. Tragic.
Right, backup cameras make sense even for sedans and other small cars. The high-hood trucks and SUVs in the US are the reason we'll probably get mandatory front cameras eventually as well.
It's a little ironic that the truck that diverged from the trend for high butch looking hood lines for no real reason is... Cybertruck. We kill pedestrians in the name of macho.
The front camera is the best thing I added to my 2004 Prius. The hood on that car is very good for visibility, but with the birds eye cameras I can roll it up within centimeters of things in front of me (there's a slight risk that you can absolutely poke the nose under stuff but at that point it's quite obvious out the windshield too).
Why are infants materialising out of nowhere behind cars? There must be something else going on here.
When I reverse, there can't possibly be something behind my car, because I've just driven forwards over that area. When I begin to reverse, I'm looking all around behind and I'll be able to see if an infant, or dog or whatever, runs into the path I intend to take.
A lot of people tend to drive forwards into parking spaces then reverse out. I've no idea why, because it's far easier to reverse in then drive forwards out. And I reckon much safer too. If people are sitting in their cars for extended periods then beginning to drive in reverse, I can see this being a problem. But there are also vehicles that you wouldn't be able to see an infant in front of the car either.
This has nothing to do with SUVs. A 3 year old is difficult to see behind ANY vehicle.
Personally I don't own a huge SUV, but I feel backup cameras are a godsend. You're so much better off looking from the point of the actual back of the car to judge the distance to the car parked behind you.
The perk of not having to twist your body around while steerins is also pretty nice.
Someone in another thread unironically called a midsized SUV a "matchbox". The vehicle in question has a size comparable to a Toyota 4Runner.
Was a great example of the ridiculous expectations some of us Americans have on ridiculously huge vehicles.
You can give people more. You cannot give people less.
That's it. That's all our problems.
deaths from people backing up over their kids predated "ginormous SUVs".
Wait until you hear what kind of vehicles the CAFE regulatory framework has incentivized US automakers to build.
This is ultimately the thing that needs to be fixed. The exemption for small trucks was stupid, and it should have been reserved for literal farm equipment (as that was intended). The fact that SUVs slip by on this now has created such a dumb market.
The OBBB Act passed by Congress last year eliminated the financial penalties associated with violations of CAFE standards, so there’s presumably no reason why automakers have to abide by them anymore, except possibly for concerns about future legislation.
It wouldn’t be HN without a commenter shoehorning the topic of a thread into proof of their pet problem. See also any topic even remotely tangential to city planning.
> In the US, no. Backup cameras are required by federal law as of 2018.
Backup cameras are required for new vehicles in a lot of markets: EU, Canada, Japan, and more.
So it's not just a US requirement.
The Slate truck has a small backup camera integrated into the gauge cluster, and many vendors implement it in the rearview mirror itself.
It doesn't need to be a giant infotainment display.
Backup cameras do contribute significantly to safety, to the point that I installed one in my 2002 vehicle with a cheap aftermarket head unit. The important thing to realize is that all the modern conveniences can be decoupled from the drivetrain. My $50 Android head unit does basically all the things that the OEM head unit on our 2018 vehicle does. It even does many things better.
The problem with modern cars is that everything is so heavily integrated and proprietary. If I swapped out the OEM touchscreen, apparently I would also lose the ability to set the clock on my instrument cluster. Now that this has become normalized, automakers have realized they can lock Android Auto/CarPlay behind a paywall and you’ll have no recourse but to buy one of those tablets that you stick on your dashboard and plug into the aux port. If your car still has an aux port.
I’m excited for the Slate, but unfortunately I have the feeling that the people who buy new cars aren’t the same people that want the Slate. The rest of us who keep our 20+ year old vehicles reliably plugging along don’t make any money for automakers.
> buy one of those tablets that you stick on your dashboard and plug into the aux port
Every single car I have been in in the last 5 years or so has Bluetooth. No need for aux ports in this day and age, especially when devices dont have headphone jacks anymore.
Are you stuck in the 2000's?
I still use headphone jacks on my phone, I wouldn't buy one without it. It is just more garbage to manage and more stuff to fix when it doesn't work. It takes half a second to plug in a cable and I don't gotta run around broadcasting a bluetooth signal which drains battery when not in use and takes as long to disable as pulling out a plug. Plus it is often lower quality than the cord.
Bluetoothing to your car is to me the same energy as using "wireless" charging stands for your phone. You are just replacing a physical tether with a less efficient digital tether of higher complexity for no actual gains.
I thought the same until my latest pixel refused to use the headphone jack to the car because it detected the hands free communications in the steering wheel as a microphone and decided to block audio out with notifications telling me to set up Google Voice Assistant first (get fucked).
GrapheneOS.org
On this site I read about Bluetooth security problems and then turn it off for a few months...
I've now seen that Android has an option to turn on Bluetooth every day... I turned it off.
Ford has the backup camera integrated with the mirror. So it is possible to have a dumb simple display vs an infotainment system.
> The intent of the law was to reduce the number of children killed by being backed over because the driver couldn't see them behind the car.
Wish they would do that for all the trucks with 5ft high hoods with no cameras.
Backup cameras are great for people who wear glasses. My visual cone is narrower, so I effectively have to turn my head 180° to see accurately enough, otherwise it's just a blur.
I find audible proximity sensors to be far more useful, as I can freely look around the vehicle while listening for the closest contact point.
Woah, really? I didn't know backup cameras were legally required now. Or have been. That's awesome.
Cameras are required, but not displays :~)
Yet everyone drives a truck and are incapable of seeing a child infront of their vehicle.
When I'm 5'11" and I often see trucks and SUVs whose hoods come nearly to my shoulder, it just boggles my mind. Of all the regulations around vehicles, I don't understand why "being able to see the road five feet in front of the vehicle" isn't one of them.
Because trucks are extremely popular, and frankly there is a cultural identity associated with them. Most people don't haul things with their truck, and if they do, it's very infrequently. BUT in American fashion, the optionality to do this partially drives purchasing decisions.
But that identity was crafted by marketing. It could just as easily craft another identity if required.
Because marketting doesn't really care about vehicle safety, they care about how cool and powerful it looks so they can sell it for a higher price.
JPY2690k($17,594) 2025 Honda `N-ONE e:`[0], 12km(7.45 mi), unregistered, 4 passengers, 29.6kWh battery, WLTP 295km(183 mi) of range, pack liquid cooling, has one-pedal, airbags, basic LKAS, rear seat ISOFIX, etc etc[2]
It's like, at least one exists in Japan, on used market even, if you absolutely have to have one, I guess
0: https://www.honda.co.jp/N-ONE-e/webcatalog/design/images/e_g...
1: https://driver-web.jp/articles/gallery/41396/36291
2: https://www.carsensor.net/usedcar/detail/AU6687733258/index.... | https://archive.is/gbBzc
Hahah super, ugly I love it. If only it was easy to import.
Ah sorry, I quickly edited that out of my comment! I had the video playing while posting, they were talking about a precursor project for embedded Flutter which this in some ways builds on, /that/ is running on the new RAV4.
One of the example uses given in the talk is 3D tutorials, which I could imagine being handy. Not sure I'd want to click on the car parts for it but with the correct affordances I could imagine a potentially useful interface.
I feel like "game engine" is a misnomer for what we're actually dealing with here. It's more like an "ECS-based scene rendering engine, which can be used for games or for advanced UI". But that doesn't have a succinct label yet.
I think "game engine" is a pretty succinct label for that. :)
We're all just waiting for the Slate for exactly that reason.
I was hoping it would be under USD 20k including all taxes but now rumors say likely NOT under USD 25k?
A Toyota Corolla starts at $23K. I think the "Under 20" and "Under 30" price points (a la the original Model 3 goal) are simply a thing of the past for any volume car with reasonable demand.
What you get for that $23k is now quite substantial though.
Power windows are standard. 169hp. Automatic climate control, central locking and key fobs, Automatic emergency braking and other radar based features. Digital gauge cluster. Modern infotainment. Modern crash safety, which is really good compared to 20 years ago.
That's a lot of car for $10k in 1996 dollars.
That's ignoring the $3k in fees, taxes, and whatever scam the dealer runs.
The reason we don't see more of it is that selling one $23k Corolla to one value minded shopper can't make line go up as much as selling one $60k MEGATRUCK to one easily influenced shopper. The new car market is exclusively for people who buy new cars regularly, and are therefore willing to get very bad deals for cars. The market is driven by people who self select for bad ability to parse value.
Yup. The expectations are set higher and to a point since cars are bigger for safety reasons (crumple zones, airbags) and have more pedestrian safety features like spring loaded hoods, it invited incremental additions until the new price points were set. A spartan 19K car isn’t going to sell as well as a CarPlay equipped 23K car.
No, it's better than that. Inflation adjusted, this $23k corolla costs less than a base model 1995 Corolla. That one had an MSRP around $12k
There has been real price decrease in small cars!
No there hasn't.
Wait until you see how cars are made now.
Comparing it to other products made by machines that actually have reduced in price since 1995 like kettles, LED lights, pc components, peripherals.
Cars should be far cheaper but they're not, and that's on purpose.
[dead]
The announced "under $20K" price was including the now-cancelled $7,500 EV subsidy.
That was based on the $7.5k EV subsidy. California will still give you $2.5k, though, so just over $20k.
Crazy to think had the federal subsidy not been cut, that car would be possible to get for around $15k. Unheard of.
well the website says "mid-twenties" so Id say more than a rumor.
> Can I just have an electric car that’s a car and nothing else? Seats, wheels pedals, mirrors, real buttons, no displays just a aux jack. I’d buy it, hell I might even take the risk and pre-order it
You can buy a tubular frame chassis for Beetle-based kit cars from a factory in the south of England, that's been adapted to take modern coilover suspension and an MGF or MGTF engine and gearbox, because Beetles are so rare that anyone wants to put the engine back into a Beetle.
I reckon with a minor amount of fettling you could squeeze a Nissan Leaf transaxle and a sufficient amount of batteries in, and still drop your Manx beach buggy shell over the top. Or any other shell you like.
You'd be running around in a solar-powered beach buggy. THAT is the future.
Part of what has made modern EVs successful in the wider market is the connected navigation system that knows your battery level, current consumption, planned navigation route, and what charging stations are available along the way.
To have a decent travel experience in an EV you'd likely at least need this data ported out to your phone via an OBD adapter or CarPlay / Android Auto integration with an in-car infotainment display.
Connecting via ODB? Come on. The car does not need any of that built into it. You can connect an app on your phone to handle all of that and just use the screen as a display. There is no need for a car to have a cellular connection just to give this functionality. That would also prevent the car from being able to communicate with the mother ship. If there's an update, have the app do that as well.
The point is that for your phone to provide accurate routing, it needs data from the car. Preferably live updating data.
Today this is done via an OBD Bluetooth adapter or via CarPlay/Android Auto APIs that allow the phone to get data from the car.
Funny, my phone can provide accurate routing data with out the car. What data from the car does the phone need to be able to accurately route? I'm at my desk no where near my car and it is working just fine
Current battery level and consumption, so that it can tell you whether you will make it to your destination with adequate charge left or insert charging stops where needed.
> ODB
Ol' Dirty Bastard? I jest, but I think the theory behind wanting an 'On-board Diagnostics' [1] connection would be to get data from the vehicle. You can get cheap bluetooth OBD-II adapters to transmit that info to your phone, it's not a given. I don't know much about electric cars, but if you want your phone to know the fuel level in an ICE vehicle then you'd need this kind of connection.
[1] https://en.wikipedia.org/wiki/On-board_diagnostics
I make typos like that lot. The one that is most common for me is CVS instead of CSV. No, this isn't a list of things to get from the drug store ::facepalm::
> Funny how “game engines” are now car parts in 2026.
Seems almost inevitable. Game engines end up supporting user interface elements and text with translations, but with an emphasis on simplicity, performance, and robustness. Many currently trending user interface stacks readily generate bursts of complexity, have poor performance even with simple usage, and are buggy and crash prone.
But once they replace gas engine with electric motor, car has NO engine. Gotta slip in a game engine.
I believe Tesla use/d Godot in their automative entertainment-instrumentation system.
"Nice car. What kind of engine does it have?"
"V8"
"Which kind of V8?"
Flat plane or cross plane? Cross plane cranks necessitate an asymmetric firing order, which produces the wonderful burble from US V8s. Flat plane is more common in Europe - think Ferrari - and has a symmetric firing order that produces a toneless metallic howl.
I was talking about the Chrome kind of v8.
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
Real buttons are more expensive than electronic. Not sure if you care, but people make that mistake more generally.
Game engines are probably trivially cheap to produce in 2026. You forget that Toyota sells 10M cars per year. In 3 years thats 30M cars. What does it cost each buyer for the game engine? 30 cents?
I can buy a 104 key mechanical keyboard for under $75 retail. That's 104 switches, 104 labelled button caps, a circuit board, controller and USB interface, with reliability likely much better than any other moving part found on an automobile.
That is very factually wrong. The reliability will be worse. That $75 keyboard is going to be used be hundreds of thousands of people, not millions. There is no safety involved. No one is testing to see how sunscreen and 50 other liquids interact with it. Dump a sugary drink on your car buttons, they will still work. Do that on your keyboard and it wont.
This only makes sense if touchscreens are reliable. They are not. You should look at the fault rates. Cheaper isn't better. In any case, we had cheap and good analogue before so let's not pretend like it's not possible. It might have been more expensive than a keyboard, but it wasn't dramatically different or we would have never had it. They just found a way to 1) reduce cost by going digital and 2) charging a premium for going digital as it was perceived as an upgrade by a majority of the market. They sold it to us, it's what they're good at. It doesn't mean it was a good idea.
Unity has a whole template and asset library for creating car displays.
https://unity.com/blog/industry/automotive-hmi-template-take...
And Unreal goes a whole lot further than that:
https://www.unrealengine.com/en-US/uses/automotive
> Real buttons are more expensive than electronic.
It might add up to a lot of money for the manufacturer who is cranking out thousands or millions of vehicles, but to the consumer buying one car it isn't a meaningful difference.
This is 10 year old outdated, but 10 years ago 1 button was ~1.00. Probably closer to $1.20 or $1.30. But sometimes buttons had 2 buttons on them, Those would go for $2.10-$2.30.
Then you had wiring each button wire I believe was $1. This wasnt 1 wire, but a few wires, power, ground, signal. Each button had them. This wasnt my job, so I didn't follow this price too much, but I asked the question at the time. I think going into the ECU, there is also a cost associated with it.
Anyway, you could assume 10 years ago, each button was $2. A car has 40-70 buttons? So its probably like $100 a car. Maybe $150 or $200 in today's money.
Also buttons and wires break, causing warranty problems.
At the time these vehicles were selling for under $20k at the bottom, and $40k at the top. So 1% of costs were buttons.
This doesn't even include the cost of hiring ~20 engineers to handle the buttons. ~6 people to check appearance and do testing... It doesn't include the assembly costs on the line. That 1% was just the cost of button + wire.
> Also buttons and wires break, causing warranty problems.
It's a good thing that doesn't happen to giant 15" integrated touchscreens. Imagine how much of a problem that would be!
> This doesn't even include the cost of hiring ~20 engineers to handle the buttons. ~6 people to check appearance and do testing... It doesn't include the assembly costs on the line. That 1% was just the cost of button + wire.
That doesn't make sense. $1 uninstalled might make sense for a fancy custom-molded button, even if it's too much for a generic button. (I'd rather have some generic buttons with labels than use a touchscreen, by the way.) But there's no way a few feet of signal wire and the proportional share of power wires get anywhere near $1 uninstalled.
Also I can find entire car stereo units with 15 buttons on them for $15? That kind of integrated button is cheap, has been common in cars for a long time, and can control things indirectly like a touch screen button if that's cheaper than direct wiring.
You are underestimating the quality you are getting with a car. The light colors match perfectly with science and experts. Its wild how much effort goes into it.
Your after market has not been tested to react with sunscreen.
But the whole argument was that it's too expensive. If impeccable color matching is too expensive then give me the cheapest button that won't break. Needing the touchscreen to adjust the A/C is more ugly than the worst looking button.
But also that kind of button doesn't need dedicated wires.
If only people bought a rag tag of aftermarket tier vehicles?
But for some reason people buy new nice vehicles and don't buy crappy new vehicles...
You missed my point entirely.
Touchscreen controls are crappy. They're less nice than ugly buttons.
(And of course people still buy cars with flaws. An entire car is an amalgamation of so many features that's it's hard to use purchases to measure people's reaction to the vast majority of specific changes. And features like controls often take longer than a test drive to evaluate, too.)
> Anyway, you could assume 10 years ago, each button was $2. A car has 40-70 buttons? So its probably like $100 a car. Maybe $150 or $200 in today's money.
I have a late 90s Range Rover. It has about 12 buttons on the dashboard, most of which I never have to bother with (they do things that turn on and off the fog lamps, which I don't need to use, or adjust the air suspension, which I rarely need to use). I turn the lights off and on, and I switch the heating from "normal" to "BLAST EVERYTHING ON, FRONT AND REAR DEMIST ON, SEAT HEATERS ON, EVERYTHING ON, EVERYTHING ON, EVERYTHING UP FULL, WE'RE AN AIR FRYER NOW" mode.
What do you actually need an LCD for in a car?
> What do you actually need an LCD for in a car?
Backup camera. They are required by law.
It doesn't have to be a LCD. Why not a CRT :)
I don't use that. It's silly and distracting.
From looking at some new car options lately, it seems like you're lucky if you can get floor mats for $200. This doesn't take away from your point - I suppose I'm just griping.
I don’t care. I want a simple car with simple parts that I can fix. Not this spaceship that we get now days. The 12v battery on my partners car had to be replaced, apparently it had to be “paired” in the shop and was not user serviceable wtf!?
The "pairing" probably makes sense if you deep-dive into the technical details. My guess is that the battery has software on it to improve performance, total life, whatever.
The real problem is that the whole is not designed to be user-servicable.
Kinda sorta the Slate truck - https://www.slate.auto/en
Their pitch is to ship a pretty minimal platform that you can customize up as you want it.
The last car that I remember being just an engine and seats was the Dodge Viper. I think some K class Japanese domestic vehicles are also likewise basic.
I loved the Viper, but its spartan interior and features list were its detriment.
That car is the Slate truck.
It’s a very small market, but yes you can. In Europe, the Citroen Ami is about that. Or the base Dacia Spring.
More expensive cars will have more electronic. They kinda want to sell them.
Slate auto is doing exactly that. They have pre-orders too. I'm waiting until I can test drive but it looks really interesting.
> a car and nothing else
sounds like slate:
https://www.slate.auto/en
It's flipped, so you now get a little petrol 4 stroke engine powering the game console in your electric car.
The dream. Although a map display would be nice to keep us from needing to fiddle with our phones. And backup camera
You’re describing the Slate truck. Really hope they deliver what they’ve promised.
First we got cars in game engines, and now we get game engines in cars too.
Cars should be a USB-C peripheral to a tablet that docks on the dash.
Given how many cars have Carplay or Android Auto, but also have their own e.g. Toyota app that you need to/ought to install, it feels as though this isn't that far off from how things basically are.
Personally, I'd be happy with some kind of situation where:
1. You have a small in-dash touchscreen, as most small sedans have these days, as the basic level of "backup camera and radio view" 2. Everything the car does has a physical button so you don't NEED to use the touchscreen 3. The car has a USB-C port that can power a tablet and which provides a standardized interface that e.g. iOS and Android can interface with, so that users don't have to worry about their new OS doesn't support the not-updated app, or the app doesn't support their not-updated device 4. Sell an optional tablet mount that attaches to the dash the way a built-in one would be 5. Sell an optional 'tablet' that does nothing but interface with the USB-C port and provide what it needs, in case someone wants a larger screen without having to buy an iPad Pro
Then again I don't drive, so I'd be happy with none of this also.
Honestly, I'd be okay with this, and then you can upgrade / replace said tablet if you wanted to. In an Alternate Universe, your iPad drives your car, your iPad Pro drives your car through hell and back, or whatever.
do you know about the slate truck? give it a search. it doesn't even come with speakers. or electric windows. or paint. it does have a backup camera afaik.
No because more basic cars have much lower profit margins while requiring higher volume and investors/capitalists will not accept that. Why earn 5% on their investment selling a million cars and building brand name when they can instead earn 20% on selling 100,000 cars at the expense of a brand name they never cared about maintaining in the first place? Brand tarnishment is something other smucks will have to deal with down the road, not the guys making these decisions right now who get performance "bonuses" and not the shareholders that want large returns.
Rivian uses the Unreal engine.
dawg idk how you have a car that's "electric" and also "basic." everything in an electric car is _necessarily_ mediated by software. if you want a simple car, you want combustion.
Basic does not mean "no software" it means "no cellular modem" and "no 15 inch tablet" and "no subscription based features"
There is functionally no difference between the powertrain of an electric road car and a brushless drill. How much software is there in your brushless drill? More than zero, far less than an electric road car.
I can build you this for $140k, I think. Interested?
The "interactive user manual" sounds neat. It probably doesn't need to be part of the car's computer.
Dear god do I not want to be trying to deal with an interactive user manual when pulled over on the side of the road trying to look up the lift point to jack the car up.
I guess they mean a car's console. Not a game console.
I think they do mean game console. The phrase "console-grade" appears right next to the word "game" (in "console-grade game engine") and the title "Console-grade 3D Rendering" on the page appears next to a selection of 3D scenes that seem like overkill for a car console.
The talk at Fosdem about it https://fosdem.org/2026/schedule/event/7ZJJWW-fluorite-game-...
For others who were curious like I was: The website doesn't mention "open" or "source" anywhere, but they did give a talk at FOSDEM 2026 about it.
There was a passing comment about "when we open up the GitHub repository" in the talk. So it's not open yet, but they've suggested it might be in the future.
The combination of Flutter + Claude Code makes cross-platform app development really, really fast. I've been impressed with how well Clause handles prompts like, "This list should expand on the web, but not on iOS." I then ask it (Claude) to run both a web instance and an iOS simulator instance. Can usability test in-tandem.
I recently (as in, last night) added WebSockets to my backend, push notifications to my frontend iOS, and notification banner to the webapp. It all kinda just works. Biggest issues have been version-matching across with Django/Gunicorn/Amazon Linux images.
How are you going to maintain all that when you find bugs if it generates a ton of code you did not get through to understand it?
You don't, and as long as you're comfortable with that you keep prompting to dig yourself out of holes.
The problem is unless your ready to waste hours prompting to get something exactly how you want it, instead of spending those few minutes doing it yourself, you start to get complacent for whatever the LLM generated for you.
IMO it feels like being a geriatric handicap, there's literally nothing you can do because of the hundreds or thousands of lines of code that's been generated already, you run into the sunk cost fallacy really fast. No matter what people say about building "hundreds of versions" you're spending time doing so much shit either prompting or spec writing that it might not feel worth getting things exactly right in case it makes you start all over again.
It's literally not as if with the LLM things are literally instantaneous, it takes upwards or 20-30 minutes to "Ralph" through all of your requirements and build.
If you start some of it yourself first and you have an idea about where things are supposed to go it really helps you in your thinking process too, just letting it vibe fully in an empty directory leads to eventual sadness.
That's also how you get security nightmares.
The way I use LLM's is that I design main data structures, function interfaces etc. and ask LLM's to fill them. Also test cases and assertions.
This. I find bringing in the LLM when there is a good structure already in place is better. I also use it sparingly, asking it for very specific things. Write me tests for this, or create me a function that does this or that. Review this, extend that etc.
They are pretty good at "scaffold this for me" and you adapt as a second step.
That is one of the three uses I give them.
The other two are: infra scripting, which tends to be isolated: "generate a python script to deploy blabla with oarameters for blabla...". That saves time.
The third use is exploring alternative solutions, high level, not with code generation, to stimulate my thinking faster and explore solutions. A "better" and more reasoned search engine. But sometimes it also outputs incorrect information, so careful there and verify. But at least it is successful at the "drop me ideas".
For big systems, generating a lot of code that I have no idea of what I end up with, that when I get bugs is going to be more difficult to modify, understand and track (Idk even the code, bc it outputs too much of it!).
Or for designing a system from zero, code-wise is not good enough INHO.
oh, a fourth thing it does well is code review, that one yes. As long as you are the expert and can quickly discard bs feedback there is always something valuable.
And maybe finding bugs in a piece of code.
Definitely, for designing from scratch it is not reliable.
Yes, I agree on all points. Also, I keep finding new use cases all the time. So, going all poetic; part of me laments the death of my craft, and the other rejoices at the superpowers of what rises from the ashes...
This reminds me of how some famous artists would paint via their studios wherein assistants put most of the pant on the canvas, under the direction / modeled off an example, and with the signature / embellishments of the named artist.
LLMs would not be popular if "spending those few minutes doing it yourself" part was true. In actuality it can be hours, days, or weeks depending on the feature and your pickiness. Everyone acts as if they are the greatest developer and that these tools are subpar, the truth is that most developers are just average, just like most drivers are average but think of themselves as above average. All of the sudden everyone that was piecing together code off of stackoverflow with no idea how to build the damn thing is actually a someone who can understand large code bases and find bugs and write flawless code? Give me a break.
To the degree that those same people are now writing 10-100x more code...that is scary, but the doom and gloom is pretty tiring.
The SO copy-pasting is actually quite accurate. The same folks are now just blindly generating code. That's why most software in the world is shit, and will continue to be in the future. There might just be more of it.
There will most definitely be much more of it, maybe machines are doing this on purpose to increase dependency on them haha. Ultimately, wagging a finger at someone will have no outcome, allowing someone to make real mistakes while vibe coding will be a much better learning experience. Someone that drops a prod database using Claude will have a very lasting memory of that(not saying that should be the goal, critical thinking obviously matters A LOT). Cars didn't used to have seatbelts, a lot of people died, then they got seatbelts and now the world is a better place.
The problem is maintenance and understanding code in the presence of bugs.
It looks very productive at first sight but when you start to find problems it is going to be a lot of fun on a production system.
Because basically you cannot study all the output that the LLM throws line by line if what you want is speed.
Which leaves reliability compromised.
Also, sometimes LLMs throw a lot of extra and unncessary code making things more barroquw than if you had sat down and thought a bit about the problem a bit.
Yes, you can deliver faster code with LLMs, maybe. But it is going to be good enough for maintenance and bug fixing?
I am not sure at all.
I never said anything against using LLMs. You're projecting.
Any engineer worth their weight will always try to avoid adding code. Any amount of code you add to a system, whether is written by you or a all knowing AI is a liability. If you spent a majority of your work day writing code it's understandable to want to rely heavily on LLMs.
Where I'd like for people to draw a line on is not knowing at all what the X thousand lines of code are doing.
In my career, I have never been in a situation where my problems could be a solved by piecing together code from SO. When I say "spend those few minutes doing it yourself" I am specifically talking about UI, but it does apply to other situations too.
For instance, if you had to change your UI layout to something specific. You could try to collect screenshots and articulate what you need to see changed. If you weren't clear enough that cycle of prompting with the AI would waste your time, you could've just made the change yourself.
There are many instances where the latter option is going to be faster and more accurate. This would only be possible if you had some idea of your code base.
When you've let an agent take full control of your codebase you will have to sink time into understanding it. Since clearly everyone is too busy for that you get stuck in a loop, the only way to make those "last 10%" changes is *only* via the agent.
I didn't say anything about your beliefs in AI, my statement was general. You're projecting.
It is still possible to write code with AI AND educate yourself on what the codebase architecture is. Even better, you can educate yourself on good software engineering and architecture and build that into making better specs. You can understand what the code is doing by having good tests, observability, and actually seeing it work. But if you're after peeping what every character is doing, I am not going to stop you!
LLMs are not reliable to fix bugs and when they do they often introduce new ones in my experience.
In fact, humans do targetted bug fixing reasonably well and knowing they did not change the structure of other code better than LLMs currently do in my experience.
I do not find them reliable enough TBH to leave such delicate tasks in a production system in their hands.
Yeah… I wonder how you write complex software without something that looks like a spec, other than slowly. It seems like the prep work is unavoidable, and this contrarian opinion you are offering is just that.
Writing the spec is becoming the default for pet projects. Which would be a good thing if the spec wasn't also partly written by an LLM.
You can already see people running into these issues, they have a spec in mind. They work on the spec with and LLM, the spec has stuff added to it that wasn't what they were expecting.
And again, I am not against LLMs but I can be against how they're being used. You write some stuff down, maybe have the LLM scaffold some skeleton for you. You could even discuss with the LLM what classes should be named what should they do etc. just be in the process so the entire code base isn't 200% foreign to you by the time it's done.
Also I am no one's mother, everyone has freewill they can do whatever they'd like. If you don't think you have better things to do than to produce 3-5 pieces of abandonware software every weekend then good for you.
Same as any other software team? You keep an eye on all PRs, dive deep on areas you know to be sensitive, and in general mostly trust till there's a bug or it's proven itself to need more thorough review.
I've only ever joined teams with large, old codebases where most of the code was written by people who haven't been at the company in years, and my coworkers commit giant changes that would take me awhile to understand so genAI feels pretty standard to me.
I love using AI and find it greatly increases my productivity, but the dirty little secret is that you have to actually read what it writes. Both because it often makes mistakes both large and small that need to be corrected (or things that even if not outright wrong, do not match the style/architecture of the project), and because you have to be able to understand it for future maintenance. One other thing I've noticed through the years is that a surprising number of developers are "write only". Reading someone else's code and working out what it's doing and why is its own skillset. I am definitely concerned that the conflux of these two things is going to create a junk code mountain in the very near future. Humans willing to untangle it might find themselves in high demand.
Strongly agreed.
And, as well as noticing actual semantic issues, it's worth noting where they've mixed up abstractions or just allowed a file to grow to an unsustainable size and needs refactoring. You can ask the AI agent to do the refactoring, with some guidance (e.g. split up this file into three files named x, y, z; put this sort of thing in x, ...). This helps you as a human to understand their changes, and also helps the AI. It also makes you feel in control of the overall code design, even though you're no longer writing all the details.
They'll often need a little final tuning afterwards (either by hand or ask the AI again) e.g. move this flag from x to y. As is often the case, it's just like you have an enthusiastic and very fast but quite junior dev working for you.
Maybe we should adapt cs studies to be more focused on debugging than creating code?
You ask it to fix it.
I've tried fixing some code manually and then reused an agent but it removed my fix.
Once you vibe code, you don't look at the code.
> Once you vibe code, you don't look at the code.
Truly one of the statements of all time. I hope you look at the code, even frontier agents make serious lapses in "judgement".
I loved learning Computer Engineering in college because it de-mystified the black box that was the PC I used growing up. I learned how it worked holistically, from physics to logic gates to processing units to kernels/operating systems to networking/applications.
It's sad to think we may be going backwards and introducing more black boxes, our own apps.
I personally don't "hate" LLMs but I see the pattern of their usage as slightly alarming; but at the same time I see the appeal of it.
Offloading your thinking, typing all the garbled thoughts in your head with respect to a problem in a prompt and getting a coherent, tailored solution in almost an instant. A superpowered crutch that helps you coast through tiring work.
That crutch soon transforms into dependence and before you know it you start saying things like "Once you vibe code, you don't look at the code".
And before you realize you're nothing more but a prompter ready to be displaced by someone cheaper.
I think a lot of people, regardless of whether they vibe code or not are going to be replaced by a cheaper sollution. A lot of software that would've required programmers before can now be created by tech savy employees in their respective fields. Sure it'll suck, but it's not like that matters for a lot of software. Software Engineering and Computer Science aren't going away, but I suspect a lot of programming is.
Ah yes, like no-code programming in the past, or what was it called again?
It's called Excel, and there's probably more logic written in it driving the world economy than in all the rest of the programming languages combined.
I've been around for a while. The closest we ever got was probably RPA. This time it's different. In my organisation we have non-programmers writing software that brings them business value on quite a large scale. Right now it's mainly through the chat framework we provide them so that they aren't just spamming data into chatGPT or similar. A couple of them figured out how to work the API and set up their own agents though.
Most of it is rather terrible, but a lot of the times it really doesn't matter. At least most of it scales better than Excel, and for the most part they can debug/fix their issues with more prompts. The stuff that turns out to matter eventually makes it to my team, and then it usually gets rewritten from scratch.
I think you underestimate how easy it is to get something to work well enough with AI.
I assume he’s mostly joking but… how often do you look at the assembly of your code?
To the AI optimist, the idea of reading code line by line will see as antiquated as perusing CPU registers line by line. Something do when needed, but typically can just trust your tooling to do the right thing.
I wouldn’t say I am in that camp, but that’s one thought on the matter. That natural language becomes “the code” and the actual code becomes “machine language”.
And you could say that the difference is that high-level languages are deterministically transformed down, but in practice the compiler is so complex you'd have no idea what it's doing and most people don't look at the machine code anyway. You may as well take a look at the LLM's prompt and make an assumption of the high-level code that it spits out.
> Once you vibe code, you don't look at the code.
And therein lies the problem
Honestly I'm not so strongly opiniated now as I was a few weeks ago. I'm in a huge questioning phase about my work/craft/hobby.
I've worked places where junior made bad code that was accepted because the QA tests were ok.
I even had a situation in production where we had memory leaks because nobody tried to use it for more than 20 minutes when we knew that the app is used 24/7.
We aim for 99% quality when no-one wants it. No-one wants to pay for it.
Github is down to one 9 and I haven't heard them losing many clients, people just cope.
We've reached a level where we have so much ram that we find garbage collection and immutability normal, even desired.
We are wasting bandwidth by using json instead of binary because it's easier to read when have to debug, because it's easier to debug while running than to think before coding.
I built a system that can hold 40,000 concurrent users with hardly 2 GiB of RAM, a bit of bandwidth (with a 300 Mbps connection it works great) using Capnproto and that I am scaling horizontally.
A server with 6 cores can hold at least 3 of these services. Now think of customers. How much you are going to save in operations? Loooooots! For backend efficiency and quality is still a critical metric, especially when operations are so cheap (tens of dollars per month).
The trick is to separate your codebase into "code I care about that I give the AI a fixed API and rarely let the AI touch" and "throwaway code I don't give one iota of damn about and I let the AI regenerate--sometimes completely from scratch".
For me, GUI and Web code falls into "throwaway". I'm trying to do something else and the GUI code development is mostly in my way. GUI (especially phone) and Web programming knowledge has a half-life measured in months and, since I don't track them, my knowledge is always out-of-date. Any GUI framework is likely to have a paroxysm and completely rewrite itself in between points when I look at it, and an LLM will almost always beat me at that conversion. Generating my GUI by creating an English description and letting an AI convert that to "GUI Flavour of the Day(tm)" is my least friction path.
This should be completely unsurprising to everybody. GUI programming is such a pain in the ass that we have collectively adopted things like Electron and TUIs. The fact that most programmers hate GUI programming and will embrace anything to avoid that unwelcome task is pretty obvious application of AI.
> push notifications to my frontend iOS
> It all kinda just works.
> Can usability test in-tandem.
Man, people say this kind of thing, and I go… really? …because I use Claude code, and an iOS MCP server (1) and hot damn I would not describe the experience as “just works”.
What MCP and model are you using to automate the testing on your device and do automated QA with to, eg. verify your native device notifications are working?
My experience is that Claude is great at writing code, but really terrible at verifying that it works.
What are you using? Not prompts; like, servers or tools or whatever, since obviously Claude doesn’t support this at all out of the box.
(1) - specifically, this one https://github.com/joshuayoes/ios-simulator-mcp
Claude set up my whole backend on AWS. That includes a load balancer, web server, email server, three application servers, and a bastion server to connect to their VPN.
It configured everything by writing an AWS Terraform file. Stored all secrets in AWS as well.
Everything I do is on the command line with Claude running in Visual Studio Code. I have a lot of MacOS X / Ubuntu Linux command line experience. Watching Claude work is like watching myself working. It blew my mind the first time it connected through the bastion to individual AWS instances to run scripts and check their logs.
So yeah, the same Claude Code instance that configured the backend is running inside a terminal in VS Code where I’m developing the frontend. Backend is Django/Python. Frontend is Flutter/Dart. Claude set up the WebSocket in Django/Gunicorn and the WebSocket in Flutter.
It also walked me through the generation of keys to configure push notifications on iOS. You have to know something about public/private key security, but that amounts to just generating the files in the right formats (PEM vs P12).
? How does any of that let you do QA against the mobile app?
> Can usability test in-tandem
…
> It also walked me through the generation of keys to configure push notifications on iOS.
??? You’re manually doing the testing and setup and not using AI for this?
Im confused at to what part of this mobile work claude is doing that “just works” for you.
I'd like to know too! I feel like many people are playing a whole different AI game than me, and I don't think I've written a single line of code since December (team experiment to optimize the vibe coding process)
Interesting, they flipped the problem around.
The UI toolkits in game engine usually suck hard, so here they started from a good UI toolkit and made it possible to make relatively performant games.
There's more info at https://www.reddit.com/r/programming/comments/1r0lx9g/fluori...
Qt Quick 3D in Qt is I guess a similar value prop.
They have a fun demo of a 3D shooter in it.
OK, I didn't know about this. This is cool.
Filament is not a console grade renderer, not even close. It's architectured around GL. Yes, it can use Vulkan but it's not in any way optimized like a console engine.
What is a console grade renderer? Specifically, what's considered table stakes and what is Filament missing?
GL is way more optimized then Vulkan style rendering on most devices today. If you speed test WebGL2 with WebGPU on a mobile device the difference is huge for rendering a simple PBR model.
This is a very interesting but also frustrating comment. If you're right that it's not a console grade renderer (not that I know what that even means) then that's really interesting - but why not? And could it be in future or is it fundamentally impossible for some reason?
Maybe they mean like the golden era of Xbox 360 rendering. Where the CPU and GPU could run together in one region of unified 512MB of memory with crazy fast rendering bandwidth. I wish there was a VR headset designed like that.
There is a hell of a lot more to a AAA+ game engine than just the renderer, to begin with.
I understand what your intent is in saying this, and I agree with the intent, but for onlookers, you don't really need a lot to make a good game and this would likely be just fine. I don't actually know if it's possible to ship GL games on modern consoles now that it's in-fashion to have your own proprietary graphics library. That said, the way Google has factored the back-end of the renderer, it won't take a PhD to target one of those GPU APIs.
Aside: GL is still a good practical choice for games built by small teams.
I guess it depends. There's no reason to promote this as "console grade" unless "console grade" means something more than, plain old 3d object renderer.
Certainly, you could define a console as an NES and the claim "console grade" but I'm guessing they are claiming "console grade" means, competitive with the renderer in games like Battlefield 6, Elden Ring, Horizon Forbidden West, etc.. Filiment is not up to those tasks.
Yes, you can make great games without the features of top console game graphics engines. But again, there's no reason for the hyperbole of putting "console grade" in the description then.
Yeah, it’s salesmanship. My feeling is that some amount of salesmanship is fine. This pales in comparison to a lot of promotion we see today. I mean this genuinely; maybe my standards have fallen too low? Perhaps I’m getting numb to it.
I wonder if a slightly broader search for existing solutions - for instance, https://defold.com - would have shown that quick-startup, 3d-capable, c-integrable, low-end-hardware performant game engines could have been grabbed off the shelf.
That said, this is cool and I would have probably celebrated a similarly fun project in their shoes. Perhaps the real accomplishment here is getting Toyota to employ you to build a new, niche game engine.
This is specifically designed to embed into Flutter apps, which have specific requirements how they interact with the GPU and renderer.
They already tried other engines, such as Unity. The team didn't just go off and build something without trying existing solutions first.
Toyota complained about poor performance on all of Unity, UE and Godot, but also about long startup times with Godot.
I don't know how bloated Godot is, but AFAIK libgodot development started as part of Migeran's automotive AR HUD prototype so I'm surprised to hear it has poor startup time for a car.
Godot is pretty lightweight (especially considering how powerful it is), generally about a second or less. But maybe they are looking for a fast enough startup time that the engine can be started when showing something onscreen and torn down when not visible. In which case, I can see the startup time being an issue.
> long startup times with Godot
As a user of libGodot embedded into our existing c++ tech stack, I can say we do not have this issue.
The fact that they tried other engines seems to imply that non Flutter options were... Options.
If literally the only option was an embedded flutter view, then there was never more than one viable solution and looking into unity etc was wasted effort.
It’s possible to integrate other things into Flutter.
However, it’s not easy. I think their options were either a popular mainstream library or a custom solution, not investing into something more obscure and less popular.
Having used both, the experience of building actual UI with Flutter is a breeze compared to building UI in any game engine. I can imagine that most of the usage of Flutter is leveraging the huge amount of work that was already done to get efficient and capable UIs done with just a stack of widgets.
Godot Engine has pretty good UI building tools.
The places where it poses challenges in my experience are high quality typesetting/rich text, responsive UI that requires a wide range of presentations (i.e. different layout structures on mobile vs desktop), and granular control over rendering details.
But for functionality-oriented UI, it's hard to beat its simplicity and scalability, particularly when you want to develop on one platform (e.g. computer) and have everything "just work" identically on other form factors (web/tablet/etc.).
For example, Godot's editor is bootstrapped/built in Godot, and runs natively on Web, Android, and Quest XR among other platforms.
"console-grade" is a stretch. They mean center console and not Xbox.
It's sad, but in the battle for a free ecosystem in video games, we must all join forces towards a single goal. IMHO, it's Godot.
the real free ecosystem is your programming language of choice, audio and graphics drives with I/O from the system
This definitely looks cool, flutter is still my tool of choice for small apps that aren't games, and I see a big company embrace it warms my soul.
Toyota assuming they move forward with this, might even become the main corporate sponsor since Google appears to be disinterested.
Does it mean it also runs in a browser? Why isn't there a demo?
It does look like Filament has a web target:
https://github.com/google/filament
but if they're targeting embedded systems, maybe they haven't prioritized a public web demo yet. If the bulk of the project is actually in C++, making a web demo probably involves a whole WASM side-quest. I suspect there's a different amount of friction between "I wanna open source this cool project we're doing" and "I wanna build a rendering target we won't use to make the README look better."
Someone asked in the Questions section at the end and they said No but they would be happy to discuss its possibility in a Github issue.
How is this related to Toyota? Toyota the car manufacturer?
I'm guessing its used for some of their in-car UIs - unreal engine has found a market (Rivian, Volvo, Ford...) for embedded automotive use now that so many cars display an interactive 3d model to the driver for things like tapping to unlock corresponding door or trunk etc etc.
> https://www.unrealengine.com/en-US/uses/hmi
Why is a full game engine needed to display a GUI for unlocking a door? There are endless simpler solutions. The apps I use every day don't use game engines (except games).
A game engine is sort of just a UI toolkit for interacting with 3d objects. If you want a 3d model you can interact with, you call that a game engine. Should they invent something new because they dislike the word "game"?
Worked for a shop that had the hardest time grasping this. We had to tell them UE4 was a "3D Rendering Engine" because they couldn't get over the term "game engine" in planning meetings...
I feel like Nvidia Omniverse's main innovation is that they call themselves an 'industrial metaverse platform' even though their product is practically not much different from a game engine.
Because you need and want all the fancy features such as
When everything is said and done this is the same bread and butter what game engines use so the industry has pushed to leverage those and spread to these markers. Both unity and epic have tried with but not without issues.Game engines, UI frameworks, desktop environments, and web browsers all share a lot of features. The Arcan project is my favorite piece of software running with this idea rn
Because modern cars compete with animations that amaze users/buyers.
In either way, it will be open source and quite fun to build stuff on top.
The market for automotive features in the US diverged from "need" long ago.
Yes, that Toyota. Looks like it came out of this group. https://www.toyotaconnected.com/about
https://en.wikipedia.org/wiki/Toyota_Connected_North_America
it'actually Toyota Connected North America, Toyota Motor Corporation's subsidiary founded in collaboration with Microsoft for working on in-vehicle software, AI, and related tech initiatives.
So basically the same sort of thing Samsung does with its corporate subsidiary. At least that's the first one I think of. But I know there others who leverage the brand all the way down the ladder.
They needed a GUI toolkit for dash display, and didn't really like long engine init time of Unreal/Unity/Godot.
Was bevy considered?
I don't think anyone's seriously using Bevy's 3D renderer, only the ECS. The only successful 3D game made with Bevy so far seems to be Tiny Glade, which used its own renderer.
I'm surprised Toyota even used something as new-ish as Flutter. Carmakers usually are the last to adopt anything.
Bevy is the opposite of an old boring solution. It's a cool engine, but I imagine a manufacturer would like to have long-term support with 15-year timelines. Bevy doesn't offer that, and even trying to have that wouldn't be good for Bevy.
Tech is becoming front and center to car sales. Adopting newer technologies is probably seen as a necessary risk to stay competitive.
Bevy releases have a lot of breaking changes, and so do many of the 3rd party plugins.
Yes. Had to look it up, but apparently it was developed by TCNA (Toyota Connected North America) which does car software and such.
Interestingly this name (fluorite.game) is in the HaGeZi normal blocklist. https://adguardteam.github.io/HostlistsRegistry/assets/filte...
[dead]
They are likely avoiding Godot because it is written in C++ and cannot run directly inside their browser-based JavaScript runtime environment.
They dont want a build process.
(was this meant to be a reply to one of the other Godot comments?)
The page says that it's "Powered by Google's Filament renderer" which is written in C++, and that Fluorite itself has "a data-oriented ECS (Entity-Component-System) architecture ... written in C++".
Also, although Flutter/Dart applications can run on web (compile to WASM or transpile to Javascript) and so can Filament, the Fluorite FOSDEM page says target platforms are "mobile, desktop, embedded and console platforms" so it's not clear Fluorite even cares about running in browser.
Isn't this a C++ app that authors UI in Dart? I don't see anything about a browser.
Flutter keeping Dart alive as always
It's quite genuinely a pleasant language.
I was learning it and having a great time with it. Unfortunately the job market for it is abysmal. And in 2026 with the current state of the job market I didn't want to focus my time on something that wouldn't help me to get a job. But still the most fun I have had with a language.
source code not available?
Should soon be available from what it seems.
[dead]
Now we’re talking. If Flutter is dying, how come I still see projects like this popping up instead of using native or KMP?
It is interesting to see players other than Google invest in it.
Makes me wonder if you might eventually see the OG Flutter team move to a shop like Toyota, the same way the original React team moved to Vercel. It's nice to see open source projects be portable beyond the companies that instigated them.
Google is still investing heavily in flutter. Not sure why folks would move to Toyota.
If Flutter is dying, so is React Native, if Google Trends is any metric to go by. Flutter has nearly double the search volume over the past 5 years.
Flutter is probably still growing. Definitely not dying but it'll probably plateau at some point this year.
Who said flutter is dying? It's more popular than ever.
Comments is more about RAV4 than game engine itself.
> console-grade
So... not PC-grade?
Rust based ECS game engine, with 3,000 word diatribes about what decentralized, federated social media presence it should have, woefully incomplete, full of bugs, with no consideration of how any actual games are written other than Factorio, because that's the game that programmers who write open source game engines and not games play: "Aww, you're sweet"
Something about games authored by a giant company that will presumably actually ship in some products: "Hello, human resources?"
Performance looks horrible in their demos.
Which console is the rendering the grade of? PS5, Xbox 360 or Atari 2600?
A console is a crippled PC, so what does console-grade mean here?
Looked great. How is it associated with toyota?
Meh.
I've been burned by using closed source game engines before. There's just too many edge cases and nuances that come up when debugging physics or graphical issues. I strongly recommend against using this until they become at the very least source-available.
Seems like it will be open-source if they are presenting it at fosdem. They said it will have a github. It's currently unreleased.
[dead]
[flagged]
[flagged]
I was impressed with how well flutter took function/react style and married it with OO, the rendering seemed to make anything possible and clean. Dart is good, just the threading model seemed awkward. Can't say I dove too deep though.
[flagged]
This trend of "complexity == moar gooder" makes me itchy. Why does a vehicle display system need a whole-ass game engine? I want my high-speed death box to have utilitarian, well-tested and well-written software, not fucking Unity.
Please stop, all this does is introduce new ways for things to break.
Not written in rust? No thanks