I tried some magic with inside() and isosurface, but povray does not 
like even the simplest terms involving the inside() function, see 
attached scene file snippet:

---<snip>---
==== [Parsing...] ===================================================
File 'bugreport.pov' line 6: Parse Error: Expected 'operand', object 
identifier found instead
Fatal error in parser: Cannot parse input.
Render failed
----<snap>----

I ask a search engine and found the same bug reported already many eons 
ago, but without useful replies, e.g. from 2010:

http://news.povray.org/povray.advanced-users/message/%3Cweb.4c7d7306e632d53a274f74a20%40news.povray.org%3E/

or from 2002:

https://news.povray.org/povray.newusers/thread/%3C083umu8qdb1gjq1o9nr1kjtlp0s93a3peq%404ax.com%3E/


Is it a bug in povray, can you reproduce it? Or am I holding it wrong?

		Lars

Post a reply to this message

Attachments:
Download 'bugreport.pov.txt' (1 KB)

On 2025-05-27 19:27 (-4), Lars Rohwedder wrote:
> I tried some magic with inside() and isosurface, but povray does not
> like even the simplest terms involving the inside() function, see
> attached scene file snippet:
> 
> ---<snip>---

I think ABX hinted at the answer in the 2002 thread: inside() is not
listed in the syntax diagram for user-defined functions.  The
documentation reads, "only float functions that apply to float values
may be used," but inside()'s arguments are not floats.

https://wiki.povray.org/content/Reference:Function

Post a reply to this message

On 5/27/25 20:06, Cousin Ricky wrote:
> On 2025-05-27 19:27 (-4), Lars Rohwedder wrote:
>> I tried some magic with inside() and isosurface, but povray does not
>> like even the simplest terms involving the inside() function, see
>> attached scene file snippet:
>>
>> ---<snip>---
> 
> I think ABX hinted at the answer in the 2002 thread: inside() is not
> listed in the syntax diagram for user-defined functions.  The
> documentation reads, "only float functions that apply to float values
> may be used," but inside()'s arguments are not floats.
> 
> https://wiki.povray.org/content/Reference:Function
> 

Adding to that:

//---
#version 3.7;

#declare V = <1,2,3>;
#declare OBJ = torus { 5,1 }

// #declare F = function { inside(OBJ, V) }
    #declare F = function { pattern { object { OBJ } } }

plane { -z, 0
     pigment { function { F(x,y,z) } }
     finish { emission 1 }
}
#declare Cam = camera {}
camera { Cam translate -20*z}
//---

Bill P.

Post a reply to this message

On 28.05.2025 01:27, Lars Rohwedder wrote:
> 
>
https://news.povray.org/povray.newusers/thread/%3C083umu8qdb1gjq1o9nr1kjtlp0s93a3peq%404ax.com%3E/
> 
> Is it a bug in povray, can you reproduce it? Or am I holding it wrong?

Well, if you had decided to read the whole thread instead of just some 
random message in it, you would already have found the answer yourself:

https://news.povray.org/povray.advanced-users/thread/%3Cweb.4c608fec6babf39befdd5d0%40news.povray.org%3E/?mtop=350184&moff=10

Post a reply to this message

Lars Rohwedder <rok### [at] gmxde> wrote:
> I tried some magic with inside() and isosurface, but povray does not
> like even the simplest terms involving the inside() function,


inside () never got implemented in the function virtual machine, so:

Use an object pigment pattern in your function instead:

function {
     pigment{
          object{
               MyObject
               rgb 0 // outside
               rgb 1 // inside
          }
     }
}

Then the result of your "inside" test will be the rgb value.

- BE

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Adding to that:
>
> //---
> #version 3.7;
>
> #declare V = <1,2,3>;
> #declare OBJ = torus { 5,1 }
>
> // #declare F = function { inside(OBJ, V) }
>     #declare F = function { pattern { object { OBJ } } }
>
> plane { -z, 0
>      pigment { function { F(x,y,z) } }
>      finish { emission 1 }
> }

So, by moving the z plane in increments-- as 2-D slices-- we get a nice *visual*
representation of which parts of the torus are 'inside' or 'outside'.

But can the V vector here still be used in some way-- with the object
*function*-- to determine if that particular point is inside/outside? (I admit
that I have trouble understanding some of the subtleties and limitations of
function use.)

I tried two naive tests, but both resulted in fatal parse errors for one reason
or another:

1) As a purely visual test, to see if the plane object would appear either fully
white or fully black:
plane { -z, 0
     pigment { function { F(V.x,V.y,V.z) } }
      finish { emission 1 }
}

2)
#if(inside(F(x,y,z),V))
// -- do something--
#else
#end

In one of the old posts mentioned previously (from 2010), Thorsten posted the
following...although I might be taking his remarks out of context:

> As you can see, "inside" is not in the list of built-in functions for use in
> "function" statements.
>
> However, you can still access an object inside a function by using the object
> pattern. This works because you can declare pattern functions...

I'm not sure what 'access' means... but does it imply that there *is* a way to
use the V vector in the example here?

Post a reply to this message

