Vehicle Software Company Marble Labs Announces Potential FFB Replacement Tech

Marble-Labs-Haptic-Architecture.jpg
Image: Marble Labs
Force Feedback is essential to enjoying sim racing. US-based vehicle software company Marble Labs attempts to turn this aspect of our favorite hobby on its head with a newly-announced haptic architecture.

After first appearing in arcade racing games as early as the 1980s, Force Feedback has conquered sim racing at least since 1997 when Microsoft introduced its Sidewinder Force Feedback Wheel - generally considered to be the first FFB wheel available to consumers.

While the hardware for has evolved considerably since then, the software-side evolution of FFB has not seen jumps that have been quite as drastic - although the current crop of racing sims certainly is leaps and bounds ahead of the titles of yesteryear thanks to a combination of both.

However, Las Vegas-based vehicle software company Marble Labs wants to get things moving at quite a drastic pace. It has patented "a revolutionary vehicle dynamics engine and haptic architecture", according to their press release (the full version of which is attached to the end of this article).

Having developed software for Advanced Driver Assist Systems and Automated Driving solutions, the company is now trying to tackle sim racing via a rethink regarding haptic feedback relayed to the player. Marble has patented a system called 'Position Control Haptics', which "delivers a pure, physics-based, accurate output that is not dependent on a pre-determined effects-based haptic architecture - the first patented alternative to force feedback, an archaic 30-year-old standard."

An All-New Way To Feel Racing Sims?​

To support the system, Marble is developing three further technologies. The press release explains them as follows:

  • Digital Contact Patch™ (DCP) provides breakthrough surface awareness to quantify the driving surface as never before. After decades of development, today’s driving games still consider a single grip value per surface per tire (with up to 8 points of resolution) state-of-the-art. Marble’s DCP utilizes over 16,000 points of resolution and grip in each contact patch, which is processed in real-time — it’s where the rubber meets the road.
  • Dynamic Multi-Surface™ (DMS) provides an unparalleled road feel. DMS is Marble’s proprietary virtualized geometry system that increases surface detail far more than what’s been possible before in a real-time driving simulation — no more predefined static surfaces. The dynamic surface types and real-time surface wear and deformation provide infinite variability in the driving experience — bringing the road to life.
  • Unlimited Drive™ provides an unconstrained virtual playground for all drivers by combining Marble’s simulation platform with Google Earth — delivering the driving world to the desktop. The proprietary platform offers an unlimited user-definable vehicle simulation experience based on expansion modules and content creation tools (UGC).

On paper, this sounds like a remarkable step up in how sim racers will be able to feel a car and how it interacts with different surfaces, which are ever-changing depending on how they are driven on. And if the promises of the Unlimited Drive system hold true, it might be the answer for those sim racers who long for a proper open-world driving simulation.

Marble Labs Co-Founder Chad Laurendau explains: "Anyone with behind-the-wheel experience should be able to enjoy a high-speed digital driving experience. And those with track experience should be able to turn fast, consistent laps and aggressively drive the car… dancing on the pedals to modulate weight distribution, tossing it into corners, and using the curbs to rotate the vehicle."

With the goal of a more natural feel for driving and racing simulations, Marble Labs certainly has lofty ambitions for the systems they are devloping. Demo videos of the systems in action are already available on the company's YouTube channel. We have embedded one with a yet-to-be named NASCAR driver at the wheel below.


More Big Physics Strides?​

With physics as in-depth as this, the question of hardware performance inevitably comes up. Should it require a high-end PC to run, they might not be able to take off in the short term. Then again, developers have found their way around hardware limitations for decades, so it will be interesting to see if the developers can implement a solution.

It is certainly an exciting time for sim racing developments, as Marcel Offermans' The Last Garage demonstration turned heads at the beginning of the year. The engine of the former Studio 397 dev also promises big strides in sim racing physics and was met very positively at Sim Formula Europe 2024, where visitors could try an early build of the project.

What do you make of Marble Labs' announcement and intentions? Let us know on Twitter @OverTake_gg or in the comments below!

Marble Labs introduces a revolutionary vehicle dynamics engine and haptic architecture, redefining the world of high-performance simulation for digital driving enthusiasts​


