> High!
>
> On 06/11/2010 09:57 PM, clipka wrote:
>
>> I still have no idea about the bright spots on the hills. At present, I
>> can only imagine that it's some precision problem with the isosurface.
>
> Increasing isosurface accuracy didn't help, I tried this earlier...
>
> See you in Khyberspace!
>
> Yadgar
>
> Now playing: Lichtermeer (Michael Rother)
>

By precision, I think that it's FP precision. I think that you are 
pushing the floating point calculations very close to it limits.

The planet is large, your position over it's surface is very low.


Alain

Post a reply to this message

High!

On 06/12/2010 08:26 PM, Alain wrote:

> By precision, I think that it's FP precision. I think that you are
> pushing the floating point calculations very close to it limits.
>
> The planet is large, your position over it's surface is very low.

So the only way would be to scale the whole scene by 10 or 100?

See you in Khyberspace!

Yadgar

Post a reply to this message

news:4c140029$1@news.povray.org...
> High!
>
> On 06/12/2010 08:26 PM, Alain wrote:
>
>> By precision, I think that it's FP precision. I think that you are
>> pushing the floating point calculations very close to it limits.
>>
>> The planet is large, your position over it's surface is very low.
>
> So the only way would be to scale the whole scene by 10 or 100?
>

I am afraid that you cannot have the best of two worlds, or like they say in 
French: "To have the butter, and the money for the butter"  ;-)
Zooming in close to a modelled planet pushes your possibilities to the 
extreme and scaling your scene would not help. My advice for the groundlevel 
landscape would be to model a scene totally separated from the planet model 
itself but in accordance with its character of course. If you want to zoom 
in from planet-wide view to groundlevel-wide view in an animation, you will 
have to find a way to merge from one to the other in a satisfactory way.

Thomas

Post a reply to this message

> High!
>
> On 06/12/2010 08:26 PM, Alain wrote:
>
>> By precision, I think that it's FP precision. I think that you are
>> pushing the floating point calculations very close to it limits.
>>
>> The planet is large, your position over it's surface is very low.
>
> So the only way would be to scale the whole scene by 10 or 100?
>
> See you in Khyberspace!
>
> Yadgar

No. The problem is not the location nor the planet itself, BUT the 
location AND the dimention of the planet.
You have very small distances with very large object. That's the 
problem: the /range/ of the scales.

One way that you could possibly work around would be, when you get close 
enough to the geound that the planetary curvature becomes barely 
perceptible, to switch to a limited, flat-world, version of the planet. 
The part beyond the horizon can then be totaly droped, or replaced by a 
large sphere located totaly under and out of view WHEN it can have an 
effect on the scene. You may also be able to use a simple disk for that. 
The function of that disk would only be to provide a shadow for the media.


Alain

Post a reply to this message

High!

On 06/13/2010 04:42 PM, Alain wrote:

> No. The problem is not the location nor the planet itself, BUT the
> location AND the dimention of the planet.
> You have very small distances with very large object. That's the
> problem: the /range/ of the scales.
>
> One way that you could possibly work around would be, when you get close
> enough to the geound that the planetary curvature becomes barely
> perceptible, to switch to a limited, flat-world, version of the planet.
> The part beyond the horizon can then be totaly droped, or replaced by a
> large sphere located totaly under and out of view WHEN it can have an
> effect on the scene. You may also be able to use a simple disk for that.
> The function of that disk would only be to provide a shadow for the media.

So even converting a, let's say 1 by 1 degree slice of the isosurface 
into a mesh2 and than using only this comparatively small (900 by 900 
vertices) mesh2 instead of the whole isosurface won't help?

See you in Khyberspace!

Yadgar

Post a reply to this message

> High!
>
> On 06/13/2010 04:42 PM, Alain wrote:
>
>> No. The problem is not the location nor the planet itself, BUT the
>> location AND the dimention of the planet.
>> You have very small distances with very large object. That's the
>> problem: the /range/ of the scales.
>>
>> One way that you could possibly work around would be, when you get close
>> enough to the geound that the planetary curvature becomes barely
>> perceptible, to switch to a limited, flat-world, version of the planet.
>> The part beyond the horizon can then be totaly droped, or replaced by a
>> large sphere located totaly under and out of view WHEN it can have an
>> effect on the scene. You may also be able to use a simple disk for that.
>> The function of that disk would only be to provide a shadow for the
>> media.
>
> So even converting a, let's say 1 by 1 degree slice of the isosurface
> into a mesh2 and than using only this comparatively small (900 by 900
> vertices) mesh2 instead of the whole isosurface won't help?
>
> See you in Khyberspace!
>
> Yadgar

It can help, if you also shift the scene toward the origin to restrict 
the effective range of values.

You can still use the isosurface, in a much smaller containing object.


Alain

Post a reply to this message

High!

On 06/14/2010 06:32 PM, Alain wrote:

