wip Real-Time Body Physics (DirectX 11)

[CPVC]

8 hours ago, jeno3 said:

Hi CPVC,

 

Following up on my previous message

 

The Physics Conflict:
Because my custom mesh slopes backward and attaches higher at the bottom, the actual Center of Mass is shifted significantly closer to the chest wall compared to the default Maxis geometry.

Since the current angular physics assumes the default Maxis mass distribution, it calculates an incorrect, overstated angular inertia. This is why the breasts clip into the body during overbending—the torque calculation is overcompensating because the physics engine "thinks" the lever arm is longer and heavier at the tip than it actually is on this custom shape.

Feature Request: Inertia/Tensor Slider for CC Support
To accommodate these realistic shapes, the Inertia Tensor/Moment of Inertia range (especially for the X-axis/Pitch) needs to be scalable downward by about 30% to 45%.

Would it be possible to implement a dedicated slider in the In-Game GUI for the Inertia/Tensor settings? Having an interactive slider would allow users and creators to easily fine-tune the physics properties for different CC breast meshes directly in the game. Lowering the inertia value via this slider would perfectly compensate for the shorter effective lever arm of adjusted mass distributions and eliminate the clipping issues entirely.

Let me know if these numbers help you with tweaking the boundaries and if a GUI slider for CC compatibility is something you could add!

 

Perhaps a good solution, and worth testing? 

 

I'll look into something like that later, after I get the initialization bugs taken care of.

 

 

Everyone else, if you are one of those unlucky few that are unable to get RTBP running and have references to "OpenAdapter10_2" near the end of your log file in the stack trace near the very bottom, looks like this:

 

[RTBP.ERRO 00:00:0.04 19452] Uncaught exception: 
    _EXCEPTION_RECORD: EXCEPTION_ACCESS_VIOLATION (0xc0000005) at 000000000022DAE0
    #1 ???
    #1 ???: 0x7ffdd3562470 D3D11CreateDeviceAndSwapChain
    #2 ???: 0x7ffdd3562470 D3D11CreateDeviceAndSwapChain
    #3 ???: 0x7ffcd43bd930 D3D11CreateDeviceAndSwapChain
    #4 ???: 0x7ffcd43bd650 D3D11CreateDevice
    #5 ???: 0x7ffcd1288fc0 OpenAdapter10_2
    #6 ???: 0x7ffcd1286640 D3D11CreateDevice
    #8 ???
    ...

    
I wonder if you wouldn't mind testing something for me? Attached is a simple pass through build of RTBP that doesn't wrap the device, but just lets the function calls pass through, unmodified. If this works, the game should start up, just without RTBP being injected into the game. I just want to see if the problem lies within the device being wrapped or if there's something wrong with the way I'm forwarding the functions.

 

So if you would, could you give this DLL a shot and let me know if it works? If it doesn't, could you share your log file? It should be in the same location as usual.

 

Thanks for your help and thanks for the patience with this. This problem has been very hard for me to fix because I haven't been able to reproduce it on any of the computers I've tested RTBP on. I've been studying open source projects that work in a similar way as RTBP and most of them have these functions forwarded to the system DLL like I have done with RTBP, but for some unknown reason it's still not working. Thanks again.

 

Also, please try the second attached DLL too if you will. This one doesn't include any of the forwarded functions. I want to see what happens if they're not available. ReShade doesn't have the forwarded functions, nor does DXVK, so I'm not sure whether they're necessary or not. I'm getting conflicting information here.

 

RTBP Passthrough 2026-08-03.zip

 

RTBP No Forward Passthrough 2026-08-03.zip

[jeno3]

On 8/4/2026 at 7:45 AM, CPVC said:

 

I'll look into something like that later, after I get the initialization bugs taken care of.

 

 

Everyone else, if you are one of those unlucky few that are unable to get RTBP running and have references to "OpenAdapter10_2" near the end of your log file in the stack trace near the very bottom, looks like this:

 

 