Marble’s technology delivers a pure, physics-based, accurate output that is not dependent on archaic 30-year-old “Force Feedback” (FFB) effects-based haptic architecture.

Patented Position Control Haptics™ (PCH) is a revolutionary haptic innovation that is a watershed in freeing vehicle simulation. It is complemented by a suite of innovative driver-focused technologies, including Digital Contact Patch™, Dynamic Multi-Surface™, and Unlimited Drive™.

Marble’s platform is the first PC-based driving simulation to deliver a real-world immersive environment with an honest vehicle feel, natural vehicle dynamics, and authentic haptic feedback.

VIDEO – Marble Labs Simulation Alpha Testing with Professional NASCAR Driver

LAS VEGAS, Nevada, May 14, 2024 — Marble Labs, a Tier 1 vehicle software company that engineers and deploys innovative tools for autonomous systems and software-defined vehicles based on its patented technology, is releasing a consumer-grade PC-based version of its high-performance driving simulation platform for digital driving enthusiasts to experience.

Every consumer driving simulation today uses decades-old technology masked with high-resolution graphics, audio, and hardware. While flashy 4K screens, surround sound, and full-motion rigs improve immersion, they don’t alter the synthetic driving experience — leaving driving enthusiasts yearning for an authentic vehicle feel.

Marble’s patented Position Control Haptics™ (PCH) is a revolutionary haptic innovation that is a watershed in freeing vehicle simulation. The technology delivers a pure, physics-based, accurate output that is not dependent on a pre-determined effects-based haptic architecture — this is the first patented alternative to “force feedback,” an archaic 30-year-old standard.

Pursuing real-world driving dynamics in a digital simulation, Marble Labs complements PCH with a suite of innovative technologies.

Digital Contact Patch™ (DCP) provides breakthrough surface awareness to quantify the driving surface as never before. After decades of development, today’s driving games still consider a single grip value per surface per tire (with up to 8 points of resolution) state-of-the-art. Marble’s DCP utilizes over 16,000 points of resolution and grip in each contact patch, which is processed in real-time — it’s where the rubber meets the road.

Dynamic Multi-Surface™ (DMS) provides an unparalleled road feel. DMS is Marble’s proprietary virtualized geometry system that increases surface detail far more than what’s been possible before in a real-time driving simulation — no more predefined static surfaces. The dynamic surface types and real-time surface wear and deformation provide infinite variability in the driving experience — bringing the road to life.

Unlimited Drive™ provides an unconstrained virtual playground for all drivers by combining Marble’s simulation platform with Google Earth — delivering the driving world to the desktop. The proprietary platform offers an unlimited user-definable vehicle simulation experience based on expansion modules and content creation tools (UGC).

Drivers experience a real-world immersive environment with an honest vehicle feel, natural vehicle dynamics, and authentic haptic feedback. It is the world’s first vehicle simulation platform that rewards driving skills, handling aptitude, and driving talent. “Anyone with behind-the-wheel experience should be able to enjoy a high-speed digital driving experience. And those with track experience should be able to turn fast, consistent laps and aggressively drive the car… dancing on the pedals to modulate weight distribution, tossing it into corners, and using the curbs to rotate the vehicle,” explains Co-Founder of Marble Labs, Chad Laurendeau.

Marble Labs’ philosophy is to upgrade how you drive in one click — drive better, faster, and more consistently against anyone, anywhere, on any device.

About Marble Labs
Marble Labs is a Tier 1 vehicle software supplier that provides authentic, accurate, and scalable tools to train and validate pioneering Advanced Driver Assist Systems (ADAS) and Automated Driving (AD) solutions for automotive OEMs, commercial operators, and the defense industry. Marble Labs’ patented technology provides a proprietary foundation for the company’s low-cost scalable consumer- and industry-focused tools that permit closed-loop simulations and crowdsourced data gathering with unlimited dynamic test environments. Founded in 2023, Marble Labs is headquartered in Las Vegas, Nevada.
Click to expand...
  • Like
Reactions: antonn, haunetal1990, fatal and 10 others
About author
Yannik Haustein
Yannik Haustein
Lifelong motorsport enthusiast and sim racing aficionado, walking racing history encyclopedia.

