Jump to content
Sign in to follow this  
rhumbaflappy

Road/VTP line width?

Recommended Posts

Guest

What in Hades happens to road widths & designations when you run them through scm2vtp?I have a scenery with 5 roads in it (all FSSC FS2k-style roads):1. 26m wide - stay as road2. 26m wide - as above3. 20m wide - as above4. 40m wide - become a stream5. 80m wide - become shoreline/sandbarHOWEVER... when I open the .asm file and edit the entry with "40" as it's second width entry, the *20m* wide road gets changed into a stream, and the 40m stays a road... Choosing the 20m as the stream changes one of the 26m roads into a stream... I FINALLY got everything sorted by changing the first 26m road into a stream, which (illogically) got me everything in the right places, seemingly at the right widths. (It looks OK to the eyeball, anyway...)The 80m wide road always works as a sandbar, at least.Several things seem to be going on:1. Obviously, order of road numbering in FSSC has little relation to the order they appear in a .asm file.2. And/or the widths change somehow - while the numbers present in the .asm file appear to remain the same as what was entered in FSSC.3. Also, I've noticed that the number of points an FSSC road has has only some bearing on the number present in it's .asm entry. Most gain points in .asm, while some seem to loose points.I hope I'm not the only person to run into this! Does anyone have a workaround or cure? Going by trial and error adds a lot of work to scenery design!Thanks,Brian.

Share this post


Link to post
Share on other sites
Guest gorchi

Hi!Take a look into my post FS2002 style roads a week or so ago. There You will find some more infos about this.Anyway, You have VTPLineWidth, which does change the width of the road. Next You have VTPTextureIndex which references to texture list at the end of ASM file. There You should find numbers for these textures. These numbers correspond to the texture numbers found in terraintextures.cfg which You can find in the FS2002 root directory. If You change these numbers in Your asm, You can even get shorelines instead of roads :-eek Regarding FSSC ordering and ASM output; yes that is true and it is a pitty, that the author did not put in the beggining of the road.Widths do change, taht is true and that for the roads with width < 10m. The minimum and acceptable width for this kind of roads seems to be 10m, which unfortunately is not as in reality. Two lane road would normaly be around 5 m wide.Points in FSSC have almost nothing in common with roads using VTP method. It is completely different way of drawing. Using VTP method You draw roads acrross numer of little squares (rhumbaflappy will explain in great detail I think) so even You have only 2 points of road in FSSC, that could make a loooot of points using VTP method. Please, take a look into FS Terrain SDK found at http://zone.msn.com/flightsim; there You will find also some more answers to Your problems.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites
Guest

