Who Am I?

This week we've seen an increase in questions from new users, potential customers (both in the consumer and professional spaces) and third party developers.  So before I start blogging about the guts of 930 and all of the new features and changes, here is some background.

I am the lead scenery developer for X-Plane; my main work area is the default scenery, the scenery tools and file formats, and the rendering engine.  I also work on modeling issues because the same rendering code draws airplane models and scenery models.  I don't work on the flight model or physics - that and about a billion other things are all Austin - heck, I don't even know what makes an airplane fly.*

My professional background is programming; I came very close to becoming an Air Traffic Controller - I went through a CTI program in California, but by the time the FAA called me for the next step of the process, over a year had gone by; I was deep in X-Plane already and the FAA was experiencing personnel turbulence.  I think I really would have really enjoyed being an ATC, but my personality is definitely better suited for a small company like Laminar Research than for a big government agency.

This blog is primarily targeted at authors who create scenery and airplanes for X-Plane, and also for users who want to know more about the "guts" of the sim.  It is not tech support; I will not answer tech support questions posted in the comments sectio -- sorry.  Please contact X-Plane tech support - they are there to help!

There are a few website resources for third parties that provide reference:

• The X-Plane scenery website - contains all the file format specs and LR's tools and code.
  
• The X-Plane Wiki - contains information on authoring planes, scenery and modeling.
  
• The X-Plane Plugin System has its own wiki.
  
• Robin manages our airport data - see his web page for downloads and file format specs.
  
• The X-Plane user's manual is available on the contact page, just in case the version you have from your DVDs is not as recent, or you are trying to use Plane-Maker in the demo.
  

There are also a number of mailing lists - the scenery and plugin pages list the appropriate mailing lists for those audiences.  I definitely recommend the mailing lists for developers and authors - traffic isn't too bad and there are a lot of knowledgeable users!

I can be reached by email via bsupnik at xsquawkbox dot net, but I must warn you: my in-box is on the verge of complete structural failure!  I try to answer everybody, but if your message gets lost, you may need to try again.

* This is actually not true - when I was in ground school, our instructor told us the real force that keeps an airplane in the air: money!

The News

By now everyone has heard the news: Microsoft is closing down ACES.

This is not a happy day; there is no joy in people losing their jobs in this economy. And having your product canceled really hurts. I have worked on programs that have been killed after I left the team, and I have worked on programs that have been killed while I was working on them, and either way, it really, really sucks.

What does this mean for X-Plane? That is something we are trying to figure out now. Halting development on MSFS is an earthquake within the flight simulation world; it was not a scenario we were planning for last week. In some ways, it changes everything, but in others it does not.

In particular, a lot of things have become high priority that were always important, but are now on a much shorter time table. Improving our documentation, simplifying the user experience, etc. Our current users have already learned the quirks of X-Plane, but we now have more people trying X-Plane for the first time and tripping over those stumbling blocks.

We are only a few days away from going beta with X-Plane 930. 930 was a huge patch for us already, with lots of new features "saved up" over several months, but now it is even more stuffed, since there are also last minute features to make the sim easier for new users, and to add in new capabilities that we are being asked about.

So to current X-Plane users, I ask two things:
* Please be patient with us, and with new users - this is a very busy time and a lot is changing very quickly.
* As always, don't panic. The first beta always has a few problems with certain video cards, and one or two really gross bugs. The quality of the betas will improve very quickly in the first week or so. Squeamish users should simply wait a few weeks, or skip beta entirely. Third party authors: please test your add-ons as soon as you can! The sooner you report the bug, the sooner we can fix it!

Our mission with X-Plane has not changed: it always was, and still is, to make the best flight simulator we possibly can!

Glass Objects

930 will have some new options for attached objects.  One is to declare a "glass" object.  When an object is declared to be glass, it is moved to the very end of the drawing order - even after the cockpit object.

The idea of glass objects is to let you make translucency that works from any view angle.  To make multiple layers of glass, the trick is to use pairs of one-sided triangles.  The glass (visible from the inside only) goes first, then the glass (visible only from the outside) goes second.  All of this goes into the object with the "glass" property in Plane-Maker.

One side benefit of the two-triangle approach is that the inside and outside of the windows can be tinted differently.

Having glass objects does three things for us architecturally:

