Hello folks,

so far, I only had a very brief look into the files and couldn't do any testing.

Some first impressions:

1. rather complex file structure
2. placement of textures in the Texture folder
3. textures, attached controllers, model setup, channels -- all fine

The way I would set up the files and the contents:

0. Use smaller textures; they are not very detailed so maps of 512 x 512 or 1024 x 1024 are sufficient, especially the submerged rock does not need a HR map
1. No texture in the Texture folder !!! All placed in the *.dat files
2. All material not changing over time removed from the _parts.files in the Library folder
3. Model of rock placed in the respective Location file, including texture.
4. Model of the platform and concrete base added into the Lighthouse files in the Land folder, including the respective texture
5. Either lantern and topmark remain the library file; then, a small cropped texture representing black and yellow metal can be placed into that file. Or place them also into the Land folder file. The lantern was likley not removed during wartime but just switched off. Therefore, it can stay; only the halo needs to "switched off".

More probably later the week (if I find some free time ...).

Inspiration.

This is the right time to do it, before we start placing lighthouses around the Atlantic coast of France :up:

Exactly, 256 shades of grey, each shade being a different height. Indeed, we need to know how many meters below the sea level each shade corresponds to. We don't have this information, all I can say righ away is that sea areas are marked with values from 0 to 47, and land areas go from 48 to 255 (0 being the deepest trench and 0 the highest peak) but...

Knowing that the globe is divided in 180 x 360 = 64,800 elevation squares having a resolution of 126 sq. pixels each, and that the three most external pixels on each side of each square are 'redundant' (i.e. they are overlapped with the outer border of the neighbouring squares), it is a matter of simple math deducing that each pixel on those squares is equal to 1 deg / (126 - 3 x 2) = 1/120 deg = 0.5 min = 30 sec = 1 km in the SHIII world. With those equations in mind, we can easily locate any set of SHIII-world coordinates on the height map.
Knowing how deep is that point in game, we can build our own chart with grey values on a column and depths in meters on the other column. I can imagine that there is a linear correlation between grey values and height values, so we don't have to repeat the process 256 times: two or three well space measures, maybe four to stay on the safe side, will be enough to plot a line which will tell us what is the right grey value for the (approximate) depth we want :yep:

Let's do an example with La Plate's position. Our lighthouse lies between 48 and 49 deg of latitude N, and 4 and 5 deg of longitude W. When we select a set of coordinates in SHIII extractor and we load a grid, SH3 TE will show a matrix of 3x3 squares, the central square having as top left coordinates the coordinates we have selected, so we should look for 49°N and 5°W if we want the square which actually encompasses La Plate's location to be loaded at the center of the 3x3 matrix:

http://i.imgur.com/NmHXY9j.jpg

The square higlighted in red is the one we are actually interested in, and the double green lines show the overlappings with surrounding squares.
When we export our square, again, it will be saved on file together with its neighbours in a raw file whose pixel resolution is 366 pixels (=120 pixels per square x 3 squares + 3 overlapping pixels per side x 2 sides). This is how it looks in PS, after converting it into a greyscale indexed image:

http://i.imgur.com/DBYvhNg.jpg

Note that I have added guidelines to it: the central area marked by the guidelines measures exactly 120 x 120 pixels, and it corresponds to the 1 deg x 1 deg quadrant that La Plate lies in.
Let's look for the exact position of our lighthouse now: we know that the bottom guideline marks 48 deg of latitude north. In SH metric units, that's 48 deg x 120,000 m/deg = 5,760,000 m. La Plate's position, from the mis file, is 5,764,737: a bit to the north of the line; 5,764,737 - 5,760,000 = 4,737: that's the metric distance between the top guidline on the elevation map and the lighthouse. Before, we had concluded that 1 pixel on that map was equal to 1,000 m, so if we want the distance from the bottom guideline in pixels we calculate 4,737 m / 1,000 m/pixel = 5 pixels. The calculation is similar for the longitude: the right guidline marks 5 deg of longitude west, -600,000 m in metric units. The lighthouse is placed at -571,143 m. -571,143 - (-600,000) = 28,857; 28,857 / 1,000 = 29 pixels from the right guidline. This is the pixel we were looking for, on the haight map:

http://i.imgur.com/dNOWdM6.jpg

For better readability I have zoomed in the map so only the zone comprised between the guidelines is visible (48-49°N, 5-4°W), and I have marked 'our' pixel with a selection mark. Its greyscale value is 46 by the way so, unless I made some gross mistake, we know now that a value of 46 on that indexed map, corresponds to an in-game depth of -17 m, and we also know that, if we want, we can do it shallower by one 'step', if we change that value from 46 to 47. Beyond that value, I think the area would still be submerged (the coastline map takes the priority for deciding what is sea and what land), but the area would probably be marked on the in-game navigation map as a brown pixel, as if it was land :03:

Precisely, the scale is not linear. A few months ago, I determined for almost all submerged pixels the exact depth, by changing colors of the scale (red-yellow-blue ... in order to distinguish between each depth) and putting land units on each depth in Mission Editor to know the exact depth.

Here is the scale :



Now, here is my idea : instead of searching the exact depth of each pixel (14400 for each square !) in Google Earth, let's take the map with red to blue scale I've posted, and convert into grey scale with the SH3 own scale, then apply to the SH3 map.

After that, I think we have to correct also the 3 pixels borders of the 9 squares around.

Hi The_Frog, thank you :salute:

