Jump to content

TheFiddler

Members
  • Content Count

    106
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by TheFiddler

  1. Hello Luis,many thanks for your reply!>Martin Wright clearly states that FSTerrain was in an>experimental stage, therefore it may not work correctly at all>times, and, of course, neither documentation nor support are>provided.Yes, I was aware of that, I did read the "yellow box" on his FS Terrain web page. And I didn't mean to criticize :-) -- he has done marvels for us all, as I very well know. I was just surprised, seeing the popularity of the tool, that I couldn't find any detailed info elsewhere (even the experts must have needed info [em]initially[/em]... :-) )>First, you will need the FS2002 version of Microsoft Resample> (dated 28 June 2002).Aha, that's one thing. I was still using the resample.exe from FS2000 SDK , because of what I had read in TerraBuilder.>I have never imported gray-scale data with this program, but>assume that resolution refers to the LOD grid, and you should>probably experiment with this in mind.Yes, I will. In the meantime I also read the grises50 documentation, and one other thing I have so far ignored is that the scenery to be created has to be aligned correctly with the LOD square borders; I have to check that, too.>Modify the values for width and height depending on the>dimensions of your source before generating inf files or>compiling.Perhaps I'll aim to manually modify the INF file until it works for my special case (which doesn't use real DEM data files to begin with), and only then let do FS Terrain the job. This way, I'll also learn a lot more about all the details, like you suggest.So I'll fiddle on, thanks again for the response.Cheers,Martin
  2. Hello,I am taking the first steps with creating FS2002 mesh (yes I'm slow :-hah ) using FS Terrain, but am running into some snags. And so far haven't been able to find anything resembling documentation for this excellent tool...Here's the scenario:I am trying to make a LOD13 mesh for a small fictitious island, from a hand-painted grey-scale BMP (so, no worries about where to get Real World data :-) ).I succeeded already in doing this for FS2000 using older scenery methods with TerraBuilder; but mesh generation for FS2002 is (still) not supported in TB. (Or?) Hence the switch to FS Terrain. (I know about grises50, but haven't yet tried it).I do the following in FS Terrain:-- Import grey-scale data. OK, works.Q: But what exactly does the "Import Resolution" in the import dialog mean?I suppose this is the distance between elevation "poles" (samples), right? The problem is I want these to be very close for my small island, which should be possible as the BMP map doesn't have an intrinsic resolution (like e.g. Real World DEM data would have). But the FSTrn dialog gives me only pre-defined values (in sec) which don't fit (resolution not high enough). What would be a good value to have anyway? I'd say 10 m or so; but how much is that in sec? -- for "Width" (longitude-distances), this depends on the geographical latitude...) -- On importing the BMP, FSTrn automatically sets "Width" and "Height" to 13 min each, which is far too big for what I intended; the island area should be ca. 3 x 5 min (this is at 60 deg N, hence the difference in latitude and longitude dimension).Q: Are "Width" and "Height" intended only to be automatically calculated, or can I change them manually to other values? (The dialog fields [em]do[/em] permit changes, but I don't understand what the consequences are.) -- Next, I click Tools / Create Terrain BGLDOS box opens and does things, but when it closes (without giving me a chance to see possible error messages), I find only these files temp.bmp temp.dem temp.inf temp.ppm temp.tmfbut not an actual BGL produced from these.(BTW, I do have all the FS2000 SDK tools in the same folder as FSTrn; TB and others say the FS2000 SDK tools are better than FS2002 SDK. Still true?)-- As a test I can manually run tmf2bgl temp.tmf xyz.bgl but then get an error message (or warning rather): temp.tmf doesn't seem to contain DEM or Class data Bounding rectangle set to the entire earth. processing: (100.00%) and end up with an xyz.bgl which is most certainly wrong, as it covers the whole Earth. I wasn't aiming for Global Domination with my island! :-eek And I don't even dare to load this BGL into FS2002...Is this tmf2bgl warning (i.e. return code not 0) perhaps the reason why FSTrn doesn't go through?Apart from detailed answers (all highly appreciated) to the above questions -- isn't there [em]anywwhere[/em] a somewhat complete tutorial or documentation for FSTerrain at all? I have hunted high and low on the net, and found a lot of very valuable info, but nothing which -- in a systematic step-by-step fashion -- puts all the bits and pieces together.Thanks in advance for all comments, tips, pointers, and advice!Cheers,Martin "Meshed Potato" E.
  3. Thanks for your reply!>Normally night textures are activated with a switch in the BGL -- >if no night textures exist, then the 'normal' texture is displayed at>night, only darker. That's why your lighted windows aren't>bright enough.Yes, that is clearly what is happening. And as far as I can make out, this switching in "normal" sceneries is handled by the LoadBitmap instruction.But what takes care of it in objects from libraries? I can find only the library BGL (with TextureList, which apparently must also list the *_LM.BMP textures), and then the actual scenery BGL using the library objects via CallLibObj statements.But I can't figure out where the "automatism" of the day/night switching is handled in these library-based cases. I am unable to locate (in the de-compiled SCASM files) any LoadBitmap instruction.Cheers,Martin
  4. Hello,Disclaimer first: :-newbie Would someone be so kind as to clarify for me some questions about FS2002 night textures for buildings, please?Here is my problem: I have a freeware scenery, which has no night textures, so I wanted to create some for the buildings. But I have BGLs and textures only, no scenery source code (except the SCASM files obtained by decompiling). (NOTE: All this is strictly for my own private education; so is the BGL de-compiling which I did. I have no intention of sabotaging the author's excellent and freely available work! And re-compiling to BGL didn't work anyway in this case.)The graphics tool I am using is PSP 7.Originally I thought that making to each day texture abcdef.bmp a night texture called abcdef_lm.bmp would take care of everything, including automatic switching between textures according to time of day.Q1: Is it possible at all to get day/night switching just by adding a *_lm.bmp texture, or does one always have to modify the BGL also?In any case it didn't work here: This scenery uses object libraries, with TextureList statements for the objects in the library , and CallLibObj in the BGL using these objects. From other sceneries which do have night textures, I gather that the TextureLists have to include entries also for the *_lm.bmp files -- apparently these are not just automatically used. Moreover, it looks as if for the buildings, no LoadBitmap instructions are used at all (though they are used for some other objects using asphalt textures, probably runways or roads).Q2: Are these observations correct? Can buildings called from object libraries, with no LoadBitmap instructions (?), still switch between day and night textures? (Well, of course they can, I can see it, but HOW?)As a kludge, I decided to go ahead anyway, give the night textures the same filename as the day textures have, and then just to manually exchange them whenever I want to see the night view.But now I have some issues with the textures themselves: Basically, they do work OK, i.e. are correctly rendered in FS2002, and look fair enough (for a first try :-) ). The strange thing is that although I made the original texture for illuminated windows very bright (almost white), they still look very dim in FS2002. I still wouldn't have thought anything of it, until I saw that a very close-by autogen building has much brighter windows. I located the texture for this (blda2lm.bmp; a replacement for the original FS2002 one, though), and the strange thing is this: Looking at the textures directly (with Martin Wright's Show), my windows have RGB values of about 200-250 (with approx. R = B = G); the true night tex.s (*_lm.bmp) have only about 80-90.However, in a screenshot made from FS2002, my windows have RGB values of only about 90-100, while those in the autogen building (true night texture) have about 120..(Measured in the same screenshot, so any bias by taking the shot and processing it is the same for both textures.)In other words, it looks as if brightness and contrast of the *lm.bmp autogen texture have actually been increased by the FS2002 night-time rendering, whereas my would-be night textures (*.bmp) have been dimmed down.Q3: Why is this? Hypotheses:Q4: Are autogen textures handled differently from non-autogen textures by the FS2002 rendering?Q5: Are textures from xyz_lm.bmp files treated differently from xyz.bmp textures -- even if both are meant to be night textures? Do LoadBitmap and CallLibObj differ in this regard?Q6: Could different stretching of the textures be a factor? (They were stretched considerably in the autogen building, but not in mine).Q7: Is there perhaps any alpha channel trickery involved which I am missing (but in DXTbmp, I don't see any alpha variation at all for both these textures -- just a uniform area the same size as the texture).I would appreciate any enlightenment very much indeed :-coolThanks in advance!Martin The Fiddler
×
×
  • Create New...