Thanks, Goran. I already knew most of what you mentioned, and have been using it in my scenery building, although not being able to do roads narrower than 10m is new info!What puzzles me is that there isn't a relationship that I can see between the road widths I enter in FSSC, what I see in the .asm file, and (finally) what I see in the sim!I don't mean that the widths are going wrong, but see my comments above about what happened to my stream: in the .asm I tagged the WRONG width as a stream texture - but it all came out find and at the right widths in 2k2! (I only had two 26m wide roads; neither was supposed to be a stream, but tagging one of them as a stream was the only way I could get the 40m wide road to show as a stream...)Pardon the length, but here's the complete contents of the .asm file. My extra comments are BLOCK CAPS, and hopefully show the strange issue I ran into!Brian.-----------------------------------------include TDFMacros.incinclude TDFHeaders.inc; VTP Method2 Roads 51.32813 -125.1563 BGLHeader 52, 50, -124, -127, TerrainHeaderStart, VTPHeaderVTPHeader label word VTPFileHeader 256, VTPIndexStart, TextureStart, VTPEndVTPStart label word datamark_v0 label word VTPDataArea 1, 1, 0, 0; Road 2 - STAY AS ROAD VTPLayer 31, 0 VTPNumTexturesInLayer 1, 0 VTPTextureId 1, 0 VTPPolyCount 1, 0 VTPPolyMethod2 31, 1, 0 VTPPolyMethod2Ex 13 VTPWidePoint 6900, 1, 6802, 0 VTPWidePointWidth 1 VTPWidePoint 6900, 1, 6802, 0 VTPWidePointWidth 20 VTPWidePoint 6900, 0, 6802, 0 VTPWidePoint 6896, 0, 6822, 0 VTPWidePoint 6889, 0, 6854, 0 VTPWidePoint 6886, 0, 6870, 0 VTPWidePoint 6883, 0, 6886, 0 VTPWidePoint 6876, 0, 6918, 0 VTPWidePoint 6869, 0, 6949, 0 VTPWidePoint 6869, 0, 6950, 0 VTPWidePoint 6866, 0, 6982, 0 VTPWidePoint 6864, 0, 7000, 0 VTPWidePoint 6855, 0, 7014, 0 VTPWidePoint 6839, 0, 7039, 0 VTPWidePoint 6832, 0, 7045, 0 VTPWidePoint 6822, 0, 7054, 0 VTPWidePoint 6797, 0, 7077, 0 VTPWidePoint 6790, 0, 7084, 0 VTPWidePoint 6763, 0, 7109, 0 VTPWidePoint 6759, 0, 7113, 0 VTPWidePoint 6746, 0, 7125, 0 VTPWidePoint 6727, 0, 7141, 0 VTPWidePoint 6726, 0, 7141, 0 VTPWidePoint 6695, 0, 7168, 0 VTPWidePoint 6688, 0, 7173, 0 VTPWidePoint 6663, 0, 7194, 0 VTPWidePoint 6651, 0, 7205, 0 VTPWidePoint 6631, 0, 7221, 0 VTPWidePoint 6626, 0, 7225, 0 VTPWidePoint 6614, 0, 7237, 0 VTPWidePoint 6599, 0, 7250, 0 VTPWidePoint 6582, 0, 7266, 0 VTPWidePoint 6580, 0, 7268, 0 VTPWidePoint 6561, 0, 7288, 0 VTPWidePoint 6544, 0, 7310, 0 VTPWidePoint 6535, 0, 7316, 0 VTPWidePoint 6504, 0, 7338, 0 VTPWidePoint 6496, 0, 7343, 0 VTPWidePoint 6483, 0, 7357, 0 VTPWidePoint 6477, 0, 7368, 0 VTPWidePoint 6471, 0, 7374, 0 VTPWidePoint 6469, 0, 7382, 0 VTPWidePoint 6473, 0, 7405, 0 VTPWidePoint 6466, 1, 7410, 0 VTPWidePointWidth 0 VTPDataArea 1, 1, 0, 0; Road 3 SHOULD BE STREAM BUT TAGGED AS ROAD. ; SHOWS AS STREAM WHEN ROAD FOUR BELOW IS TAGGED AS STREAM. VTPLayer 31, 0 VTPNumTexturesInLayer 1, 0 VTPTextureId 1, 0 VTPPolyCount 1, 0 VTPPolyMethod2 18, 1, 0 VTPWidePoint 6582, 1, 7266, 0 VTPWidePointWidth 1 VTPWidePoint 6582, 1, 7266, 0 VTPWidePointWidth 40 VTPWidePoint 6582, 0, 7266, 0 VTPWidePoint 6578, 0, 7270, 0 VTPWidePoint 6580, 0, 7276, 0 VTPWidePoint 6582, 0, 7280, 0 VTPWidePoint 6583, 0, 7284, 0 VTPWidePoint 6584, 0, 7287, 0 VTPWidePoint 6587, 0, 7289, 0 VTPWidePoint 6590, 0, 7289, 0 VTPWidePoint 6593, 0, 7288, 0 VTPWidePoint 6593, 0, 7286, 0 VTPWidePoint 6594, 0, 7284, 0 VTPWidePoint 6592, 0, 7282, 0 VTPWidePoint 6590, 0, 7282, 0 VTPWidePoint 6588, 0, 7281, 0 VTPWidePoint 6586, 0, 7281, 0 VTPWidePoint 6582, 1, 7280, 0 VTPWidePointWidth 0 VTPDataArea 1, 1, 0, 0; Road 4 SHOULD BE ROAD, TAGGED AS STREAM BUT SHOWS AS ROAD VTPLayer 32, 0 VTPNumTexturesInLayer 1, 0 VTPTextureId 3, 0 VTPPolyCount 1, 0 VTPPolyMethod2 31, 1, 0 VTPPolyMethod2Ex 7 VTPWidePoint 5823, 1, 7201, 0 VTPWidePointWidth 1 VTPWidePoint 5823, 1, 7201, 0 VTPWidePointWidth 26 VTPWidePoint 5823, 0, 7201, 0 VTPWidePoint 5834, 0, 7201, 0 VTPWidePoint 5866, 0, 7202, 0 VTPWidePoint 5898, 0, 7204, 0 VTPWidePoint 5930, 0, 7205, 0 VTPWidePoint 5962, 0, 7206, 0 VTPWidePoint 5987, 0, 7207, 0 VTPWidePoint 5994, 0, 7210, 0 VTPWidePoint 6025, 0, 7222, 0 VTPWidePoint 6057, 0, 7234, 0 VTPWidePoint 6089, 0, 7246, 0 VTPWidePoint 6092, 0, 7248, 0 VTPWidePoint 6121, 0, 7256, 0 VTPWidePoint 6153, 0, 7265, 0 VTPWidePoint 6163, 0, 7269, 0 VTPWidePoint 6185, 0, 7275, 0 VTPWidePoint 6217, 0, 7284, 0 VTPWidePoint 6249, 0, 7294, 0 VTPWidePoint 6251, 0, 7294, 0 VTPWidePoint 6280, 0, 7294, 0 VTPWidePoint 6301, 0, 7294, 0 VTPWidePoint 6306, 0, 7300, 0 VTPWidePoint 6324, 0, 7325, 0 VTPWidePoint 6344, 0, 7321, 0 VTPWidePoint 6376, 0, 7315, 0 VTPWidePoint 6390, 0, 7312, 0 VTPWidePoint 6408, 0, 7319, 0 VTPWidePoint 6439, 0, 7331, 0 VTPWidePoint 6440, 0, 7331, 0 VTPWidePoint 6442, 0, 7332, 0 VTPWidePoint 6472, 0, 7348, 0 VTPWidePoint 6476, 0, 7350, 0 VTPWidePoint 6504, 0, 7355, 0 VTPWidePoint 6508, 0, 7355, 0 VTPWidePoint 6535, 0, 7367, 0 VTPWidePoint 6542, 1, 7370, 0 VTPWidePointWidth 0 VTPDataArea 1, 1, 0, 0; Road 5 TAGGED, SHOULD BE AND IS A ROAD VTPLayer 31, 0 VTPNumTexturesInLayer 1, 0 VTPTextureId 1, 0 VTPPolyCount 1, 0 VTPPolyMethod2 31, 1, 0 VTPPolyMethod2Ex 73 VTPWidePoint 5988, 1, 8674, 0 VTPWidePointWidth 1 VTPWidePoint 5988, 1, 8674, 0 VTPWidePointWidth 26 VTPWidePoint 5988, 0, 8674, 0 VTPWidePoint 5983, 0, 8671, 0 VTPWidePoint 5962, 0, 8655, 0 VTPWidePoint 5941, 0, 8639, 0 VTPWidePoint 5930, 0, 8631, 0 VTPWidePoint 5898, 0, 8607, 0 VTPWidePoint 5898, 0, 8607, 0 VTPWidePoint 5868, 0, 8585, 0 VTPWidePoint 5866, 0, 8584, 0 VTPWidePoint 5834, 0, 8579, 0 VTPWidePoint 5802, 0, 8574, 0 VTPWidePoint 5770, 0, 8569, 0 VTPWidePoint 5739, 0, 8564, 0 VTPWidePoint 5730, 0, 8563, 0 VTPWidePoint 5719, 0, 8544, 0 VTPWidePoint 5707, 0, 8524, 0 VTPWidePoint 5699, 0, 8512, 0 VTPWidePoint 5680, 0, 8480, 0 VTPWidePoint 5675, 0, 8471, 0 VTPWidePoint 5661, 0, 8448, 0 VTPWidePoint 5643, 0, 8418, 0 VTPWidePoint 5642, 0, 8416, 0 VTPWidePoint 5640, 0, 8414, 0 VTPWidePoint 5627, 0, 8384, 0 VTPWidePoint 5613, 0, 8352, 0 VTPWidePoint 5611, 0, 8347, 0 VTPWidePoint 5590, 0, 8320, 0 VTPWidePoint 5579, 0, 8306, 0 VTPWidePoint 5566, 0, 8289, 0 VTPWidePoint 5547, 0, 8263, 0 VTPWidePoint 5542, 0, 8257, 0 VTPWidePoint 5518, 0, 8225, 0 VTPWidePoint 5515, 0, 8221, 0 VTPWidePoint 5494, 0, 8193, 0 VTPWidePoint 5484, 0, 8179, 0 VTPWidePoint 5483, 0, 8178, 0 VTPWidePoint 5480, 0, 8161, 0 VTPWidePoint 5475, 0, 8131, 0 VTPWidePoint 5475, 0, 8129, 0 VTPWidePoint 5480, 0, 8097, 0 VTPWidePoint 5485, 0, 8065, 0 VTPWidePoint 5490, 0, 8034, 0 VTPWidePoint 5495, 0, 8003, 0 VTPWidePoint 5496, 0, 8002, 0 VTPWidePoint 5512, 0, 7970, 0 VTPWidePoint 5515, 0, 7964, 0 VTPWidePoint 5529, 0, 7938, 0 VTPWidePoint 5541, 0, 7914, 0 VTPWidePoint 5547, 0, 7910, 0 VTPWidePoint 5554, 0, 7906, 0 VTPWidePoint 5579, 0, 7889, 0 VTPWidePoint 5602, 0, 7874, 0 VTPWidePoint 5611, 0, 7868, 0 VTPWidePoint 5642, 0, 7848, 0 VTPWidePoint 5643, 0, 7848, 0 VTPWidePoint 5658, 0, 7842, 0 VTPWidePoint 5675, 0, 7836, 0 VTPWidePoint 5707, 0, 7825, 0 VTPWidePoint 5739, 0, 7813, 0 VTPWidePoint 5746, 0, 7810, 0 VTPWidePoint 5759, 0, 7806, 0 VTPWidePoint 5770, 0, 7793, 0 VTPWidePoint 5783, 0, 7779, 0 VTPWidePoint 5802, 0, 7757, 0 VTPWidePoint 5812, 0, 7747, 0 VTPWidePoint 5834, 0, 7721, 0 VTPWidePoint 5840, 0, 7715, 0 VTPWidePoint 5848, 0, 7706, 0 VTPWidePoint 5863, 0, 7683, 0 VTPWidePoint 5866, 0, 7678, 0 VTPWidePoint 5883, 0, 7651, 0 VTPWidePoint 5898, 0, 7629, 0 VTPWidePoint 5900, 0, 7625, 0 VTPWidePoint 5907, 0, 7619, 0 VTPWidePoint 5930, 0, 7599, 0 VTPWidePoint 5944, 0, 7587, 0 VTPWidePoint 5946, 0, 7586, 0 VTPWidePoint 5962, 0, 7580, 0 VTPWidePoint 5994, 0, 7568, 0 VTPWidePoint 6021, 0, 7558, 0 VTPWidePoint 6025, 0, 7557, 0 VTPWidePoint 6031, 0, 7555, 0 VTPWidePoint 6057, 0, 7548, 0 VTPWidePoint 6089, 0, 7538, 0 VTPWidePoint 6121, 0, 7529, 0 VTPWidePoint 6139, 0, 7524, 0 VTPWidePoint 6153, 0, 7519, 0 VTPWidePoint 6157, 0, 7518, 0 VTPWidePoint 6185, 0, 7513, 0 VTPWidePoint 6217, 0, 7507, 0 VTPWidePoint 6249, 0, 7501, 0 VTPWidePoint 6280, 0, 7496, 0 VTPWidePoint 6287, 0, 7494, 0 VTPWidePoint 6292, 0, 7492, 0 VTPWidePoint 6312, 0, 7481, 0 VTPWidePoint 6344, 0, 7464, 0 VTPWidePoint 6352, 0, 7460, 0 VTPWidePoint 6376, 0, 7447, 0 VTPWidePoint 6384, 0, 7443, 0 VTPWidePoint 6408, 0, 7440, 0 VTPWidePoint 6439, 0, 7436, 0 VTPWidePoint 6457, 1, 7419, 0 VTPWidePointWidth 0 VTPDataArea 1, 1, 0, 0; Road 6 SHORELINE WITH NO STRANGE ISSUES AT ALL VTPLayer 31, 0 VTPNumTexturesInLayer 1, 0 VTPTextureId 4, 0 VTPPolyCount 1, 0 VTPPolyMethod2 22, 1, 0 VTPWidePoint 6080, 1, 7610, 0 VTPWidePointWidth 1 VTPWidePoint 6080, 1, 7610, 0 VTPWidePointWidth 80 VTPWidePoint 6080, 0, 7610, 0 VTPWidePoint 6057, 0, 7622, 0 VTPWidePoint 6035, 0, 7634, 0 VTPWidePoint 6015, 0, 7662, 0 VTPWidePoint 5985, 0, 7698, 0 VTPWidePoint 5977, 0, 7715, 0 VTPWidePoint 5964, 0, 7742, 0 VTPWidePoint 5987, 0, 7715, 0 VTPWidePoint 5994, 0, 7708, 0 VTPWidePoint 6015, 0, 7683, 0 VTPWidePoint 6018, 0, 7679, 0 VTPWidePoint 6038, 0, 7651, 0 VTPWidePoint 6043, 0, 7645, 0 VTPWidePoint 6070, 0, 7627, 0 VTPWidePoint 6089, 0, 7621, 0 VTPWidePoint 6121, 0, 7611, 0 VTPWidePoint 6143, 0, 7604, 0 VTPWidePoint 6121, 0, 7607, 0 VTPWidePoint 6089, 0, 7611, 0 VTPWidePoint 6073, 1, 7613, 0 VTPWidePointWidth 0 datamark_v1 label word; ---------------------------------------------------------------------------------------------------------Cellv_117_110 EQU VTPCellID 0, 117, 110; --------------------------------------------------------------------------------------------------------- VTPIndexStart label word VTPIndexHeader 1, VTPIndexData, VTPStart VTPIndexData label word VTPIndexEntry Cellv_117_110, VTPStart, datamark_v0, datamark_v1; ---------------------------------------------------------------------------------------------------------TextureStart label word VTPTextureListHeader 5, TextureIndexStart, TextureDataStart, TextureDataEndTextureIndexStart label word VTPTextureListEntry TextureDataStart, texturemark_0, texturemark_1 VTPTextureListEntry TextureDataStart, texturemark_1, texturemark_2 VTPTextureListEntry TextureDataStart, texturemark_2, texturemark_3 VTPTextureListEntry TextureDataStart, texturemark_3, texturemark_4 VTPTextureListEntry TextureDataStart, texturemark_4, texturemark_5TextureDataStart label word texturemark_0 label word VTPTextureName "1162" VTPTextureType 2, 0, 0, 4 texturemark_1 label word VTPTextureName "1158" VTPTextureType 2, 0, 0, 4 texturemark_2 label word VTPTextureName "1160" VTPTextureType 2, 0, 0, 4 texturemark_3 label word VTPTextureName "1025" VTPTextureType 2, 0, 0, 4 texturemark_4 label word VTPTextureName "1059" VTPTextureType 2, 0, 0, 4 texturemark_5 label wordTextureDataEnd label word; ---------------------------------------------------------------------------------------------------------VTPEnd label word-----------------------------------------

