Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
At least one of us is confused about how things are structured. Heh. I mean if You add some model with great sphere in it, without addition things, all who have that model installed will see part of giant sphere in the sky or whole sphere. I have no idea what you mean by the distinction of Nasal being on a local level and the core on a global level. If you look into /Nasal/, you find scripts like multiplayer.nas, tanker.nas or redout.nas which are available whatever aircraft you have installed or whatever aircraft you are in - just as the core, they are part of every Flightgear session. I mean that because if You will add that sphere on Nasal level only then main terrain engine would continue to work and would produce great lags on most of computers. And because there's need to do something with that on C level then it's easier to make whole engine on it. Even if it's simple textured sphere, it's gotta be on terrain engine level anyway, that's why I call it so. If that would happen, it would be very nice. It also would be nice if people would send me their GPL-compatible photographs of Cb clouds so that I could improve my thunderstorm textures which are rather lousy at the moment. It would also be nice if people would pool their resources to create a nice GPL-compatible database of aerial images so that we'd have raw material for texturing. I had seen some photos of that type on CC license only, and they allows to use in some CC project only one texture from that site, and with additional restrictions. I suppose it's easier to make own photos. Dunno why. Maybe because there's a lot of selfish guys in outer world. All that doesn't just seem to happen... so I have to make do with what happens. It's a bit up to you - if you can get off a demo of a nice Earth view from space using existing technology, the likelihood of getting more people interested in working on the issue increases. If you wait for the best solution to be implemented up front, you may be lucky, but it also may be a long wait. Honestly, I do not know if number of interested people would increase. Anyway, I do not ask, only tell what's needed. It's not please do that or I order You to do that thing. If simple if...then stating of fact. In case there is no one who even could or want to tell where start to look about how to switch current engine off, in month after first question in devel list, then it's unreasonable to make such personal attempts. It will not be helped on case of need, and may get some resistance instead. Too risky. And it needed only in Vostok, X-15, and other projects of that type really. I suppose there's about ten of people who even started Vostok and approximately so who get high enough on X-15. Only we two of that guys have interest to even talk about how to make it better now. It's too few to make serious work in that means reasonable. So I put that aside for a while. Better to make something else what could become a bit more popular and make FG bit more popular. So for now I already focused my mind on another project. Maybe in time I will look into that terrain engines stuff personally, maybe not. For now surely not. Cheers, * Thorsten Cheers, * Victor -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
If two users in parallel flying spacecrafts will see the same good then there is no problem. But everything on Nasal is on local level, not global core level. At least one of us is confused about how things are structured. My understanding is that there's nothing in Flightgear which guarantees that two users flying parallel get to see the same. My understanding of the multiplayer protocol is that it largely exchanges position information of models and submodels, in addition to model and livery path. If we're flying over Seattle, and you have the default scenery and I the Pacific Northwest custom scenery, I will see different terrain than you do. If I don't have your aircraft model installed, then I will see a placeholder (I think a funny-coloured glider) at your position. If I'm running live weather and you have 'Fair Weather' selected, I might have few hundred meters visibility and rain whereas you fly next to me in bright sunshine. Similarly, I don't see how you could guarantee that two spacecraft users see the same, unless they have the same models/textures/scripts for rendering Earth from high altitude installed. I have no idea what you mean by the distinction of Nasal being on a local level and the core on a global level. If you look into /Nasal/, you find scripts like multiplayer.nas, tanker.nas or redout.nas which are available whatever aircraft you have installed or whatever aircraft you are in - just as the core, they are part of every Flightgear session. But, see above, neither core nor scripts are ever global in the sense that they'd be the same for every user - if you run GIT and I run 2.0.0, the core is obviously not the same. Scenery models usually exist on the whole FG level... Earth is not scenery. Well, that's precisely my point, isn't it? You don't need a new terrain engine if you stop thinking about planets from high above as 'terrain'. From a Celestia perspective, Earth is just a sphere with a very high resolution texture and reflection and normalmap shaders. That's something Flightgear has the functionality to render without much ado or additional coding - as a scenery model. So if, for spaceflight, you write a /Nasal/earthview.nas which periodically checks altitude and loads a large enough scenery model above 40 km while it de-activates the default terrain, you have solved the problem of implementing Celestia-like views of Earth in Flightgear. So if choice is between redoing things what's already done and including that things I would prefer including. There is four or five Open Source space simulators and most of them is not so addable for modder or even usable for end user. If them authors could put their efforts together then we could have best space sim already. If that would happen, it would be very nice. It also would be nice if people would send me their GPL-compatible photographs of Cb clouds so that I could improve my thunderstorm textures which are rather lousy at the moment. It would also be nice if people would pool their resources to create a nice GPL-compatible database of aerial images so that we'd have raw material for texturing. All that doesn't just seem to happen... so I have to make do with what happens. It's a bit up to you - if you can get off a demo of a nice Earth view from space using existing technology, the likelihood of getting more people interested in working on the issue increases. If you wait for the best solution to be implemented up front, you may be lucky, but it also may be a long wait. Cheers, * Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
It would be nice to get fgfred64's project finally into, as the current terrain seems outdated to me http://www.youtube.com/watch?v=fkzsD95K_Jk --- On Wed, 6/1/11, Slavutinsky Victor vitos...@mail.ru wrote: From: Slavutinsky Victor vitos...@mail.ru Subject: Re: [Flightgear-devel] High altitute/speed flights terrain engine problems To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Wednesday, June 1, 2011, 2:29 PM As I indicated in the Forum http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 a solution to the problem would be to represent Earth from high altitude by pieces of a hires textured sphere (textures to be obtained from Celestia), with (at least as demo) a simple Nasal script controlling which pieces of the sphere are currently to be loaded. As I said previously, it's gotta be implemented not on model level but on whole FG level, or not implemented at all. Think You have more productive computer while I have midproductive. We must orientate on users with midproductive or even less powerful computers. Current FG terrain engine can not be used on high altitude/speeds on current midlevel computers and gotta be switched off anyway. I did some experiments with a textured sphere and found that I can't simply place an Earth-sized sphere at the coordinate origin - the model is apparently deemed to be too far away and isn't shown. Maybe there is a simple way to switch this off - but if not, a viable solution would be to use a nearer (co-moving) sphere bit which is kept in the precise proportion to the real thing as given by simple ray optics. Using this trick, I have managed to get a plausible ufo-above-Earth view within 35 minutes work with a simple lowres (4096x4096) textured Earth. Well, I suppose there is possible solution, as rising LOD of whole model and LOD of Earth in model xml file. animation typerange/type min-m0/min-m max-m100/max-m /animation But what will You do in multiplayer? I believe all this is doable without significant modifications to the core. It may not be an elegant solution, but it can be picked up by anyone who is able to code a bit Nasal and can texture a model. Admittedly there are much more elegant solutions, and solutions which generalize to flights in the whole solar system, but I don't really see us getting started on that. Again, in multiplayer You'll cover sky of other users with giant sphere or will look as craft with big sphere aside for others. It's not only not elegant, it's not solved problem really. Of course it possible to make mutiplayer model without that sphere and so on, but normal things gotta be common. Otherwise it makes problems what can not be solved. Cheers, * Thorsten Cheers, * Victor -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
It would be nice to get fgfred64's project finally into, as the current terrain seems outdated to me http://www.youtube.com/watch?v=fkzsD95K_Jk He do not answer on my message on YouTube, his email what mike4lin had gave me on forum is outdated, his folder on fotolia.com is closed. If someone have more modern contact information then please let me know. Everything gotta be made in time. There is things what can not be delayed because we are alive people. -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
As I said previously, it's gotta be implemented not on model level but on whole FG level, or not implemented at all. Nobody is talking about implementing anything on *aircraft* model level - the idea is to represent *Earth* by a model the same way we can represent, say, clouds by a model. Scenery models usually exist on the whole FG level... Well, Stuart got it right: The perfect is the enemy of the good. - Voltaire If the choice is between an existing imperfect implementation and a theoretical perfect implementation, I'd go with the first any time. :-) Cheers, * Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
Nobody is talking about implementing anything on *aircraft* model level - the idea is to represent *Earth* by a model the same way we can represent, say, clouds by a model. If two users in parallel flying spacecrafts will see the same good then there is no problem. But everything on Nasal is on local level, not global core level. Scenery models usually exist on the whole FG level... Earth is not scenery. Well, Stuart got it right: The perfect is the enemy of the good. - Voltaire If the choice is between an existing imperfect implementation and a theoretical perfect implementation, I'd go with the first any time. :-) At first, until current engine can not be stopped there is no choice at all. Secondly, that Frederic's engine is existed already while textured globe engine what You are mean not yet. But it's unknown can it be included or not, same as already existed osgEarth textured globe engine BTW. I understand what You have some vision of way to solve problem. It's good solution, at least for You, because it will lead You to some personal improvement by Your own, which means not so expensive for You, way. But what's I really do not like in current Open Source what's people constantly solving same problems again and again without real results while other unfinished solutions is existed and solving problems by half solutions what become to need of complete rewriting faster then it could become really nice to end user. So if choice is between redoing things what's already done and including that things I would prefer including. There is four or five Open Source space simulators and most of them is not so addable for modder or even usable for end user. If them authors could put their efforts together then we could have best space sim already. Honestly, I appreciate Your solution, but only in case if it's impossible to include already existed other one. Cheers, * Thorsten Cheers, * Victor -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
Current terrain engine makes flights on high altitudes or long flights on high speeds unreasonable. There is no Earth surface visible, only blue fog, but lags very big, fps may drop to one per second or less, simulation may crash on attempt to switch to other window and so on, because it still loads some terrain even if it is invisible to pilot and that terrain is unreasonably exact. For the record, I'm not experiencing any of these problems when the visibility is ~ 100 km - the terrain is simply gone. But I think it would be nice to have an option to switch off the default terrain, to replace it by something else. As I indicated in the Forum http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 a solution to the problem would be to represent Earth from high altitude by pieces of a hires textured sphere (textures to be obtained from Celestia), with (at least as demo) a simple Nasal script controlling which pieces of the sphere are currently to be loaded. I did some experiments with a textured sphere and found that I can't simply place an Earth-sized sphere at the coordinate origin - the model is apparently deemed to be too far away and isn't shown. Maybe there is a simple way to switch this off - but if not, a viable solution would be to use a nearer (co-moving) sphere bit which is kept in the precise proportion to the real thing as given by simple ray optics. Using this trick, I have managed to get a plausible ufo-above-Earth view within 35 minutes work with a simple lowres (4096x4096) textured Earth. I believe all this is doable without significant modifications to the core. It may not be an elegant solution, but it can be picked up by anyone who is able to code a bit Nasal and can texture a model. Admittedly there are much more elegant solutions, and solutions which generalize to flights in the whole solar system, but I don't really see us getting started on that. Cheers, * Thorsten -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitute/speed flights terrain engine problems
As I indicated in the Forum http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 a solution to the problem would be to represent Earth from high altitude by pieces of a hires textured sphere (textures to be obtained from Celestia), with (at least as demo) a simple Nasal script controlling which pieces of the sphere are currently to be loaded. As I said previously, it's gotta be implemented not on model level but on whole FG level, or not implemented at all. Think You have more productive computer while I have midproductive. We must orientate on users with midproductive or even less powerful computers. Current FG terrain engine can not be used on high altitude/speeds on current midlevel computers and gotta be switched off anyway. I did some experiments with a textured sphere and found that I can't simply place an Earth-sized sphere at the coordinate origin - the model is apparently deemed to be too far away and isn't shown. Maybe there is a simple way to switch this off - but if not, a viable solution would be to use a nearer (co-moving) sphere bit which is kept in the precise proportion to the real thing as given by simple ray optics. Using this trick, I have managed to get a plausible ufo-above-Earth view within 35 minutes work with a simple lowres (4096x4096) textured Earth. Well, I suppose there is possible solution, as rising LOD of whole model and LOD of Earth in model xml file. animation typerange/type min-m0/min-m max-m100/max-m /animation But what will You do in multiplayer? I believe all this is doable without significant modifications to the core. It may not be an elegant solution, but it can be picked up by anyone who is able to code a bit Nasal and can texture a model. Admittedly there are much more elegant solutions, and solutions which generalize to flights in the whole solar system, but I don't really see us getting started on that. Again, in multiplayer You'll cover sky of other users with giant sphere or will look as craft with big sphere aside for others. It's not only not elegant, it's not solved problem really. Of course it possible to make mutiplayer model without that sphere and so on, but normal things gotta be common. Otherwise it makes problems what can not be solved. Cheers, * Thorsten Cheers, * Victor -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