Sim racing editor, streamer and one half of the SimRacing Buddies podcast (warning, German!).

Heel & Toe Gang 4 life :D

More in Misc

Comments

H
Thanks for the insight @pai, what I meant with dynamic range was on the hardware side: the max frequency at which the motor force can actually oscillate.
If the control loop runs at at least double that frequency you should already be in a pretty good position to minimize error compared to a torque-sensor based loop
pai said:
Also, any CNC driver works primarily looking for position as targets, and that is the main branch of technology from where the DD systems come from. The limitations from the FFB loops we use in simracing titles nowadays lie strictly on the software side; the hardware handles it without breaking a sweat and with capabilities to do more if asked to.

Moving from FFB to PFB, in DD systems at least, is doable: it would require new firmwares developed from scratch to use the hardware power available via a different loop. But again, the ball would be on the software's field: they would have to write PFB code to output a different signal towards the hardware devices, and we don't know if developers will actively tackle this project.
Click to expand...
I understand most DD wheels have an internal control loop running at a much higher frequency, but if you use a PID loop to minimize the position error and recieve the target position at - let's say - 400hz my gut feeling is that when the wheel is rapidly rotating it may be difficult to make it smooth, since now the position can change at an arbitrary frequency thanks to user's external force, which may be above game's update rate, and it'd become a choice between FFB oscillations or PFB roughness.

Also using only position it becomes difficult to simulate "numb" steering wheel when you have no front grip, you need a way to tell it that there's very little force to bring the wheel in the target position.

pai said:
It's not like we are far from reaching the limits of what USB3 can do on simracing either: just running a Direct Drive wheelbase and a VR headset through the same controller, making both devices fight for the native bandwidth available, is enough to bring the controller to its knees and make for one of the devices to falter or stop working (or make others suffer if there is more than those two running through the same center), which is why several users owning both had to install dedicate PCIe boards with separate USB controllers to offload the data via different paths.
Click to expand...
That's actually a good reason, but most wheels and sim devices are still USB2, just doubling the bandwidth to send both force and position would still leave room to share a single USB3 port
Marcel Offermans said:
Not all titles are currently running their physics in the 300-400 Hz range. Remember AMS? That started out with 360 Hz like rFactor, but during its development it doubled that frequency to 720 Hz. Interestingly though, this actually caused issues with some FFB wheels that could not handle that speed. And these were not even the most low-end wheels either. I happened to own one, the first SimSteering wheel by Leo Bodnar. Through experimentation I learned that staying around 400 Hz for sending FFB updates for that one was about the maximum. So in real life situations, the FFB update rate might depend on your hardware.
Click to expand...
BeamNG has configurable FFB update rate up to 2khz, with a Simucube2 Sport I cannot set it above 1khz without extremely low FPS. Up to 750hz it's good, then FPS decrease pretty fast and FFB gets really bad. That's consistent on different CPUs (2600x, 3900x, 5800x3d) so I'd guess is up to the wheelbase.

In an ideal world there are more exact ways to do wheel control, but encoder VS load-cell, the first doesn't suffer from signal noise and can have better precision, and both current FFB and a new PFB control have to take slower-than-ideal update rate into account, which I think needs less wheelbase side filtering to be masked on a FFB (or hybrid) loop.
 
Last edited:
pz666
This is very interesting...

Given the constant back and forth about how much is too much on the subject of FFB, too many cues can really annoy some whilst not enough can annoy others, it's great to see some more new technology aimed at bridging the gap between our current FFB and tyres plateau and more realism in sim racing...

Rather than continued use of over a decade old ideas it's great to see something new to shake up the industry...

This and The Last Garage will definitely be on my radar going forwards...
 
P
hotak said:
Thanks for the insight @pai, what I meant with dynamic range was on the hardware side: the max frequency at which the motor force can actually oscillate.
If the control loop runs at at least double that frequency you should already be in a pretty good position to minimize error compared to a torque-sensor based loop

I understand most DD wheels have an internal control loop running at a much higher frequency, but if you use a PID loop to minimize the position error and recieve the target position at - let's say - 400hz my gut feeling is that when the wheel is rapidly rotating it may be difficult to make it smooth, since now the position can change at an arbitrary frequency thanks to user's external force, which may be above game's update rate, and it'd become a choice between FFB oscillations or PFB roughness.