Share this post


Link to post
Share on other sites
Guest falko

Hi Brianyou are right, there is a bug in SCM2VTP witch stores the comment-line and the width of the road to the wrong road-block. This problem should be solved by the SCM2VTP-version from 3.12.2002 witch is available at "Falko.Dienstbach.bei.t-online.de". best regardsFalko

Share this post


Link to post
Share on other sites

Hi BrianB.I've resisted answering anything here because I do not know the internal workings of scm2vtp. That limits anything I can say about that program. Many people are using it, and it seems to work well, and is a great relief to most users as BGLC handcoding can be dreadful.But you have raised some interesting points.Just what does the VTPWidePointhWidth define? Is it the actual width of the line, or is it just the display of the texture?The width actually defines the width of the line. But what is the measurement of that width? Pixels? Meters? 4 meters/pixel? Truthfully, I've never thought of it before... but it seems to me it is meters.The display of these lines is also odd, because they use textures with alpha transparency, and the transparency must also be accounted for in the displayed width. So that is a very interesting observation.Regarding why parts of the ASM code aren't showing the proper textures, I'm also not sure. But the code is doing something I haven't dealt with before.The default BGLs keep lines types separate. MS doesn't mix roads ( rdl ), streams ( stl ), and beaches ( hyl ). Nor do they mix polys and lines... and I have noted problems when mixing polys and lines. So that may be a clue as to the abnormalities of the display.Also, the ASM code may have a problem.VTPNumTexturesInLayer 1, 0...states there is one texture used in the layer. Yet your layer 31 uses both a road texture and a shore texture. And the SDK also states:"you can use the same TextureID more than once in a given layer, but every occurance must be accounted for in the texture count."You are using layer 31 for 4 lines, with 2 textures, and the SDK is unclear as to whether each line as structured in your ASM would need to declare:VTPNumTexturesInLayer 1, 0or...VTPNumTexturesInLayer 2, 0or...VTPNumTexturesInLayer 4, 0or whether the SDK is actually wrong, and maybe...VTPNumTexturesInLayer 5, 0...needs to be declared.I don't know the answer to this, as I've never mixed line textures and layers in the same BGL. My guess would be that, as you are using a separate, complete data structure for each line, it should work as coded! But obviously it doesn't work right. I don't know why the terrain engine would need to know of other textures in the layer, if they are declared as a separate line structure in the data stream.So time permitting, I'll play with this code as well, and see if I can figure anything out.Dick

