POV-Ray : Newsgroups : povray.advanced-users : Is an AOI function possible? Server Time
15 Oct 2024 17:04:37 EDT (-0400)
  Is an AOI function possible? (Message 1 to 3 of 3)  
From: Cousin Ricky
Subject: Is an AOI function possible?
Date: 13 Apr 2024 13:18:32
Message: <661abe68$1@news.povray.org>
Is it possible to vary a texture by AOI according to a function, rather
than by a texture list?  I don't see anything in the aoi syntax diagrams
that allows this, but it would be nice to know if I missed something.


Post a reply to this message

From: William F Pokorny
Subject: Re: Is an AOI function possible?
Date: 14 Apr 2024 14:50:38
Message: <661c257e$1@news.povray.org>
On 4/13/24 13:18, Cousin Ricky wrote:
> Is it possible to vary a texture by AOI according to a function, rather
> than by a texture list?  I don't see anything in the aoi syntax diagrams
> that allows this, but it would be nice to know if I missed something.

The 'texture list' wording confuses me. Did you mean texture map?

I believe the short answer is no and that you see the situation correctly.

Bill P.


---
A longer answer is that you can get past the parser's checks which 
prevent the usual direct pattern{} wrap of the aoi pattern.

The parser prevents:

//  #declare Fn02 = function { pattern { aoi } }  // Illegal

The following or, a similar non-yuqk form of it for official POV-Ray, 
slips by the parser checks and runs:

     #declare Pg03 = pigment {
         aoi function_interval
         color_map { [-1 color 0] [+1 color +1] }
     }
     #declare Fn03 = function {
         pigment {
             pigment_pattern { Pg03 }
         }
     }
     #declare Pg99 = pigment { function { Fn03(x,y,z).red } }

However, it does no good because the ray and perturbed normals are not
available via the function route - and so a 0.0 value is always returned 
(.red is always 0.5 above).

FWIW. It is on the yuqk fork's todo list to implement an 'information' 
pattern which, rather than being a true scalar value pattern, will 
return 21 bit float encoded, 3 component vectors for things like ray 
direction, raw and perturbed normals. With this information you'd be 
able to build up user 'aoi' functions of your own for surfaces.

The yuqk fork today has an inbuilt f_normal() function which can be 
employed to determine the raw normal in a value field in a way matching 
that done for isosurfaces. So in limited situations where you might know 
the ray direction (orthographic camera, parallel light rays, ...) and 
have well behaved isosurface shapes or pattern value fields (media), you 
might be able to implement certain 'aoi' like functions today in the 
yuqk fork.

There is the slope pattern which might help depending on what you want 
to do, but it too has function usage constraints.


Post a reply to this message

From: Cousin Ricky
Subject: Re: Is an AOI function possible?
Date: 14 Apr 2024 17:34:28
Message: <661c4be4$1@news.povray.org>
On 2024-04-14 14:50 (-4), William F Pokorny wrote:
> On 4/13/24 13:18, Cousin Ricky wrote:
>> Is it possible to vary a texture by AOI according to a function, rather
>> than by a texture list?  I don't see anything in the aoi syntax diagrams
>> that allows this, but it would be nice to know if I missed something.
> 
> The 'texture list' wording confuses me. Did you mean texture map?

Yes, that is what I meant.  I was thinking the list of textures that go
into a texture_map.

> I believe the short answer is no and that you see the situation correctly.

Thanks.

> There is the slope pattern which might help depending on what you want
> to do, but it too has function usage constraints.

No, the slope pattern is definitely not what I'm looking for.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.