Jump to content
Sign in to follow this  
rhumbaflappy

Default VTP textures and other questions

Recommended Posts

Guest

Hello, everybody.After a nice detailed mesh scenery for Andaluc

Share this post


Link to post
Share on other sites

Hi Juan.I don't believe anyone has replaced landclass with VTP1 ( or VTP2 ) polys. But you are right, in that will most probably be the next step in TDF design.VTP2 is handled exactly like landclass in that the texture 'tiles' to the LOD13 Areas, and are located with the LOD8 Cell dimensions.VTP1's are cutouts of textures 'stamped' within the LOD13 Area. VTP2 polys can be as large as the LOD8 Cell size. VTP1 polys are restricted to the LOD13 Area.If you are considering using polyshapes for the towns and cities, laid over the landclass, then we are thinking very much alike. The VTP2 poly could be drawn to the shape desired, a default city texture indexed, and the seasons and autogen would be added automatically.The drawback is that there is no blending, like the landclass... so you would have to trim the edges of the city polys to blend to the landclass. I've looked at the way cities blend to the fields and woods, and the landclass does a very nice job, so studying their patterns of blending would be a good exercise, I think.If you are thinking of accurate placement of city streets, then you would want a background poly that is, perhaps grass, or fields, then the streets on top, then building objects ( and perhaps trees ) placed. Quite a bit of work for an area larger than a small city, and the framerates will be hit by the objects. In my smalltown, in Wisconsin, there are perhaps 20,000 trees, and 3000 buildings. In my case, an accurate portrayal of the city would probably be CUSTOM texture, with seasons, and autogen ( to place trees and buildings ). A landclass with transparency can be used to place the textures... and the textures could be derived from default textures, to assist blending, using aerial photos for a reference... many things can be done with a paint program, and layering. The use of autogen would greatly help with the framerates, and I'm only needing 24 custom textures ( 4 tiles * 6, for the seasons and night ).Dick

Share this post


Link to post
Share on other sites
Guest

I'll have to keep on thinking about it. Any approach that I take must be subject to automation, since I'm building scenery that covers a very large area.Just curious here, but have you or anyone per chance produced a bgl showcasing all the possible landclasses and how they blend together? When the time comes for me to choose the appropriate ones, I guess a good look at it will be better than the description in the documentation.Since you didn't mention it, should I understand nobody has produced free replacements and/or additions for VTP roads and railroad textures? I'm a programmer and my skills at anything artistic leave much to be desired :-)Cheers,Juan.

Share this post


Link to post
Share on other sites

Hi Juan.To make things even more difficult, landclass is affected by region, elevation, and ground-slope.Part of the problem with VTP2 line textures is the default resolution of 4.8 meters..I don't believe the display of the texture can be altered away from this. That makes rails, and centerlines impossible for these lines.Dick

Share this post


Link to post
Share on other sites
Guest

Humm... I've been looking a bit more into it. I'm not sure I understand what you mean about the resolution issue.I wouldn't want to try to use a VTP2 line to draw the centerline of a RWY, but for the roads themselves, which I don't mind at all if they are a couple of meters off. Perhaps you were talking about the texture resolution, which for the default textures is 4 meters/pixel. If a new texture is created with size set to 1, which is still not good at all to draw the details of a railroad, the problem now is that the maximum road/railroad width is 64 meters, which is more than good enough for a railroad, but not necesserely for a wide highway. And a 1m pixes is still too big to paint the road centerlines. Maybe I'm asking for too much?I had thought that the line width served to stretch or compress the textures, but I reckon now that it actually defines a "window" through which you see the underlying texture. I guess I should start testing and get over with it.Humm... I think I'm going to search for 1m resolution aereal photographs, and have a look at what the roads look like.Cheers,Juan.

Share this post


Link to post
Share on other sites
Guest