A while ago, Kendras asked me for some generic lighthouses that we can place around the globe while we wait for more accurate models to get available. My idea is creating models of real lighthouses and day beacons that can be stripped down to their basic elements. Those elements should be easy to combine in order to create the said generic lighthouses, and the file structure I have adopted is functional to this 'modular' concept :)

I think I will move textures that are specific to a lighthouse unit, into the folder of that unit. All the remaining textures should remain in the tex folder, as I plan to re-use them on other models.

Still, there's something wrong in our files, otherwise specular masks would work. I hope that apllying some of your suggestions below can solve the problem...

You are right; we are still at the alpha stage, but soon all the textures used by the model will be resized/compressed, especially the ones of the rock model. When it comes to textures and non-vectorial 2D art, my philosophy is: the bigger the source files, the better they will look once they are resized to their final size :up:

If you mean in the same folder as the dat file, that's what I want to do. If you mean embedded in the dat files, I am a bit against embedded textures, essentially for two reasons:
a. they are not configurable; once you link a material to a 3d model and that material has a texture embedded, that model will have the same texture forever.
b. if you want to use the same texture on several dat files, you need to re-embed it as many times as the dat files that use it, with a total waste of disc stoting space and RAM.

I don't get you here :hmm2:

The rock model might be re-used in other locations, that's why I decided to store it in the library file. If you look into stock locations, they are mostly composed of dummy nodes and placement nodes pointing to models in the harbor_kit.dat library file :yep:

This is an option I had taken into consideration, but ad the end I decided to make it part of the rock terrain object, mostly for two reasons:
a. I don't want it to be destroyable
b. Ease of making terrain objects collisionable using the StaticObject controller

I don't get you. What would be the use of the cropped texture you are talking about?

It is not only about the lantern or topmark being removed during wartime. As I mentioned before, we might proxy-clone the La Plate tower and use it in another position as a different type of sea mark. Depending on the type of mark we want to reproduce, we might need to replace or remove at all one or more library parts, including lantern and topmark.

I am looking forward to listening to any other suggestion or remark you might come from you :up:

Amazing video Anvar1061, thank you for sharing, and by the way...

https://3dwarehouse.sketchup.com/mod...u-Fastnet-Rock :03:

Oh, amazing :yeah:

Tha's exactly the scale we need, with the Terrain.act palette applied to it. You can replace each shade of blue on it with a grey value going from 0 to 47 :yep:

Out of curiosity: do the first two values both correspond to -17 m?

Sure, we can't do this work pixel by pixel :O:

We are going to face some problems though:

1- what is the scale/projection of your depth map? If we want to do a decent work, that map should be stretched to fit the SHIII world

2- sure we can convert that colour map into a grey-scale image, but then grey values wouldn't have any relation with depths.

It would be better starting from a greyscale haight map. I have read on the web that, though a bit complicated, extracting height data from Google Earth is all but impossible. :yep:

That's going to be a real PITA :doh:

:sunny:

I think so, but first value should not be used, as it can take blue or brown color, depending on the map scale... :doh:

Except if we "rescale" the SH3 map picture in order to be linear. :yep:

That would be amazing ! :yep:

Just a note : I realized that the map from Schnell Boot v2 is even better than the map from War Ace Campaign v4.1. So, we should use the one coming with SBM 2.

Maybe that's a feature. Let's take a mental note of it, just in case we will need something like that in future :03:

Believe me, that's not going to happen. The SH world is the way it is and, once you know the rules, everything is in its right place. Look for any known location on my spreadsheet if you don't believe it.
Sure, distances are not right, and land masses are stretched out, but there is no way we can squeeze a spherical world into a cylindrical one. The one thing we would achieve, is moving around islands, ports, straits, landmarks and other geographical features in unpredictable ways :yep:

Let's put us on that. Provided that we manage getting our hands on good quality grayscale heightmaps, we couldn't use them as they are. Reason is that shades of gray shown on them are a linear fucntion of RW heights, whereas in SHIII the relation is not linear. I have plotted data from your chart on an Excel graph and left the program to interpolate a likely tendency line. This is the result:



Before we could use any heightmap, we should adjust its tonal range to reflect the graph above...

Yes.

You didn't understand me. :O: I mean the picture of the SH3 scale, in photoshop or paint.net : for each meter of depth, and thanks to the scale i've posted, we add the correct grey used by SH3 (Terrain Editor). Then, we get a real depth map (heightmap for example), we create the depth color scale used by it, and put this scale just above the grey SH3 scale. And then, for each SH3 depth intervall (one unique grey color), we select all the colors from the real depth map scale, and convert them into the correct grey. Easy ! :p2: But maybe i'm not clear enough... :doh:

I think I got you now :up:

That would be easier if we had access to a bathymetric chart with several bands of different colours, each colour representing a range of heights, like the one below:



Even easier if we had a graph showing bathymetric curves:



Working on colour gradients, as the ones in the graph we have currently available, makes things much more complicated :hmmm:

What card are you talking about? Show the path to the file and how it can be opened.

So here in WAC 4.1 :



And here in SBM 2 :

Hello gap,

before making things too complex -- what I was suggesting:

-- consider a less complex file structure (this may cause SH3 loosing track of all texture file paths ... that sometimes causes funny texture effects ....
-- this happens often preferentially with textures in the Texture folders ... that's why in GWX most textures were placed into the respective *.dat files or into the subfolders of the Air and Sea folder. Also, loading of large external texutures takes longer (and may cause fancy effects) than of embedded textures