> But ... there is no visible structure in textures folder yet for regional > textures, is it ? Want a "zurich_kreis_6_neighbourhood_grass.png" as a > 30mb .dds for my next merge request ? ;-)
I think that's because we don't know yet how a reasonable structure should look like. What I'm discovering is that textures have multiple uses. I call a texture shrub_hawaii.png because I first used it for Hawaii - but next I discover that it's also a very good representation of tropical shrub in South America. So do I rename it to shrub_hawaii_south_america.png? I think that has to be solved by waiting, seeing what is committed and what order structure makes sense and then be sorted into a useful pattern. If you come up with a scheme now, unless you're very good in predicting the future it will likely not be useful. For the same reason, it doesn't make sense to associate the textures with a particular scenery in the scenery folders - right now, think of it as a growing pool of possibilities. With a few variants of landclasses in the repository, there'll be no need to commit yet more and more. I also think you're again exaggerating the problem. The Hawaii test case has shown to me that it's just marginally feasible to do this at a resolution scale of single islands, so I'm expecting that really we do this by vegetation zones rather than by city (I just wanted to see how it works focusing on a small test case, now I know the answer). > I miss some ideas and proposals from core developers here where this > should go. Materials have a structure now, but textures and aircrafts > still miss a "naming convention" and better structure (and some textures > committed the last months just filled up the clonable repository, even > they have been removed because this area is under heavy development). Just to put this into perspective: /Textures.high/Terrain/ in my devel branch has 238 MB and that includes a lot of non-GPL texture material which I have there for giving me ideas where I want to go. That's the size of two highly detailed aircraft (P-51D: 101 MB, IAR-80: 121 MB, Vostok-1: 166 MB) or 4-5 detailed ones (A320family:67MB, 767-300: 79MB, ...) As long as nobody starts restricting aircraft commits for size reasons, I don't buy any arguments that scenery texturing is a problem for simple reasons of fairness and equality. At the level of 'What if?' questions - what do we do if I put a merge request for my 2GB highly detailed monster aircraft next time? With some problems, we can start dealing once they actually arise... I know that a GIT repository always grows because it saves the commit history - so what should the consequence be? Stop working with GIT when we have larger-sized stuff to commit? Advise aircraft makers to really only commit the very final version of textures and everything? That defeats the purpose of a development branch. If we have GIT to share stuff in development, you can't come talking we shouldn't do that because of repository size. That's not a scenery specific problem but needs to be addressed by the GIT wizards - as long as I am told we're using GIT for development, I use it. You seem to be expecting really a lot of scenery textures coming in. For comparison: Number of parties I have ever seen working on halfway complete scenery textures during my whole Flightgear experience: 6 Number of parties being able to come up with fully GPL compatible scenery textures: 3 Compared to aircraft development, that's not really a lot. I don't see why the mere problem that potentially 20 people could start on regional texturing next month requires us to fix guidelines now just in case, I think that's a pretty exotic assumption. 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
