> So when wrap=true the core code will wrap the edges, shift the layer
> with altitude and move it with the wind With wrap=false, we'll just move
> it with the wind.
>
> OK?
Sounds good to me.
> One function I had on my TODO list was something to return the cloud
> position in lat/lon. However,
On Tue, Apr 26, 2011 at 3:45 PM, Heiko Schulz wrote:
>
>>
>> One function I had on my TODO list was something to return
>> the cloud
>> position in lat/lon. However, it's a bit tricky due to the
>> current
>> limitations in the command interface. Do you see any need
>> for it?
>
>
> Weather Radar?
>
> One function I had on my TODO list was something to return
> the cloud
> position in lat/lon. However, it's a bit tricky due to the
> current
> limitations in the command interface. Do you see any need
> for it?
Weather Radar?
--
On Tue, Apr 26, 2011 at 10:42 AM, thorsten.i.renk wrote:
>> Now, the placed 3D clouds are wrapped, just like the global clouds, so
>> if you travel far enough (50km), you'll come across the same cloud
>> again. For local weather, that probably isn't what we want. So, I'm
>> thinking of adding a n
> I've just committed (thanks to Torsten) an update to the 3D clouds. As
> well as fixing a bug that caused the cloud density to be significantly
> less than it should have been, the global 3D clouds now move with the
> wind, which looks rather nice IMO.
>
> This update also adds a couple of new co
I've just committed (thanks to Torsten) an update to the 3D clouds. As
well as fixing a bug that caused the cloud density to be significantly
less than it should have been, the global 3D clouds now move with the
wind, which looks rather nice IMO.
This update also adds a couple of new commands that
> Which reminds me, a long time ago (in the cutover from PLIB to OSG) we
> lost the ability to detect clouds using the Weather Radar.
> It would be very nice
> to restore that function. The code still exists, it's just the 3d clouds
> are
> no longer accessible.
What would it need, and what can i
>> Since my basic Cu texture image is often 1024x512 (sometimes larger),
>> sorting through the y-coordinate of the texture sheet isn't an option
>> unless you use 4096x4096 sheets - which may not be so nice. (?) Well, I
>> guess that depends on the texture cache which you seem to have anyway.
>
>
On Thu, Mar 31, 2011 at 8:42 AM, Thorsten Renk wrote:
> Mixing is actually not a problem at all - I can just create 2 overlapping
> cloudlets from 2 different texture sheets and place a third with dark
> diffuse bottoms below - that doesn't need to be hard-coded as long as I
> can ask for a textur
Thorsten wrote
>
> > Yes, in fact, my basic strategy was to use the existing default 3D cloud
> > code almost untouched from the perspective of creating a set of sprites
> > that are built up into a cloudlet. So, you can define (amongst other
> > things)
> >
> > - the texture sheet to use,
> > -
> Yes, in fact, my basic strategy was to use the existing default 3D cloud
> code almost untouched from the perspective of creating a set of sprites
> that are built up into a cloudlet. So, you can define (amongst other
> things)
>
> - the texture sheet to use,
> - the number of sprites,
> - min/ma
On Wed, Mar 30, 2011 at 12:56 PM, Thorsten Renk wrote:
>
> To follow up Stuart, here are some of my thoughts:
>
Thanks. Comments below, significantly colored by what I've
managed to implement in a couple of hours of hacking here :)
> I) Basic building blocks - texture sheets
>
> I assume the b
To follow up Stuart, here are some of my thoughts:
> FYI I'm currently looking at adding support for creating a 3D shader
> cloud
> using Nasal, to bypass the need to have XML wrappers etc. I'm hoping
> that this can off-load some of the low level quad-tree work you
> currently
> have to do.
(..
13 matches
Mail list logo
