Consider this prism

  prism {
    linear_sweep
    cubic_spline
    0, 1, 18,
    <3,-5>, <3,5>, <-5,0>, <3, -5>, <3,5>, <-5,0>,
    <2,-4>, <2,4>, <-4,0>, <2,-4>, <2,4>, <-4,0>,
    <1,-3>, <1,3>, <-3,0>, <1, -3>, <1,3>, <-3,0>
    pigment { color rgb<0,1,0> }
  }

I want to draw the biggest sphere with the centre of <0,0,0> which can fit
within the inner part of the prism (not the whole prism; and then, min_extent
and max_extent are useless here).

Is there a direct way to do so?

I came with an idea to check a set of spheres in a loop,

  #local i = 0.1;
  #while(i<1000)
    #if(CONDITION)
      sphere{<0,0,0>,1.8 pigment{color rgb<1,1,1>}}
      #break
    #end
  #local i = i+0.1;
  #end

I need the CONDITION.

Since we should run this test in a loop, the performance is of utmost
importance.

Note that y-axis is not important here. We can draw the prism from -1000 to 1000
and find the biggest sphere, which is not visible from outside.

Post a reply to this message

I correct a typo in my loop:

  #local i = 0.1;
  #while(i<1000)
    #if(CONDITION)
      sphere{<0,0,0>,i }
      #break
    #end
  #local i = i+0.1;
  #end

Post a reply to this message

"Kima" <nomail@nomail> wrote:

> I want to draw the biggest sphere with the centre of <0,0,0> which can fit
> within the inner part of the prism

> Is there a direct way to do so?

This would be the inscribed circle, or the inscribed sphere.
You might be able to do it with a matrix, but I'm guessing.

You could do it numerically / computationally / algorithmically by taking sets
of adjacent vertices, calculating the coordinates of the midpoint, and measuring
the distance from the origin.   The minimum distance would give you what you
want.


> I need the CONDITION.

Do you just want to do an insidedness test?
#if (inside (prism, point)) ....

If you want to have each sphere be fully inside the prism, construct a smaller
test prism where the edges are closer to the origin by the radius of the
spheres.   Test against that, and then render the spheres in the actual prism.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> > I need the CONDITION.
>
> Do you just want to do an insidedness test?
> #if (inside (prism, point)) ....
>
> If you want to have each sphere be fully inside the prism, construct a smaller
> test prism where the edges are closer to the origin by the radius of the
> spheres.   Test against that, and then render the spheres in the actual prism.

For using the "inside" function, I should test all the points on the sphere. And
then, it will check the entire prism, not the visible part.

Post a reply to this message

On 6/12/20 1:31 PM, Bald Eagle wrote:
> 
> "Kima" <nomail@nomail> wrote:
> 
>> I want to draw the biggest sphere with the centre of <0,0,0> which can fit
>> within the inner part of the prism
> 
>> Is there a direct way to do so?
> 
> This would be the inscribed circle, or the inscribed sphere.
> You might be able to do it with a matrix, but I'm guessing.
> 
> You could do it numerically / computationally / algorithmically by taking sets
> of adjacent vertices, calculating the coordinates of the midpoint, and measuring
> the distance from the origin.   The minimum distance would give you what you
> want.
> 
> 
>> I need the CONDITION.
> 
> Do you just want to do an insidedness test?
> #if (inside (prism, point)) ....
> 
> If you want to have each sphere be fully inside the prism, construct a smaller
> test prism where the edges are closer to the origin by the radius of the
> spheres.   Test against that, and then render the spheres in the actual prism.
> 
> 
I don't think there is any general approach other than sampling.

As Bald Eagle suggested, inside prism tests around the circle after each 
growth/shrink.

