Please login or register.

Login with username, password and session length

News:

Registration is only required if you want to post, and is not needed to read any posts. To avoid excess 'spam' accounts, all accounts where no posts have been made will be deleted after two weeks. Please register again if you wish to post.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - forum_admin

Pages: 1 ... 7 8 [9] 10
121
Bridge Command General Support / Re: NMEA TCP/IP
« on: April 01, 2014, 10:29:32 PM »
Hi,

I haven't yet had a chance to check the code you linked to, but one quick question: Are you running the client or server code? Bridge Command is basically working as a TCP/IP client, so your code should be setting up a TCP/IP server (bound to port 10110 or whatever you set), and Bridge Command will then connect to this.

James

122
Bridge Command General Support / Re: unable to create 3d screen
« on: April 01, 2014, 06:19:26 PM »
Hi, running on a 64 bit machine should not be a problem in itself - I've recently moved to a 64 bit Windows 8.1 machine.

Can I check what graphics driver you have installed, and if you've been able to run any other 3d software. One way of checking the driver is to run 'dxdiag' (from start, run). On the display tab, it should show information on the driver, and if direct3d acceleration is enabled.

James

123
Development / Re: Creating a controller program
« on: February 16, 2014, 05:31:11 PM »
Hi, that all looks reasonable. I've tried replicating your terrain.ini file (with TerrainLat(1)=30), using a plain black image for the heightmap, and it behaves as expected, with a large depth when the vessel starts at
Code: [Select]
InitialLong=-77.5
InitialLat=32.5
.
Is it possible that you may have switched the Lat and Long starting positions, so you're starting off the map?

Just one additional comment - because the height map is loaded from an image with only 256 grey shades, a terrain with such a large height range (-2063 to 633 metres) will load with large 'steps' visible in the land, as the height will only be resolved to the nearest ~10m. For very large depths (defaulting to 100m), the depth sounder will just read "-", so it may be best to truncate any depths below ~110 metres, which would increase the resolution of the heights that can be displayed.

124
Development / Re: Creating a controller program
« on: February 10, 2014, 07:24:50 PM »
Hi, I've looked into this a little more. If you start on the defined world area, and move off it, Bridge Command assumes that the seabed depth stays the same as the point just before you left the map, and if you start off the map, it will assume a depth of zero.

To find the depth under the keel, the tidal height is added, and the ship's draught taken away. Therefore if you have any tides configured, you may be 'running aground' when the tide falls. If this is the problem, starting on the defined world area, and making sure that it's deep enough to avoid any grounding should fix the problem.

Alternatively, there may be some sort of numerical jitter that's causing the maintained depth to reduce over time, but that seems quite unlikely.

125
Development / Re: Creating a controller program
« on: February 09, 2014, 09:23:45 PM »
Hi, I haven't come across this before but can investigate more. When it became unresponsive, was the position displayed in Bridge Command reasonable, or did it go to Inf or NaN?

126
Development / Re: Creating a controller program
« on: February 03, 2014, 10:10:09 PM »
Hi,

It may be worth checking through each calculation step comparing the result to a manual calculation to check for any problems. The code I've tested, based on what you posted above, seems to give the correct result. This is in C++:

Code: [Select]
#include <iostream>
#include <cmath>

const double EARTH_RADIUS = 6371000; //in meters
const double PI = 3.141592653589793;

int main ()
{
    //Inputs (in metres)
    double dXPosition = 43944.3;
    double dZPosition = 94138.5;

    //Terrain parameters
    double dTerrainLongExtent = 1.0;
    double dTerrainLatExtent = 1.0;
    double dTerrainLong = -119.0;
    double dTerrainLat = 32.58333;

    //calculate width of terrain in metres
    double dTerrainXWidth = dTerrainLongExtent * 2 * PI * EARTH_RADIUS * cos( (2*PI/360)*(dTerrainLat + (dTerrainLatExtent / 2))) / 360;
    double dTerrainZWidth = dTerrainLatExtent * 2 * PI * EARTH_RADIUS / 360;

    //find lat & long
    double Longitude = (dXPosition * dTerrainLongExtent / dTerrainXWidth) + dTerrainLong;
    double Latitude = (dZPosition * dTerrainLatExtent / dTerrainZWidth) + dTerrainLat;

    //print out
    std::cout << "Long: " << Longitude << std::endl;
    std::cout << "Lat:  " << Latitude << std::endl;

    return 0;
}

