X-Aviation just posted an update to SkyMaxx Pro – the new 1.1 patch brings big performance improvements and fixes rendering problems with HDR. From the user reports I’ve read, performance in HDR mode is good. (I hate to see users have to pick between HDR and third party add-ons; we want HDR to be the basis for superior next-generation aircraft and scenery.)
Getting a plugin that draws in 3-d to work with HDR mode requires some caution; the plugin APIs for drawing were designed in X-Plane 6, when ‘deferred rendering’ didn’t even exist as a concept.
I have updated the X-Plane SDK tech-note on 3-d drawing to contain modern guidance on how to cope with 3-d drawing callbacks. In particular, you get called twice when your plugin requests to draw in 3-d:
- The first callback is for drawing “solid” stuff that will be affected by spill lights; the only safe thing you can do from this callback is to call XPLMDrawObject.
- The second callback is after lights have been mixed; at this point normal OpenGL drawing works reliably (albeit without spill lights being mixed in). This is the time to draw translucent prop discs, coach marks and labels, clouds, smoke and particle systems, etc.
If your plugin does any 3-d drawing (e.g. custom particle system drawing or any kind of effects code), please review the tech note, and email me if you have questions. The next-gen CSL code sample that is linked from the article is tested and works correctly too.
Hi Ben. Thanks for highlighting what looks like a great add-on. I’ll be sure to try it out, but I might wait until I have a more powerful computer first.
It did make me wonder though, does LR take into account the availability of add-ons when deciding where to focus future development? For example, a lot of commenters on your (excellent, informative and insightful!) blog have bemoaned the lack of towering cumulus and poorly implemented fog. I recall that you have stated on a number of occasions that the fog problem is one which you guys are intending to address at some stage. But when there’s a high quality third party add-on readily available, which, by the sound of it, does a particular job better than the existing inbuilt solution, does that dissuade you at all from spending time on further development for that part of the sim?
Same with the inbuilt ATC vs online ATC networks etc?
I’m just curious because the SkyMaxx Pro developers, on their blog, have said that they have worked closely with you on the product.
I see Skymaxx Pro as taking a very different approach to clouds than what we use – we looked at multiple third party cloud engines during v10 dev and picked the solution we ship now. That decision was partly a technical and business decision, but it’s also partly aesthetic.
Therefore it doesn’t surprise me that we get two very different responses on weather. Some users love our weather and don’t see any value to SkyMaxx Pro. Other users love Skymaxx Pro, were never happy with our weather, and now consider what we did obsolete.
So I don’t see Skymaxx Pro as taking the pressure off of us to fix bugs in our own weather system; rather I see them reaching an audience that didn’t like the ‘what’ of what we coded, not the ‘how’.
The “fog bug”* is different – it can only be fixed inside X-Plane – that’s on us, and there’s a fix in progress.
For the ATC networks, I think it’s a question of immersion…at some point an AI ATC is never going to be as immersive as having real live humans with VoIP.
Cheers
Ben
* Is the fog bug a bug, or just a limited (and unsatisfactory design)? Turns out it’s both; I am working on fixing the bugs in the lighting model that make the fog bug worse _and_ increasing the visibility range with more DSFs, something we have had in the road map for a long time that requires 64-bit.
Skymaxx Pro rocks !
But I hate how the clouds aren’t visible on the horizon when you approach a line of clouds. They blame is on XPX. Hopefully there is a solution in the near future ? !
Hi Eric,
I have not heard anything about horizon-cloud visibility, so I cannot comment on this.
The tech note is a little incomplete when it comes to describing how your draw callback is called. Suggest a little more detail please.
In practice, every frame, your ‘draw’ callback is called:
– Once for drawing reflections (if you’ve called XPLMEnableFeature(“XPLM_WANTS_REFLECTIONS”, 1) and reflections are turned on in the user’s preferences). During the callback sim/graphics/view/world_render_type == 1.
– One or more times for drawing shadows (if shadows are turned on in the user’s preferences under X-Plane 10). During the callback sim/graphics/view/world_render_type == 3.
– Finally, once for drawing the actual object normally. During the callback sim/graphics/view/world_render_type == 0.
(The is is what happens if you register your callback for xplm_Phase_Objects – haven’t tried with other phases).
If you have complex calculations that you want to perform every frame, then it’s a good idea to check the value of the sim/time/total_running_time_sec in your callback, and only perform those calculations when that value changes (i.e. when you’re on to the next frame).
All true. I should add sample code, it would clarify. Other notes:
– I do not recommend ANY per-frame calls in drawing callbacks – use the flight loop CB – you’ll actually get called once per frame. 🙂
– I don’t recommend using xplm_Phase_Objects at all.
cheers
ben
I do not recommend ANY per-frame calls in drawing callbacks – use the flight loop CB – you’ll actually get called once per frame. 🙂I guess my thinking was that I’ve already registered a draw callback, so why add the overhead of also registering a flightloop callback? But happy to move per-frame calculations into the flight loop if that’s the preferred way.
I don’t recommend using xplm_Phase_Objects at all.Not even for drawing ground-level scenery-type stuff?
Hi Jonathan,
I think the FP callback is the preferred way – plugins are already using it for one-time graphics prep, so we have to keep supporting it, and it has no fine print abotu when it is called. The cost of a callback is usually cheap compared to the cost of what you do in it. (And if you already have a FL CB you can reuse it.)
For phase objects, I’d say this: the original API as shown in the headers describes x-plane 6 – it’s pretty much impossible to even pretend the abstraction makes sense. So all we can do for now is document what really happens and provide a narrow set of best practices that work in an understandable way. Since the object callback phase provides none of the benefits that it used to in v6 (and none compared to airplanes), I say do all 3-d drawing from airplanes – it’s the closest thing to the API we do want for now.
(In the long term we’ll make a newer API that better maps to what we have, but since it will only be usable in newer sims, the awkward procedure we have now is not just ‘what we have now’ but also the only way to span v9 and v10.)
cheers
Ben