Or you could fire of a sample set of trace()s from the circle origin 
outward (toward the prism's, circle containing, inside surface), taking 
the smallest ray length found as your circle's radius. No grow/shrink 
search with the latter approach.

Sampling though, so a perfectly inscribed you might not get...

Bill P.

Post a reply to this message

Le 12/06/2020 à 16:38, Kima a écrit :
> Consider this prism
> 
>   prism {
>     linear_sweep
>     cubic_spline
>     0, 1, 18,
>     <3,-5>, <3,5>, <-5,0>, <3, -5>, <3,5>, <-5,0>,
>     <2,-4>, <2,4>, <-4,0>, <2,-4>, <2,4>, <-4,0>,
>     <1,-3>, <1,3>, <-3,0>, <1, -3>, <1,3>, <-3,0>
>     pigment { color rgb<0,1,0> }
>   }
> 
> I want to draw the biggest sphere with the centre of <0,0,0> which can fit
> within the inner part of the prism (not the whole prism; and then, min_extent
> and max_extent are useless here).
> 
> Is there a direct way to do so?

Wrong approach and wrong specification.

The radius of the sphere at 0 which can fit inside the inner prism is 0.

Because a prism extend between the planes y=0 and y=1.

If we ignore that point to return to the basic problem, it is easier to
sample the inner prism by isolating it via a spline.

==================

#version 3.7;
global_settings{ assumed_gamma 1.0 }
#default{ finish { emission 0.5 diffuse 0.5 } }

camera { orthographic
  location -90*y
  up z
  right -image_width/image_height*x
  look_at 0
  angle 12.5
}

  prism {
    linear_sweep
    cubic_spline
    0, 1, 18,
    <3,-5>, <3,5>, <-5,0>, <3, -5>, <3,5>, <-5,0>,
    <2,-4>, <2,4>, <-4,0>, <2,-4>, <2,4>, <-4,0>,
    <1,-3>, <1,3>, <-3,0>, <1, -3>, <1,3>, <-3,0>
    pigment { color rgb<0,1,0> }
  }

light_source { <-1,-1,0.5>*40, 1 }
#declare Sp=spline { cubic_spline

-1, <1,-3>,
0, <1,3>,
1, <-3,0>,
2,<1, -3>,
3, <1,3>,
4, <-3,0>
}
#declare LOWEST = 10;// big enough to start
#for(i,0,3,0.01)
#local Pt = <Sp(i).x, 0, Sp(i).y> ;
#local LENGTH=vlength(Pt);
#declare LOWEST=min(LOWEST,LENGTH);
#end
#debug concat("\nLargest radius of fitting cylinder is ",
str(LOWEST,3,3), "\n")

sphere { 0,LOWEST pigment { color red 1 } }

Post a reply to this message

On 6/13/20 9:31 AM, Le_Forgeron wrote:
> Le 12/06/2020 à 16:38, Kima a écrit :
...
> #declare LOWEST = 10;// big enough to start
> #for(i,0,3,0.01)
> #local Pt = <Sp(i).x, 0, Sp(i).y> ;
> #local LENGTH=vlength(Pt);
> #declare LOWEST=min(LOWEST,LENGTH);
> #end
> #debug concat("\nLargest radius of fitting cylinder is ",
> str(LOWEST,3,3), "\n")
> 
> sphere { 0,LOWEST pigment { color red 1 } }
> 

Ah. Excellent idea/method!

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Ah. Excellent idea/method!
>
> Bill P.

It is.   I frequently forget at first the interoperability of splines and
prisms.
Way more elegant than my suggestion.

A few points:

Directly:
1.  Does the code as pasted give the desired result?  I made an array of all 18
points and used those in a spline, and I got a larger sphere (r = 3.701) that
touches the outer part of the prism.



Only tangentially related:

2. It would be nice for prism{} to accept an array as an argument directly, and
for it to select the x, z coordinates from a vector with greater than 2 elements
/ components.