On 5/31/25 06:10, Kenneth wrote:
> But can the V vector here still be used in some way-- with the object
> *function*-- to determine if that particular point is inside/outside? (I admit
> that I have trouble understanding some of the subtleties and limitations of
> function use.)

As always, a good job asking deeper questions, Kenneth. :-)

In the function{} body context we cannot use vectors(*) which means 
there are some situations, like function{} block use in pigment{} blocks 
where we must - in the parser, parse-time, context - escape the 
function{} body context in ugly-ish ways to access vectors over time.

Hopefully the updated SDL is of more help.

//---
#version 3.7;

#declare V = <1,2,3>;
#declare OBJ = torus { 5,1 }

//  #declare F = function { inside(OBJ, V) }
     #declare F = function { pattern { bool_object { OBJ } } }
     #declare F_inside = function { pattern { bool_object { OBJ } } }

     #declare ValZeroOROne = F(V.x,V.y,V.z);
//  #if (ValZeroOROne=0)
     #if (!F(V.x,V.y,V.z))
         #declare AnsStr = "outside"
     #else
         #declare AnsStr = "inside"
     #end

     #declare Vx = V.x;
     #declare Vy = V.y;
     #declare Vz = V.z;
//  #declare F2 = function { F(V.x,V.y,V.z) } // Illegal.
     #declare F2 = function { F(Vx,Vy,Vz) }    // OK

     #declare F3 = function (x,y,z) {
         // Ugly way to fixed, parse time float arguments
         // in a function{} block context
         F(#local X=V.x;X*x, #local Y=V.y; Y*y, #local Z=V.y;Z*z)
         #undef X #undef Y #undef Z
     }

     #declare F4 = function (x,y,z,X,Y,Z) {
         F(X*x,Y*y,Z*z)
     }

     #declare tmpVal = F(V.x,V.y,V.z);        // OK
     #declare tmpVal = F_inside(V.x,V.y,V.z); // OK  (**)
     #declare tmpVal = F4(V.x,V.y,V.z,1,1,1); // OK
     #declare tmpVal = F4(1,1,1,V.x,V.y,V.z); // OK

plane { -z, 0
//  pigment { function { F(x,y,z) } }
//  pigment { function { F2(x,y,z) } }
     pigment {
         function { // Ugly way to parse time-fixed, function
                    // context, float arguments
             F(#local X=V.x;X,
               #local Y=V.y;Y,
               #local Z=V.y;Z) #undef X #undef Y #undef Z
         }
     }
     finish { emission 1 }
}
#declare Cam = camera {}
camera { Cam translate -20*z}

#debug concat ("==> The test point V is ",AnsStr," <==\n")

Bill P.

(*) The yuqk fork implemented a limited ability to use 32bit 2D vectors 
and 21bit 3D vectors by encoding them in the 64bit float space the VM 
function mechanism supports, but that's more of a FWIW thing.

(**) A long time ago I ran across some SDL which defined an Inside() 
user function which was essentially F_inside(). If others saw this too, 
or mention of it exists somewhere in the forums etc., it might be 
contributing some to the confusion.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> As always, a good job asking deeper questions, Kenneth. :-)
>

I never know if my questions are deeper-- or just crazy and uninformed, ha!

THANKS for your *multiple* examples of how to incorporate the V vector here.
Bald Eagle has been trying to 'enlighten' me for years as to the finer points of
writing user-defined functions, which are not my forte; but between the two of
you, I might just learn something!

Using several of your syntax examples, my two previously-failed function tests
work successfully now:

1) To get a visual indication on the z-plane of whether the V point is 'inside
or outside' the torus-as-object-pattern-function. (The plane will either be
totally black or totally white, due to the function's 'pattern' having two
default colors):

#declare Vx = V.x;
     #declare Vy = V.y;
     #declare Vz = V.z;
     #declare F2 = function { F(Vx,Vy,Vz) }
plane{-z,0
pigment { function {F2(Vx,Vy,Vz)}}
 finish{emission 1}
 }

I tested this with an animation, by varying the V-vector values. Of course, if I
move the z-plane from z=0 , the visual result will no longer exactly correspond
to the fixed position of the torus, which  is centered on <0,0,0>.

2) Far more useful! (This #if works because the two default colors of the
pattern function are pure black and white-- corresponding to boolean 0 and 1.)

 #if (!F(V.x,V.y,V.z))
         #declare AnsStr = "outside"
         #else
         #declare AnsStr = "inside"
 #end

#debug concat ("==> The test point V is ",AnsStr," <==\n")

-----------
By the way, one of your function examples was initially a mystery to me, because
I had never seen one like it:

declare F3 = function (x,y,z) {
         // Ugly way to fixed, parse time float arguments
         // in a function{} block context
         F(#local X=V.x;X*x, #local Y=V.y; Y*y, #local Z=V.y;Z*z)
         #undef X #undef Y #undef Z
     }

It finally occurred to me that each argument in the function is like a
'shorthand' version of:

#local X=V.x;
then...
X*x

I didn't know that values could be declared ( #local'ed here) *within* a
function statement, then immediately used.  Another new discovery! ;-)

Post a reply to this message