[RTBP.ERRO 00:00:0.04 19452] Uncaught exception: 
    _EXCEPTION_RECORD: EXCEPTION_ACCESS_VIOLATION (0xc0000005) at 000000000022DAE0
    #1 ???
    #1 ???: 0x7ffdd3562470 D3D11CreateDeviceAndSwapChain
    #2 ???: 0x7ffdd3562470 D3D11CreateDeviceAndSwapChain
    #3 ???: 0x7ffcd43bd930 D3D11CreateDeviceAndSwapChain
    #4 ???: 0x7ffcd43bd650 D3D11CreateDevice
    #5 ???: 0x7ffcd1288fc0 OpenAdapter10_2
    #6 ???: 0x7ffcd1286640 D3D11CreateDevice
    #8 ???
    ...

 

    
I wonder if you wouldn't mind testing something for me? Attached is a simple pass through build of RTBP that doesn't wrap the device, but just lets the function calls pass through, unmodified. If this works, the game should start up, just without RTBP being injected into the game. I just want to see if the problem lies within the device being wrapped or if there's something wrong with the way I'm forwarding the functions.

 

So if you would, could you give this DLL a shot and let me know if it works? If it doesn't, could you share your log file? It should be in the same location as usual.

 

Thanks for your help and thanks for the patience with this. This problem has been very hard for me to fix because I haven't been able to reproduce it on any of the computers I've tested RTBP on. I've been studying open source projects that work in a similar way as RTBP and most of them have these functions forwarded to the system DLL like I have done with RTBP, but for some unknown reason it's still not working. Thanks again.

 

Also, please try the second attached DLL too if you will. This one doesn't include any of the forwarded functions. I want to see what happens if they're not available. ReShade doesn't have the forwarded functions, nor does DXVK, so I'm not sure whether they're necessary or not. I'm getting conflicting information here.

 

RTBP Passthrough 2026-08-03.zip 1.57 MB · 2 downloads

 

RTBP No Forward Passthrough 2026-08-03.zip 1.56 MB · 2 downloads

Hi CPVC,

I just tested the Passthrough DLL and it works exactly as you intended: the Game starts up perfectly fine, but all RTBP features—including the GUI and the physics—are completely disabled/absent.

Since it works on my machine, your function forwarding logic seems to be theoretically correct. The fact that it fails on other computers strongly points toward system-specific environment issues. Here are a few potential conflicts that the affected users should check on their end:

• Overlay Conflicts: They should check if programs like MSI Afterburner (RivaTuner), Discord, or GeForce Experience are running. These use the same hook method and can cause instant crashes when they clash with your DLL.
• Antivirus/Windows Defender: Users should check if their AV scanner or Windows Defender is silently blocking or quarantining the custom DLL, as injection behavior often triggers false positives.
• Windows/DirectX Builds: They might be on a different Windows 10/11 build or GPU driver that looks for specific, undocumented functions that aren't forwarded yet.
• Missing Runtimes: They should verify they have all Visual C++ Redistributables installed, which you and I likely already have.

I think you really need the log files from those specific users who are experiencing the crashes to see exactly which function or hook is failing on their systems.

 

[jeno3]

Hi CPVC,

I just tested the second DLL (no forward passtrough)  as well, and surprisingly, the game starts up perfectly fine too! Just like the first test, there are no physics and no GUI present, but the game runs without any issues or crashes.

This confirms that you are right about ReShade and DXVK: the forwarded functions are actually not necessary for the game to boot up in this setup. Windows seems to handle the fallback to the system DLLs correctly.

For your troubleshooting, this is great news because it completely rules out the function forwarding as the culprit for the other users' crashes. Since both versions work perfectly on my machine, the issue with the other players almost certainly stems from their local environment (like overlay conflicts, antivirus blocking, or specific Windows user permissions).

Let me know what your next steps are or if you have another build you want me to try!

[0Spirit0]

Sent 2 more logs to server, one with Passthrough, the other with No Forward Passthrough

Both CTD

[CPVC]

1 hour ago, 0Spirit0 said:

