> Sorry for my impatience, but I think before one start to have tousands of > custom scenery textures in fgdata we should discuss if such limited > custom scenery changes makes sense to be in the (already heavy) fgdata > repository.
Okay, what would your answer to the following question be: 'We already have 400+ aircraft available, shouldn't we discuss if it makes any sense adding more aircraft to the already heavy fgdata repository?' The answer to the aircraft designers currently is 'Yes, keep adding, there is no restriction.' Why would scenery suddenly be a concern? I would think different if our problem were really thousands of people trying to commit their custom textures, but somehow I don't see that coming. I have been trying for years to get folks interested in texturing without any success, and if there are even 10 regional texture projects in the next years I will be surprised. So my prediction is that what will be added to scenery textures is actually less than what we can remove from FGData as obsolete weather textures, I don't see data size as a real concern here but the 'thousands of scenery textures' as a strawman argument. Also note that these are *not* custom scenery textures - they are regional textures for our default world scenery. This is not trying to by-pass a consistent world scenery, this is trying to support it. They're also not limited to a particular region - I've found that rice textures work nicely for irrigation in Hawaii for instance and European-agricultural patterns fit well my photos from the Caribbean. > I may rot in custom scenery hell for what I write down here because I > still have some kind of "world scenery" in mind ... Something I really > fear meantime is a git-exploding texture folder in fgdata because of > focus on "better" textures for small custom scenery projects. Again, regional textures are not custom scenery, they are a way to make world scenery richer. > Yes, it's just as simple as this more or less useless comparison in this > first post at the forums. The only thing that needs to be done here is > improving landcover shapefiles to get more details, later changing some > textures and materials.xml and providing a custom scenery project, > trought > whatever channel ... but when I look at this, why not being consistent > and just go for detailed photo scenery at the end ? Looks wow all the time. > (But once you will realize with photoscenery you're only flying at noon > for the rest of your flightgear scenery life ;-) I beg to disagree. I never ever found any comparison of Flightgear with a real photograph useless. I often work for 2-3 hours trying to adjust parameters to reproduce a particular cloud scene just to see if it works theoretically and we have all relevant knobs in the code, or if there is something missing that should be added. But - why should the Caribbean be a custom scenery project? Is that now the stated design goal that people working on scenery should create their custom patches? As for photo-scenery, I guess your comment is somewhat skeptical? I think it's not feasible except for small areas because of sheer data size and license, and since I tend to work on solutions working for a larger scope, I didn't look into that. > Here I will add a note to the concept of the transition shader I > introduced a longer time ago. Stupid, but the idea was to have LESS > texture files at the end to free resources. It was inspired by the idea > of > having "natural structures", giving (transitional) patterns with > different > colour schemes, following water/clima/temperature or whatever parameters. *shrugs* You're talking to the guy who introduced a dust-cover into the shader to make dry desert areas more realistic in the current scheme. I don't think it's an either - or question, there are some things one can do better with a shader effect, and some which one can't. Shader code saves space on the harddisk, but takes a lot of framerate runtime - I'm guessing most people these days see framerate limits before harddisk limits, so it's easier to use a new texture for a complicated pattern than to create it in a shader. But simple patterns are rather limited - vertex altitude is about the only thing which you can use to introduce transition patterns, the rest you'd have to do with noise textures and such like. > But personally I vote against having a big bunch of rural textures in a > "wow"-fgdata for the moment. I would really like that new overall > shader/texture concepts are tested and discussed well and gives proposals > and roadmaps to all the scenery projects, eating less resources when > possible. Otherwise I guess we will end up with a heavy archive of > temporary custom scenery approaches. Again, the whole point of regional texturing is to make some regions of the world look more realistic without creating a private custom scenery project. I also don't understand why this should be seen as temporary? Scenery generation doesn't do that job, so even in a new world scenery, the question arises how to paint landclasses. Okay, admittedly I see your concerns largely as a red herring. If all envisioned regional texture projects actually take place, we're actually talking about adding less than 20 MB to FGData after I recently flagged 40 MB which can be removed and have identified another 15 MB that can go as well. You're throwing out the danger of fragmenting into custom sceneries again, but regional texturing is independent of scenery creation - it'd work with world scenery, with hires scenery and with custom scenery - these are simply different questions. If anything, it makes using world scenery more attractive and lessens the need to start private custom sceneries. You're mixing two things which are actually largely separate. Shader coding does not require any additional action on the scenery generation side, and neither does texturing. In general, you can't have a more faithful and more detailed scenery eating less resources. To ask for that as a design goal isn't reasonable. You pay either with disk space or with framerate or both. If you want to talk about shader and texturing concepts, then please start talking - I'd be interested in hearing your ideas. I've certainy thought about doing shader things to vegetation (autumn coloring for instance I tried) but I found that the color-postprocessing is quite non-trivial to get right, and in general my impression is that in order to generate a shape in the shader, you need a texture, so you might as well start with the texture. So, how do you want to do it? Or do you think the current visuals are really competitive and we don't need to do better? Cheers, * Thorsten ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