OK, I've done my testing. Here are my findings:1.- PointWidth actually scales the texture.2.- The width that shows max detail for the textures, and hence gives a scale of 4 meters per pixel is 255 (thus getting a road 4 times the size of real life ones)3.- FS hanged on me when I set the texture to 1m/pixel in TextureType, and using a 2m/pixel had the expected effect of reducing the size of the road, _whithout getting additional resolution_. See below.4.- FS stretches the textures longitudinally. I.e., there seems to be a constant number of texture pixels between line points, so that if you place two points very far apart the texture becomes distorted. This seems to be the reason that roads and other VTP textures are so featureless. When using a less uniform texture, dirtroadsu.bmp, the distortion was more obvious.5.- Even when terraintextures.cfg says that the texture will just be dirtroadsu.bmp, FS adds a whiteish "layer" on top. I had to copy it under a different name to see the plain dirtroadsu.bmpAnd then, what I found most important of all to me, although I guess it might already be obvious to many of you: no terrain texture can ever be displayed with a higher resolution than 4m/pixel.I've realized that FS renders areas with all landclass, LWM and VTP information in CPU to a resolution of 4m/pixel (at maximum terrain detail setting), and the resulting image is what gets passed to Direct3D to be represented.This explains many things:a) Why using photographic textures doesn't have an impact in FPS. The fact is that by using a photographic texture FS saves all the time it needs to render the areas using all the different elements.:( Once an area has been rendered, it doesn't matter how complicated the LWM or VTP polygons were... The terrain texture has already been generated and the accelerated portion treats it as a plain flat texture.As a consequence if you don't move too fast, very complex terrains don't eat up FPS, only when moving and other areas need to be rerendered in additional detail.c) I now understand why the "Multiple textures" tick box is called so in the hardware display settings. Water, land, landclass and VTP polygons are not different textures, but are combined into one. Additional texture detail and water effects _are_ additional higher resolution textures superimposed on the terrain one.As a consequence, there is no chance to get higher resolution roads. Even the default VTP road textures have resolution that is wasted (save for aliasing during processing). Pity. I guess I'll still try to represent railroads, even if they don't look like much more than black lines.But that will be tomorrow. Time for me to go to bed. I hope that my rant is of use to somebody at all. :-/Cheers,Juan.

Share this post


Link to post
Share on other sites

Hi Juan.Yes, the '4.8' meters resolution I refered to was the "wall". All TDF/TMF textures are displayed at that resolution... roads, photoreal, landclass, VTP, LWm, are all the same.Roads might just as well be a pure grey line, rails... Shorelines have exaggerated size and colr to overcome this, and so their 'cartoonish' quality.I believe FS2000-style roads may still work, and will have more detailed texture, but at a large framerate loss, and don't cling to the mesh.Dick

Share this post


Link to post
Share on other sites
Guest christian

Hi Juan>:( Once an area has been rendered, it doesn't matter how >complicated the LWM or VTP polygons were... The terrain >texture has already been generated and the accelerated >portion treats it as a plain flat texture. >>As a consequence if you don't move too fast, very complex >terrains don't eat up FPS, only when moving and other areas >need to be rerendered in additional detail. >>c) I now understand why the "Multiple textures" tick box is >called so in the hardware display settings. Water, land, >landclass and VTP polygons are not different textures, but >are combined into one. Additional texture detail and water >effects _are_ additional higher resolution textures >superimposed on the terrain one. >>As a consequence, there is no chance to get higher >resolution roads. Even the default VTP road textures have >resolution that is wasted (save for aliasing during >processing). Pity. I guess I'll still try to represent >railroads, even if they don't look like much more than black >lines. yes, I'm quite certain M$ is using the stencil buffer to combine the textures, which would make a lot of sense...Cheers, Christian

Share this post


Link to post
Share on other sites
Guest christian

Hi Juan>On a similar subject, has anybody succeeded on putting in >powerlines in any way? From what I know there wouldn't be >no easy and satisfactory way, but it doesn't hurt asking, >does it? :-) Not powerlines, but power pylons, generic factories, antennas, etc. I wrote an ArcGIS plugin, should be easy to do for MapInfo also...Cheers, Christian