Sent 2 more logs to server, one with Passthrough, the other with No Forward Passthrough

Both CTD

 

Thank you. Do you have the Steam overlay enabled? If you do, would you mind disabling it and trying again? Thanks.

[alexlll]

Could you make it so that when the Sim moves suddenly, the chest moves slower, because the biggest glitches appear at this moment.

[jeno3]

14 hours ago, CPVC said:

 

Thank you. Do you have the Steam overlay enabled? If you do, would you mind disabling it and trying again? Thanks.

"I’m really curious to see if it actually comes down to the overlays and ReShade, but honestly, it’s super likely. If that turns out to be the case, do you already have a fix in mind for it? Let me know if I can help you out with anything—always happy to pitch in if you need a hand!"

[0Spirit0]

I did not have steam overlay on, however, even if the game is installed by steam the ea app also have to be running, unfortunately it wasn't ea overlay either.

Sent another log to server

 

Edit:

I think i discovered what was happening in my pc,

for some reason when I updated nvidia drivers my firewall started blocking your dll silently, added rule to HIPS function and game run again with the version that is on top of this page, now I can only do more testing next week to see if it's really working.
Sorry for any extra work I have caused to you.

Edited August 7 by 0Spirit0

[CPVC]

13 hours ago, jeno3 said:

"I’m really curious to see if it actually comes down to the overlays and ReShade, but honestly, it’s super likely. If that turns out to be the case, do you already have a fix in mind for it? Let me know if I can help you out with anything—always happy to pitch in if you need a hand!"

 

It could be. I'm not certain. I have tested both Steam and EA overlays and they worked, but I have not tested them on an NVidia GPU.

 

6 hours ago, 0Spirit0 said:

I did not have steam overlay on, however, even if the game is installed by steam the ea app also have to be running, unfortunately it wasn't ea overlay either.

Sent another log to server

 

Edit:

I think i discovered what was happening in my pc,

for some reason when I updated nvidia drivers my firewall started blocking your dll silently, added rule to HIPS function and game run again with the version that is on top of this page, now I can only do more testing next week to see if it's really working.
Sorry for any extra work I have caused to you.

 

I doubt it has anything to to with RTBP being blocked in the firewall. This is likely a linking thing and you're not the only one with the problem, a lot of users have the exact same issue. I think it has something to do with the new NVidia drivers. They're unable to create a device failing at the "OpenAdapter10_2" function.

[jeno3]

12 hours ago, CPVC said:

 

I doubt it has anything to to with RTBP being blocked in the firewall. This is likely a linking thing and you're not the only one with the problem, a lot of users have the exact same issue. I think it has something to do with the new NVidia drivers. They're unable to create a device failing at the "OpenAdapter10_2" function.

Yeah, very interesting and certainly possible. One question, though—if that turns out to be the cause...

 

Since RTBP runs perfectly for me, I’m following this mainly out of curiosity. I was wondering how you usually handle these driver-specific adjustments: do you implement a dynamic fallback for older drivers, or does the new driver structure differ so significantly that a completely separate branch is required? I’d just like to learn a bit more about the inner workings. Thanks for your great work on this mod!

[CPVC]

On 8/7/2026 at 1:15 PM, jeno3 said:

Yeah, very interesting and certainly possible. One question, though—if that turns out to be the cause...

 

Since RTBP runs perfectly for me, I’m following this mainly out of curiosity. I was wondering how you usually handle these driver-specific adjustments: do you implement a dynamic fallback for older drivers, or does the new driver structure differ so significantly that a completely separate branch is required? I’d just like to learn a bit more about the inner workings. Thanks for your great work on this mod!

 

There hasn't been the need to do any driver-specific tweaks before, but I can query the system to find out what device they have and make some changes if necessary. There is still only one function that needs to be altered to inject RTBP into the Sims 4 and newer drivers shouldn't require any changes to RTBP for it to work. Why the new NVidia drivers aren't working with RTBP is currently beyond me. I think it's just NVidia, but I'll have to poke around in the database of error reports to confirm.

