Just wondering, does nobody have any experience with this type of thing, or is
the general feeling maybe that I should do my own hard work? ;)

In any case, I'm doing my best, and shall upload the results (provided they are
worth it).

Also, when it's finished, I'll upload the macro(s) when they're done, I have a
feeling that other people may have a use for them. :)

D103

Post a reply to this message

Le 12/04/2012 11:59, D103 nous fit lire :
> Just wondering, does nobody have any experience with this type of thing, or is
> the general feeling maybe that I should do my own hard work? ;)
> 

No real experience here. At best a notion that the atmosphere of earth
is split in "cell", or rather bands (5): around the equator, at the
poles, and midway. the boundaries moving with seasons. The most complex
bands being the midway ones, with Coriolis and other effects.
Pole are "simple": expend on light, contract on darkness.

Rain/clouds starting when hot wet air met colder area: either another
cell/band or due to the local geography (such as an island or a
mountain) or local albedo (rain forest is self-supporting, as long as
its wet and dark... once the wood is gone, expect Sahara desert-like and
no return: it could turn into Atacama)

Also, a bit particular: nearly constant circular winds around Australia
main mount.
Not found on the other side of the planet. (but looks like Jupiter's
stable whirl in south hemisphere)

I probably miss a lot of influences too.

> In any case, I'm doing my best, and shall upload the results (provided they are
> worth it).
> 
> Also, when it's finished, I'll upload the macro(s) when they're done, I have a
> feeling that other people may have a use for them. :)
> 
> D103
> 
>

Post a reply to this message

On 12-4-2012 11:59, D103 wrote:
> Just wondering, does nobody have any experience with this type of thing, or is
> the general feeling maybe that I should do my own hard work? ;)
>
> In any case, I'm doing my best, and shall upload the results (provided they are
> worth it).
>
> Also, when it's finished, I'll upload the macro(s) when they're done, I have a
> feeling that other people may have a use for them. :)
>
> D103
>
>
It looks quite exciting although it seems not easy to do to me. I 
suppose you do not want to emulate the super-computers that try to model 
the atmosphere ;-) but even so, there are so many complex parameters 
that I would wonder where to start. However, you seem to have some ideas 
and I am looking forward to some preliminary results. I suppose that 
would make it easier to discuss.

Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> It looks quite exciting although it seems not easy to do to me. I
> suppose you do not want to emulate the super-computers that try to model
> the atmosphere ;-) but even so, there are so many complex parameters
> that I would wonder where to start. However, you seem to have some ideas
> and I am looking forward to some preliminary results. I suppose that
> would make it easier to discuss.
>
> Thomas

Exactly my reasons for posting. :) You are right, there are myriad parameters,
however I am trying to get away with as few as possible. ;)

Le_Forgeron <jgr### [at] freefr> wrote:
> No real experience here. At best a notion that the atmosphere of earth
> is split in "cell", or rather bands (5): around the equator, at the
> poles, and midway. the boundaries moving with seasons. The most complex
> bands being the midway ones, with Coriolis and other effects.
> Pole are "simple": expend on light, contract on darkness.
>
> Rain/clouds starting when hot wet air met colder area: either another
> cell/band or due to the local geography (such as an island or a
> mountain) or local albedo (rain forest is self-supporting, as long as
> its wet and dark... once the wood is gone, expect Sahara desert-like and
> no return: it could turn into Atacama)
>
> Also, a bit particular: nearly constant circular winds around Australia
> main mount.
> Not found on the other side of the planet. (but looks like Jupiter's
> stable whirl in south hemisphere)
>
> I probably miss a lot of influences too.

Yeah that's all generally correct, naturally there are other influences as you
said. Thing is though, not all the planets I will be doing cloud maps for are
Earth-like, otherwise I could simply use variations of Earth's, as the
developers of Vega-Strike have done wherever they can already. :)

Thanks for feedback/interest, :)

D103

Post a reply to this message