Share this post


Link to post
Share on other sites
Guest

Hi, everyone.I'm slowly chugging along, and I've got roads now. I'm running into a couple of problems, I'm afraid.The most annoying one is that spanning several LOD8 cells. It all works fine if I create several bgl files with only one VTPIndexEntry each, but not several in the same file.I'm terribly sorry I'm not at home at the moment, so I can't provide a code example (I thought I had left a sample ready yesterday night, but it seems I overwrote it at some point). The general structure that I'm using isBGLHeader 38, 36,-4,-7, TerrainHeaderStart, VTPHeaderVTPHeader label word VTPFileHeader 256, VTPIndexStart, TextureStart, VTPEndVTPStart label word; Cell_371_149's Area data 0,0 datamark_0 label word VTPDataArea 1, 1, 0, 0 VTPLayer 32, 1 VTPNumTexturesInLayer 1,0 VTPTextureId 0,0 VTPPolyCount 3,0 VTPPolyMethod2 9,1,0 VTPWidePoint 11333, 1, 11835, 0........ datamark_1 label word; ------------------------------------------------------------------------------; Cell_372_149's Area data 0,0 datamark_1 label word VTPDataArea 1, 1, 0, 0 VTPLayer 32, 1 VTPNumTexturesInLayer 1,0 VTPTextureId 0,0 VTPPolyCount 33,0 VTPPolyMethod2 6,1,0 VTPWidePoint 4001, 1, 12269, 0 VTPWidePointWidth 63 VTPWidePoint 4002, 0, 12270, 0................ VTPWidePoint 3924, 0, 4392, 0 datamark_9 label word; ------------------------------------------------------------------------------Cell_371_149 EQU VTPCellID 0,371,149Cell_372_149 EQU VTPCellID 0,372,149Cell_373_149 EQU VTPCellID 0,373,149Cell_371_150 EQU VTPCellID 0,371,150......; ------------------------------------------------------------------------------ VTPIndexStart label word VTPIndexHeader 9, VTPIndexData, VTPStart VTPIndexData label word VTPIndexEntry Cell_371_149, VTPStart, datamark_0, datamark_1 VTPIndexEntry Cell_372_149, VTPStart, datamark_1, datamark_2 VTPIndexEntry Cell_372_150, VTPStart, datamark_4, datamark_5 VTPIndexEntry Cell_373_150, VTPStart, datamark_5, datamark_6 VTPIndexEntry Cell_371_151, VTPStart, datamark_6, datamark_7 VTPIndexEntry Cell_372_151, VTPStart, datamark_7, datamark_8 VTPIndexEntry Cell_373_151, VTPStart, datamark_8, datamark_9;--------------------------------------------------------------------TextureStart label word VTPTextureListHeader 1, TextureIndexStart, TextureDataStart, TextureDataEndTextureIndexStart label word VTPTextureListEntry TextureDataStart, texturemark_0, texturemark_1TextureDataStart label word texturemark_0 label word VTPTextureName "1163" VTPTextureType 2, 0, 0, 4 texturemark_1 label wordTextureDataEnd label word; ------------------------------------------------------------------------------VTPEnd label word; ------------------------------------------------------------------------------As I say, it works fine when I stick to a single cell, even when I have to use several times the same texture because there are so many lines, and using VTPPolyMethod2Ex as well. I've checked polygon and point counts, and it doesn't seem to be the problem.It seem to work when doing columns or rows only (at least with the tests I've done). I've checked cell ordering, and transposing doesn't help. And though in this example the cells themselves don't look "square" (373_149, and 371_150 are "missing"), some others I've tried did look square and still failed.I know I should try to get the smallest possible non working example for you to try yourselves, but I'm unable at the moment and maybe there is something obviously wrong in what I'm doing.---------------The second problem is minor, but still annoying. As you can see from above the VTPLayer's are set to exclude previous data, but it doesn't seem to be working too well. It looks as if instead of deleting any previous layer information in the whole LOD8 cell, it only did it in the LOD13 areas of the cell for which I am providing information. Again I'm afraid I can't provide a screenshot right now, hopefully at lunch time, but perhaps this is known and expected behaviour and I failed to read about it somewhere?It could also be because what I'm seeing is in the layer 31, rather than 32. I doubt it, though, since they are isolated bits that used to belong to main roads.-----------------And to finnish up, a bit of information that I hope is useful for other people. As we know, VTPLines are wormlike, and need to build up their intended width. Elsewhere I've seen examples of setting the initial point twice in order to make this happen, but when I tried in massive scale this wasn't really working.After trying different approaches, I've found one that works very very well, except for LOD8 boundaries. What I do is use two additional points at each end, displaced to build up "momentum" for the line. The following example only had two points in the source data. They are the third and fourth points. Notice that the other ones don't have the same coordinates. Rather, I note the direction of the line and use points displaced 1 and 2 pixels outwards. As I say, this works wonders where simply repeating the points didn't work. There are no visible signs of tapering at all, and different lines that are supposed to have points in common do blend in. I'll post screenshots later. VTPPolyMethod2 6,1,0 VTPWidePoint 5950, 1, 5070, 0 VTPWidePointWidth 63 VTPWidePoint 5951, 0, 5069, 0 VTPWidePoint 5952, 0, 5068, 0 VTPWidePoint 5956, 0, 5022, 0 VTPWidePoint 5957, 0, 5021, 0 VTPWidePoint 5958, 0, 5020, 0-----------Christian, thanks for your suggestion on power pylons. Unfortunately my data doesn't give information on where the poles themselves should be, only the track of the power line. Humm... I may leave it as an "extra credit" project if my girlfriend hasn't dumped me by the time I'm done with what I consider good enough for an initial release :-D-------------------Now that I'm rereading my post I'm wondering why lines don't actually match at LOD8 boundaries. I'll have to do some research with Landcalc3 and see what the coordinates for the points at the boundaries are, and whether they are actually the same to the ones set in the asm file.Cheers,Juan.

Share this post


Link to post
Share on other sites
Guest

Hold fire! I don't know what I was doing wrong yesterday night, but it's worked fine now! A 16Mbyte asm compiled fine to a 1.5Mbyte bgl spanning 76 cells... :-)There goes a screenshot. First one is to show off :-). The other is to show the problem with the limited exclusion. Only the main road to the left is mine. The other two to the right are left overs from the default. Notice how the one closer is clipped. That is a LOD13 area boundary.The next step now is to class the roads into their appropriate category. Right now all roads look like highways. It still looks nice, though. :-)Cheers,Juan.

