Jump to content
Sign in to follow this  
Guest Horst

Exploring Terrain.CFG and creating incompatibilities .....

Recommended Posts

Guest luissa

Hi,I was exploring the possibilities of using my own texture lines. For example I would like to use my own river (or stream) texture. FS has only 2 textures (1024 and 1025) and, as far as I can tell, they are equal :-hmmm My first experience was to use a pack of named textures. This has nothing to do with Terrain.CFG. In SBuilder I use a similar approach that I found in Ground 2k. The approach is to use an integer to refer to the pack of name textures. My LINES.TXT in SBuilder ends as follows:...[Texture.1261]Title=Bridge dirt / 10 lanes / undivided medianColor=0 200 50Textures=na.bmp[Texture.5001]Title=Water Texture for linesColor=0 0 255Textures=001b2wa1.bmpNamePack="riospt0.bmp;riospt0.bmp;riospt0.bmp;riospt0.bmp;riospt0.bmp;riospt0.bmp" 1 0 0 4 [Texture.5002]Title=Large RiversColor=0 0 255Textures=riospt1.bmpNamePack="riospt1.bmp;riospt1.bmp;riospt1.bmp;riospt1.bmp;riospt1.bmp;riospt1.bmp" 1 0 0 4 [Texture.5003]Title=Small RiversColor=0 0 255Textures=riospt2.bmpNamePack="riospt2.bmp;riospt2.bmp;riospt2.bmp;riospt2.bmp;riospt2.bmp;riospt2.bmp" 1 0 0 4 [Texture.5004]Title=Rivers using the default rivers.bmp texture Color=0 0 255Textures=rivers.bmpNamePack="rivers.bmp;rivers.bmp;rivers.bmp;rivers.bmp;rivers.bmp;rivers.bmp" 1 0 0 4 [Texture.5005]Title=Waves without any textureColor=0 0 255Textures=na.bmpNamePack=";;;;;" 1 1 0 4 "wavecontroller" I adopted the convention that integers larger than 5000 are in fact packs of named textures. With named textures I can use effects and seasonal variations but I do not know how to use offsets and other nice features described in the Terrain.CFG documentation. I would like to make a depression for my rivers. This could be done adding my lines to Terrain.CFG but here comes the danger for conflict.Terrain.CFG starts with:[General]DefaultTextureCount=238AutogenCount=14// texture order = wi,hw,sp,su,fa,nighttexture//Stream Lines[Texture.1024] // stream lines / unknown / perennialType=1Size=4ExcludeAutogen=1MaskClassMap=3Textures=RiverSU.bmpoffset=-10[Texture.1025] // stream lines / unknown / non-perennialType=1Size=4ExcludeAutogen=1MaskClassMap=3Textures=RiverSU.bmpoffset=-10...The first texture ID (an integer) is 1024. The parameter DefaultTextureCount=238 means that we will have 238 textures starting at 1024 and ending at 1261 (1261-1024+1=238). So the obvious thing to do is to increase this number to 239 and add a texture section with ID 1262. I inserted my own texture after ID 1261 lines:[Texture.1261] // dirt / 10 lanes / undivided medianType=3Size=4ExcludeAutogen=1MaskClassMap=0VectorAutogen=7//My Own river textures[Texture.1262] // River with a depression of 5 metersType=1Size=4ExcludeAutogen=1MaskClassMap=3Textures=riospt2.bmpoffset=-5Those who followed me see the problem for conflict. It is important to note that if I change DefaultTextureCount=239 and declare my texture to be 1263 FS crashes. But if I change DefaultTextureCount=240 apparently I can use 1263 even without having 1262. I just have done DefaultTextureCount=4000 and declared my texture to be 3000 without problems!It came to my mind that AVSIM and this forum is probably read by all scenery designers in the world. May be we could adopt a convention. For example we could assign IDs from 2000 to 2999 to America (or to American designers). IDs 3000 to 3999 could be used in Europe (or by European designers) and so on. Or better still we could maintain a sticky thread as the one that Luiz Felizardo started as "Guide to Scenery Design" where we could pick up numbers (and hopefully upload the textures to the Library) sequencially.I am sorry if there is a simpler solution to this problem and if I made you lost time in reading this post.Kind Regards, Luis

Share this post


Link to post
Share on other sites

