Is it really that "hardcoded"? A bit silly solution but can't we just bind to seat jbeams? At least passenger one. All front seats in most cars have their own slots and jbeams. And they obviously aren't placed outside of the car. Uninterested people won't even try to calculate node position, but those who want, might have this as an option. {"isPassengerSeat": 1} for example. I'd be personally interested because i had an idea of adding custom gopro-like cameras on the rollcage
Would be awesome to get more technical insights every now and then about what you are planning to integrate and what technologies you are evaluating. Though this will probably lead to too many comments from backseat devs On that note, I heard (heh) that the Steam Audio API is pretty advanced and doesn't rely on Steam to run.
"Hardcoded"? Well, it's currently programmed like this. You cannot customize the logic via settings nor via mods, so in a way it you can say it's hardcoded. Regarding improvements to the current system. You need to understand there's two kind of improvements: those that are incremental (applied on top of the current approach), and those that start from scratch with a new approach. The current approach is a dead end. It will never, ever be able to have all the features we want, and solve all the bugs it currently has. A proper approach is based on raycasting / realtime enclosure detection / etc. Dedicating time to the current futureless approach, means losing devtime into something that sooner or later will need to be completely scrapped. So not only are you wasting devtime for marginal improvements, but on top of that you now have a technical debts towards the modders who have began using those improvements. So you need to invest even more devtime to implement and maintain a bug-free mod retrocompatibility layer, during the future transition to the proper approach. So it's a matter of balance, you need to choose how much devtime to waste on marginal improvements + slower code maintenance + potentially more broken mods, versus leaving it as-is and reserve that devtime for more productive tasks. It's a difficult compromise, we all know we could do minor improvements easily but, at what cost, and where do we stop. For example, I already added support for the 'Rider' camera in busses, since I evaluated the maintenance and future-mod-breaking cost to be acceptable. But further improvements are not clear from devtime/efficiency pov. The downside is of course that this particular part of audio will remain as-is for all of us until we get to that shiny promised new approach (who knows when we'll have time for it).
Now one thing ive noticed for a while now and idk if it would be accurate or not but it seems turbo whistle and blow off valve noises dont have reverb in tunnels. Ive never driven a turbo car in a tunnel irl so idk but superchargers do and turbos dont seem to.
They do have reverb in the tunnels. The nature and type of the sound just means they don't "travel" as well. Superchargers are generally loud and very piercing sounds, which just perceivably reverberate better. Turbo whistle for example, doesn't travel a large distance in the first place
Overrun is implemented, and is controlled by the engine simulation depending on what parts you have installed on the vehicle, plus jbeam audio settings on the exhaust. Check out vehicles like the hillclimb Vivace.
Seems like it's alive and well: https://store.steampowered.com/news/app/596420/view/7745698166044243232?l=german https://www.phoronix.com/news/Steam-Audio-SDK-Fully-Open
I meant the sound direction. It sounds like exhaust is pointing to front of the car and not to back of the car. Its much louder and clearer in rear view(as far as i can work out).
When you say "rear view" you mean the chase camera? I just checked a random car, and I can't find any problem here. My audio is running in surround however.
So you're saying the exhaust is brighter when looking back at the car from the front. This is not what I experienced when I checked yesterday, and would be incorrect. What car? and are you in stereo or surround?
I checked again and i think i was wrong and you are right. On another topic would it be possible to get a realistic volume ramp that makes higher rpms realistically more loud vs lower rpms. On the bastion v8 it doesnt seem like it. It makes sense that if pistons are firing 8 times as much at 8000 rpm vs 1000 rpm it will be much louder.
The loops are set up that they are 8db quieter at 1000 than they are at 8000. I'll have a look at the torque curves and see what's going on as they should be controlling the overall volume. Edit: You can see here with the 1.8 Sunburst, I've logged the volume of the exhaust from idle in 3rd gear, accelerating up to redline and then releasing the throttle. However, I'm not seeing the "volume" alter as torque changes; I would expect to increase with RPM and then drop towards the top of the RPM range.... so will investigate further.
Hi! I'd like to know how you get the moving sound from the car, such as the engine sound, accelerating, decelerating, etc. Are they all made up by tools or collected in real life? Is there an official documentation to inform that? Please,,, it's really important to me!
Hi, I did pick up on your other post but yeah, good to reply here. So most of our current loops we licensed from a 3rd party. They appear to have originated from recordings, and then processed with potentially granular synthesis to derive the loops. Moving forwards we are licensing more content from other 3rd parties where we need to do the processing ourselves. This content will all be recorded from real vehicles on track for the time being, but we are exploring other avenues such as procedural synthesis. That's a very brief summary
Hi! It's a very good summary, and it's really helpful for me! Do you have a more specific official paper to introduce your sound? I'm more than happy to read that!
We haven't as yet. Things are quite fluid as the game evolves. Happy to answer questions where we can.