[0Spirit0]

Did a few more tests and is indeed my firewall (comodo) preventing the game to start with your dll. The HIPS (Host Intrusion Protection System) of the firewall block your dll.

Created a rule set to allow your dll to run. 

The odd part of this is, It only started after I updated nvidia drivers.

[yokozii]

22 hours ago, CPVC said:

 

There hasn't been the need to do any driver-specific tweaks before, but I can query the system to find out what device they have and make some changes if necessary. There is still only one function that needs to be altered to inject RTBP into the Sims 4 and newer drivers shouldn't require any changes to RTBP for it to work. Why the new NVidia drivers aren't working with RTBP is currently beyond me. I think it's just NVidia, but I'll have to poke around in the database of error reports to confirm.

 

Hii soo I'm not the *most* tech savvy and innovative with programming but I know enough to know that when it comes to the sims4 ESPECIALLY prior to the DX11 transition update the sims team has worked on a case by case old way how they've maintained and developed the game over time. you notice how long it took for sims4 for to get updated enough JUST to be compatible with reshade/Gshade? thats the same with their coding and all the bits and updates inside. This is why script mods are hard to maintain due to so many patches and how we can't have stability because everything runs on an engine meant for something else in 2008 ONLY so it's all backwards compatible with a bunch of stuff theyre STILL using from 2005-2009 etc. its the same with our PCs. in order to get 3rd party injected code and programing code to work with current 2026 tech we have to have bridge-software...here is what I've figured out: 

 

I did not get any logs (sorry) as I fresh uninstalled both the RTBP PASSTHROUGH and RTBP NO FORWARD PASSTHROUGH. neither copy worked. and I tried both without Companion. 

the V 2.3-8 / 07-30-2026 ONLY worked in game with reshade for 3-4 minutes after attempting to minimize the game window, causing that visual error pop-up then it crashed. seems like the GUI / companion cannot minimize since the code was not formatted or something to minimize or clashing that lead me to my discovery ..

 

I  do not think it is *just* the new NVIDIA drivers causing issues. I think its people not having RUNTIME or updated RUNTIME AND it is the C+++ microsoft files that most PCs would get in an 'optional update' that is missing to make the newest RTBP work. Sims 4 runs on a C+++ and there is this code error I got hit with every time I try to run RTBP + RESHADE. as I always have, reshade runs fine however this error code pops up and says its incompatible with RESHADE not SIMS 4. so there was a clash. I thought what does sims 4 communicate with reshade that RTBP does not? I looked in my files along with the NVIDIA updates etc. 

 

there are new C++ Redistributable add-ons for free to download that communicate web client applications (reshade + companion ) to basically work with new graphics upgrades that are visual heavy to become compatible with the new x86 format. YES x64 is no longer the maximum format size. now its bigger BUT backwards compatibility is available...and reshade was able to run on top of sims 4 using this C++ Redistributable 2005-2008-2013-2015 etc with the new x64 + X86 bridge compatible install. I think this is how microsoft is helping people still use their visual heavy games & and add on software with NIVIDIAs ever expanding pixel upgrades. 

 

I found Reshade had this same problem 11 years ago >> CLICK HERE  

 

I have an auto-install file that takes a few minutes and installs all of x64 & x86 C+++ from an online repo , I can post the file if you want. but they are free to get CLICK HERE

 

I would suggest adding this inside along with a 'hook' for RTBP moving forward just like reshade did, so the drivers and firewall won't block it 

 

Edited August 11 by yokozii

[CPVC]

On 8/10/2026 at 10:10 PM, yokozii said:

 

Hii soo I'm not the *most* tech savvy and innovative with programming but I know enough to know that when it comes to the sims4 ESPECIALLY prior to the DX11 transition update the sims team has worked on a case by case old way how they've maintained and developed the game over time. you notice how long it took for sims4 for to get updated enough JUST to be compatible with reshade/Gshade? thats the same with their coding and all the bits and updates inside. This is why script mods are hard to maintain due to so many patches and how we can't have stability because everything runs on an engine meant for something else in 2008 ONLY so it's all backwards compatible with a bunch of stuff theyre STILL using from 2005-2009 etc. its the same with our PCs. in order to get 3rd party injected code and programing code to work with current 2026 tech we have to have bridge-software...here is what I've figured out: 

 