Share this post


Link to post
Share on other sites

Hi Juan.I'd like to direct you to this long thread on roadlines. It should answer a few questions you've been having.In paticular, the posts by 'falko' and 'fumey' are of interest.The last entries, of the following post, describe a discovery by Christian Fumey regarding the exclusion of VTP layers, and the conclusions we made.Roadline discussion------------------------The wormlike characteristics of the roadlines may be defeated by starting the road with a point whose width is 1, then repeating the same point as a width of 63 ( or whatever width you desire ). The same can be done with the final point of the line... first declaring a width of 63, then repeating the point as a width of 0.Dick

Share this post


Link to post
Share on other sites
Guest

Thank you for pointing out this thread to me. I'm sorry I asked something for which there was already an answer elsewhere. Actually I had already read that thread (I spent quite some time reading before getting to code at all), but that was several days ago before I really grasped the details, and what I recalled was that the replacement was for LOD8 cells and not LOD13 areas. So much for my memory. :-)I

Share this post


Link to post
Share on other sites

Hi Juan.The exclude Macro was pretty simple... you should be able to see the logic:; VTPLayerExcludes.inc BGLC includes for Terrain Data File Exclusions; --------------------------------------------------------------------------------; --------------------------------------------------------------------------------VTPAreaExclude Macro Layer, U, V WORD ( V * 800h ) + ( U * 40h ) + 1 BYTE 80h + Layer BYTE 0EndM; --------------------------------------------------------------------------------VTPCellRowExclude Macro Layer, V VTPAreaExclude Layer, 0, V VTPAreaExclude Layer, 1, V VTPAreaExclude Layer, 2, V VTPAreaExclude Layer, 3, V VTPAreaExclude Layer, 4, V VTPAreaExclude Layer, 5, V VTPAreaExclude Layer, 6, V VTPAreaExclude Layer, 7, V VTPAreaExclude Layer, 8, V VTPAreaExclude Layer, 9, V VTPAreaExclude Layer, 10, V VTPAreaExclude Layer, 11, V VTPAreaExclude Layer, 12, V VTPAreaExclude Layer, 13, V VTPAreaExclude Layer, 14, V VTPAreaExclude Layer, 15, V VTPAreaExclude Layer, 16, V VTPAreaExclude Layer, 17, V VTPAreaExclude Layer, 19, V VTPAreaExclude Layer, 19, V VTPAreaExclude Layer, 20, V VTPAreaExclude Layer, 21, V VTPAreaExclude Layer, 22, V VTPAreaExclude Layer, 23, V VTPAreaExclude Layer, 24, V VTPAreaExclude Layer, 25, V VTPAreaExclude Layer, 26, V VTPAreaExclude Layer, 27, V VTPAreaExclude Layer, 28, V VTPAreaExclude Layer, 29, V VTPAreaExclude Layer, 30, V VTPAreaExclude Layer, 31, VEndM; -----------------------------------------------------------; -----------------------------------------------------------VTPCellExclude Macro Layer VTPCellRowExclude Layer, 0 VTPCellRowExclude Layer, 1 VTPCellRowExclude Layer, 2 VTPCellRowExclude Layer, 3 VTPCellRowExclude Layer, 4 VTPCellRowExclude Layer, 5 VTPCellRowExclude Layer, 6 VTPCellRowExclude Layer, 7 VTPCellRowExclude Layer, 8 VTPCellRowExclude Layer, 9 VTPCellRowExclude Layer, 10 VTPCellRowExclude Layer, 11 VTPCellRowExclude Layer, 12 VTPCellRowExclude Layer, 13 VTPCellRowExclude Layer, 14 VTPCellRowExclude Layer, 15 VTPCellRowExclude Layer, 16 VTPCellRowExclude Layer, 17 VTPCellRowExclude Layer, 18 VTPCellRowExclude Layer, 19 VTPCellRowExclude Layer, 20 VTPCellRowExclude Layer, 21 VTPCellRowExclude Layer, 22 VTPCellRowExclude Layer, 23 VTPCellRowExclude Layer, 24 VTPCellRowExclude Layer, 25 VTPCellRowExclude Layer, 26 VTPCellRowExclude Layer, 27 VTPCellRowExclude Layer, 28 VTPCellRowExclude Layer, 29 VTPCellRowExclude Layer, 30 VTPCellRowExclude Layer, 31EndM; -------------------------------------------------------------------[/font]I'm attaching it as a text file, as well.Dick

Share this post


Link to post
Share on other sites
Guest

As usual, thank you very much, Dick. :-)The excludes worked very well. I then took some time tweaking which road textures might look better for the different classes in my data, a bit more tweaking with the widths and done I was.Well... Not completely, though. In the first run I simply ignored lines that went over the 31+127 point limit. It mostly looks fine, but I was checking today some particularly winding roads up the mountains and those are mostly gone :-(. It's a bit surprising that a whole UINT16 is limited to a range of 0-127. Has anybody tried pushing this limit, or does it crash for sure? I'll test it myself this evening, but maybe somebody has tested it before?I case anybody wants to have a look at the results, you can find it in http://lazaro.ddts.net/fssdk/roads.zip. Some starting points might be LEZL, LEMG, LEGR or LEAM.Out of curiousity, here. Are there many other projects taking large quantities of geo data and passing them to LWM and VTP format?Regards,Juan.

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