We eat our own dog food” is a term in software development for a company that uses the product it sells for its own operations.  The idea of “dogfooding” is that developers who use their own software will have much stronger incentives to make the software usable, productive, and reliable.

Laminar Research practices a form of dogfooding with the scenery tools:

  • All of the scenery tools are open source, so we don’t have any “special secret magic tools” that you don’t have.
  • Our art team uses the same set of tools that third parties use.

Dogfooding does have an effect on development: when the artists get on my case about the usability of a scenery tool, it gets my attention.  We pay those guys to churn out a lot of artwork; if they aren’t productive, we can’t get the sim out.

However, there is an Achilles heal to dogfooding: you can only dogfood software that is useful for your company’s business.  We have this problem with MeshTool: since we don’t make our own orthophoto sceneries, MeshTool doesn’t get heavy internal use, and as a result I think it’s been a lot slower to become usable.  The MT users who have filed bugs have been very helpful, but I feel for their suffering with a very raw tool.

Dog Food and Version 10

For  version 10, we are producing art assets that use new rendering technology for the very first version.  This means we’ve had to build the tools to support new version 10 technology early on, and that’s good news for third party developers.  When version 10 is released, I’ll package up the various version 10 tools we’ve created for public consumption.

In most cases, the tools need additional polish – our artists often use tools in very early, buggy, raw form.  But what we already have is a big head start, which should shorten the time from version 10 release to a full set of tools.

I’ll post more over the next few days regarding some of the specific tools we have and what we will do with them once version 10 ships.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

9 comments on “Scenery Tools, Dog Food, and X-Plane 10

  1. Really looking forward to v10 ,, thanks for posting updates and informing the community.

  2. I’d like to see a post about minimizing framerate hit with regards to animated objects subject to a Hide versus just hidden from view, as well as the load of third party plugins. I do hope you guys are going to give us control of smoke objects for startup and fires. Smoke objects are in the ac3d plugin but don’t work for planes. Furthermore, as more people get involved with custom sounds via plugin, could turning off canned sounds rather than playing silent sounds be something worth mining?

    One more: pause mode needs to be invoked when loading new aircraft otherwise those custom sounds can’t be turned off. Pause mode seems to be invoked in Local Map view but not in Finder/file operations.

    Apologies for the off topic.

    1. Hi Vonhinx,
      Re: fps, do you mean, a post on how to minimize fps in these cases, or answering the question “is there a fps hit” or…something else?

      Smoke & sound: both need some attention, both need more than just a quick patch – I think they need new SDKs – that is, new ways to create the effects that are comprehensive and have future expansion.

  3. I have quite a few possibly quick questions on X-plane’s AI:
    Will X-plane 10’s (including any X-plane 10 updates) AI system…
    …include planes that: Take off? Land? Taxi? Park at a gate/ramp?
    …have planes that emit their own individual sound?
    …use aircraft within the users aircraft library as the AI planes or use CSL’s?
    …have a viewable Arrival and Departure board?
    …include AI airport vehicles?
    …know what continent we are in and generate relevant aircraft with relevant liveries?
    …have a limit to the amount of AI traffic visible according to computer power? If so, why does it have to be that way???
    …be able to tackle the Kai Tak approach?
    …give the ability to adjust AI pilot skill (increasing the likelihood of mistakes and aborted landings and take off’s)?
    …allow planes to physically collide or just pass through each other (like if using X-traffic)?

    I have also heard you will be able to adjust the accent of the ATC voice, is this limited to a variety of US accents? or can I have an Aussie or Brit?

    1. If Ben answers all these questions, also ask him if 10 will include AI butterflies and their cumulative effect on global weather patterns, adjusting ATIS along the way! Woah!

    2. First, I can’t comment on v10 updates _at all_. Why? Because they’re just an idea that gets thrown around the office right now. Basically we have a pretty much closed down feature set for v10, although it’s always subject to change as the work gets done. But then we also have lists of things we’d like to do but don’t have time to do. Once v10 is finished, we will re-evaluate all of those lists and start planning patches. That planning will include what we learn from customers, e.g. what users are saying most important _after_ they have seen version 10. So it’s impossible to know what goes into the patches now – probably some stuff that we will do we haven’t even thought of and will be suggested by users; some things that we think we’ll do will be pre-empted by better ideas and user feedback.

      I also can’t go into a ton of detail on the final feature set. I can tell you that AI planes will make full gate to gate flights, and the audio system is designed for audio file customization via audio voice packs.

  4. Yes, how to minimize framerate as we’re now seeing animated service vehicles, stowaway tables, video screens and dynamically lit cabinet interiors in new aircraft. So, something along the lines of hiding an .obj versus dynamically fading to a transparent texture; or hiding an object that is unseen because it is inside something else; or even displacing it by some ridiculous distance.

    I think I’d better read the object8 spec again….

    The other thing I’m seeing is, “can’t load buffer ID”s in the log.txt when a plane is reloaded about a dozen times during sound modelling runs. I’m not sure how it works but if some cache mechanism gets filled it should flush the lot and reload from scratch, which would be quicker than restarting the app. Hope I made some sense.

    As for smoke, we have one source per engine and two variants (white and black) but no way to invoke them for such things as hung or hot starts. Similarly, the wet runway ‘smoke’ could be reused for brake fires – a not uncommon event – if we had some means of control without climbing the open GL mountain.

    1. Re: OBJ optimizing…
      is a good start, and if you follow the links and search the blog, there’s more. I need to consolidate this stuff at some point.
      For what you mentioned:
      – ATTR_hide saves fill rate and vertex count but not CPU/batch count.
      – Transparent texture saves _nothing_ don’t do that.
      – An OBJ past its _last_ level of detail (e.g. farther than the farthest LOD) saves everything – CPU and working set included, and is the biggest win. So…low LOD is key.

      Can’t load buffer ID – I need an _exact_ error message. It’s also not really on topic for this blog post – maybe send an email.

  5. Got it thanks. I forgot I haven’t reduced object count and inspected the final file with a text editor yet but I think I’m going in the right direction.

Comments are closed.