But could you use the second GPU for rendering the co-pilot’s view in future version of X-plane 10 (without METAL or Vulcan) or X-Plane 11 (with METAL or Vulcan)?

I’d be willing to offer two bottles for an updated ac3d plugin. I use blender only occasionally but I prefer AC3D.

Sorry, I was doing by the wrong way, there isn´t a bug! This new features with real weather of version 10.45 are really good. I only think that if exist a way to change the turbulence with real weather without disabling the real weather, something like a dataref “real_weather_turbulence_override” or delimit turbulence areas (or radius) at an external file (similar de winds.rwx) it will give a lot of options to developement of weather plugins.
Another thing is occasionally add cirrus clouds at weather stations without using the 3 layers, it´s nice to pass at high speed at this type of cloud and overall scene get more beautifull

This is great news, I’ll check it out in Blender. Thanks Ben.

Great job anyway

You should ping Austin about this.

Thanks for the clear answer Ben, it is very interesting !

Cheers.

On my canard design it is necessary to match the incidence of the horizontal stabilizer to the angle of attack of the aircraft to provide propper control and handling. For testing purposes I am currently using the workaround as follows: At the Wings definition window I have selected “incidence with elevtr 2” for the Horiz Stab. Additionally I have selected “incidence with trim” for it. At the Control Geometry window I have set a range for “all-moving stabilizer trim”. With this done I currently try to match incidence to AOA manually in flight. As there are many canard type aircraft out there using this feature it would be great, if you could add an automatic incidence matching for the all-moving stabilzer.

Many thanks & cheers
Alex

Yes – in fact, support for the new manipulators is already available in the Blender 2.49 (my fork) and blender 2.73 (new 3.3 version) scripts. I also have ac3d support; I wasn’t planning on doing another ac3d plugin release but I would probably trade one more release for a good bottle of Scotch.

First, more than anything I hope alpilotx does -not- stop making things for X-Plane. His work is really wonderful! I -believe- that I have the right setup that I can still cut DSF tiles even if he cannot do so, but he does a much better job than I do at data acquisition.

Regarding Orbx, I have never had any communication from them, and my impression is that in the past they have made strong statements that they will not move to X-Plane. My door is always open to all third parties, and I would be glad to help them to develop for x-Plane just as I do any scenery authors, but at this point I would be very surprised to hear from them because I would expect that whatever agreement they have with Dovetail would lock them in to Dovetail’s new sim.

Finally, I am -not- considering a total breaking change in how scenery tiles are created that would force 3-d parties to redo their work — there isn’t a strong need to do that and it would be a big slap in the face to content developers who work on X-Plane. The FSX community has a strange challenge ahead of it – because FSX has been a “dead tree” for such a long time, third parties have gotten used to perfect unchanging backward compatibility, no matter what they do. There is mathematically no way Dovetail can maintain that level of compatibility going forward, since that kind of “nothing changes” compatibility comes from doing nothing (e.g. having the sim not being actively develope) – as soon as they write even one line of C++, third party authors will have to figure out what will remain working and what will not.

That kind of approach (just leave it alone) has never been okay for X-Plane; instead we actively maintain a level of backward compatibility to give authors a window to evolve their work. This means large projects can have a reasonable shelf life but X-Plane doesn’t have to be anchored to the past. The “window” of time for old features varies – I’m willing to leave backward compatibility in for longer when it isn’t actively dragging down the sim, but at a minimum we try to keep airplanes working for a major version, e.g. X-Plane 9 aircraft (saved in 9.70) work in every version of X-Plane 10; in some cases the experience is rougher if new v10 features aren’t adopted, but it’s not a total reset. The old ENV file format (x-plane 6, 7) was supported in X-Plane 8 and 9 and dropped in 10.

We don’t usually drop a piece of technology until a better replacement has had time to be adopted. In the case of DSF, there isn’t some new “better-than-DSF” format that would replace it, so it’s way too early to even talk about dropping DSFs.

With that in mind, I expect DSF to evolve – DSF is just a big geometry container, so unless we stop using geometry, we’ll have DSFs. We’ve moved toward having more raster and less vector data in DSFs and we may be able to take further steps in that direction; there may someday also be a new set of binary encodings in DSF for better efficiency. No matter what, I expect there will be compatibility code so that no one has to wake up and go “oh noes, I have to rebuild all of my DSFs right now!”