> You can still use the isosurface, in a much smaller containing object.

No, this does not work - if I try to constrain the isosurface to a 
sphere rotated to the chosen camera position (in geographical 
coordinates), such as:

     isosurface
     {
       function { Terrain_Function(x, y, z) }
       contained_by
       {
	sphere
	{
	  <0, 15, 0>/5178, <20, 25, 20>/5178
	  rotate <0, 0, 90-lat>
	  rotate <0, -long+90, 0>
	  translate <sin(radians(-long))*cos(radians(lat)), sin(radians(lat)), 
cos(radians(-long))*cos(radians(lat))>
	}
       }
       max_gradient 5
       accuracy 0.0001
       double_illuminate
       texture { T_Ghurghusht }
       scale 5178
     }

// end of code

I get error messages like "rotate found instead"... the container sphere 
may not even scaled non-uniformly!

See you in Khyberspace!

Yadgar

Post a reply to this message

> High!
>
> On 06/14/2010 06:32 PM, Alain wrote:
>
>> You can still use the isosurface, in a much smaller containing object.
>
> No, this does not work - if I try to constrain the isosurface to a
> sphere rotated to the chosen camera position (in geographical
> coordinates), such as:
>
> isosurface
> {
> function { Terrain_Function(x, y, z) }
> contained_by
> {
> sphere
> {
> <0, 15, 0>/5178, <20, 25, 20>/5178
> rotate <0, 0, 90-lat>
> rotate <0, -long+90, 0>
> translate <sin(radians(-long))*cos(radians(lat)), sin(radians(lat)),
> cos(radians(-long))*cos(radians(lat))>
> }
> }
> max_gradient 5
> accuracy 0.0001
> double_illuminate
> texture { T_Ghurghusht }
> scale 5178
> }
>
> // end of code
>
> I get error messages like "rotate found instead"... the container sphere
> may not even scaled non-uniformly!
>
> See you in Khyberspace!
>
> Yadgar
>
>
I was thinking of a box that you can set to any arbitrary dimention. 
Very often, the sphere is very far from the best container.

Bottom just under the lowest part of the ground.
Top at the maximum hight in the area.
Depth and width acording to where you are situated and what part is 
likely to be visible.

If you still want to use a sphere, apply the rotation to the center 
using v_rotate(), then, if needed, add any translation also to the 
center itself.

sphere{vrotate(v_rotate(<0, 15, 0>/5178,rotate <0, 0, 90-lat>),<0, 
-long+90, 0>)+<sin(radians(-long))*cos(radians(lat)), 
sin(radians(lat)),cos(radians(-long))*cos(radians(lat))> , <20, 25, 
20>/5178}
Should be equivalent to your case.



Alain

Post a reply to this message

High!

On 06/16/2010 06:25 PM, Alain wrote:
>
> sphere{vrotate(v_rotate(<0, 15, 0>/5178,rotate <0, 0, 90-lat>),<0,
> -long+90, 0>)+<sin(radians(-long))*cos(radians(lat)),
> sin(radians(lat)),cos(radians(-long))*cos(radians(lat))> , <20, 25,
> 20>/5178}
> Should be equivalent to your case.

It still doesn't work... contained_by does not accept any rotate or 
translate statements! At least it's that way with 3.6...

See you in Khyberspace!

Yadgar

Post a reply to this message

> High!
>
> On 06/16/2010 06:25 PM, Alain wrote:
>>
>> sphere{v_rotate(v_rotate(<0, 15, 0>/5178,rotate <0, 0, 90-lat>),<0,
>> -long+90, 0>)+<sin(radians(-long))*cos(radians(lat)),
>> sin(radians(lat)),cos(radians(-long))*cos(radians(lat))> , <20, 25,
>> 20>/5178}
>> Should be equivalent to your case.
>
> It still doesn't work... contained_by does not accept any rotate or
> translate statements! At least it's that way with 3.6...
Did not change with 3.7 to my knowlege.
>
> See you in Khyberspace!
>
> Yadgar
Oups, forgot to remove a rotate in the macro call. Also, there is a 
superfluous underscore "_".

sphere{vrotate(vrotate(<0, 15, 0>/5178,<0, 0, 90-lat>),<0, -long+90, 
0>)+<sin(radians(-long))*cos(radians(lat)), 
sin(radians(lat)),cos(radians(-long))*cos(radians(lat))> , <20, 25, 
20>/5178}

That long location statement is meant to replace your translate and rotates.
The v_rotate() macro replace the rotations.
Everything between the "+" and the radius replace your translate.

Don't forget to remove those:
rotate <0, 0, 90-lat>
rotate <0, -long+90, 0>
translate <sin(radians(-long))*cos(radians(lat)), sin(radians(lat)),
cos(radians(-long))*cos(radians(lat))>



Alain

Post a reply to this message