Tuesday, May 25, 2010

Plugin-Based Prop Discs

I was discussing plugin-controlled prop discs with a third party developer. The developer wanted to know if custom prop disc control would end up inside Plane-Maker. It may end up doing so, but I don't think this would be nearly as useful as it would seem. What follows is my explanation to him of why this is.


Let me draw an analogy: when it comes to systems modeling, using a plugin is to Plane-Maker as using Blender is to using Plane-Maker.

Users who cannot use Blender are frustrated because they cannot make something as nice as those who are building planes out of OBJs. Sometimes they ask for more features in Plane-Maker, like: more stations! This new editing mode! Make the UI better!

But...you tell me: will Plane-Maker's UI ever be as flexible and powerful as Blender? And if it ever did get to be that good, would that have turned out to be a good use of LR's time, when Blender is already available?

The motivation for OBJ-based airplane geometry via third party tools is that what users want to do cannot be easily generalized into a few simple cases. Every plane is different, so a truly flexible platform is needed.

The prop disc (and other systems modeling problems) are the same way. In developing the prop disc graphics, I spoke with a number of third party developers who had already tried to push prop discs as far as they could go, were using plugins, were drawing themselves, as well as 25 other crazy hacks. I also spoke to our internal art team. And what I found was: no one had any consensus on how the prop disc system should work. Everyone wanted to tune a very specific set of behaviors to their peculiar art assets.

That's what drove me to put it into a plugin. When we need an equation or a strategy we reach the point where we need more flexibility than Plane-Maker can exhibit. A plugin can encapsulate a strategy or technique in a way that Plane-Maker radio buttons cannot.

Consider what would happen if custom prop disc parameters were built into Plane-Maker. Everyone would have to wait until Austin implemented the prop disc algorithm they wanted. How would this be bad? Let me count the ways?
  1. How many algorithms do you think Austin has time to code? Not more than he has fingers on his right hand. Only the five lucky third party developers who get their algorithm coded will be happy with this.
  2. Austin code exactly what you want? Don't get your hopes up.
  3. , what you asked for wasn't what you wanted? We can't change the behavior now, that would break compatibility!
  4. oh...your email got eaten by a spam filter? Too bad...no custom prop disc for you!
  5. Sorry, we don't have a release vehicle lined up for the next 3 months. You'll have to wait.
This problem is already happening across pretty much every aspect of systems modeling: airplane have unique, quirky systems which are usually useful for exactly one plane. It is not even remotely sustainable for X-Plane to code these things one at a time with a set of check-boxes. We might as well have a pop-up menu for every airplane ever invented, and simulate every single airplane inside the sim itself. Imagine the development costs...if a single high quality MSFS add-on sells for $30-$50...

Think of the prop disc via plugins situation (and the strobe lights are the same way) as an experiment in generic instruments for systems. By transitioning to a generic abstaction for instruments we've let a lot more users do exactly what they want with a small, high performance piece of code. The original instrument strategy (one of everything) reached a point where we simply couldn't meet user needs in a cost-effective manner.

7 comments:

Arista said...

What would be really great for these kind of things would be a simple scripting facility. At times, the overhead of developing a full-fledged plugin for one simple custom behavior can feel like overkill. Besides, many content creators seem to be reluctant to learn writing plugins in the first place - C can be a scary beast for someone who never programmed before. If, on the other hand, we could enter a couple of lines of, say, Python or Lua, at a few strategic places right in Plane Maker, the overhead would be much lower, and while this would technically still be programming, it might be much less scary for the uninitiated.

Benjamin Supnik said...

Arista, you are spot on re: scripting to lower the barrier of entry. See also my previous ranting:

http://xplanescenery.blogspot.com/2009/01/scripting-line-in-sand.html

Basically the C ABI provides a base level with maximum power/flexibility, and what we need now (from LR or a third party) are layers on top that increase abstraction and simplify ease of use at the expense of some flexibility and performance.

Steve said...

How does this apply to custom turbofan discs, Ben? Can it be applied? The same effects, albeit somewhat concealed, apply to the spinning blades of a jet engine. I recall a spiffy demo on a 757 once that was very convincing...same sort of advancement and stroboscopic effect. Thanks for working on this, by the way - it's the little things that really make this sim sing.

Benjamin Supnik said...

Steve, I would say it does not.

1. You can't use the prop disc tech unless your plane has...a prop.

2. Jet fan discs do not suffer the problems that causes all of the prop disc issues:

- Prop discs are translucent geometry outside the plane that interacts with scenery.
- Prop discs can be viewed from the side.

So...most authors just make a separate rotating disc out of an obj for jet discs, and since they are fully inside the engine housing teh Z and translucency issues are not issues.

vonhinx said...

Two points. Most newbies start out with Plane Maker; not everyone goes all the way. You can make a very decent looking plane in Plane Maker with a bit of care, but there's no way you can overcome a few massive flaws:

• You can't have a perfectly smooth windshield on both sides because of the asymmetry;

• Control surfaces are limited: no spoilers overlapping flaps, no end balance tabs attached to main control surfaces, no partly buried flaps, no cut lines perpendicular to hinge line.

The first one is low hanging fruit; the second is much harder but not impossible. Both would make Plane Maker-only aircraft pretty decent to start with.

The biggest limitation to instruments are their single dependency: show if this dataref <=, = or >= to n. Take an idiot-light annunciator, for example: green if tank pump moving fuel; orange if fuel low; red if fuel exhausted; off is tank pump off.

It's possible to include some logic by simple boolean combinations. All that is needed in this case is an additive dependency at the top: Requires Bus1, Bus2, Avionics, AND Pump is On, (AND EFIS page is p, AND... whatever).

Benjamin Supnik said...

These aren't "massive flaws". They are design limitations.

Unknown said...

I like what Arista brought up. I have my Q400 for which is has huge prop discs. i want to eventually have the plugin running my props but I am no programmer. So I am holding off till the end to finish the prop disc, cause I know it will take me a few days to really grasp what the plugin is and how it works and then how I can get it to work for me.
If it was in any way simpler. hell even if there was a short video tutorial on how it works and how it can work for me, that would be fine. if you guys decide to make it even simpler then that, its all pluses for me.
and as always you guys do a great job. love the blog.