Gives:

Code: [Select]
Long: -118.528
Lat:  33.4299

Which matches with the BC output.

127
Development / Re: Creating a controller program
« on: February 02, 2014, 09:39:02 AM »
I think the only change required is to convert the angle used in the Cos() function into radians - you're currently giving it an input in degrees.
i.e.
Code: [Select]
Math.Cos(dTerrainLat + (dTerrainLatExtent / 2))becomes
Code: [Select]
Math.Cos((Math.PI/180)*(dTerrainLat + (dTerrainLatExtent / 2)))

128
Development / Re: Creating a controller program
« on: January 31, 2014, 08:26:16 AM »
Sorry for missing this part of the question.

Bridge Command uses a very simple projection, and this means that the translation from the position in metres sent over UDP to lat/long is:

Longitude[Degrees] = (X[Metres]  * TerrainLongExtent / terrain_x_width) + TerrainLong
Latitude[Degrees] = (Z[Metres] * TerrainLatExtent *  / terrain_z_width) + TerrainLat

In this, X and Z are the position from the South West corner in metres (the values sent over UDP), TerrainLat, TerrainLong, TerrainLongExtent and TerrainLatExtent are all set in the world model terrain.ini file.

Terrain_x_width is the world model width in metres, and is calculated:
terrain_x_width = TerrainLongExtent * 2 * Pi * EarthRadius * Cos(TerrainLat + (TerrainLatExtent/2)) / 360

similarly for terrain_z_width:
terrain_z_width = TerrainLatExtent * 2 * Pi * EarthRadius / 360

(EarthRadius is defined as 6.371e6 metres, and this assumes that your calculations are all in degrees.)

As Bridge Command does not stop you at the limits of the world model, it may return a negative X and Z value.

I hope that this helps!

129
Development / Re: Creating a controller program
« on: January 23, 2014, 06:32:37 PM »
That sounds an interesting project. Will your controller give the speed and heading of the boat, or the rudder and engine settings? Both approaches should be possible, using the UDP networking messages.

These are defined in http://bridgecommand.co.uk/Doc/networkprotocol.php

If you are controlling the engine and rudder settings, the boat's dynamics will be simulated in Bridge Command. For this approach, you'd run Bridge Command in 'Networked (Main)' mode, but instead of connecting to the 'Map Controller', you would connect to your own controller program, which would send 'MC' messages to Bridge Command via UDP. In particular, you would use the 'Engine and rudder failure record', using this to set the engine and rudder parameters.

Instead, if you are simulating the boat's dynamics yourself, giving speed and heading, you will need to use these to generate a current position in metres (relative to the South West corner of the sea area). You would then run Bridge Command in Secondary (3d) mode, and update its position by sending 'BC' messages to Bridge Command. You would also need to send at least one 'SC' message as well to set up the scenario.

Hopefully this and the documentation in http://bridgecommand.co.uk/Doc/networkprotocol.php should help you get this set up, but please ask if you have any questions.

130
Scenarios / Re: Modify Boyage Region
« on: March 15, 2013, 07:52:59 AM »
Hi. Are you getting the error "Could not save to file" when you try to save the modified world model? If so, it probably means that your user account is not allowed to modify files within your Bridge Command installation folder.

You can check this by finding your world model directory (Probably C:\Program Files\Bridge Command 4.5GPL\World), and trying to edit and save one of the world model files with notepad.

If this is the problem, you could re-install Bridge Command in a location where you do have write access (for example in a Bridge Command folder in My Documents), or change your user permissions so you do have write access to your 'World' folder.

If this does not solve the problem, let me know and I can investigate further.

131
Scenarios / Re: Modify Boyage Region
« on: January 19, 2013, 06:04:57 PM »
Hi, I've uploaded a zip file containing the buoys modified for IALA region B to
http://www.bridgecommand.co.uk/file/IALA_RegionB.zip

If you download this, find the 'Buoy' folder in the 'Models' folder in your Bridge Command installation folder, and replace it with the one from the .zip file.

In Bridge Command, all of the ship and buoy models are 3d model files, so you don't need to make any changes to the source code itself. To make these changes to the buoys, all I have done is changed the colour in the model files.