Hi Luis,great to hear you're working on custom texture extensions for SBuilder.In my opinion, depressions of streams are no longer necessary once they fit well with a high-res add-on mesh. But that's just my personal opinion!I'd rather not have designers distribute altered terrain.cfg files as that could potentially lead to all sorts of confusion, even with "standards" as you propose.Instead, I suggest to use "duplicate" lines as a simple work-around: for streams, the lower layer would use #1024 or #1025 to make the depressions, with a width of "0" (or as close to "0" as possible: G2K4 allows a minimum of "2"). The higher layer would utilize the custom (seasonal) texture, with an appropriate width. This approach works the same for the flatten effects of roads and railroads; no need to make any changes to the terrain.cfg.The obvious drawback is that the double lines would require twice the HD/RAM space and potentially higher processing power but my application of this method hasn't shown any major impact. Perhaps others could test this approach and let us know...Cheers, Holger

Share this post


Link to post
Share on other sites
Guest luissa

Hi Holger,Thanks for the input>In my opinion, depressions of streams are no longer necessary>once they fit well with a high-res add-on mesh. But that's>just my personal opinion!Uhmmm! I spent many hours editing rivers because they do not fit a detailed mesh. The worst thing about rivers is when they do not stay in the valleys! I even bought a pen and a digitizing tablet (an add support of these into SBuilder) to save my right hand from a "tendinite". The mesh is LOD10 and I placed every point in my rivers in the lowest altitude. I use the "mesh background" in SBuilder to do that. But I need, at least, to flat or I see the river going up slightly.>The obvious drawback is that the double lines would require>twice the HD/RAM space and potentially higher processing power>but my application of this method hasn't shown any major>impact. Perhaps others could test this approach and let us>know...Very clever Holger! I would never thought about this walkaround! I need to access the impact! Regards, Luis

Share this post


Link to post
Share on other sites

Hi Luis,"The worst thing about rivers is when they do not stay in the valleys! I even bought a pen and a digitizing tablet (an add support of these into SBuilder) to save my right hand from a "tendinite". The mesh is LOD10 and I placed every point in my rivers in the lowest altitude. I use the "mesh background" in SBuilder to do that. But I need, at least, to flat or I see the river going up slightly."I know exactly what you're talking about ;-) I try drawing them in on the background map/image (in G2K4) first but usually end up doing the "slew-drawing" in the sim, something you might want to consider for SBuilder too. It works quite well - autogen off, starting at the lower end of the stream and slewing upriver - and is a bit more fun than click-click-click.Cheers, Holger

Share this post


Link to post
Share on other sites

Hi Luis and Holger.The method Holger is proposing will be fine for streams. However, roads may be a bit more of a problem, because there can be so many of them! A duplicate set of small-width roads, over an entire LOD5 series, would probably cause a good chunk of memory to be used. Just a caution when making large-area sceneries.Some users of the newer US road sceneries are getting shocked by the amounts of memory needed by those products.I think don't think we should support the suggestion of adopting a convention for the Terrain.cfg. I agree with you, Holger, that this is not a good situation. If an end-user has memory problems with duplicate lines, then he would be better served by buying more PC memory, then messing with the Terrain.cfg.From a distribution standpoint, this would be a nightmare, with auto-installers messing up the terrain.cfg, conflicting number usage... x( I think we should resist any additions to it because it is global in nature, rather than allowing us to have a "local" terrain.cfg within the Project folder.It would be nice if the next version of FS would allow us "local" control of all elements of LWM-VTP-Landclass-Autogen-Mesh within each separate Project folder. If we had that, discussions like these would be unneeded. As it stands for terrain designers, FS9 is a bit user-UNfriendly, forcing us to replace elements of FS scenery and/or "trick" the sim, rather than to simply make the changes.Sorry for the rant, but IF the FS design team is reading this... PLEASE give us a hand here. You don't need to bloat the next version with higher detail terrain, just give us the means to easily alter it!Dick

Share this post


Link to post
Share on other sites
Guest luissa

Hi Holger and Dick,I see that you do not agree with the idea of creating an improved Terrain.CFG. I myself tend to agree with you. Even so, just after writing my post, I found, in the avsim archives, a discussion beteween Rhumba and Chris about bridges. Chris even posted its Terrain.CFG to get more predicatable bridges.May be the following example is not good but what I was suggesting was something like the "airport for windows textures". Some years ago almost every macro used that set of textures. Then people placed those textures in the default texture folder. And, in those times of slow and narrow band internet connections, designers did not distributed those textures. Everyone was supposed to download the standard textures once ...Another example is the "TDF macros" which is a "de facto" standard for working with BGLCOMP.I though we could all agree on some addings to Terrain.CFG and "making it official". My vote for the first adding would be://Custom Roads - AVSIM forum[Texture.1262] // Flat Road no 1Type=1Size=4ExcludeAutogen=1MaskClassMap=?Textures=avsimroads1.bmpoffset=flatAt the moment of writing I have not the "Terrain Config document" with me. So the "?" and the single texture (I do not remember the season order for textures). Otherwise I would propose a set of seasonal textures.Designers could make their own custom avsimroads1.bmp which would be placed in the local texture folder (I hope that this is possible!).Sorry for repeating my own ideas, but, the forum is very quiet!Regards, LuisPS: I completely agree with the suggestion by Dick for the next FS !!!

