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: #SKYMAXX PRO 4.5 REVIEW HOW TO# The second callback is after lights have been mixed at this point normal OpenGL drawing works reliably (albeit without spill lights being mixed in).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. 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. 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. Same with the inbuilt ATC vs online ATC networks etc? 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? 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. 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’.
0 kommentar(er)