1. It takes pressure off the interior cockpit object.  The interior cockpit is the only object that can have manipulators, so texture space in the interior cockpit object is quite valuable.  By allowing translucency in an attached object, you can put your window textures somewhere else and save texture space for the cockpit object.
2. It gets around the current weirdness where the interior cockpit object is drawn last but the exterior cockpit object is drawn first.  The glass object is always drawn last.  Period.
3. It sets us up someday for some kind of shadowing scheme in the cockpit.  This is a bit pie in the sky, but most pixel-based shadowing algorithms go a bit bonkers on translucent geometry; by flagging the whole object as "glass" we can simply omit it from shadow calculations.

The 921 draw order has the exterior cockpit object drawn first (if drawn) and the interior cockpit object drawn last (if drawn).  This made sense at the time - the exterior cockpit object was being used primarily for a pilot figure, with windows in the ACF paint - so it had to be drawn before the ACF fuselage.  The interior cockpit object has to be drawn last because the coordinate system is changed to a super-close-to-the-user coordinate system that has to be drawn last.

Now that there are attached objects, people are modeling a lot more of the airplane, the usual approach is to have all 3-d present all the time, so that a roaming camera won't reveal missing parts of the airplane.

Broken Panels

I have found the cause of a rather serious bug in Plane-Maker: sometimes instruments disappear from the hierarchy (but are still visible in the main window).

The problem is that the cut-paste facility, when used with multiple-instrument selections, was corrupting the hierarchy information.  Because of the way instrument hierarchies are managed, this corruption persists - even if it isn't visible.  So if you manage to ungroup everything, it looks okay until you work more, then the instruments disappear again!

This is a really bad bug of mine, particularly since a panel is such a time investment.  Here is what we'll be able to do in 930 to get around this:

1. A new "flatten panel" command simply ungroups everything and completely cleans the hierarchy.  All corruption of hierarchy is fixed with this command, finally exposing every instrument.  From that point on, you can then re-group and things should be okay.
2. I am fixing the cut-paste commands to not trash the hierarchy, and I am looking for any more hierarchy-corruption problems.
3. 930 has export/import of instrument groups to text files.  So another way around instrument corruption problems would be to export the panel to a text file, fix the grouping problems (which is a matter of moving the GROUP/END_GROUP lines) and then re-importing.  If you do not have a selection, the entire panel is exported, including any hidden items in the hierarchy.

I believe that text-based panel import/export will also be useful for sharing individual instruments (or clusters of grouped generic instruments), archiving work, and making large-scale changes using search-and-replace.

Two Squashed Bugs for 930

These two issues have been discussed a lot in the forums, so I thought I'd mention them:

First, I finally found and nuked that star-burst pattern in the rain.  It turns out that for some textures, compression was destroying the lower res mip-maps, causing the geometry that the rain drops are drawn on to show up as that starburst pattern.  It should be fixed for 930 beta 1.

Second, it turns out that the code that converts the 900-format generic instruments to 920-format generic instruments* was being run on the user's airplane whenever a multiplayer airplane older than version 920 was being run.  That could cause generic instruments to disappear, appear incorrectly, or just crash the sim, because the aircraft data in the user's plane (once the user is flying) is already in 920 format...if you interpret it as 900 format again, you get non-sense.  

I am fixing this for 930 beta 1; there may be other bugs relating to multiplayer and generics, so we'll see if this fixes most of the problems, or others crop up.  The panel system is essentially "global" (that is, there is one panel for the user in all of x-plane) but the instrument data is per-plane...so there is always a risk of code mistakes where the multiplayer planes affect the user's panel.

When will 930 beta 1 be out?  I don't know.  Hopefully pretty soon - when bug fixes make it into the blog, we're usually in the push to get to beta.  But I'm working on features on a few fronts, so it's hard to say which ones will be done first.

* X-Plane 920 revised the ACF format from version 900.  The file format for generic instruments was pretty much completely changed to accommodate new features like key frames.  920 has code that converts the 900 generic instruments into 920.  For example, simple key frame tables are built out of the older offset-scale parameters per instrument.

Unfinished Business

I have recently started leaving pieces of email and notes on the Wiki.  To see this mess, just view Category:Unfinished.

The problem is that often I don't know what people don't know but want to know.  So when I get an email question whose answer is not already posted somewhere, I make a wiki page and dump the info.

