Christian Stock wrote: > > Hi, > > Let me introduce myself, before I start with what I'm interested at.
Hi! > My main goal is to convert the commercial 1:25000 topographical data for > New Zealand, I'm sitting on into a flight simulator and to get some decent > scenery + good framerates. Oh, I'd love to use such a detailed NZ scenery! > My next task will be to look into our own renderer which is > based on OpenGL Performer. So, I would think that I can do quite similar > tasks, I work for my 'real research work' and reuse some stuff for FG. > However, the performer libraries are commercial, so I suspect that there is > some more low level OpenGL demand here. We are using PLIB (http://plib.sf.net/) that offers some features that are very simmilar to performer. Steve Baker, the guy who wrote the initial version is very familiar with Performer and wanted something simmilar for his OpenSource projects... > I'm actually quite looking forward > to play around with opengl, and maybe we can bring the scenery engine up to > a standard that surpasses FS2K2, eg using bump-mapping on buildings / > cockpits. Great! > Finally, a good point to start would maybe be a bgl importer for FG, I have > seen a webpage on that already, with my bgl knowledge it shouldn't be hard > to get some decent advances in that field. As we use SSG of PLIB as our scene graph we'd need a bgl loader for PLIB. There's already a loader for MSFS planes so you could start with modifying it. But for the scenery we are using a different approach than Microsoft. We want to be able to generate the whole world automatically. This allows us to offer every part of the world and doesn't limit us to the places where people put all their work into it. But that doesn't mean that we can hand tweak it (e.g. placing special object). So IMHO it would be best to write a tool that understands your NZ data and converts it, together with all the other data of the world, into our native scenery format. As others wrote http://www.terragear.org/ is the place to look for that. > start. How is the LOD of the elevation mesh handled? We don't have LOD yet, as there are some big difficulties. Steve Baker (he writes comercial flight simulators for a living) wrote a detailed mail about it once. I hope you can help us there. > The squares I have seen in the screenshots look > quite nasty, I think FS2K2 uses some bitmap strips as a mask to make this > more realistic looking. These squares are only an artefact of the data we are using. The landcover data is pixel orientated (i.e. no vectors) and thus we can only get squares out of it. But you are right: it looks ugly and takes away the advantage we've got with the irregular mesh. Perhaps we should add an antialiasing algorithm there. > Also, are seasons implemented? No. But I think it shouldn't be too hard. > The bitmaps could also look better, but I know someone > who made a complete replacement set of the FS2K2 textures as freeware, they > look really good and I think I can maybe organise something there :). Please! We really need good textures! > And > finally, the new 'autogen' feature of FS2K2 is one of the features I really > like. Having autogenerated 3D objects depending on land use textures is > just great (looks good and gives you more of a feel of 'beeing there'). I > can also have a look into how this works in detail. That would also go into Terragear and would be deeply appreciated. > Is > there maybe a state of the art document for the terrain part, or will I > have to just have a look at the source code and make some sense out of it? The best would be to look into the TerraGear code I guess. The loader on the FGFS side will probably also help. CU, Christian -- The idea is to die young as late as possible. -- Ashley Montague _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