Share this post


Link to post
Share on other sites

Hi BrianB.The code you have given displays perfectly. I don't understand what you want to change.I see a road following the edge of the river, a sandbar, and a stream coming down off the moutain into the river.The layer number of the stream is 32... you probably want Layer 16 for streams, and Layer 8 for the sandbar shoreline. That's what the SDK recommends so that everything lies down 'over and under' correctly. Right now, the stream displays over the road, unless that is your intention.Dick

Share this post


Link to post
Share on other sites

Hi Dick,We (NL2000 Team) haven't got our lines working at the moment, still working on that, but for the VTP polygons (and I assume they work the same) we use different textures and layers in one file. That works fine and in the VTPNumTexturesInLayer command we specify the number of textures that is used in that specific layer (so not the total number).Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

Hi Arno.I think the code Brian posted was his post-fix version... so I can't see anything that was wrong.I see Dr. Dienstbach replied, and he has a fix for some problem that may help Brian... so hopefully all is well there.-----------------In the above example, the lines are defined as separate structures, so I would expect they don't need to declare more than 1 texture for each structure.I might try today to create a code that does require increasing the declaration of the number of textures in the layer.

VTPDataArea 1, 1, 0, 0VTPLayer 31, 0VTPNumTexturesInLayer 2, 0;;VTPTextureId 1, 0VTPPolyCount 1, 0VTPPolyMethod2 31, 1, 0VTPPolyMethod2Ex 13VTPWidePoint 6900, 1, 6802, 0VTPWidePointWidth 1 VTPWidePoint 6900, 1, 6802, 0VTPWidePointWidth 20VTPWidePoint 6900, 0, 6802, 0.................;;VTPTextureId 3, 0VTPPolyCount 1, 0VTPPolyMethod2 31, 1, 0VTPPolyMethod2Ex 7VTPWidePoint 5823, 1, 7201, 0VTPWidePointWidth 1 VTPWidePoint 5823, 1, 7201, 0VTPWidePointWidth 26VTPWidePoint 5823, 0, 7201, 0VTPWidePoint 5834, 0, 7201, 0..................