This stub is in response to some work I did this morning.  In particular, lights in X-Plane often have visibility much larger than the objects they come with.  This used to be true for the cars, but I broke the code in 921 and didn't notice.  In 921 headlights do persist beyond the car object's visibility distance, but not by much.  930 will fix this, restoring the "string of lights" look on the roads at night.  

I've also tuned the headlights to be visible from a wider viewing angle, to try to make them more noticeable from above.  (In real life, the lights illuminate an area of the pavement, which is visible, but we don't do this.)

If there is a scenery subject that is poorly or not-at-all documented, shoot me an email and I'll stub out a Wiki page - it's a first step to getting comprehensive documentation.

(Note that I have not added pages for tutorial steps like "how do I add a manipulator to my object" because I am doing the tools work for ac3d now ... better to write a tutorial for manipulators the easy way with ac3d than to write one on the hard way - editing the OBJ - and changing it later.  That is to say, I am trying to documetn tools, not temporary work-arounds!)

Panel Texture and Panel Clicking

As of X-Plane 9, life was simple: ATTR_cockpit and ATTR_cockpit_region caused your triangles to be textured by the panel, and they could be clicked. ATTR_no_cockpit went back to regular texture and no clicking.

Well, it turns out that secretly ATTR_cockpit was two attributes jammed into one:

• Panel texture - that is, changing the texture from the object texture to the panel texture.
• Panel clickability - that is, mouse clicks are sent to the 2-d panel and act on those instruments.

With X-Plane 920 and the manipulator commands, this "clickability" aspect is revealed as a separate attribute, e.g. ATTR_manip_none sets no clickability, and ATTR_manip_command makes a command be run when the triangle is clicked. These attributes can be applied to any kind of texture - panel texture or object texture.

So how does ATTR_cockpit work in this context? Basically you can think of ATTR_cockpit as two "hidden" attributes:

ATTR_texture_panel
ATTR_manip_panel
and similarly, ATTR_no_cockpit is likeATTR_texture_object
ATTR_manip_none
With this you can actually get any number of combinations of attributes, but the code is sometimes unexpected. In particular: if you want a manipulator other than the panel or none, you have to specify it again. Example:# set command manip
ATTR_manip_command hand sim/operation/pause Pause
TRIS 0 3
ATTR_cockpit
# we now have to reset the cmd manipulator!
ATTR_manip_command hand sim/operation/pause Pause
TRIS 3 3
ATTR_no_cockpit
# we have to reset the cmd manipulator again!
ATTR_manip_command hand sim/operation/pause Pause
TRIS 6 3
Similarly, if you want the panel manipulator, you may have to reset the cockpit!ATTR_cockpit
TRIS 0 3
# now make the mesh not clickable
ATTR_manip_none
TRIS 3 3
# Mesh clickable again
ATTR_cockpit
TRIS 6 3
The good news is: this isn't nearly as wasteful as it seems. X-Plane's object attribute optimizer is smart enough that it will remove the unnecessary attributes in both cases. In the first one, what you end up with is one manipulator change (to the command manipulator), and the panel texture change is done without changing manipulator state at all. In the second case, you end up with the manipulator change, but the panel texture is kept loaded the whole time.

In other words, even though the double-attributes or duplicate attrbibutes might seem to be inefficient, the optimizer will fix them for you.

One reason you might care: the cost of panel texture is one-time - that is, you pay for the size of the panel texture once per frame. But the cost of manipulatable triangles is per-triangle! So having more is bad. With ATTR_manip_none, you can use the panel texture but not have it be clickable, which can be a big performance win.

930 will handle manipulatable triangles a lot faster than 920 -- but that's still not a good reason to have all of your triangles be clickable!

This article is still unfinished, but I am trying to put together some info on how to detect performance problems like too many clickable triangles.

What Happened to X-Plane 910

X-Plane 910 was an update to X-Plane 9 for our professional customers.  But all of the new features that they got in 910, everyone got in 920.  Here's how it happened:

X-Plane 9 had a very long beta, and the end of that beta was mostly spent with a finished sim and me trying to fix the pixel shaders for five thousand flavors of video card, driver, and operating system.  During this time, Austin started work on new systems modeling features for professional level sims.  We branched the code, with my work going into 900 and his going into 910.

When he finished his systems code and I got the pixel shaders fixed and both were fixed, the two were combined into what became 920.

So that's how we "lost" the 910 version number - some professional customers have the version number, but everyone got the features.

