Jump to content

Cumulusx! 1.8 And External Weather


scott967

Recommended Posts

I looked at the old thread on Active Sky and CumulusX! but I think maybe it needs updating for 1.8? When using Active Sky (enhanced), I have options in that program set to not generate thermals or ridge lift. But in reading CumulusX! document, it seems like sometimes station weather is used and sometimes global weather, and I wonder how that is impacted by programs like like Active Sky. Also, Active Sky has an option called "direct wind control" which seems to set global weather and disables station weather.

Is there some way to determine the weather that cumulusX! is responding to (maybe in the debug log?) that can be compared to what Active Sky "thinks" the weather should be?

Also to avoid starting new thread, I have 1.8 installed and also a license but I don't understand how the dll works with the exe? They both are needed but the dll takes priority with a license? I have both installed in the xml files, but I have the exe on a "manual" start so I don't start it when not soaring. Any problem with that?

scott s.

.

Link to comment
Share on other sites

Hi Scott,

hm, there is currently no way for an end-user of finding out which weather data determines the creation of thermals. AFAIK, ASA generates own thermals (and possible ridge-lift, too) programmatically, by using FSX' built-in thermal function calls, which functions the same way like FSX' stock-thermals.

Toggling the AutoStart option creates the entries in EXE.XML and DLL.XML. The DLL-entry is created only if the DLL is present in the CumulusX! program directory at that time. If you turn AutoStart off again, CumulusX! and the DLL will still load along with FSX but stay inactive. Once CumulusX! is activated and the DLL and a license are present, control is transferred to the DLL. As long as CumulusX! is not active the DLL does nothing.

regards,

Peter

Link to comment
Share on other sites

I looked at the old thread on Active Sky and CumulusX! but I think maybe it needs updating for 1.8?

Eh Scott

I'm constantly use ASESP1 with CumulusX 1.8 both in DWC mode and not. CumulusX handles both modes with ease. Relax and enjoy the two working together. It is complicated to have these engines all working separately from each other and there are bugs in ASE but not CumulusX. The bugs that are in ASE luckily don't impact us glider pilots too badly. The problem with being able to depict total overcast conditions is not an issue for us and also the bug with haze at very high altitudes is also not an issue for us! If you are using ASESP1, just don't fly at high altitude airports. There is a bug with clouds in the ground in FSX and ASE doesn't work when the dynamic rate of change slider is set to zero (needed to fix the bug). Basically all is pretty good and it is amazing how little impact there is on frame rates and how stable the simulation is with all that extra code chugging away in the background even on my Quad 9300 CPU. I have been using DWC mode off lately and thus leaving the global station alone. Either way has worked for me. Just disable all thermal generation both in FSX and ASE and you should be fine. If you have drama's or need to know how to do it, I can help you. I have also started experimenting with the REX2 weather engine and CumulusX and that also seems to work well.

Cheers,

Harry

Link to comment
Share on other sites

I would agree, if you are running Active Sky as well as CumulusX it is better overall to turn off the Active Sky thermal and ridgelift generation and rely entirely on CumulusX for the vertical air movement. The Cx development has been dominated by the 'vertical air movement' requirement for soaring pilots and other products are relatively limited in this area.

The Active Sky developers have made a good effort to dip a toe into the calculation of ridge lift but are currently limited by the fact they only sample the ground elevation at a single point immediately under the glider and build up a ground profile along the route the glider has flown. This works if you fly perpendicularly towards a slope (Active Sky detects the rising ground) but the method becomes ineffective when you fly along the ridge. Unless you're a developer it's tricky to visualize the fact that the lift formula has *no* idea of the terrain around the glider except for this single thread of sample elevation points. The trick we learned with sim_probe and Cx is that it is possible to get multiple real-time samples of ground elevation around the user aircraft so you can work out the incident slope to the wind, and this has been refined over the years with additional samples.

B21

Link to comment
Share on other sites

  • 4 months later...

Hi there

Just more thanks and appreciation to the developers of CumulusX Peter and testers. I have a question about the behaviour of CumulusX with the latest release of ASE external weather engine. It supports a third weather mode "Smooth Cloud Transitions":