In that snip, the VTPDataArea is not restated, or the VTPLayer, so I'm thinking it would then require declaring more than one texture.If VTPDataArea is stated for each line segment, or the segments are accounted for in the same polycount, I think they don't need the VTPNumTexturesInLayer increased. I don't know for sure, and have never needed to increase the count for VTPNumTexturesInLayer, but it should be there for a reason. But, then again, there may be no reason for it, other than the terrain engine expects a number of textures count there in the datastream, even if it's not implemented.It's too bad there are almost no examples of code in the SDK. ( Some C+ code is included... and some of that is wrong! ) So we need to find the usages as they 'popup' as problems.For now, in my coding, I've never had to change:VTPNumTexturesInLayer 1, 0...to anything other than 1.Dick

Share this post


Link to post
Share on other sites
Guest fumey

HelloI have taken a look to your code :due to the structure of VTP, for a given Cell, there is no need to repeat VTPDataArea because your roads/streams are in the same Cell, nor VTPLayer if your lines have the same layer in the same Cell.It could be the cause of problems (?).For the number of textures in a layer, I use the number of texture calls as stated in the documentation, it works.Width : I thought that 80 m could be too large but I have tested 200m, I got correct results.Other tests : - for wave effects, the land must be on the left! I'm on the other side of the Greenweech meridian; is it may be the reason ? or Coriolis strength ?- number of points for a line : I have reached 280 points without problems and cut a 600 points line in several lines; no problemI'm fighting with landclasses and waterclasses : I see nothing with Waterclasses, and have strange results with Landclasses, trying Landclass Assistant or using my own CellX/Ydimensions with 256x256 or 257x257;I need to test more, and than I shall send comments.Resample.exe and CUSTOM option :I use NumOfCellsPerLine and Numoflines with a value 1 and of course the good corresponding values for CellX/Ydimensions; the explanation is simple : the number of pixels is found in the bitmap itself, Resample.exe needing only the sizes in degrees for the covered surface.An other conclusion is that Resample.exe uses this parameters in regard of the choosed option. In other words, I think that the used rule is depending on the options (Custom, ClassU8...)Christian