Which is Faster: Panel Texture or 3-d Instruments

There are two ways to make 3-d instruments in your 3-d cockpit:

• Create 2-d instruments on a panel and use the "panel texture" (ATTR_cockpit or ATTR_cockpit_region in your OBJ) to show those 2-d instruments in the 3-d cockpit.
  
• Model the instruments in 3-d using animation.

So...which gives better framerate?  Well, it turns out that they are actually almost the same...a few details:

• If your card can't directly render-to-texture, there is an extra step for the panel texture. But that would be a weird case - all modern cards can render directly to textures unless you have hosed drivers.
• For very small amounts of geometry, there's pretty much no difference between rotating a needle using the CPU and telling the GPU to do it by changing the coordinate system.
• The panel texture does put pressure on VRAM - if you've had to go to a 2048x2048 panel texture to have enough space, it's going to hurt you.

Both approaches are actually quite inefficient - you get best vertex throughput on the card when you have at least 100 vertices per batch.  But if a panel has 800 batches, you don't necessarily want to do this - you'd pick up 80,000 vertices just trying to "utilize" the graphics card.  That's not a huge number, but it's big enough to consider.  Panels have enough moving parts that they're going to push the CPU more than the GPU.

A number of authors like the 3-d approach because they are more comfortable with 3-d tools, and because it can look sharper (since there is no intermediate limiting texture resolution). 

There is only one case where I would advise against the 3-d approach: if it takes a huge number of animation commands to accomplish what can be done in one generic, use the panel texture; the generic instruments are all coded cleanly and none of them take that much CPU power.  But some of them produce effects that would be relatively difficult to reproduce with animation.

Fixing Panel Editing in AC3D

The X-Plane export plugin for AC3D doesn't handle panel textures very well.  The current plugin tries to identify cases where you have used your panel background as a texture - this queues it to generate ATTR_cockpit.  This scheme has a number of problems:

1. The search paths for the panel background are not up-to-date.  The plugin doesn't know about the new naming conventions or the cockpit_3d folder.
2. The scheme doesn't address panel regions at all - there is some support for them but it doesn't work well.
3. Most important: panel editing is not WYSIWYG.  Since you are using the panel background as your texture, you can't actually see where all the moving parts are!  Doh!

That last point is perhaps the most important one, and it is why, for the next version of the plugin, I am introducing panel previews.

Basically a panel preview is a screenshot of your panel with the instruments on it, sitting in your cockpit_3d/-PANELS- folder.  AC3D will recognize and use the panel preview when possible.  This will solve problems (1) and (3) - there will be only one naming convention for previews, and they will be screenshots of the panel in action, so you can texture with a preview of the instruments.

Plane-Maker 930 will contain a facility to generate panel previews; if you are using X-Plane 920, you can generate the preview manually by taking a screenshot in X-Plane.

For panel regions, we will have one preview file for each region (e.g. Panel_preview0.png, panel_preview1.png).  This addresses issue 2 - usage of the region previews will invoke ATTR_cockpit_region.

Finally,  I am moving the panel sub-region information from the preferences to the .ac file (hopefully) so that it will be saved with your plane.

Hopefully this will make a work-flow which is much simpler.  To make a 3-d cockpit you will simply pick "generate previews" in Plane-Maker, and then start using the previews as textures.

Robin Redoes the Airport Data Page

I really like what he's done with the new page - see it for yourself here!

Accidental Contracts

In a previous post I ranted about the hidden cost of adding new third-party-accessible features to X-Plane - that cost being the cost of supporting the APIs way into the future so that third party content doesn't break.

Even trickier are accidental contracts - that is, unintentional behaviors that the sim exposes that third parties take advantage of.  This can be particularly tricky for us because we might not even realize that the behaviors are happening.

In 921 we allowed the HUD to be visible in the 3-d cockpit for planes that use our "default" 3-d cockpit, like the 777.  Ignoring that this was a truly silly feature to do, one of the side effects of the code change was that EFIS glass instruments now render correctly over transparent parts of the panel texture on some hardware.  Javier immediately jumpedon this to build a 3-d HUD.

These EFIS glass instruments appearing in that region was totally unintentional, and this is about the last way I wanted to implement 3-d HUDs, but now that it's in there, I have to ask: do I want to break Javier's airplane, which a lot of users will like?  Probably not!