Also using only position it becomes difficult to simulate "numb" steering wheel when you have no front grip, you need a way to tell it that there's very little force to bring the wheel in the target position.


That's actually a good reason, but most wheels and sim devices are still USB2, just doubling the bandwidth to send both force and position would still leave room to share a single USB3 port

BeamNG has configurable FFB update rate up to 2khz, with a Simucube2 Sport I cannot set it above 1khz without extremely low FPS. Up to 750hz it's good, then FPS decrease pretty fast and FFB gets really bad. That's consistent on different CPUs (2600x, 3900x, 5800x3d) so I'd guess is up to the wheelbase.

In an ideal world there are more exact ways to do wheel control, but encoder VS load-cell, the first doesn't suffer from signal noise and can have better precision, and both current FFB and a new PFB control have to take slower-than-ideal update rate into account, which I think needs less wheelbase side filtering to be masked on a FFB (or hybrid) loop.
Click to expand...
These are VERY interesting counterpoints :)

Maybe there is something I´m not getting, but is a torque sensor a must? Cannot the actual torque be determined livetime by a rapid calculation with voltage and current, while also inputting to the system beforehand the exact dimensional parameters (diameter and weights) of the rim and QR systems (or if we are talking about a closed ecosystem, detecting the rim and adding those parameters to the math automatically)? Because if this is not the case, my argument of just having new firmware goes down the drain in a blink, and new hardware would make this project an absolute no go for the commercial simracing market! I do understand that a high quality servo IS a must, and not all options in the market achieve this, as both speed and precision become (even more) paramount. The Small Mige with a BiSS-C encoder may still fit the bill though, but I can´t say with certainty.

Now, we definitely don´t want numb feeling, so maybe a new protocol should be able to combine both FFB and PFB instead of relying in just one, while at the same time removing the old 16 bit limitation from Direct Input? Hard to understand that just from the announcement, but from what you said at the beginning, the patent does not point at that being done. Meaning that the conversation remains interesting, but it´s not about this project anymore :)

Your test results with the SC2 BeamNG are very interesting, but I may ask: does that increase the tick rate of the whole engine? I´m not convinced that extrapolating calculations to force a higher FFB has any meaningful result and could even cause a set of problems of its own. But then, it would not be the first time I was wrong in this debate :p It would also be good to clarify if you had the SC2 running alone via a separate controller (cannot recall if it is a USB2 or 3 device).