With regard to names / syntax (recent commentary/questions about #declare /
#undef, and rewriting things in povr has my mind in that mode):

Why do we have # before things like for, etc. and not others?
dimension_size is "long" and I find awkward to remember.  array_size, size_of,
or something like that would be a nice alternative.

Inside of various declarations, I often add an extra comma, so if I were coding
Jerome's scene, I will frequently write
sphere {0, LOWEST, pigment {color red 1 }}
                 ^
and POV-Ray does not like that.
I believe there are a few other places where extra commas generate an error that
prevents rendering - I will try to be mindful of those and point them out.

Post a reply to this message

Le 13/06/2020 à 20:20, Bald Eagle a écrit :
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Ah. Excellent idea/method!
>>
>> Bill P.
> 
> It is.   I frequently forget at first the interoperability of splines and
> prisms.
> Way more elegant than my suggestion.
> 
> A few points:
> 
> Directly:
> 1.  Does the code as pasted give the desired result?  I made an array of all 18
> points and used those in a spline, and I got a larger sphere (r = 3.701) that
> touches the outer part of the prism.
> 
> 

Nope, because spline does not support loops which cause prism to have
more than one part. You have to identify the inner loop, then you can
use spline.

Not seen in posted code, inside the for-loop, I also drawn a tiny sphere
at Pt to check it did follow the perimeter of the prism.

Also, if you used a spline for the 18 points, did you adjust the range
of the for-loop ?

Post a reply to this message

On 6/13/20 2:20 PM, Bald Eagle wrote:
> 
...
> 
> A few points:
> 
> Directly:
> 1.  Does the code as pasted give the desired result?  I made an array of all 18
> points and used those in a spline, and I got a larger sphere (r = 3.701) that
> touches the outer part of the prism.
> 
Le_Forgeron was careful to exclude the control points and use only the 
inner loop, but seems like using all points would work in this 
particular case...

My first guess would be not all the points were walked in your case - 
that you perhaps left the for loop end the same? Supposing you have the 
loop start and end right, the second guess would be there is something 
going on when there are loops within loops. This certainly not the 
normal set up when walking a spline.

> With regard to names / syntax (recent commentary/questions about #declare /
> #undef, and rewriting things in povr has my mind in that mode):
> 
> Why do we have # before things like for, etc. and not others?

I don't know the history. In the parser there is code forcing it where 
not there depending on the version setting (declare keyword IIRC is 
one). Of late I think Christoph was pushing toward only language control 
needing the # prefix, but guessing some there based upon particular 
corrections from him. Mostly, the parser treats the # as a space. It can 
be there or not. This is something which trips me up pretty often 
because I code a lot in tcl and bash where a leading # indicates a comment.

Not tried it, but wonder if I took scenes and just stripped all the 
'#'s, if they'd would work? If so, maybe we just make '#'s all illegal 
to get consistency?

> dimension_size is "long" and I find awkward to remember.  array_size, size_of,
> or something like that would be a nice alternative.

I don't know, I think dimension_size is more descriptive of what it does.

> 
> Inside of various declarations, I often add an extra comma, so if I were coding
> Jerome's scene, I will frequently write
> sphere {0, LOWEST, pigment {color red 1 }}
>                   ^
> and POV-Ray does not like that.
> I believe there are a few other places where extra commas generate an error that
> prevents rendering - I will try to be mindful of those and point them out.
> 

I have a hypothesis we are supposed to be using fewer commas, not more.

Remember when in maps - or splines? - someone complained about commas 
being needed in some places and not others? Also having to have some 
commas, but not with the last item etc.

Christoph did something in v38 so the commas are now less often required 
- or illegal - they can now mostly be there or not. The changes, 
perhaps, encourage us to think they can be used, or not, most everywhere.

In the parser code there is a bit of code used specifically to look for 
commas for certain keywords. I suspect this got updated to accept spaces 
(no comma token/optional) - or, it always worked this way and he added 
calls to it in more places. For commas to be ignored the parser needs to 
call that code. It must look for a comma to ignore it, and in many 
places where spaces only have long worked, it - today - does not.

This gets us to intended best practice given his changes, which I 
believe, is a continuing push toward fewer commas everywhere, not more. 
Meaning for spheres we want to encourage: sphere { 0 1 pigment... } usage.

I too still tend to insert the comma and a space between the 0 and 1 
above - and in many other places - because I long have. I believe for 
quite some long time, it's just been an extra character if you already 
have a space. A character which needs to be parsed.

Aside: Our documentation still shows commas everywhere and in only a few 
places commas as optional. For example, the prism in this discussion I 
believe will run fine if you turn all the commas not inside the point <> 
vectors (commas are needed there due the negative values) to spaces.

What I've not done is to systematically test not using commas. Are there 
still constructs after Christoph's recent changes where they are still 
needlessly forced or illegal?

Anyway... My take.

Bill P.

Post a reply to this message