Share this post


Link to post
Share on other sites

Hi Arno.I've now found that changingVTPNumTexturesInLayer 1, 0to any number other than 0 or 1, will crash the sim.The SDK seems to indicate that you could declare more textures, then simply provide the ID and the polycount before each set of points... but it doesn't work.VTPDataArea 1, 1, 0, 0VTPLayer 31, 0VTPNumTexturesInLayer 1, 0VTPTextureId 1, 0VTPPolyCount 3, 0This example allows 3 polys of the same texture... but I cannot do this:VTPDataArea 1, 1, 0, 0VTPLayer 31, 0VTPNumTexturesInLayer 2, 0VTPTextureId 1, 0VTPPolyCount 2, 0................points........then:VTPTextureId 3, 0VTPPolyCount 1, 0................pointsYet, that is what the SDK says is possible. Instead, this is allowed:VTPDataArea 1, 1, 0, 0VTPLayer 31, 0VTPNumTexturesInLayer 1, 0VTPTextureId 1, 0VTPPolyCount 2, 0................points........then:VTPDataArea 1, 1, 0, 0VTPLayer 31, 0VTPNumTexturesInLayer 1, 0VTPTextureId 3, 0VTPPolyCount 1, 0................pointsAnd the SDK indicates that should not work, as we are now using another texture for that layer in the BGL... but the datastream was notified of a new VTP structure by the repeated use of:VTPDataArea 1, 1, 0, 0...so, we don't need to worry about the number of textures in the layer, as we are now in a new structure in the datastream, even though it's in the same BGL.--------------------So I have no idea why there would ever be more than one texture declared for a layer. Zero textures allows a layer deletion, and is used to good effect in Christian Fumey's "defarea" program... but again, the LOD13 Area must be correctly stated for defarea, and that also contradicts the SDK. The SDK states that the Area should be set to 0,0.-------------------Many of the details of the SDK must be taken with scepticism. In addition to a lack of examples, they also didn't test their documentation.Other, unrelated examples of this is the limit of 24 points for a VTPm1 poly... with no extended form possible; the use of semicolons, not commas, for named textures; the disregard of night textures for VTPm1s; the vertical flipping of textures with all VTP polys...The issues with VTPm1s were known to MS programmers in CFS2, but the documentation was never changed. So the SDK writers have no TDF programming experience.------------------Regarding Brian's problem, I can think of no reason why changing the width of a line would cause any problems with the VTP lines... and certainly not affecting the texture type displayed.Dick