Ok, problems. :(

To generate a unique cloud map for each planet, I need to (among other things)
load the image map and normal map.

From these, I need to take samples along the x and y axis, and I don't know how
to do so. My first thought was the trace() function, but I don't know whether I
can get trace() to return the colour of the intersection.

Second problem, even if I can use trace(), this means that I have to have the
colour_maps in the scene in some form or another, and as the cloud_map is
partially transparent, this would mean that the other objects would appear in
the final render. :(

Perhaps I could get around this by using two scene files? Downside would be less
convenience, but if it's the only way...

Regards
D103

Post a reply to this message

On 16-4-2012 12:56, D103 wrote:
> Ok, problems. :(
>
> To generate a unique cloud map for each planet, I need to (among other things)
> load the image map and normal map.
>
>  From these, I need to take samples along the x and y axis, and I don't know how
> to do so. My first thought was the trace() function, but I don't know whether I
> can get trace() to return the colour of the intersection.
>
> Second problem, even if I can use trace(), this means that I have to have the
> colour_maps in the scene in some form or another, and as the cloud_map is
> partially transparent, this would mean that the other objects would appear in
> the final render. :(
>
> Perhaps I could get around this by using two scene files? Downside would be less
> convenience, but if it's the only way...
>
> Regards
> D103
>
>
If I understand you correctly, I think you should use eval_pigment() 
instead of trace().

Thomas

Post a reply to this message

Am 16.04.2012 12:56, schrieb D103:
> Ok, problems. :(
>
> To generate a unique cloud map for each planet, I need to (among other things)
> load the image map and normal map.
>
>  From these, I need to take samples along the x and y axis, and I don't know how
> to do so. My first thought was the trace() function, but I don't know whether I
> can get trace() to return the colour of the intersection.
>
> Second problem, even if I can use trace(), this means that I have to have the
> colour_maps in the scene in some form or another, and as the cloud_map is
> partially transparent, this would mean that the other objects would appear in
> the final render. :(
>
> Perhaps I could get around this by using two scene files? Downside would be less
> convenience, but if it's the only way...

Remember that you need to pass a #declare'd (or #local) object to 
trace(). Note that trace() only probes this single object, and that this 
object isn't visible in the scene unless you also instantiate it with 
"object{MyObjectVariable}". You could use this to trace() a height_field 
of the image.

trace() is comparatively slow for your purposes though. Instead, a 
better alternative is probably to define a "pigment function", which you 
can then directly evaluate to retrieve the pigment's color at any given 
point. The "functions.inc" macro "eval_pigment" encapsulates this in a 
simple macro:

#macro eval_pigment(pigm, vec)
     #local fn = function { pigment { pigm } }
     #local result = (fn(vec.x, vec.y, vec.z));
     result
#end

You pass it the pigment and the point to be evaluated, and will get a 
color value. (This is one of the few exceptions where functions may 
return colors rather than scalars.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Remember that you need to pass a #declare'd (or #local) object to
> trace(). Note that trace() only probes this single object, and that this
> object isn't visible in the scene unless you also instantiate it with
> "object{MyObjectVariable}". You could use this to trace() a height_field
> of the image.

Of course, why didn't I realise that... *shakes head at himself*

Thanks :D

>
> trace() is comparatively slow for your purposes though. Instead, a
> better alternative is probably to define a "pigment function", which you
> can then directly evaluate to retrieve the pigment's color at any given
> point. The "functions.inc" macro "eval_pigment" encapsulates this in a
> simple macro:
>
> #macro eval_pigment(pigm, vec)
>      #local fn = function { pigment { pigm } }
>      #local result = (fn(vec.x, vec.y, vec.z));
>      result
> #end

That looks exactly what I want. Many thanks clipka :)

>
> You pass it the pigment and the point to be evaluated, and will get a
> color value. (This is one of the few exceptions where functions may
> return colors rather than scalars.)

Probably why I haven't heard of it. ;)

So, a good way to read an image would be something like this?

Identify the image to pov with a #declare or #local, whichever is appropriate.
Pull the x and y resolutions from it using a function (I know there's one around
somewhere, can't find it at the moment).
Use a nested loop to write the values from the image to a two dimensional array.

From there, it's a simple thing to determine if the point in question is water,
or if not, how close to water it is. If the planet in use has no surface water,
then it would be a simple thing to add an "eval_pigment" to the macro, with a
conditional value which returns true or false depending, thus saving
computational time. :)

Any flaws?

Thanks for your time.

Regards
D103

Post a reply to this message

> clipka<ano### [at] anonymousorg>  wrote:
>>
>> Remember that you need to pass a #declare'd (or #local) object to
>> trace(). Note that trace() only probes this single object, and that this
>> object isn't visible in the scene unless you also instantiate it with
>> "object{MyObjectVariable}". You could use this to trace() a height_field
>> of the image.
>
> Of course, why didn't I realise that... *shakes head at himself*
>
> Thanks :D
>
>>
>> trace() is comparatively slow for your purposes though. Instead, a
>> better alternative is probably to define a "pigment function", which you
>> can then directly evaluate to retrieve the pigment's color at any given
>> point. The "functions.inc" macro "eval_pigment" encapsulates this in a
>> simple macro:
>>
>> #macro eval_pigment(pigm, vec)
>>       #local fn = function { pigment { pigm } }
>>       #local result = (fn(vec.x, vec.y, vec.z));
>>       result
>> #end
>
> That looks exactly what I want. Many thanks clipka :)
>
>>
>> You pass it the pigment and the point to be evaluated, and will get a
>> color value. (This is one of the few exceptions where functions may
>> return colors rather than scalars.)
>
> Probably why I haven't heard of it. ;)
>
> So, a good way to read an image would be something like this?
>
> Identify the image to pov with a #declare or #local, whichever is appropriate.
> Pull the x and y resolutions from it using a function (I know there's one around
> somewhere, can't find it at the moment).
> Use a nested loop to write the values from the image to a two dimensional array.
>
>  From there, it's a simple thing to determine if the point in question is water,
> or if not, how close to water it is. If the planet in use has no surface water,
> then it would be a simple thing to add an "eval_pigment" to the macro, with a
> conditional value which returns true or false depending, thus saving
> computational time. :)
>
> Any flaws?
>
> Thanks for your time.
>
> Regards
> D103
>
>

 From the documentations:

As of version 3.7 experimental support for reading the pixel resolution 
of an image map was added. This is done by giving an image map pigment 
identifier to max_extent(), which will then return the resolution of the 
image map as the x and y values of the returned vector.

Sample code:
#declare Image =
pigment {
   image_map {
     jpeg "YourImage.jpg"
     once
     }
   };

#declare Resolution = max_extent ( Image );

It return Resolution = <horizontal_size, vertical_size, 0>;



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> > ..........................
> > (I know there's one around
> > somewhere, can't find it at the moment).
> > ..........................

>
>  From the documentations:
>
> As of version 3.7 experimental support for reading the pixel resolution
> of an image map was added. This is done by giving an image map pigment
> identifier to max_extent(), which will then return the resolution of the
> image map as the x and y values of the returned vector.
>
> Sample code:
> #declare Image =
> pigment {
>    image_map {
>      jpeg "YourImage.jpg"
>      once
>      }
>    };
>
> #declare Resolution = max_extent ( Image );
>
> It return Resolution = <horizontal_size, vertical_size, 0>;
>
>
>
> Alain

That was indeed it. *feels embarrassed* :(

Thanks Alain, I didn't realise (not having actually used it ;) ) that
max_extent() returned a vector. This makes things a little easier.

Regards
D103

Post a reply to this message