Smooth Cloud Transitions

"Smooth Cloud Transitions depiction mode uses enhanced SimConnect weather writes that supports transitional cloud depictions that change over a period of 30 seconds. May result in inconsistent weather parameters at locations other than departure area and in winds aloft. Recommended for short-range and local flights or where visual cloud smoothness is preferred over accuracy"

Firstly I do no know what they are trying to say actually but what I notice is that CumulusX thermals work correctly as per usual in this mode but the graphics engine seems to send all the CumulusX clouds into the background and put all the REX/ASE/FSX clouds in the foreground. So what you get are these beautiful REX cloud depictions of cirrus drawn in front of the CumulusX clouds. It looks a bit like a surreal dream experience rolleyes.gif.

I think the effect was also present in standard depiction mode as well as "direct weather control" mode but not as bad.

Any thoughts anyone?

Cheers, thanks again for all the hard work on CumulusX!

Harry

Link to comment
Share on other sites

I'm sure Peter will comment but in the meantime I should mention the FSX 3D rendering engine has a hard-coded 'efficiency' enhancement which means FSX clouds always draw in front of anything else. If you think about it, this optimisation makes sense nearly all of the time - i.e. if you're above the clouds then they obscure the ground, and if you're below cloudbase and look up then you see the clouds obscuring any plane above them. But it totally messes up if you try and draw any normal FSX scenery object with a cloud behind it - the cloud will 'show through' the object in the foreground... this is the issue Peter has placing his 'cloud' objects which are necessarily standard FSX objects as each has to be placed exactly over a thermal. ASE is presumably using the 'FSX' cloud rendering which doesn't actually allow lat/long placement of individual clouds.

B21

Link to comment
Share on other sites

Ok thanks! The main question has been answered. I doubt that the weather mode in ASE is what is causing or making the problem worse. It's just a function of the graphics engine. I think that is what I am experiencing as I experiment with the weather engine depiction modes.

Cheers!

Harry

Link to comment
Share on other sites

Hi Harry,

there's a general problem with semi-transparent objects, such as clouds, and computer graphics with z-order rendering.

Occlusion of non-transparent objects is nowadays mostly handled by the pixel z-buffer which remembers the distance coordinate of the foremost pixel that has been drawn. Any subsequent pixel draw is executed only, if the distance coordinate object closer to the viewer than the previous foremost pixel. Then the z-buffer takes over the current distance value as the new base line. This simplifies occlusion checking very much, as it is not necessary to pre-sort objects in decreasing z-order. This works perfectly with any opaque object.

Unfortunately, this does not work with semitransparent objects, such as clouds. Let's assume there is a semitransparent object already there. If another object should appear behind this, it has to be drawn although the z-buffer tells that there is a already a nearer object. Second the drawing engine has to remember the transparency of this nearer object to correctly determine the blending between the existing object and the new one. It would require to memorize the z-sequence of all overlapping transparent objects and their transparency properties from front to the first fully opaque object, resulting in exploding pixel buffer efforts.

The current way is that these objects are again pre-sorted in decreasing z-order and draw at last in the render chain, thereby taking advantage of the z-buffer values of the previosuly drawn opaque objects. However this can only work, if it is sure that after sorting any particular objects of these is positioned entirely before ore behind any other semitransparent object, i.e. individual objects most not overlap in z-distance. This is because the z-buffer mechanism does not work with semitransparent objects.

Unfortunately, FSX built-in cumulus clouds are formed from large groups of clouds with considerable extension (~16x16 km), rather then individual cloud objects (stratus clouds are single!). These groups are treated as a whole during z-ordering. It is pretty obvious that the individual CumulusX!-clouds are usually somehow interspersed in the large FSX cloud groups. It is then a mere incidence if the group's reference coordinate and the reference coordinate of the CumulusX! cloud is related such that the FSX cloud shows correctly before or behind the CumulusX!-cloud.

hope that gives some insight into the nature of the problem,

best regards,

Peter

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use