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, it's a
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 new wrap
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 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?
Good point. The
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
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.
The
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 it
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/max width
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,
- the number of
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 texture
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.
(...)
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 :)
snip
I) Basic building blocks - texture sheets
I assume the
12 matches
Mail list logo