I did not get any logs (sorry) as I fresh uninstalled both the RTBP PASSTHROUGH and RTBP NO FORWARD PASSTHROUGH. neither copy worked. and I tried both without Companion. 

the V 2.3-8 / 07-30-2026 ONLY worked in game with reshade for 3-4 minutes after attempting to minimize the game window, causing that visual error pop-up then it crashed. seems like the GUI / companion cannot minimize since the code was not formatted or something to minimize or clashing that lead me to my discovery ..

 

I  do not think it is *just* the new NVIDIA drivers causing issues. I think its people not having RUNTIME or updated RUNTIME AND it is the C+++ microsoft files that most PCs would get in an 'optional update' that is missing to make the newest RTBP work. Sims 4 runs on a C+++ and there is this code error I got hit with every time I try to run RTBP + RESHADE. as I always have, reshade runs fine however this error code pops up and says its incompatible with RESHADE not SIMS 4. so there was a clash. I thought what does sims 4 communicate with reshade that RTBP does not? I looked in my files along with the NVIDIA updates etc. 

 

there are new C++ Redistributable add-ons for free to download that communicate web client applications (reshade + companion ) to basically work with new graphics upgrades that are visual heavy to become compatible with the new x86 format. YES x64 is no longer the maximum format size. now its bigger BUT backwards compatibility is available...and reshade was able to run on top of sims 4 using this C++ Redistributable 2005-2008-2013-2015 etc with the new x64 + X86 bridge compatible install. I think this is how microsoft is helping people still use their visual heavy games & and add on software with NIVIDIAs ever expanding pixel upgrades. 

 

I found Reshade had this same problem 11 years ago >> CLICK HERE  

 

I have an auto-install file that takes a few minutes and installs all of x64 & x86 C+++ from an online repo , I can post the file if you want. but they are free to get CLICK HERE

 

I would suggest adding this inside along with a 'hook' for RTBP moving forward just like reshade did, so the drivers and firewall won't block it 

 

 

That's a possibility. It wouldn't hurt to keep your Visual C++ runtimes updated.

 

 

Everyone else, I did some reading and it turns out the error code we're getting corresponds to a software exception. If I catch that, I should be able to get more information. Could one of you who is having the issue with "OpenAdapter10_2" showing up in their stack trace try out this build and get your log to me? Thanks.

 

Oh, and I threw in the debug information, too, so make sure "d3d11.pdb" is located in your "Game/Bin/" folder along with "d3d11.dll". That should add more information to the log files when they're generated. Thanks again!

 

Edit: Check next post for current experimental version.

Edited Sunday at 01:48 AM by CPVC

[CPVC]

After checking the error reports, I have another build for you all to test. Hopefully this does something. Check it out if you will. Once again, thanks so much.

 

RTBP 2.3.1~3 2026-08-15.zip

[jeno3]

Hi,

I installed a new graphics card yesterday, and now I’m having the same problem: the game crashes after a few minutes. So, it does seem to be related to Nvidia after all. I also had to perform a BIOS update for the new GPU. I’m not sure exactly what differs in my setup compared to before, but I did have to adjust some graphics settings. I’ll test your new DLL later. Since I’m now someone experiencing issues with the DLL, I can send you the logs separately.

[jeno3]

On 8/16/2026 at 3:47 AM, CPVC said:

After checking the error reports, I have another build for you all to test. Hopefully this does something. Check it out if you will. Once again, thanks so much.

 

RTBP 2.3.1~3 2026-08-15.zip 5.75 MB · 2 downloads

It looks good so far. I tested it yesterday and didn't run into any problems. I'm sending you the log data anyway; maybe you can glean something useful from it.

Log_RTBP.rar