If you want to change the colour of the lights, find the 'world model' you want to change, and open up the light.ini file. For each light, you will see some settings like this for a red light:
Code: [Select]
Red(1)=255
Green(1)=0
Blue(1)=0

Since all red and green lights should swap colours, you can change this to a green light.
Code: [Select]
Red(1)=0
Green(1)=255
Blue(1)=0

If you swap all red and green lights, the world model should now be set up for IALA region B.

Let me know if you have any questions about this.

132
Environment models / Re: World Model Creation
« on: October 29, 2011, 10:30:59 PM »
To follow up:

The best data source for importing STRM data for terrain models appears to be CGIAR, who maintain an SRTM dataset with voids filled in (http://srtm.csi.cgiar.org).

I have also put together a tool to convert this data from ArcInfo ASCII format into an image format suitable to generate a heightmap for Bridge Command. This creates a 'pgm' file, which can be read in a good image editor, such as the free GIMP (http://www.gimp.org/downloads/), and saved as a .bmp or jpeg file.

To use this data to generate a height map image:
>Go to: http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp and select the area you want.
>Select 'ArcInfo ASCII' as the file format
>Search and download the data you want

>Download the conversion tool from http://www.bridgecommand.co.uk/file/import.exe
>Save import.exe somewhere
>Drag and drop the .asc file you have downloaded with your data onto the import.exe program file
>Set the sea depth when requested (SRTM has no sub-sea data)
>The program will process the file, which will take a number of minutes, and may appear to freeze while writing the output file
>When done, the output file will be saved in the same location as the input, with .pgm appended to the filename. Note the TerrainMaxHeight and SeaMaxDepth values to use.
>Open the .pgm file in your image editor, and follow the documentation to save this in the correct size as a .bmp or .jpg file.

Please note the terms of use of the CGIAR data at http://srtm.csi.cgiar.org/SELECTION/SRT_disclaimer.htm.

Please let me know if this is helpful, or if you come across any issues,

James Packer

133
Environment models / Re: World Model Creation
« on: October 28, 2011, 09:34:18 PM »
Hi Marvin,

Yes, one of the main sources of data for elevation maps is SRTM data, which can be downloaded from http://earthexplorer.usgs.gov/. In addition, for the USA, the NGDC Coastal Relief Model (http://ngdc.noaa.gov/mgg/coastal/startcrm.htm) is a very good data set which combines land elevation with sub-sea bathymetry for the US continental shelf.

Since I have last worked with these data sets, the data formats available have changed, so I need to investigate further what tools are available to convert the data into BMP format, suitable to load into Bridge Command. I will look into this over the weekend and post an update here.

In the UK, the Ordnance Survey have recently released a reasonably high resolution digital elevation map (Land-Form PANORAMA on https://www.ordnancesurvey.co.uk/opendatadownload/products.html) under their OpenData licence. However, this is referenced to the UK National Grid, so I am currently looking at how to re-process this into a latitude/longitude format using WGS84, the standard datum used by modern charts and gps.

Once you have your heightmap in an image format, you can also generate a texture image to display on the terrain when it is loaded in the program, which should be the same image size as the heightmap. For this I currently use L3DT (http://www.bundysoft.com/L3DT/).

The radar image file is now only used as a map in the scenario editor and map controller, as the radar image is simulated directly from the terrain. Therefore I normally use the same image as the land texture.

I will report back on tools to convert the available datasets into a bitmap image,

James Packer

134
Development / Re: Sockets
« on: May 18, 2011, 09:06:35 PM »
Which code on that page are you trying to use? It appears that most of the code posted is for BlitzMax rather than Blitz3d.

I have implemented similar communication between Bridge Command and the Map Controller. For this, I decided to use UDP rather than TCP for this. TCP guarantees eventual delivery of the packet, and in the right order. This means that each packet may be resent many times, resulting in a significant slow-down. With UDP, you have none of this overhead, so the process is much faster, but there is no guarantee that the packets will come through in the right order (or at all).

I decided that getting some packets through quickly was more important, but you do need to discard any packets that come through in the wrong order.

As an example, here is some simple, bi-directional code.

Code: [Select]
AppTitle "Sender"

;set up address and ports (note that if the sender and client run on different computers, then only 1 port is required)
ipAddress = dotToInt("127.0.0.1")
udpSendPort = 40002
udpRecvPort = 40001

;make stream
udpStream=CreateUDPStream(udpRecvPort)
UDPTimeouts 30 ;wait 30ms to receive see if any message comes in

i=0

While Not KeyHit(1)

i=i+1

If udpStream <> 0
WriteString udpStream, "Test send " + Str(i)

SendUDPMsg(udpStream, ipAddress, udpSendPort)

;receive too
recvIP = RecvUDPMsg(udpStream)

If recvIP <> 0
Print ReadString(udpStream)
EndIf

Else
Print "No stream created"
EndIf

Wend

CloseUDPStream udpStream

End

Function DotToInt%(ip$)
ip$=Trim$(ip$)

ip1=split$(ip$,1,".")
ip2=split$(ip$,2,".")
ip3=split$(ip$,3,".")
ip4=split$(ip$,4,".")

Return ip1 Shl 24 + ip2 Shl 16 + ip3 Shl 8 + ip4
End Function

Function Split$(in$,n,delim$)
;splits string by one character delimiter
;returns nth component

For i = 1 To n
;find location of next delimiter
;find part to left of delimiter
pos=Instr(in$,delim$)
If pos=0
;no further delimiter found
If i<>n
lh$="" ;there is no nth part of the list, so return ""
Else
lh$=in$ ;we have found the nth part, which is the last in the list
EndIf
Exit ;break out of loop
EndIf

lh$ = Left(in$,pos-1)
;discard part to left of delimiter
in$ = Right(in$,Len(in$)-pos)
Next
Return lh$
End Function

Code: [Select]
AppTitle "Receiver"

;set up address and ports (note that if the sender and client run on different computers, then only 1 port is required)
ipAddress = dotToInt("127.0.0.1")
udpSendPort = 40001
udpRecvPort = 40002

;make stream
udpStream=CreateUDPStream(udpRecvPort)
UDPTimeouts 30 ;wait 30ms to receive see if any message comes in

i=0

While Not KeyHit(1)

i = i + 1

If udpStream <> 0
recvIP = RecvUDPMsg(udpStream)

If recvIP <> 0
Print ReadString(udpStream)
EndIf

;send a message too
WriteString udpStream, "Test reply " + Str(i)
SendUDPMsg(udpStream, ipAddress, udpSendPort)

Else
Print "No stream created"
EndIf

Wend

CloseUDPStream udpStream

End

Function DotToInt%(ip$)
ip$=Trim$(ip$)

ip1=split$(ip$,1,".")
ip2=split$(ip$,2,".")
ip3=split$(ip$,3,".")
ip4=split$(ip$,4,".")

Return ip1 Shl 24 + ip2 Shl 16 + ip3 Shl 8 + ip4
End Function

Function Split$(in$,n,delim$)
;splits string by one character delimiter
;returns nth component

For i = 1 To n
;find location of next delimiter
;find part to left of delimiter
pos=Instr(in$,delim$)
If pos=0
;no further delimiter found
If i<>n
lh$="" ;there is no nth part of the list, so return ""
Else
lh$=in$ ;we have found the nth part, which is the last in the list
EndIf
Exit ;break out of loop
EndIf

lh$ = Left(in$,pos-1)
;discard part to left of delimiter
in$ = Right(in$,Len(in$)-pos)
Next
Return lh$
End Function

135
Thanks for sharing your thoughts. I believe that this could be a very good approach. I will definitely consider the option seriously when I decide to commit to re-programming the simulator, on whatever base. One option may be the Delta3D engine, which could be a good starting point (http://www.delta3d.org/).

However, for the moment I have decided to focus my efforts on improving Bridge Command in it's current form, in particular developing the radar simulation, and improving the simulation areas available, as well as the associated charts and navigational data. I think that working from the existing base is the best option for providing a high quality simulation environment at the current time, avoiding the inevitable delay involved in a re-write of any kind.

When I was seriously considering a re-write, it appeared that future versions of Windows might not support versions of Bridge Command written in Blitz3D, but with the release of Windows 7, I have found that the simulator runs well on both the 32 and 64 bit versions. This has given me confidence that work on the current version will be valuable into the foreseeable future.

Pages: 1 ... 7 8 [9] 10