![]() |
Main difference compared to DW is the delays induced by finite sound speed will be correctly simulated, to such extent, that it alone will allow active sonar simulation.
Each sound will 'travel' and 'hit' other platforms in correct order, where it will get detected (for passive) or bounced (read new sound event will be generated) for active sonar. This is general mechanism how sound will get from source to listener. This is actually what I'm working on in the moment. As for transmission loss, layers, channels and so on, nothing like raytracing is possible because of huge amount of computing it needs, so it will be just lookup tables based on range, depth of listener, depth of target. However I plan to have these changing fluently with daytime and location. I'd also like to have let's say 3 frequency ranges so different frequencies can react differently on sound speed profile. As for sound source, it's clear DW's 4 constant lines per platform is huge simplification, and I plan to have quite complex sound sources, since it's cheap. So there will be many components, each related to expected cause, and variable not only in amplitude, but in frequency too, where it should be. Propeler noise, flow noise, gear whine, pumps, steam noises, generators, you name it. And of course, correctly simulated transients, which will generaly be samples played (and heard on listener side) when some specific event happens (like torpedo tube opened, or coin dropped :rotfl:). This will make identification much harder and description of sub wont be 4 frequencies. Expect long process of guessing and ruling out. You should be able to tell 'this is ruskie sub' quite soon, while it might be hard to tell if it's delta III or delta IV. Anyway this rich possibilities will easily allow each hull to be slightly different. As for listener side gear, it will just look slightly more complicated, there is nothing much wrong with it in DW, except it's simplistic at some details. Of course there will also be MUCH more false contacts, and there will be better environment simulation. |
Sounds good Sid,
I have a week and a half off over Christmas....so I'll send you some more subs. If you can let me know what happens with the surface models where they go weird on you I could try and mitigate it in the model before I send it. I'd like to make a big push with this and get you some nice surface vessels. |
Hopefully I get more time over Christmas so I'd like to find those 3ds bugs. Most probably I just ignore some sections which did not appear earlier.
|
It's odd as they work in DW fine after being converted to J3D.
I'd have thought if there was a problem with the model DW would have shown it up. |
There for sure is no 'problem' with those files. They just use some feature I don't support at the moment.
|
Quote:
|
That's actually why I like modern subs .. because you can play with sonar so much :arrgh!:
|
Quote:
|
Dr. Sid, how do you plan to do better environment simulation and false contacts?
|
Honestly I don't know much yet. I did not discuss this much with anyone.
By environment I mean background noise. This seems to be covered quite well in Urick, and there is no technical problem (I know of). As for false targets .. there should be more bio targets, rocks, ice peaks or wrecks, all with both passive (water flow and eddies for silent ones) and active, and magnetic and so on when we get there. Also for active the bottom reflection should be made better I think, especially if it's rocky, there should be a chance to hide at the bottom (I guess). Any comments are appreciated. |
Dr. Sid, I agree with all of your ideas for more realistic sonar environment. A few interesting items, would be the ability to detect other contacts from the reflections from other vessels active sonar emissions. I wouldn't expect a real accurate range based on the fact that the ownship wouldn't know the exact time the active pulse was transmitted, but you should be able to at least detect reflections and get a bearing.
You mentioned you wanted to use ray tracing, but it is too expensive. Maybe there are some optimizations/compromises that can be made. For example, only perform the ray-tracing from a noise source to ships that may be listening. For example, if there is a sub X nm from the noise source, but the sub is traveling too fast to pick up the signal, then you could optimize that ray away. I know NVidia did a demo recently of a real time ray traced scene. I don't recall the resolution, but it was higher than 1280x1024. Although I believe that was on a quad GPU setup. I guess my point is, it would be nice to built the engine with the ability to support ray tracing and a table based system. If you can't hit the performance goals on a certain platform, you fall back to the table based system. But if you have a powerful enough system, you could use the ray tracing scheme. |
There is absolutely no need for raytracing in the first place. It would not be better then the tables, since the tables itself would be based on raytracing. But raytracing alone is only valid for high frequencies and idealistic conditions. It's also good for estimating convergence zone range for example, and there could be such tool accessible from sonar station, but generaly it's only one solution for part of the problem.
Here I have to take all phenomemons I want to simulate, and find best approach. Also realtime is not enough, since we want to use time compression, and lot of it. And 'every listening platform' may be array of 50 sonobuoys .. the sonar really has to be done as fast as possible. Look at DW . .even on my core duo 2.3 GHz it mostly does not manage to go 32x, if there is more platforms, and it fakes sonar in great way, especially for AI. |
Quote:
|
There are technical problems in terms of getting data. Even though theoretically we know how to model it to some reasonable approximation, the next question is, which numbers do you stick into the equations to make them work?
One of the things I REALLY wish for is actually more control for the scenario designer of the environment. I mean... suppose you just assumed that omnidirectional noise level was a Gaussian distributed random number with some mean, m and some standard deviation, s. It'd be nice if the scenario designer could fill those values in. I'd have to really review Urick's chapter on the noise level. The real issue is not so much how to model it but more what options to include so that the system is as flexible as possible and still meaningful to people. Ya know? I come at it from the direction of a sonar geek, but someone else might say, "I don't want to stick in a mean and a standard deviation, I just want to say it's raining or there's a lot of shrimp snapping." That to me, though limits it's flexibility. To a certain extent, giving more control to the scenario designer also eliminates the need for data. It's essentially saying, "you can have any values you want anywhere, if you have some oceanographic database to justify it, all the better." There might be some default values for strategically interesting areas that we've researched, but even those should be changable. Biological noise is complicated because it tends to be concentrated in specific areas but it shouldn't be constrained to them either. Off Cape Cod, for example, there's a very rich Marine preserve where there's tons of whales, dolphins and the entire ecosystem to support them. But it's also seasonal, so doing anything other than leaving it up to the user to include them means you need data. Do you know the distribution of whales globally as a function of time? What about shrimp? Seals? Croakers? Lobsters? Scallops? All fish with swim bladders? The list could be as long as you want. The "bottom reflection" or reverberation issue is actually fairly complicated. Depending on sea state there's also surface reverberation. There's actually computer models built specifically for reverberation. I imagine that in order to get the desired effect you'd have to take into account grazing angle issues. You'd also have to worry about things like depression/elevation angle on the sonar set itself. Pointing the sonar beam pattern down might mean less reverberation, although less direct path range, pointing it up might increase reverberation but you also get more range. If you're planning to do stuff with just lookup tables, I'm not quite sure how to make this work. To make matters worse there's also volumetric scatterers in the water column that contribute to reverberation as well, so it's not just the bottom. You're also limited by the available data again. Quote:
|
Quote:
Just as I, a nuke, will have to settle for approximations in ownship noise levels and the factors that control them, you as a sonar tech, will have to settle for a little less as well. Granted, I think that sensor data and the variables that create and modify them should be done to a greater extent. This is after all, a sensor sim. |
Quote:
|
Quote:
|
Quote:
The laws of physics don't change across borders. It's no big secret how a nuclear reactor works, for example, or how beamforming works. You can find beautiful books on all of that. All of it is unclassified. Heck, we actually gave the technology to build nuclear reactors to Iran under that Atoms for Peace program in the 1950s under Eisenhower. The problems pop up when people say, "here's how we do it specifically on this vessel, and oh, btw, here's some performance numbers." |
Quote:
The actual details of power plant operation is not really a issue as it is far beyond the scope of any sim. Things like plant management and power constraints DO play a part as you can opt for low power/lower noise levels/lower max speeds vs high power/higher plant noise/higher max speed. Because of the nature of speed/drag/power curves there is no simple linear solution. You are able to make a trade-off that have a tangible tactical effect. Since this IS a sim, these are things that need to be taken into consideration as they are a part of the operational equation. Unfortunatly, there is very little outside references into the operational considerations and tactical employement of a submarines. This is where those of us who have served try and give an insight without busting the rules. |
Quote:
:cry: |
All times are GMT -5. The time now is 06:49 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © 1995- 2025 Subsim®
"Subsim" is a registered trademark, all rights reserved.