Share this post


Link to post
Share on other sites
Guest C_Fumey

Hi all,I was sleeping and now is awake !there is a workaround in Groud2K; you can define your own lines/textures in the file ...RESOURCEOwnLines4.txt and use the correspondig number you have defined for your them. There is new coming version including 'lines duplication, cutting, multiple selection ..'; will be the gift for Christmas I hope.Christian

Share this post


Link to post
Share on other sites

In principle I agree with Dick and Holger that it would be a bad idea to let everybody alter the terrain.cfg file. It would just make it one big chaos.The first idea of giving each region a set of number to use, as suggested in the first post, would make too much a chaos as well I think. But I must say that the last idea of Luis of making one extended terrain.cfg file sounds like a good idea to me. If we as community could make one extended list for designers to use, I think it could help a lot of people.


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

>there is a workaround in Groud2K; you can define your own>lines/textures in the file ...RESOURCEOwnLines4.txt and use>the correspondig number you have defined for your them. But how does it end up in the actual BGL file? Do you read the texture for the file and just write the name in the BGL? Luis wanted to use the offset option of the terrain.cfg file as well, I guess that is no option with this approach.


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
Guest Horst

Hello,I would undersign Dicks post here!There is really a big need from Microsoft!!Holger, you will have an impact! (Not in the mountains of Alaska and Canada, when you make a duplicate line)Because you double the points!And there is also not a chance, to reduce the points for the second line.Because you will leave the

Share this post


Link to post
Share on other sites

Hi all,"To use a double line will give you very nice effects for lines not having an offset. But only for parts, and different offset values in the terrain.cfg."Horst, can you explain that sentence to me? I don't understand what you mean by "parts" (parts of the roads?) and "different offset values" (if we don't change the terrain.cfg the offset values are fixed, no?).I wouldn't advocate giving each and every road a flatten switch. In fact, the nice thing about the duplicate line option is that it allows us to choose those roads that should receive flattens. The way I do this in G2K4 is to complete a road system with my custom textures and layers, then duplicate the project file, edit the G2K4 .LWM file to replace my custom textures with a (any) default road texture number (and change the layer number), then open that file in G2K4 and remove all roads I don't want to have flattens for.Obviously, for major projects like USARoads or American Data, one would have to make the decision on road types, i.e., provide flattens to major roads and highways only. I think the Flight1 designers are looking into that option right now.---I'm still not convinced that the second option proposed by Luis is really feasible. It's better than his original idea but the main problem remains that there is no such thing as "we, the community" (for that reason alone, using "Avsim" in the name of a texture is a big no no for me). However, I guess the best test for this is "in the field", i.e., someone with a feasible project should start and see how it goes.Cheers, Holger

Share this post


Link to post
Share on other sites

Me again,thanks for the reply, Horst. Still not entirely sure what you mean but I'll get it eventually.I just realized after re-reading this thread that my statement "... the main problem remains that there is no such thing as "we, the community" ..." sounds a bit odd. What I meant to say is that we here at the Avsim forum are just a part of the entire group of scenery designers and not everyone reads or agrees with our posts. We can try to establish standards and guidelines but whether they will be used by everyone is far from certain ;-)Cheers, Holger

Share this post


Link to post
Share on other sites
Guest C_Fumey

>But how does it end up in the actual BGL file? Do you read the >texture for the file and just write the name in the BGL? Luis wanted >to use the offset option of the terrain.cfg file as well, I guess >that is no option with this approach.Yes, I take the corresponding texture names when generating the line.Christian

Share this post


Link to post
Share on other sites
Guest Horst

Hello Holger,Sorry for my short answer yesterday, it was late.I found 4 old Screenshots showing the problem.It is not nice scenery, it was only a test!.Sorry for the quality of the screens, I hope you can see, what I am talking about.I used the default mesh, and put some lines and polygons (-9999) in.Have a look to the streamlines and the influence to the other lines.Screen1:Shows the lines with offset=flatScreen2:Streams 1024 : offset= -5(the slope textures coming)Screen3:Streams 1024 : offset= -10(the default value)Screen4:Streams: offset=flatRailroads: offset= +5So you can set you up in the terrain.cfg, different offset value for the same line(-10,-9,-8

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...