The bit in bold is what I struggle to understand. AFAIK, update rates are mostly limited by physics engine designs first and computer hardware power second, with most FFB systems not being able to take advantage from higher rates a known problem but not center stage. I own an old OSW IONICUBE with a Small MIge coupled with a 2500ppr encoder. It`s coarse and brute, and quite a tool to determine how refined FFB comes from a simracing title, as it has little tools to correct, filter, amplify or mask certain signal characteristics. Some games are a real mess and outright dangerous for my wrists! My point is, from my experience the biggest limitations still lie on the software side. I will do that BeamNG test during this week or the next to find out what happens on my end though, it will add more data to this discussion.
 
T
Things are definitely getting interesting... You got Last Garage's sim project, this new one with a new proposed FFB system, you got ACE on the way sometime this year, good time to be a sim racer. Based on the alpha footage they seem to have the bones of something that could be decent.
 
H
pai said:
Maybe there is something I´m not getting, but is a torque sensor a must? Cannot the actual torque be determined livetime by a rapid calculation with voltage and current, while also inputting to the system beforehand the exact dimensional parameters (diameter and weights) of the rim and QR systems (or if we are talking about a closed ecosystem, detecting the rim and adding those parameters to the math automatically)?
Click to expand...
it's not a must, since the wheelbase can try to approximate it from how much the wheel accelerates given its own output torque, which is something I'm pretty sure it already estimates in its own internal control loop.
But if the game outputs a position it must get a force back, because a position-position loop won't work (at least I cannot think about how it could)

pai said:
Now, we definitely don´t want numb feeling, so maybe a new protocol should be able to combine both FFB and PFB instead of relying in just one, while at the same time removing the old 16 bit limitation from Direct Input? Hard to understand that just from the announcement, but from what you said at the beginning, the patent does not point at that being done. Meaning that the conversation remains interesting, but it´s not about this project anymore :)
Click to expand...
Yeah, there are a lot of ways to accomplish some sort of PBF, but in most cases the wheelbase should know some car-dependant parameters unless you give it some extra realtime info. As a Control Engineer I'm really enjoying this discussion because it brings up some very valid points about current FFB limitations but also makes me think that there's a reason why it ended up being the way it is - other options would be quite difficult to make.

pai said:
Your test results with the SC2 BeamNG are very interesting, but I may ask: does that increase the tick rate of the whole engine? I´m not convinced that extrapolating calculations to force a higher FFB has any meaningful result and could even cause a set of problems of its own. But then, it would not be the first time I was wrong in this debate :p It would also be good to clarify if you had the SC2 running alone via a separate controller (cannot recall if it is a USB2 or 3 device).
Click to expand...
I think BeamNG physics runs at 2khz for the soft-body part, so the FFB is most likely physics-based, the SC2 runs on USB2
pai said:
The bit in bold is what I struggle to understand. AFAIK, update rates are mostly limited by physics engine designs first and computer hardware power second, with most FFB systems not being able to take advantage from higher rates a known problem but not center stage.
Click to expand...
the update rate is indeed limited by physics frequency, still I think the game could run an higher rate on steering rack simulation just for FFB and get a better accuracy than what you can get from wheelbase's internal upscaling/filtering of the game's signal, since it knows its geometry and friction/damping (you'd probably get more latency tho, so not sure where the diminishing returns start coming). Hardware limitation is another issue I don't have enough knowledge to comment about.
 
Last edited:
P
hotak said:
it's not a must, since the wheelbase can try to approximate it from how much the wheel accelerates given its own output torque, which is something I'm pretty sure it already estimates in its own internal control loop.
But if the game outputs a position it must get a force back, because a position-position loop won't work (at least I cannot think about how it could)
Click to expand...
I agree with you there, just thinking out loud about possibilities of such implementation with the current simracing hardware. My guess is that maybe, just maybe, the wheelbase can calculate somehow the leverage you are inputting to it with the variation of voltage and current happening on the wheelbase (which would also need a certain previous parametrization), and output the corresponding torque into the simulation. Because if not, what you would need is a shaft-mounted torquimeter (kinda an engine dyno), which could be more expensive than the full servomotor! And that would make this protocol useless for commercial simracing market.

hotak said:
Yeah, there are a lot of ways to accomplish some sort of PBF, but in most cases the wheelbase should know some car-dependant parameters unless you give it some extra realtime info. As a Control Engineer I'm really enjoying this discussion because it brings up some very valid points about current FFB limitations but also makes me think that there's a reason why it ended up being the way it is - other options would be quite difficult to make.
Click to expand...
Now I understand why we can speak more or less the same language :) I'm no engineer, but I work for a living an Instruments Maintenance Officer. Regarding of why is the best way to go, I guess is because it's quite plug & play with the design of a servomotor. Perhaps not the best, but definitely the most simple. This discussion also seems to point at why moving away from it is not easy.
hotak said:
I think BeamNG physics runs at 2khz for the soft-body part, so the FFB is most likely physics-based, the SC2 runs on USB2
Click to expand...
Noted, thank you. I think it's a bit disappointing that such a high profile wheelbase has not went with USB3 directly. I guess they figured out that for most sims running at the said 300-400 hz range (not all of them do, as I was pointed to before, but most do) it was enough. But given that its design is overkill on every aspect, it would have been an interesting bonus to have and use for specific taxing tests like the ones you did.
hotak said:
the update rate is indeed limited by physics frequency, still I think the game could run an higher rate on steering rack simulation just for FFB and get a better accuracy than what you can get from wheelbase's internal upscaling/filtering of the game's signal, since it knows its geometry and friction/damping (you'd probably get more latency tho, so not sure where the diminishing returns start coming). Hardware limitation is another issue I don't have enough knowledge to comment about.
Click to expand...
Agreed, it's a shame that we are a bit limited at this nowadays, although I wonder if somebody like the guys at Granite Devices did not build a prototype on USB3 and ran it on a high frequency scenario to see how it handled. We would need for somebody like Tero Kontkanen to chime in, probably they would have something to tell.
 
R
Car behavior appears very nice and positive on the 2nd video on their channel. I hope it turns out as a finished consumer product.
 
Last edited:
Marcel Offermans
Premium
For those speculating about where Marble Labs is going and hoping for a consumer product, Michael Harley (co-founder of the company) writes on LinkedIn:
Today, Chad and I have partnered to create Marble Labs, a Tier 1 automotive software provider. We are currently raising seed capital for our market launch next year.
Click to expand...
Source: LinkedIn

So they are indeed just getting started, looking for funding, and focusing on the professional automotive market. But who knows, maybe some of that technology will make its way into consumer products.
 
Skinny McLean
Seeking seed capital to become a patent troll, perhaps? We are talking about a two-man company, started by a "vehicle software supplier" and another guy who worked in a bank for twenty years, before he in 2015 became a "Game physics and Haptics Engineer" (in his own company, which has seemingly vanished into thin air since closing in 2023) and was hit by a spark of ingenuity and invented - and patented - sim racing! (He has basically patented "a system comprised of" a PC, a sim and a connected force-feedback steering wheel.)

In 2024 he added "Unity Game Developer" to his impressive list of skills.

"The multiple patents held," as mentioned on one of the co-founder's LinkedIn page is practically the same "invention," plus some minor amendments in the claims section. The first one is, as mentioned, from 2015, the next The first two are from 2016 and the last from 2020. And they all bear the same title.

Edit: Corrected a year, and added source links.
 
Last edited:
P
Skinny McLean said:
Seeking seed capital to become a patent troll, perhaps? We are talking about a two-man company, started by a "vehicle software supplier" and another guy who worked in a bank for twenty years, before he in 2015 became a "Game physics and Haptics Engineer" (in his own company, which has seemingly vanished into thin air since closing in 2023) and was hit by a spark of ingenuity and invented - and patented - sim racing! (He has basically patented "a system comprised of" a PC, a sim and a connected force-feedback steering wheel.)

In 2024 he added "Unity Game Developer" to his impressive list of skills.

"The multiple patents held," as mentioned on one of the co-founder's LinkedIn page is practically the same "invention," plus some minor amendments in the claims section. The first one is, as mentioned, from 2015, the next from 2016 and the last from 2020. And they all bear the same title.
Click to expand...
Cannot remember the details, but some years ago there was some uproar as one company claimed they have the patent for haptic feedback, therefor demanding royalties for hardware builders and software developers for PC, consoles and even arcade machines. Don't recall how it ended, but it would be an useful case study.
 
Marcel Offermans
Premium
Skinny McLean
Yeah, Immersion Corporation is a good example of a patent troll. They thrive off how arduous and expensive it is to defend against the trolls and their bogus patents in a court of law (in the US, such cases are usually filed in a certain jurisdiction in Texas, where patent lawsuits apparently is a big business.)

Just take a look at the patent I linked to earlier. It's full of flowcharts and technobabble - it looks to me as if it was first and foremost designed to impress the lay person (such as judges and jurors.) I mean, is it really necessary to mention and explain things like memory-mapped files, multiprocessing, USB addressing and processor clocks and so forth in a patent application for a purportedly ground-breaking improvement in force-feedback technology?

Edit: @Marcel Offermans: Apparently, not all of their patents are expired. They sued Valve in 2023 for the vibration function in Valve's Index VR goggles and its Steam Deck.
 
Last edited:

Latest News

Article information

Author
Yannik Haustein
Article read time
3 min read
Views
4,911
Comments
33
Last update

Share this article

What is the reason for your passion for sim racing?

  • Watching real motorsport

    Votes: 413 69.2%

  • Physics and mechanics

    Votes: 261 43.7%

  • Competition and adrenaline

    Votes: 282 47.2%

  • Practice for real racing

    Votes: 124 20.8%

  • Community and simracers

    Votes: 165 27.6%
See comments…
Back
Top