Share this post


Link to post
Share on other sites

Hi Christian.It is good to hear from you!If it is alright, could you send me an example of code that you have used with 'VTPNumTexturesInLayer' set to more than 0 or 1?ludowr@charter.comI would hate to leave the discussion misleading anyone about that, and you seem to have got that working. There may be something I've misunderstood about the code sequence.Regarding the restatement of:VTPDataArea 1, 1, 0, 0VTPLayer 31, 0... that just states a new structure in the datastream... and I have looked at many examples of the default BGLs using just that technique.Also, as long as I've got your 'ear', have you had problems with mixing VTPm2 polys and lines in the same BGL? I've had some issues with that.Dick

Share this post


Link to post
Share on other sites
Guest

As was pointed out, the .asm I posted above was my corrected, working version. I should have saved one of the oddball early versions to show the problem I was having...Having played with the asm and two others again last night, I still can't figure out why putting the 'wrong' texture on one line causes FS to display all the textures on the correct lines. I'll go back later tonight and re-create one of the bad .asm files, and post that here for dissection by the experts! (with a screenshot, pics being worth 1000 words and so on...)I'll also correct the layer tags - some of my other work last night revealed why it's actually a good idea to follow the layer guidelines instead of being lazy.It's interesting (and irritating) to learn that apparently MS doesn't know how to use their own formats either! I've only skimmed most of the SDK docs, but it sounds like I haven't really missed much accurate information!Brian.