Another accidental contract is the draw order of the cockpit objects.  Basically due to a coincidence of how the code is structured, the external cockpit object is drawn before attached objects, but the internal cockpit object is drawn after.  There is no good reason for this, but now that authors build airplanes based on this, we have to preserve it because changing draw order can break translucent geometry.

X-Plane is full of this kind of thing - and all of these hidden conventions make it tricky to restructure subsections of the code.

Al Bedo Makes an Omlette

Sometimes you have to break a few eggs to make an omlette.  Or at least, you have to consider whether breaking them is acceptable.  Often I hit cases where the cost of supporting a legacy feature is somewhat painful.

One way to decide what to do is to change the feature early in beta, see who squawks, and then change it back if necessary.  There are two I am looking at for 930.

Glass Instruments

It turns out that glass instruments fade to black, not to transparency.  This is a little bit weird, because that means they will leave black footprints if they are on top of a non-black background.  My guess is that most people use them on black screens and thus did not notice.

If people really need fade-to-black glass instruments, I'll just create a new lighting type (glass-transparent), but if everyone can live with fading to transparent, it's certainly the more useful case and probably what most people always wanted.

Separate Specular Hilights

For as long as I've been involved, X-Plane's specular hilights are modulated by the object or airplane texture color.  In other words, if you paint your airplane red, you get red hilights, and if you paint it black, you get no hilights at all.

This is not a very good way to do things for a few reasons:

• Under this scheme, you can't make a shiny black object.
• Someday we will add gloss maps - but the glossy part of the gloss map will be defeated by the black texture.

So for 930, I am looking at not modulating specular hilights by texture.  (This is called "separate specular hilights" in OpenGL lingo.)  My guess is that they will look enough better in almost every case that people would rather have it this way.

Should specular hilights be white for a black object?  Yes!  A specular hilight is a simulated intense reflection from a very far away, very bright object (the sun).  So it should take its color from the sun, not the object itself.  To this end, I have also (finally) set the specular hilights to take on the daylight sun color, so that they get fainter and yellowish at dusk.  This makes dusk and dawn look a little bit less strange.

