SUBSIM Radio Room Forums - Community subsim

SUBSIM Radio Room Forums (https://www.subsim.com/radioroom/index.php)

- Dangerous Waters (https://www.subsim.com/radioroom/forumdisplay.php?f=181)

- - Community subsim (https://www.subsim.com/radioroom/showthread.php?t=104574)

You cant come here, make everyone thisrsty, and tell you wanna do it for yourself. that'd look like you want all the $ :rotfl:

Well who else is interested? I for sure would work on the 3d models, I have many that could be used even for just getting the thing up and running 3d wise once Sid is happy with the code.

The only worry is that people would say yes then drop out.

By myself .. not for myself. I just have few frustrating experiences with cooperation. On the other hand I also have some frustrating experiences with myself .. please keep me interested. :rotfl:
No $ never ever on this one. Who would buy it anyway ? Just some freaks .. :|\\

Well I've found something I was looking for:

http://en.wikipedia.org/wiki/Sonar

It has lots of things I needed to know. Please if you consider yourself capable od such thing, go thru the text, and post comments and missing stuff here.
Also .. do you know any better online source of sound or anything related ?

Like others here I believe such a game should start as a pure subsim, but I also believe it's important to build a system with expandability in mind. That way, when we have a solid product - well beyond proof of concept - we can start thinking about developing air and surface platforms, provided that there's a demand for them.

Having said that, this is a really clever idea. I would love to lend a hand, especially since I have almost too much free time over the summers. I could help out with graphic-type things, like interfaces and promo material (eg websites). I consider myself competent with Photoshop, some of you may recall that I won the Silent Hunter 4 Magazine Ad competition a few months ago.

I also have experience researching naval topics and am in regular communication with a few former admirals :up:

Edit: Yes Sid, I know the pains of working on such intricate projects with partners. When I was developing a community game not long ago, our policy eventually became that there could be only one coder at a time. We recognized that he had the ultimate architecture for how everything was supposed to work in his head. We found it best for us to avoid stepping on his toes and stick to our respective "peripheral" tasks and consult from time to time to make sure we were still heading towards the same goal.

That's what's my experience too. No great painting was made by two man .. and programming is much like painting.

Good news ! We need somebody like you. Not in the beginning I guess.
We don't need website until phase 1 is finished.

We need just some comm-central. My experience is instant messangers are the best, but in that case we need to find some time we are all online (or at least those interested in the moment). Some group would be also useful. I suggest Yahoo-groups.

Of course, all the "fluff" comes later.

Maybe we could appeal to have a forum opened up here or we could open up an IRC channel. In the project I mentioned, we created a simple website to post discussion minutes and things "for the record." Different circumstances but it functioned well to keep several heads on the same page.

Yahoo would suit me fine.

What would be your ideal platform to start with? 688i or Seawolf?

Quote:

Originally Posted by Dr.Sid

http://en.wikipedia.org/wiki/Sonar

It has lots of things I needed to know. Please if you consider yourself capable od such thing, go thru the text, and post comments and missing stuff here.
Also .. do you know any better online source of sound or anything related ?

The classic FAS.org sites are here and here.

Yahoo groups would be a good start.

I use Yahoo Messenger most of the time.

About my database alternative, I have it pretty much down here, sort of. This is pretty pervasive on the core engine design, and the object interfaces will need to be fleshed out, preferrably early. I haven't 'proofread' it, and there may be parts that seem disjointed.

The basic idea is that every ship has a directory containing an xml file for some 'common' details (names, hull numbers, etc, various such things that appear in a mission editor) graphics files, perhaps sound files, and a .dll or similar containing code specific for that ship.

Interface files could of course be included in that directory; the presence of these interface files could determine if a unit was playable or not.

One could use "dependencies" so as to e.g. keep the SPY-n radars in a 'module' of its own, and used by the ships using it.

I am, for (semi-)obvious reasons, writing this in c++.

Code:

class RadarTarget {

    // Another platform is using radar against this. 

    // Horizon is how high above the waterline the other radars horizon is at this distance. 

    // Direction is the relative bearing at which it is

    // This order of parameters is probably rather messed up, but they're only showing a concept.

    virtual float radarfeedback (char band, float horizon, float direction, float power) = 0;

};



class SonarTarget; // with similar content

The idea is that the sonar tonals can be partially randomized,
seeded with only the classname and hullnumber, or such, thereby creating a different sound signature for each hull. Heck, a player might choose to have them further randomized and have fun creating a listing of sound signatures...

Note that the above are all interfaces without function definitions.

Code:

class Platform : RadarTarget, SonarTarget   // and of course lots more

{ };

    

// Provides very generic functions based on some typical database-ish data

class GenericPlatform : Platform

{

  // ...

}

The below would, in the 'final' version, be in a dll in a directory

Code:

class ArleighBurkeFlt1 : Platform 

{

  // proper function definitions for everything, adjusted so as to fit the Burke.

}

As a guideline, DRY (Don't Repeat Yourself) says that common stuff (like radar direction absolute to relative bearing) should be in the calling code.

This method will easily require a lot more work per platform, but on the other hand it will also offer a sort of flexibility that those using the old-fashioned databases only have wet dreams about.

Oh and... I do volunteer for this project; I've been wanting it for a while myself, but my major project completion rate has been... low.

I do have a lot of knowledge of C++ (I primarily do 'backend' type programming) and, should I say, 'how computers work' all the way down to machine code. I have a subversion server and a bugtracker around as well.

Here are some images form my experimental sound propagation model. Today I removed some bugs and made surface bounce dependent on angle the rays hit it. The bending effect is increased like 100 times, so this is nowhere near reality.

You can see sound source in the left, SSP in the right, this is distance vs. depth, so imagine you're looking from the side. Brighter means louder. Note how the rays are trapped in 'slow' medium and how almost whole sound energy they can be focused into small areas. Also note that there is no signal weakening implemented and that these focused points are much weaker that how it's displayed here. Focused points are ring in reality, and the energy distribution must follow it (it does not now). It looks magically and it is much more complicated then I expected.

Note that this is just a toy for experiments, nothing for the sim. It takes several seconds to compute these ..

Above the layer
http://roger.questions.cz/other/above-layer.jpg

Below the layer:
http://roger.questions.cz/other/below-layer.jpg

Above channel:
http://roger.questions.cz/other/above-channel.jpg

In the channel:
http://roger.questions.cz/other/in-channel.jpg

Very interesting diagrams, they look pretty darn close to what I expect from thermoclines. Do we know if the DW sound propagation engine is as accurate as this?

Quote:

Originally Posted by Dr.Sid

It's my own program .. it's just simulation of beam bending based on different speed of propagation. You give it speed vs. depth, sound source position and it draws 2D map (distance vs depth) of sound transfer effectivity. I'll make some user interface and will post it somewhere.

It's really simple .. while I use more or less real sound speeds, I also multiply the bending effect so it is more visible. It by no means gives realistic data. Sure it can't be used .. but maybe some sound propagation effectivity maps could be computed with this and then used in simulation.

Did you just make a ray tracer or do you actually solve the parabolic equation?

Quote:

Anyway it seems you know something about it. Can you list most important phenomenons ? Let's walk thru that, let's discuss tactical importance of such effects and let's talk about their implementation, both accurate and fast.

Computational acoustics is one area where I can get extrordinarily geeky, and the scary thing is, I'm not even close to being an expert on it.

You'll never have an "accurate" model that runs in real time. The math is too hard to do that fast. I run up against this all the time in designing professional wargames. We're forced to make approximations.

You can have a model that has some substance to it, and gives reasonable results, though. There's lots of phenomena to capture, only a few of which are in DW or else they're abstracted. The way I think about everything is in terms of a sonar equation. A sort of simplified version of a sonar equation is that detection occurs when

TL <= FOM

Some acoustic phenomema are accounted for on the transmission loss (TL) side, like sound speed profile, duct cutoff frequency, bottom loss, and surface scattering. Others are accounted for in the figure of merit (FOM) side, like ambient noise, the ability of the array to filter out extraneous sources of noise, and the operator's ability to interpret the things he sees. The best place to start making a sonar model is a sonar equation.

Quote:

Originally Posted by Dr.Sid

Here are some images form my experimental sound propagation model. Today I removed some bugs and made surface bounce dependent on angle the rays hit it.

Very nice! It looks like you've made a ray tracer.

Quote:

Originally Posted by SeaQueen

Quote:

Originally Posted by Dr.Sid

Here are some images form my experimental sound propagation model. Today I removed some bugs and made surface bounce dependent on angle the rays hit it.

Very nice! It looks like you've made a ray tracer.

Really it is raytracer. I'd like to improve it in these areas now:

- ray splitting - this should be faster closer to the sound source and more accurate far from the sound source. Simply after some distance ray will be split in two with half energy, sure, ray amount must be kept reasonable, but like this I have much more control over it.
- surface scattering .. I already tried that, but it needs more rays so I guess the above technique will make it better. I'd also keep some scatter info along the ray. High frequencies suffers more from scattering and if I know how much each point was subject to scatter I can have even some frequency characteristics.
- bottom .. should be similar to surface
- exact energy loss
- fit it to realistic parametres, so it gives believable results. I need realistic sound speeds, realistic surface and bottom characteristics.

But considering the game, we have time to think what model will be used. Realistic sonar is not in the phase 1.