Share this post


Link to post
Share on other sites
Guest

>Hi Brian >you are right, there is a bug in SCM2VTP witch stores the >comment-line and the width of the road to the wrong >road-block. This problem should be solved by the >SCM2VTP-version from 3.12.2002 witch is available at >"Falko.Dienstbach.bei.t-online.de". >best regards >Falko Oops... We're all getting excited solving this problem I've been having, and it turns out that Falko's newest version of Scm2Vtp does away with the problem entirely! Thanks, Falko!I just created a new .sca file, ran it thru scm2vtp, did the usual manual edit and compile, and it works fine. The new scm2vtp keeps everything in exactly the same order as FSSC, with the right widths and everything.The scenery is a completely redone version of my Homathko River & Scar Creek package that I uploaded a couple of weeks ago; it's the result of a batch of new real-world information I got, and my learning curve with 2k2 scenery building! It should be releasable this weekend, finally! (I'd post a screenshot, but my firewall doesn't seem to like AvSim's upload process for some reason...Oh well, I know I've learned a lot from this thread...Thanks again,Brian.

Share this post


Link to post
Share on other sites

Hi Dick,What I said is only tested for polygons and not for lines, but as the structure of the code is the same, I expect that the code will work the same.In our NL2000 scenery we are using polygons with different textures on the same layer. Then you have to specify with the VTPNumTexturesInLayer the number of different textures that will be used in the layer. It works fine with our scenery that way. In some layers we use 4 textures or so.If you want I can send you a piece of source code as we made it (I think it will be too big to post here, you can mail me at arno@nl-2000.com).And, yes you are right about the errors in the SDK. We also found out that there are some mistakes in the examples and the text. But with trial and error we have got most of it working now.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...