(Nerd note: Technically, for the day texture to be an albedo texture, it shouldn't affect specular hilights.)

File Name Replacement Vs. the Library

When you make an airplane, you customize some of the images and sounds by simply putting a wav or png file in your aircraft package, with the same name as X-Plane's default. This is "file name" substitution.

What is good about file name substitution is that it is very, very simple.

But file name substitution has some limitations:

• If you need to provide multiple versions of a file, there is no way to do this. You can at most replace one file with one other file.
• There is a risk of "file name collision" - so file name substitution is only appropriate when we can be sure that a folder is only used for one simple purpose.
• The file name cannot easily encode a lot of information about how the file is to be used. We use _LIT to indicate an emissive texture, but imagine trying to encode every aspect of a .ter file in a file name (all of the projection parameters, physics parameters, texture clamping and alpha managemnent, paged texture loading). You'd end up with a file name like my_tex_na_42.23E_72.32W_conc_pd_5000_4000_nw_LIT.png. You can't tell me that that's an easy file to work with!

The scenery system hits all three of these limitations, and it deals with them in two ways:

1. Texture files are almost always referenced from a text file. The text file provides a place to put all of the important parameters about the texture.
2. The library system maps art assets to virtual file paths, avoiding collisions and allowing multiple files to be mapped to one virtual path.

Cristianno wrote this awesome tutorial, which shows how the library system works.

Who Is This Al Bedo Guy Anyway?

That's Mr. Bedo to you!

Sometimes I end up learning the name for a computer graphics idea or technique long after I use it. So I was amused the other day to find out that the fancy computer-graphics name for the "daytime" textures in X-Plane (you know, the normal ones for OBJs and airplanes) are called albedo textures in technical terms - or rather they define the albedo component of the lighting equation.

This is handy because I had a nice big fancy word for _LIT textures: emissive. So now, armed with both technical terms, we can accurately describe the two parts of lighting that X-Plane usually specifies by texture: albedo and emissive.

Basically the albedo texture tells what color you see when light shines on it (or rather, how much of that light is reflected back to the viewer diffusely) - it represents color information that does not generate its own light. The emissive texture describes light created by the object, and thus visible under any circumstances.

X-Plane's lighting equation is thus typically:

albedo * brightness at that point + emissive

Where "brightness at that point" is the sum of all of the lighting effects from any number of lights, the sun, ambient light, etc.

Now there is something interesting about this lighting equation: the emissive component is added to the "modulated" albedo component. So what happens if:

• Albedo is 100% (that is, white)
• The brightness of the sun is 100% bright (really bright day) and
• Emissive is non-zero?

Answer: the total lighting is more than 100%!

100% of what? These lighting values are described in terms of the range of color your monitor can output, from black (0%) to white (100%). So if we have a lighting value of 120%, basically it shows up as white (100%) and the "extra" white is lost. The result is a loss of color accuracy and detail.

For 930 I have a to-do item to scale down all emissive light by a constant factor when the day time overall brightness is high.

The idea is this: in the real world, your eyes have non-linear, adjustable sensitivity to light (and the sun is really, really bright). So when the sun is out, the amount of light added by a neon sign is trivial compared to the light already on the sign from the sun. At night the sign's light is much more significant because it is relatively dark (thus the sign is in a more sensitive part of your vision and your eyes are adjusted).

In X-Plane, scaling down the emissive texture during the day will simulate its lesser effect during the day.

One more note on emissive vs. albedo texturing: ATTR_emission_rgb basically sends a certain portion of the day time (albedo) texture to the emissive part of X-Plane's lighting. But the emissive (LIT) texture is still used. So if you use ATTR_emission_rgb, don't set the emission level to full (1.0 1.0 1.0) and use a very bright _LIT texture; the result will be more than 100% brightness.

Failed Ideas and Two-Core Rendering

I'm pretty gun-shy about posting new features to this blog before they are released.  One reason is that a fair number of the things I code never make it into the final X-Plane because they just don't perform as expected.  But the converse of that is: there should be no problem posting about what failed.

One idea that I believe now will not make it into the sim is dual-core pipelined rendering.  Let me clarify what I mean by that.

As I have blogged before, object throughput is one of the hardest things to improve in X-Plane. That code has been tuned over and over, and it's getting to be like squeezing water from a rock. That's where dual-core pipelined rendering comes in.  The idea is pretty simple.  Normally, the way X-Plane draws the frame is this:

for each object
is it on screen?
if it is tell the video driver, hey go draw this OBJ

Now the decision about whether objects are on screen (culling) is actually heavily optimized with a quadtree, so it's not that expensive.  But still when we look at the loop, one core is spending all of its time both (1) deciding what is visible and (2) telling the video driver go draw the object.

So the idea of the pipelined render is to have one core decide what's on screen and then send that to another core that talks to the video driver.  Sort of a bucket-brigade for visible objects. The idea would be that instead of each frame taking the sum of the time to cull and draw, each frame should take whichever one is longer, and that's it.

The problem is: the idea doesn't actually work very well.  First, the math above is wrong: the time it takes to run is the time of the longer process plus the waiting time.  If you are at the end of a bucket brigade putting out the fire, you waste time waiting until that first bucket goes down the line.  In practice the real problem though is that on the kinds of machines that are powerful enough to be limited only by object count, the culling phase is really fast.  If it takes 1 ms to cull and 19 ms to draw, and we wait for 0.5 ms, the savings of this scheme is only 2.5%.

Now 2.5% is better than nothing, but there's another problem: this scheme assumes that we have two cores with nothing to do but draw.  This is true sometimes, but if you have a dual-core machine and you just flew over a DSF boundary, or there are heavy forests, or a lot of complex airports, or you have paged-texture orthophoto scenery, then that second core really isn't free some of the time, and at least some frames will pick up an extra delay: the delay waiting for the second core to finish the last thing it was doing (e.g. building one taxiway, or one forest stand) and be ready to help render.

And we lose do to one more problem: the actual cost of rendering goes up due to the overhead of having to make it work on two cores.  Nothing quite gloms up tight fast inlined code like making it thread-safe.

So in the end I suspect that this idea won't ever make it into the sim...the combination of little benefit, interference by normal multi-core processing, and slow-down to the code in all cases means it just doesn't quite perform the way we hoped.

I am still trying to use multiple cores as much as possible.  But I believe that the extra cores are better spent preparing scenery than trying to help with that main render.  (For example, having more cores to recompute the forest meshes more frequently lowers the total forest load on the first CPU, indirectly improving fps.)