povray.newusers message digest

[Kenneth] Re: arbitrary camera path in animation [76 days 4 hours and 55 minutes ago]

Mon, 26 Jan 2026 18:05:00 GMT

Anton Sherwood <bro### [at] poboxcom> wrote:
> >
> > Can I define an array of points and have the camera shoot from each of them?
>
> .. oh i think i found it in the docs.

Did you find the Spline_Trans(...) macro, in 'transforms.inc'?

That is what I would use. It takes a spline--made from your designated points--
then the macro is used in a camera, which will follow the spline.

There is a nice animated demonstration scene included with POV-ray, called
'splinefollow.pov', in scenes\animations. Take a look.

[Anton Sherwood] Re: arbitrary camera path in animation [76 days 18 hours and 41 minutes ago]

Mon, 26 Jan 2026 04:18:47 GMT

>> On 2026-01-25 12:04, Anton Sherwood wrote:
 >>> The mesh for the attached image was generated by a program.  I would
 >>> like to make a simple animation with the camera following the path.
 >>>
 >>> Can I define an array of points and have the camera
 >>> shoot from each of them?

(I don't remember ever using an array before in povray)


On 2026-01-25 13:35, Leroy wrote:
 > It all depends on the program that wrote the mesh and what values
 > you have access to. [...]

Ah, well, I wrote the program, so I have whatever access I want.
(It's a special-purpose program, not a general modeller.)


 > I noticed that the mesh intersects itself a lot and the camera
 > could run into it if care is not taken.

I'll take points in the middle of the 'beams' (which are generated 
first) and double them to get the camera positions.


 > I wrote this up and hit preview and it kicked me out.
 > So I came back and this:

 > Anton Sherwood <bro### [at] poboxcom> wrote:
 >> .. oh i think i found it in the docs.

 > I'm posting this any way!  Sorry, I hate to waste typing!

May it be of use to someone!


-- 
*\\* Anton Sherwood *\\* bendwavy.org

[Leroy] Re: arbitrary camera path in animation [77 days 1 hour and 20 minutes ago]

Sun, 25 Jan 2026 21:40:00 GMT

Anton Sherwood <bro### [at] poboxcom> wrote:
> On 2026-01-25 12:04, Anton Sherwood wrote:
> > The mesh for the attached image was generated by a program.  I would
> > like to make a simple animation with the camera following the path.
> >
> > Can I define an array of points and have the camera shoot from each of them?
>

It all depends on the program that wrote the mesh and what values you have
access to. It also depends on how good you want the simple animation to be.
 If it was wrote with a spline and you have access to it. It wouldn't be much
trouble to make your own spline to move the camera while looking at the old
spline.
 If the mesh was made with a function again if you have access you could make an
array of points that can be use.
 If all you have is the mesh then finding those points you want maybe a little
difficult. But not impossible. It all depends on how the mesh was made. If the
mesh is a POV mesh2 then all the point are in one place and you could go through
them and throw away all but the ones you need. A lot of work but could be done.

I noticed that the mesh intersects itself a lot and the camera could run into it
if care is not taken.

Have Fun!

I wrote this up and hit preview and it kicked me out. So I came back and this:
> .. oh i think i found it in the docs.
I'm posting this any way!  Sorry, I hate to waste typing!

[Anton Sherwood] Re: arbitrary camera path in animation [77 days 2 hours and 28 minutes ago]

Sun, 25 Jan 2026 20:31:44 GMT

On 2026-01-25 12:04, Anton Sherwood wrote:
> The mesh for the attached image was generated by a program.  I would
> like to make a simple animation with the camera following the path.
> 
> Can I define an array of points and have the camera shoot from each of them?

.. oh i think i found it in the docs.

[Anton Sherwood] arbitrary camera path in animation [77 days 2 hours and 56 minutes ago]

Sun, 25 Jan 2026 20:04:20 GMT

The mesh for the attached image was generated by a program.  I would 
like to make a simple animation with the camera following the path.

Can I define an array of points and have the camera shoot from each of them?

-- 
*\\* Anton Sherwood *\\* https://bendwavy.org/

[Kenneth] Re: What does the 'mod' operator do? [152 days 1 hour ago]

Tue, 11 Nov 2025 22:00:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
>
> The “last” number is therefore the remainder. This is the number that
> the modulo function returns.
>
> Try this :
>
> #declare a = 27.44;
> #declare b = 7.97;
>
> #while(a > b)
>   #declare r = a - b;
>   #debug concat("mod(",str(a,0,2),", ",str(b,0,2),") = ",str(r,0,2),"\n")
>   #declare a = r;
> #end
>
> Which gives :
>
> mod(27.44, 7.97) = 19.47
> mod(19.47, 7.97) = 11.50
> mod(11.50, 7.97) = 3.53
>
> ...and 3.53 is of course equal to mod(27.44, 7.97)
>

That's a clever little demonstration; I'm going to keep it for reference.
Thanks!

[Bald Eagle] Re: What does the 'mod' operator do? [153 days 1 hour and 40 minutes ago]

Mon, 10 Nov 2025 21:20:00 GMT

Interesting application:

https://math.stackexchange.com/questions/101324/how-to-use-modulo-to-find-the-last-character-of-an-exponentiation

https://math.stackexchange.com/questions/23918/how-to-find-the-last-digit-of-31000/23920#23920

REALLY interesting reference therein (!):

https://math.stackexchange.com/questions/2033639/mod-of-numbers-with-large-exponents-modular-order-reduction/2033681#20
33681

- BW

[Bald Eagle] Re: What does the 'mod' operator do? [153 days 1 hour and 45 minutes ago]

Mon, 10 Nov 2025 21:15:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > I can attest that there are an amazing number of things that can be done with
> > the simplest of "tricks" - just using vcross, vdot, matrix determinants,
> > eigenvalues, and vector swizzling.
>
> About the only thing I truly grasp from that bunch is vector swizzling. :-( I
> have lots more learnin' to do...

I did some tutorial stuff on vcross and vdot.  Hopefully that's clear enough for
you.  There's also the stuff in the distro.
Matrix determinants are ... not my strong point, but I believe relate to area or
volume, and IIRC can signify other things as well (maybe?) - probably depending
on what the input data is.
Eigenvalues are the scalar values in a transformation matrix that tell you how
much the associated vector gets stretched or compressed.  3Blue1Brown does an
EXCELLENT series on linear algebra, which you absolutely should watch - it's
VERY visual and intuitive.  He will tell you EXACTLY what all these things are
and mean, and WHY.

> > And while that may all sound complicated and "out of reach" - the point
> > is that you don't have to understand a damned thing about how any of it
> > is "done" - you just need to understand the significance of the result.
> > What it means.
> >
> > And then you can go on to code some pretty amazing stuff, that's easy to
> > write (as a result of knowing the "tricks"), and is FAST - compared to
> > the usual "I'm going to write my code in the exact same way as I went about
> > figuring this out the long way" that we all do so often.

Yeah, but what I mean here, is that if you did something like rename mod (A,B)
to "remainder" - using a macro or function, then you really wouldn't need to be
able to regurgitate the exact steps of the process - you'd intuitively know what
the calculated result meant.

I just coded a "Cash Register" macro, since it was one of the fun examples that
I found while searching for examples for you.   Hopefully I'll get a little time
to test it out tonight to see if I did it right without the code-parse
error-edit cycle.  ;)

-BW

[jr] Re: What does the 'mod' operator do? [153 days 1 hour and 55 minutes ago]

Mon, 10 Nov 2025 21:05:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> Thorsten <tho### [at] trfde> wrote:
> >
> > Well, have you considered that "AI" in the sense of large language
> > models is the equivalent of a parrot? ;-)
> > ...
> ...
> Here's one AI answer/example that I saw while searching for 'modulo'-- it
> quickly came and went, but I swear that I'm not making it up, honest!
>
> "72 mod 10: The result is 2, because 10 goes into 70 three times, with a
> remainder of 2."
>
> So 10 X 3 = 70? I didn't know that!

it probably works for people who have six fingers on each hand. ;-)


regards, jr.

[Kenneth] Re: What does the 'mod' operator do? [153 days 2 hours ago]

Mon, 10 Nov 2025 21:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> I can attest that there are an amazing number of things that can be done with
> the simplest of "tricks" - just using vcross, vdot, matrix determinants,
> eigenvalues, and vector swizzling.

About the only thing I truly grasp from that bunch is vector swizzling. :-( I
have lots more learnin' to do...
>
> And while that may all sound complicated and "out of reach" - the point
> is that you don't have to understand a damned thing about how any of it
> is "done" - you just need to understand the significance of the result.
> What it means.
>
> And then you can go on to code some pretty amazing stuff, that's easy to
> write (as a result of knowing the "tricks"), and is FAST - compared to
> the usual "I'm going to write my code in the exact same way as I went about
> figuring this out the long way" that we all do so often.
>

Well-said. Fortunately or unfortunately, I always think in terms of 'visual
images' regarding math stuff-- I have to construct a step-by-step mental picture
of the particular process that I'm dealing with...as well as for the particular
math 'tool' that I'm trying to use, before putting it to work. Only then do I
have a clear understanding of what the result will be. It's a plodding and
cautious process, admittedly. But at some point I'll (hopefully) have a
'Eureka!' moment, when all is clear. :-)

But then there are times that I'll just *experiment*-- using renders, one after
another-- with no clear idea of what's happening or what to expect, until I see
some kind of result that helps me learn. That's usually a lot of fun, because
unexpected things arise! I should do more of that, instead of trying to do so
much 'pre-thinking'.

[Bald Eagle] Re: What does the 'mod' operator do? [153 days 2 hours and 40 minutes ago]

Mon, 10 Nov 2025 20:20:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Unfortunately, I'm still a bit puzzled by the docs' written description.

Check out the "divmod" function!
https://docs.python.org/3/library/functions.html#divmod

divmod(a, b, /)
Take two (non-complex) numbers as arguments and return a pair of numbers
consisting of their quotient and remainder when using integer division. With
mixed operand types, the rules for binary arithmetic operators apply. For
integers, the result is the same as (a // b, a % b). For floating-point numbers
the result is (q, a % b), where q is usually math.floor(a / b) but may be 1 less
than that. In any case q * b + a % b is very close to a, if a % b is non-zero it
has the same sign as b, and 0 <= abs(a % b) < abs(b).

HuhSayWhat?

"Your next assignment, should you choose to accept it....."

:D

[Kenneth] Re: What does the 'mod' operator do? [153 days 2 hours and 45 minutes ago]

Mon, 10 Nov 2025 20:15:00 GMT

Thorsten <tho### [at] trfde> wrote:
>
> Well, have you considered that "AI" in the sense of large language
> models is the equivalent of a parrot? ;-)
>
> Maybe a real source of information edited by humans might help? Apart
> from a good math book, try https://en.wikipedia.org/wiki/Modulo , which
> is reasonably complete and free human-made information.

Currently, I have a very skeptical response to AI-generated answers -- when I
even pay attention to them; I wish Google would place those summaries at the
*bottom* of the search page, instead of at the top where they are the first
things we see. But of course, that would negate the entire purpose of why they
are there: using all of us as guinea pigs to help the AI engine 'learn', if only
by clicking on the 'Like' or 'Don't like' buttons that are so conveniently
placed-- which I never respond to, as MY silent protest.

Here's one AI answer/example that I saw while searching for 'modulo'-- it
quickly came and went, but I swear that I'm not making it up, honest!

"72 mod 10: The result is 2, because 10 goes into 70 three times, with a
remainder of 2."

So 10 X 3 = 70? I didn't know that!

[Thorsten] Re: What does the 'mod' operator do? [153 days 4 hours and 4 minutes ago]

Mon, 10 Nov 2025 18:55:55 GMT

On 10.11.2025 12:13, Kenneth wrote:
> When I was first querying Google about this topic and read the AI summary--
> which changes by the minute, apparently-- it also suggested a particular
> video...which I now can't find. The mathematician host quickly discussed some
> typical (i.e. pure-integer) examples of using mod...but then began a rather
> abstract discourse on how modulo should be thought of in other NON-math
> contexts. I had real trouble following it, but my own takeaway would be
> *something* like this (not his own original example, which I didn't understand):

Well, have you considered that "AI" in the sense of large language 
models is the equivalent of a parrot? ;-)

Maybe a real source of information edited by humans might help? Apart 
from a good math book, try https://en.wikipedia.org/wiki/Modulo , which 
is reasonably complete and free human-made information.

[Bald Eagle] Re: What does the 'mod' operator do? [153 days 4 hours and 10 minutes ago]

Mon, 10 Nov 2025 18:50:00 GMT

Just got a chance to do a quick AI-interrogation

 Practical Computer Graphics Uses of Modulo


Tiling and Repeating Patterns

Use case: Seamless textures, checkerboards, brick walls.
How: mod(x, tile_width) wraps coordinates to repeat a pattern.
Example: Creating a grid of alternating colors:
Plain Textpov isn’t fully supported. Syntax highlighting is based on Plain
Text.#declare Color = select(mod(X + Y, 2), rgb <1,1,1>, rgb <0,0,0>);Show more
lines




UV Mapping and Texture Wrapping

Use case: Preventing texture coordinates from exceeding [0,1].
How: mod(U, 1) ensures UVs stay within bounds.



Animation Loops

Use case: Looping motion or color changes.
How: mod(Time, Duration) resets animation after a cycle.



Striping and Banding Effects

Use case: Zebra stripes, barcodes, scanlines.
How: mod(Y, StripeHeight) < Threshold to alternate colors.



Grid Indexing

Use case: Mapping 1D index to 2D grid.
How: Row = Index / Width, Col = mod(Index, Width).



Symmetry and Mirroring

Use case: Reflecting patterns across axes.
How: mod(abs(X), MirrorWidth) to repeat mirrored segments.



Procedural Noise and Randomization

Use case: Repeating pseudo-random patterns.
How: Seeded PRNGs often use mod to wrap values.




Non-Math Logic and Programming Tasks Using Modulo


Alternating Behavior

Use case: Toggle between two states (e.g., even/odd rows).
How: if (mod(i, 2) = 0) → even; else → odd.



Scheduling and Timing

Use case: Trigger events every N frames or seconds.
How: if (mod(Frame, N) = 0) → trigger.



Circular Buffers

Use case: Wrap-around indexing in fixed-size arrays.
How: Index = mod(CurrentIndex, BufferSize).



Color Cycling

Use case: Cycle through a palette.
How: Color = Palette[mod(i, PaletteSize)].



Hashing and Bucketing

Use case: Assign items to groups or bins.
How: Bucket = mod(ID, NumBuckets).



File Naming or Resource Allocation

Use case: Distribute tasks or files evenly.
How: mod(TaskID, NumWorkers).

[Bald Eagle] Re: What does the 'mod' operator do? [153 days 7 hours and 35 minutes ago]

Mon, 10 Nov 2025 15:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> ... it also suggested a particular
> video...which I now can't find. The mathematician host quickly discussed some
> typical (i.e. pure-integer) examples of using mod...but then began a rather
> abstract discourse on how modulo should be thought of in other NON-math
> contexts.

Video length?
Background?
Visual aids?
Presenter?

You're at the part where things get interesting - and remarkably useful - if you
stick with it and follow through far enough.

I can attest that there are an amazing number of things that can be done with
the simplest of "tricks" - just using vcross, vdot, matrix determinants,
eigenvalues, and vector swizzling.

And while that may all sound complicated and "out of reach" - the point is that
you don't have to understand a damned thing about how any of it is "done" - you
just need to understand the significance of the result.   What it means.

And then you can go on to code some pretty amazing stuff, that's easy to write
(as a result of knowing the "tricks"), and is FAST - compared to the usual "I'm
going to write my code in the exact same way as I went about figuring this out
the long way" that we all do so often.

- BW

[Bald Eagle] Re: What does the 'mod' operator do? [153 days 8 hours ago]

Mon, 10 Nov 2025 15:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Unfortunately, I'm still a bit puzzled by the docs' written description.

Well don't feel bad - because at one time I was too.
https://news.povray.org/povray.newusers/thread/%3Cweb.51fb3b6e744b4afe73fc9ebb0%40news.povray.org%3E/?mtop=386122

> But
> another interpretation in the 'modulo' topic...if I understand it
> correctly...puts no restriction on the values re: floats vs. integers--
> "depending on the programming language used."

Yes, well, when you get around to playing with / using these things enough, you
find that things like this can be ... flexible.
What is N/0?  It it "undefined"?  "unbounded"?  Infinity?
what about pow(0, 0)?

Sometimes the definitions of things change - or, rather - grow - to encompass
new discoveries and new ways of understanding, and therefore defining what that
thing is.

Like acids.  There have been a number of progressive expansions of the
definition of what an acid is.  All the way from Bronstead to Lewis.

zero
Negative numbers
or the square root of -1.
Look at the fundamentals of calculus.  We needed LIMITS to make that leap, and
land on putatively solid ground.

So:
Can you take the modulo of a COMPLEX number?
.. . .might depend on which computer language you use.

> In any case, POV-ray's 'mod' can obviously work with float values too...and
> fractions...at least when running in Windows.

Well of course.  If I have a 40-foot, 9-inch long log, and I want to cut it up
into sections that are 18 inches long, or 1.5 feet, then I will get a certain
integer number of logs, plus some remainder.
Just conceptually replace "integer" with "unit value".

(The universe is silently begging you to then expand your inquiries and
understanding to Basis Vectors ;) )

> So IMO the docs are either
> outdated or too 'strict', and at least somewhat unclear.

The docs in that case are just "poorly written" - because probably at the time,
they just wanted to casually provide the kindergarten-level explanation of the
function, and get on with the rest of it, rather than expanding it into a
mathematically accurate treatise on Modular Arithmetic.

Likely the documentation needs to be written in a large number of places, if
only to clear up little details like this.

I voluntell Kenneth.   :D

- BE

[kurtz le pirate] Re: What does the 'mod' operator do? [153 days 8 hours and 49 minutes ago]

Mon, 10 Nov 2025 14:11:06 GMT

On 10/11/2025 03:52, Kenneth wrote:
> In any case, POV-ray's 'mod' can obviously work with float values too...and
> fractions...at least when running in Windows. So IMO the docs are either
> outdated or too 'strict', and at least somewhat unclear.

Indeed, the definition given in the documentation is somewhat 
restrictive or ambiguous at first glance.

Just as multiplication is a simple addition, division is a simple 
subtraction.

Starting with any number (numerator), subtract the denominator as many 
times as possible : that is, as long as the remainder is greater than 
the denominator.

The â€œlastâ€ number is therefore the remainder. This
is the number that 
the modulo function returns.

Try this :

#declare a = 27.44;
#declare b = 7.97;

#while(a > b)
  #declare r = a - b;
  #debug concat("mod(",str(a,0,2),", ",str(b,0,2),") = ",str(r,0,2),"\n")
  #declare a = r;
#end

Which gives :

mod(27.44, 7.97) = 19.47
mod(19.47, 7.97) = 11.50
mod(11.50, 7.97) = 3.53

...and 3.53 is of course equal to mod(27.44, 7.97)

-- 
kurtz le pirate
compagnie de la banquise

[Kenneth] Re: What does the 'mod' operator do? [153 days 11 hours and 45 minutes ago]

Mon, 10 Nov 2025 11:15:00 GMT

"jr" <cre### [at] gmailcom> wrote:
>
> fwiw, I like the term "clock arithmetic", can understand it :-), find it
> "illustrative".
> <en.wikipedia.org/wiki/Modular_arithmetic>
>

Yes, I saw that too, and it makes perfect sense-- I could 'see' the result! I
even made a note about it in my test scene, for future reference when I
eventually forget what 'modulo' means, ha.

When I was first querying Google about this topic and read the AI summary--
which changes by the minute, apparently-- it also suggested a particular
video...which I now can't find. The mathematician host quickly discussed some
typical (i.e. pure-integer) examples of using mod...but then began a rather
abstract discourse on how modulo should be thought of in other NON-math
contexts. I had real trouble following it, but my own takeaway would be
*something* like this (not his own original example, which I didn't understand):

      mod(a collection of vegetables,vegetables that are red)

so the 'remainder' would be...vegetables that are not red(?)

Anyway, the video was certainly not a 'simple and easy' introduction to the
topic; it's a mystery as to how the AI engine picked it, out of so many others.

[jr] Re: What does the 'mod' operator do? [153 days 15 hours and 20 minutes ago]

Mon, 10 Nov 2025 07:40:00 GMT

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> I am new to POV-ray's 'mod' operator-- and the meaning of 'modulo' itself. I
> have seen it used in many newsgroup code examples-- and there are probably
> numerous newsgroup posts asking questions about it through the years-- but I
> never really understood what it does or what to expect as the result, due to the
> rather terse explanation in the docs:
>
> mod(A,B)
> Value of A modulo B. Returns the remainder after the integer division of A/B.
> Formula is mod=((A/B)-int(A/B))*B.
>
> It has never been quite clear to me what 'integer division' means there ...
> ...
> QUESTION: "What does 'modulo' really mean?"
> ANSWER: "It depends on who you ask..."
>    :-o

fwiw, I like the term "clock arithmetic", can understand it :-), find it
"illustrative".
<en.wikipedia.org/wiki/Modular_arithmetic>


regards, jr.

[Kenneth] What does the 'mod' operator do? [153 days 20 hours and 5 minutes ago]

Mon, 10 Nov 2025 02:55:00 GMT

I am new to POV-ray's 'mod' operator-- and the meaning of 'modulo' itself. I
have seen it used in many newsgroup code examples-- and there are probably
numerous newsgroup posts asking questions about it through the years-- but I
never really understood what it does or what to expect as the result, due to the
rather terse explanation in the docs:

mod(A,B)
Value of A modulo B. Returns the remainder after the integer division of A/B.
Formula is mod=((A/B)-int(A/B))*B.

It has never been quite clear to me what 'integer division' means there-- since
the supplied A and B values could conceivably be typical floats and not just
integers. Did it mean initially truncating the fractional parts of
float values >= 1.0? And I assumed that the 'remainder' would be the
*fractional* part of a division of the two integers -- like 30/7 = 4.2857... ,
with .2857 being the remainder. At least, this was my rather fuzzy
interpretation of the docs...without actually paying attention to the math
formula there :-(

So, rather than allowing my existential crisis to continue, I finally got
curious enough to actually try USING it, along with #debug:
       mod(30,7)
The result is... 2.  What the...??  Since this obviously didn't agree with my
assumptions, I had some learning to do...which led me down an interesting
Wikipedia path to various interrelated topics:
      modulo
      Euclidean arithmetic
      modular arithmetic
Plus Google's now-ubiquitous A.I. 'summaries',  as well as some videos by
mathematicians with their own (arcane!) discussions of what 'modulo' means.

So my mod result of '2' finally made sense:  7 goes into 30 four times-- with
a remainder of 2! Simple. And I finally took the time to plug these A and B
values into the docs' equation, working it out piece by piece. :-D
Unfortunately, I'm still a bit puzzled by the docs' written description.

Armed with my newly-found confidence and quasi-knowledge, I tried a trickier
example...not really knowing what to expect:
      mod(27.44, 7.97)
The #debug result is...  3.53      a float and not just an integer(!)

An even trickier example:
      mod(0.87, 0.59)
The result is 0.28        just a fractional float value.

Those remainder results are correct of course-- but how do these two examples
jibe with the docs' interpretation of 'integer division'? Interestingly, from
reading the Wikipedia entry about 'modulo' (with a little help from 'Euclidean
arithmetic'), it seems that the strictest meaning of the modulo operator
involves the use of integers and only integers-- for the A and B values *and*
the result. So the meaning of POV-ray's documentation becomes a bit clearer. But
another interpretation in the 'modulo' topic...if I understand it
correctly...puts no restriction on the values re: floats vs. integers--
"depending on the programming language used."

In any case, POV-ray's 'mod' can obviously work with float values too...and
fractions...at least when running in Windows. So IMO the docs are either
outdated or too 'strict', and at least somewhat unclear.

QUESTION: "What does 'modulo' really mean?"
ANSWER: "It depends on who you ask..."
   :-o

[jr] Re: Something strange is happening to me (again) [174 days 4 hours and 10 minutes ago]

Mon, 20 Oct 2025 18:50:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > a wiki page, with simple "bullet" list ?
> This would likely suffice, if there were someone to compile the present list,
> and it were editable by a sufficiently wide user list.
> Maybe a talk page or something.

to begin with, I think, getting "the list" going is priority, as one of your
pages perhaps.  medium to long-term, and when the details are fixed, we can move
the page.

> I could likely write a simple spreadsheet to list keyword, file, macro,
> whatever, who reported the bug, the link to the thread, who volunteered to fix
> it, date, present status, etc.
> That could be updated periodically to reflect the state of things.
> Or maybe there's a way to format data on the wiki for retrieval by a spreadsheet
> so that any local copies of the spreadsheet that people download can get
> updated.

we do have tables.  I also think that the list(ing) should be kept simple,
mostly just a reference/index providing links to the details (like "who
volunteered").

> A record of the code development history - even as a simple text file - ought to
> be provided in the distribution.

back when s/wares used to provide a 'ChangeLog' file, for the exact purpose.

regards, jr.

[Bald Eagle] Re: Something strange is happening to me (again) [174 days 5 hours and 10 minutes ago]

Mon, 20 Oct 2025 17:50:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/20/25 03:53, kurtz le pirate wrote:
> > Let an array of "4D" vectors.
> > This code works well :
> >
> > #write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
>
> Below the contents of a documentation scene I'm adding to the next yuqk
> release (R20). What's going on is part of a larger tangle due when and
> how the features involved were implemented over time.
>
> Bill P.
>
> //---
> // Odd behavior with 'write' and 5D color vectors...
>
> #declare V2 = <1,2>;
> #declare V3 = <1,2,3>;
> #declare V4 = <1,2,3,4>;
> #declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'
>
> #fopen FH "zzz" write
>
> // These are OK in yuqk or in v3.8 beta 2
> #write (FH,V3.x,",",V3.y,",",V3.z)
> #write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
> #write (FH,(V5.x),",",(V5.y),",",(V5.z))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
> #write (FH,V2)
> #write (FH,V3)
> #write (FH,V4)
>
> // This fails in yuqk and in v3.8 beta 2 because 'write' only
> // supports 2D, 3D and 4D vectors.
> #if (0)
> #write (FH,V5)
> #end
>
> // This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
> // and 4D vectors. Due how the dot operator works, incorrectly,
> // for the v3.8 tuple feature the V5.transmit is first seen as a 5D
> // color vector - before it is seen as a float due the dot operator.
> #if (0)
> #write (FH,V5.transmit)
> #end
>
> // These fail in yuqk due fixes with the tuple assignment feature of
> // v3.8 which changes how the dot operators are evaluated. The yuqk
> // fork always sees 'V5' before it thinks about the dot operator. In
> // other words, with yuqk you must wrap all, 5D color vector, element
> // to float conversions in ()s with write!
> #if (0)
> #write (FH,V5.x,",",V5.y,",",V5.z)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
> #end
>
> #fclose FH
>
> #error "Stop early"
> //---
>
> Bill P.

So,
I'm curious about all of this.
There seems to be an awful lot of bouncing around under the hood, and a fair
amount of replicated code for things like splines, etc.

How are the vector components stored, and why do they need to be recast into
floats?

I see that there is no 5d vector defined in math/vector.h - it is in
base/colour.h

Can we somehow consolidate/unify the colors and the vectors, or do we want to
somehow completely separate them with a means to interconvert as per clipka?


#write converts everything to strings first?

[Bald Eagle] Re: Something strange is happening to me (again) [174 days 5 hours and 40 minutes ago]

Mon, 20 Oct 2025 17:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:

> +1 wrt "here".
>
> a wiki page, with simple "bullet" list ?

This would likely suffice, if there were someone to compile the present list,
and it were editable by a sufficiently wide user list.

Maybe a talk page or something.

I could likely write a simple spreadsheet to list keyword, file, macro,
whatever, who reported the bug, the link to the thread, who volunteered to fix
it, date, present status, etc.
That could be updated periodically to reflect the state of things.

Or maybe there's a way to format data on the wiki for retrieval by a spreadsheet
so that any local copies of the spreadsheet that people download can get
updated.

A record of the code development history - even as a simple text file - ought to
be provided in the distribution.

"I'm putting together a team.  People with special abilities."
- BW

[ingo] Re: Something strange is happening to me (again) [174 days 6 hours and 10 minutes ago]

Mon, 20 Oct 2025 16:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Here again, I will shamelessly make a plug for some kind of project management
> system.
>

Github has that and many other tools, but you have to pay.
https://github.com/features/issues I'm not a github user so I know little of it.

I asked their "thing" for a summary:

Copilot said: Here is a summary of the issues

Here is a summary of the issues for POV-Ray, ordered by severity (highest to
lowest). Please note: this is based on public issue titles, labels, and visible
context—actual severity may require deeper investigation or prioritization by
project maintainers.
Critical Bugs & Vulnerabilities

    Potential Vulnerabilities (Cloned Functions)
        Fix potential vulnerable cloned function
        Fix potential vulnerable cloned functions
        Fix potential vulnerable cloned function Severity: Security-related,
likely the most urgent.

    Bug: Functionality Failure
        [BUG] function "trace" fails to find intersections in distances of more
than 10⁷ units Severity: Major feature broken for large distances.

    Build/Compatibility Failures
        [BUILD][UNIX] Failure on macOS w/ Xcode 16.4, error: unknown type name
'Fixed'
        [BUILD][UNIX] Build fails with strict-aliasing violations
        [BUILD][UNIX] Test for Boost Libraries fail on Apple silicon (Homebrew
path change) Severity: Prevents build on certain platforms.

    Bug: Parse/Error Handling
        [BUG] Parse error when using povray built by GCC 13, no error with GCC
12
        [BUG] doesn't give an error if a polygon is not 2D
        [BUG][UNIX] Failed to parse command line option with space in filename
Severity: Could lead to silent failures or unpredictable behavior.

    Bug: Memory/Allocation
        Assigned interior causes a bad allocation error Severity: May cause
crashes or data corruption.

    Bug: Incorrect Rendering
        Photons do not work properly with true inverse power fading
        Option "Keep Single Instance" is not working for *.inc files
        Error in POV-RAY output generated from Project Chrono Demo Severity: Can
result in incorrect output or broken features.

Medium Severity

    Performance/Optimization
        Usage of Enhanced Math Library for better performance
        AVX512 version for POVRAY Severity: Performance improvements, not
critical but useful.

    Feature Requests: Important for Users
        [FEATURE] support all Opentype font formats
        [FEATURE] LaTeX support
        Can we develop POV-RayMCP similar to BlenderMCP? Severity: Not bugs, but
could be important for project adoption.

Low Severity / Minor Issues

    Minor Bugs and UI Issues
        Debug string is not displayed in console if start with more than 14
hyphens
        Need to run POVRAY on a single thread
        Updates to screen.inc
        Issue a parse warning for out-of-domain arguments to the srgb keywords
        remove unecessary nullptr check before 'delete' and 'delete[]'
        Apply translate and rotate to user_defined cameras.
        Fixing some missing stuff in VS 2022
        What about 3.7 branch ? Severity: Minor bugs, enhancements, or
low-priority tasks.

Note:

    This list is based on 30 issues (API limit). For a complete and up-to-date
list, view all POV-Ray issues on GitHub.
    Severity is estimated—project maintainers may prioritize differently based
on user impact, security, or strategic goals.
    If you want a more detailed triage or deeper analysis of a specific issue,
let me know!


ingo

[jr] Re: Something strange is happening to me (again) [174 days 6 hours and 30 minutes ago]

Mon, 20 Oct 2025 16:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
> > > Do we have a comprehensive list of unfixed bugs for various POV-Ray features?
> > That's what github is for. Once a bug is identified as a bug (here on the forum)
> > post it and the information gathered on github. Or post it directly on github
> > and discuss there. Personally I prefer here,
> ...
> What I'd like is a consolidated, up-to-date list that anyone can look at
> "at-a-glance" and be able to readily assess the state of every keyword and
> primitive, and distribution include file, etc.
> Right here on our own, locally-controlled server space.
> Because I prefer "here" as well.

+1 wrt "here".

a wiki page, with simple "bullet" list ?


regards, jr.

[Bald Eagle] Re: Something strange is happening to me (again) [174 days 6 hours and 40 minutes ago]

Mon, 20 Oct 2025 16:20:00 GMT

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Do we have a comprehensive list of unfixed bugs for various POV-Ray features?

> That's what github is for. Once a bug is identified as a bug (here on the forum)
> post it and the information gathered on github. Or post it directly on github
> and discuss there. Personally I prefer here,

An expected reply, and exactly the kind of thing I'm trying to avoid.
Just look at the 30-year collection of information that we have here on the
newsgroup.  Too vast, too spread out, and currently unreliably searchable.
And I don't want to go to github and have to then sift through all of that.

What I'd like is a consolidated, up-to-date list that anyone can look at
"at-a-glance" and be able to readily assess the state of every keyword and
primitive, and distribution include file, etc.

Right here on our own, locally-controlled server space.
Because I prefer "here" as well.

I should be able to scroll down to, or search for #read, and only see _existing_
bugs (unless I want to view the bug report and remediation history).  Every new
POV-Ray task should not trigger a new, epic quest.

3rd party stuff is undeniably useful.  However I disdain _reliance_ upon it.
Just look at the Object Collection fiasco.

Here again, I will shamelessly make a plug for some kind of project management
system.

- BW

[ingo] Re: Something strange is happening to me (again) [174 days 7 hours and 10 minutes ago]

Mon, 20 Oct 2025 15:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Do we have a comprehensive list of unfixed bugs for various POV-Ray features?
>
> It might be helpful to have some method by which we list known limitations and
> bugs in the actual documentation until such time that they get fixed.

That's what github is for. Once a bug is identified as a bug (here on the forum)
post it and the information gathered on github. Or post it directly on github
and discuss there. Personally I prefer here,

ingo

[Bald Eagle] Re: Something strange is happening to me (again) [174 days 8 hours and 45 minutes ago]

Mon, 20 Oct 2025 14:15:00 GMT

Do we have a comprehensive list of unfixed bugs for various POV-Ray features?

It might be helpful to have some method by which we list known limitations and
bugs in the actual documentation until such time that they get fixed.

- BW

[kurtz le pirate] Re: Something strange is happening to me (again) [174 days 9 hours and 18 minutes ago]

Mon, 20 Oct 2025 13:42:40 GMT

On 20/10/2025 13:20, Alain Martel wrote:
> Le 2025-10-20 Ã  03:53, kurtz le pirate a Ã©critÂ :
>>
>>
>> Hello,
>>
>> Let an array of "4D" vectors.
>> This code works well :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
>>
>>
>>
>>
>> Now with and array of "5D" vectors.
>> Base on the same schema i code this :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit
)
>>
>> And i get this error : "Expected 'string', colour identifier found 
>> instead".
>>
>>
>> On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
>> from Bald Eagle, you can read :
>> #declare Vector = < 1, 2, 3, 4, 5>;
>> ...
>> #declare Fifth_Component = Vector.transmit;// 5
>>
>>
>> The fifth element corresponds well to the keyword "transmit".
>> So why did this error occur?
>>
>> I got around the issue like this :
>> #declare _x = Array[i].x;
>> #declare _y = Array[i].y;
>> #declare _z = Array[i].z;
>> #declare _f = Array[i].filter;
>> #declare _t = Array[i].transmit;
>> #write ( FH, _x,",",_y,",",_z,",",_f,",",_t )
>>
>> However, I would like to understand what is wrong with my syntax.
>> Thank you for your help.
>>
> 
> Working from William's reply, I have this workaround :
> Replace :
> #write 
> (
FH,Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit
)
> 
> With :
> #declare Trans = Array[i].transmit;
> #write ( FH, 
> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Trans )
> 

Yes Alain, shorter as my workaround but in the same spirit.




-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Something strange is happening to me (again) [174 days 9 hours and 20 minutes ago]

Mon, 20 Oct 2025 13:40:32 GMT

On 20/10/2025 12:49, William F Pokorny wrote:
> On 10/20/25 03:53, kurtz le pirate wrote:
>> Let an array of "4D" vectors.
>> This code works well :
>>
>> #write ( FH, 
>> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
> 
> Below the contents of a documentation scene I'm adding to the next yuqk 
> release (R20). What's going on is part of a larger tangle due when and 
> how the features involved were implemented over time.
> 
> Bill P.
> 
> //---
> // Odd behavior with 'write' and 5D color vectors...
> 
> #declare V2 = <1,2>;
> #declare V3 = <1,2,3>;
> #declare V4 = <1,2,3,4>;
> #declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'
> 
> #fopen FH "zzz" write
> 
> // These are OK in yuqk or in v3.8 beta 2
> #write (FH,V3.x,",",V3.y,",",V3.z)
> #write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
> #write (FH,(V5.x),",",(V5.y),",",(V5.z))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
> #write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
> #write (FH,V2)
> #write (FH,V3)
> #write (FH,V4)
> 
> // This fails in yuqk and in v3.8 beta 2 because 'write' only
> // supports 2D, 3D and 4D vectors.
> #if (0)
> #write (FH,V5)
> #end
> 
> // This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
> // and 4D vectors. Due how the dot operator works, incorrectly,
> // for the v3.8 tuple feature the V5.transmit is first seen as a 5D
> // color vector - before it is seen as a float due the dot operator.
> #if (0)
> #write (FH,V5.transmit)
> #end
> 
> // These fail in yuqk due fixes with the tuple assignment feature of
> // v3.8 which changes how the dot operators are evaluated. The yuqk
> // fork always sees 'V5' before it thinks about the dot operator. In
> // other words, with yuqk you must wrap all, 5D color vector, element
> // to float conversions in ()s with write!
> #if (0)
> #write (FH,V5.x,",",V5.y,",",V5.z)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
> // #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
> #end
> 
> #fclose FH
> 
> #error "Stop early"
> //---
> 
> Bill P.

Thanks Bill.


I see "This fails in v3.8 beta 2 because 'write' only supports 2D, 3D 
and 4D vectors."

So in a way, it's not coming from me.
Phew!


One more thing to add (or not?) to your to-do list for v4.




-- 
kurtz le pirate
compagnie de la banquise

[Alain Martel] Re: Something strange is happening to me (again) [174 days 11 hours and 40 minutes ago]

Mon, 20 Oct 2025 11:20:31 GMT

Le 2025-10-20 Ã  03:53, kurtz le pirate a Ã©critÂ :
> 
> 
> Hello,
> 
> Let an array of "4D" vectors.
> This code works well :
> 
> #write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )
> 
> 
> 
> 
> Now with and array of "5D" vectors.
> Base on the same schema i code this :
> 
> #write ( FH, 
> Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit )
> 
> And i get this error : "Expected 'string', colour identifier found 
> instead".
> 
> 
> On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
> from Bald Eagle, you can read :
> #declare Vector = < 1, 2, 3, 4, 5>;
> ...
> #declare Fifth_Component = Vector.transmit;// 5
> 
> 
> The fifth element corresponds well to the keyword "transmit".
> So why did this error occur?
> 
> I got around the issue like this :
> #declare _x = Array[i].x;
> #declare _y = Array[i].y;
> #declare _z = Array[i].z;
> #declare _f = Array[i].filter;
> #declare _t = Array[i].transmit;
> #write ( FH, _x,",",_y,",",_z,",",_f,",",_t )
> 
> However, I would like to understand what is wrong with my syntax.
> Thank you for your help.
> 

Working from William's reply, I have this workaround :
Replace :
#write ( 
FH,Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit 
)

With :
#declare Trans = Array[i].transmit;
#write ( FH, 
Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Trans )

[William F Pokorny] Re: Something strange is happening to me (again) [174 days 12 hours and 10 minutes ago]

Mon, 20 Oct 2025 10:49:53 GMT

On 10/20/25 03:53, kurtz le pirate wrote:
> Let an array of "4D" vectors.
> This code works well :
> 
> #write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )

Below the contents of a documentation scene I'm adding to the next yuqk 
release (R20). What's going on is part of a larger tangle due when and 
how the features involved were implemented over time.

Bill P.

//---
// Odd behavior with 'write' and 5D color vectors...

#declare V2 = <1,2>;
#declare V3 = <1,2,3>;
#declare V4 = <1,2,3,4>;
#declare V5 = <1,2,3,4,5>; // Internally this a 'color vector'

#fopen FH "zzz" write

// These are OK in yuqk or in v3.8 beta 2
#write (FH,V3.x,",",V3.y,",",V3.z)
#write (FH,V4.x,",",V4.y,",",V4.z,",",V4.t)
#write (FH,(V5.x),",",(V5.y),",",(V5.z))
#write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t))
#write (FH,(V5.x),",",(V5.y),",",(V5.z)",",(V5.t)",",(V5.transmit))
#write (FH,V2)
#write (FH,V3)
#write (FH,V4)

// This fails in yuqk and in v3.8 beta 2 because 'write' only
// supports 2D, 3D and 4D vectors.
#if (0)
#write (FH,V5)
#end

// This fails in v3.8 beta 2 because 'write' only supports 2D, 3D
// and 4D vectors. Due how the dot operator works, incorrectly,
// for the v3.8 tuple feature the V5.transmit is first seen as a 5D
// color vector - before it is seen as a float due the dot operator.
#if (0)
#write (FH,V5.transmit)
#end

// These fail in yuqk due fixes with the tuple assignment feature of
// v3.8 which changes how the dot operators are evaluated. The yuqk
// fork always sees 'V5' before it thinks about the dot operator. In
// other words, with yuqk you must wrap all, 5D color vector, element
// to float conversions in ()s with write!
#if (0)
#write (FH,V5.x,",",V5.y,",",V5.z)
// #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.t)
// #write (FH,V5.x,",",V5.y,",",V5.z,",",V5.transmit)
#end

#fclose FH

#error "Stop early"
//---

Bill P.

[kurtz le pirate] Something strange is happening to me (again) [174 days 15 hours and 7 minutes ago]

Mon, 20 Oct 2025 07:53:28 GMT

Hello,

Let an array of "4D" vectors.
This code works well :

#write ( FH, Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter )




Now with and array of "5D" vectors.
Base on the same schema i code this :

#write ( FH, 
Array[i].x,",",Array[i].y,",",Array[i].z,",",Array[i].filter,",",Array[i].transmit 
)

And i get this error : "Expected 'string', colour identifier found instead".


On <https://wiki.povray.org/content/Reference_Talk:Vector_Expressions> 
from Bald Eagle, you can read :
#declare Vector = < 1, 2, 3, 4, 5>;
...
#declare Fifth_Component = Vector.transmit;// 5


The fifth element corresponds well to the keyword "transmit".
So why did this error occur?

I got around the issue like this :
#declare _x = Array[i].x;
#declare _y = Array[i].y;
#declare _z = Array[i].z;
#declare _f = Array[i].filter;
#declare _t = Array[i].transmit;
#write ( FH, _x,",",_y,",",_z,",",_f,",",_t )

However, I would like to understand what is wrong with my syntax.
Thank you for your help.






-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: scientific notation [189 days 13 hours and 42 minutes ago]

Sun, 5 Oct 2025 09:18:07 GMT

On 24/09/2025 18:08, Kenneth wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>>> #local Exponent = int(floor(log(abs(Num))));
>>
>> int(floor()) is redundant.
>> just use floor ()
>>
> 
> Yes indeedee it does work. I should have seen that :-|
> 
> #local Exponent = floor(log(abs(Num)));
> 
> 



Sorry for my late reply. I've had some family issues.


So, thank you for your ideas. Actually, I was thinking more of a special 
option in the str(n,l,p) function.



-- 
kurtz le pirate
compagnie de la banquise

[Kenneth] Re: scientific notation [200 days 6 hours and 50 minutes ago]

Wed, 24 Sep 2025 16:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > #local Exponent = int(floor(log(abs(Num))));
>
> int(floor()) is redundant.
> just use floor ()
>

Yes indeedee it does work. I should have seen that :-|

#local Exponent = floor(log(abs(Num)));

[Bald Eagle] Re: scientific notation [200 days 7 hours ago]

Wed, 24 Sep 2025 16:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> #local Exponent = int(floor(log(abs(Num))));

int(floor()) is redundant.
just use floor ()

floor(A)
Floor of A. Returns the largest integer less than A. Rounds down to the next
lower integer.

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

> BTW, this will also work:
> #local Exponent = int(log(#if(Num < 1 & Num > -1) .1* #else #end abs(Num)));

:O

- bw

[Kenneth] Re: scientific notation [200 days 7 hours and 20 minutes ago]

Wed, 24 Sep 2025 15:40:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Try using floor().  Or ceil.  Or maybe POV-Ray does weird things and you
> need to test your value and then conditionally use one or the other.
>

FIXED for fractional values, by using floor:

---------
#macro SciNot (Num, Precision)
#if (Num = 0)
#local Result = "0\n"
#else
#local Exponent = int(floor(log(abs(Num))));
#local Significand = Num/pow(10, Exponent);
#local Result = concat (str(Significand, 0, Precision), "e", str(Exponent, 0,
0), "\n")
#end
#debug Result
#end
---------

Example:
#declare MY_VAL = -.00674;

// the macro:
SciNot (MY_VAL, 3)

returns  -6.740e-3

-----------
BTW, this will also work:
#local Exponent = int(log(#if(Num < 1 & Num > -1) .1* #else #end abs(Num)));

[Bald Eagle] Re: scientific notation [201 days 5 hours ago]

Tue, 23 Sep 2025 18:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> Yes, it works and is quite elegant, although it's a bit beyond my mental grasp
> as to how. I haven't used logarithms since my college days, ha.

log(N) = 10^exponent

which gives you some (usually) non-integer exponent.
But you only want the integer part of that.

then you raise 10 to that power, and divide your original number by that.
That obviously gives you the number to multiply that power of 10 by.
Then you just cobble it all together with concat.

> Although: For fractional values like .000794, it returns 0.794e-3. Shouldn't it
> return 7.94e-4 instead?

I don't have my laptop at hand because "reasons" - so I'm just doing this in
Excel.

Excel has a weird Floor format, so I used Int.

Try using floor().  Or ceil.  Or maybe POV-Ray does weird things and you need to
test your value and then conditionally use one or the other.

I would love an online parser.  :)

- bw

[Kenneth] Re: scientific notation [201 days 5 hours and 15 minutes ago]

Tue, 23 Sep 2025 17:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> try:
>
> #macro SciNot (Num, Precision)
> #if (Num = 0)
> #local Result = "0\n"
> #else
> #local Exponent = int(log(abs(Num)));
> #local Significand = Num/pow(10, Exponent);
> #local Result = concat (str(Significand, 0, Precision), " x 10^", str(Exponent,
> 0, 0), "\n")
> #end // end if
> #debug Result
> #end // end macro
>

(I changed your " x 10^" to "e" )

Yes, it works and is quite elegant, although it's a bit beyond my mental grasp
as to how. I haven't used logarithms since my college days, ha.

Although: For fractional values like .000794, it returns 0.794e-3. Shouldn't it
return 7.94e-4 instead?

[Bald Eagle] Re: scientific notation [201 days 5 hours and 55 minutes ago]

Tue, 23 Sep 2025 17:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> Forget my clumsy string-code
> version; this one is certainly more compact and easy to grasp. It works with all
> float values, as far as I know from many tests. I have included the code itself
> and as a macro. The output is again as a #debug message.

Forget my crummy early-morning loop suggestion.  Just use int(log(abs(num)))

No idea what you're doing in your code,
but try:

#macro SciNot (Num, Precision)
#if (Num = 0)
#local Result = "0\n"
#else
#local Exponent = int(log(abs(Num)));
#local Significand = Num/pow(10, Exponent);
#local Result = concat (str(Significand, 0, Precision), " x 10^", str(Exponent,
0, 0), "\n")
#end // end if
#debug Result
#end // end macro

- BW

[Kenneth] Re: scientific notation [201 days 6 hours and 40 minutes ago]

Tue, 23 Sep 2025 16:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> But why don't you just write a macro that takes your number as an argument, and
> determines if its (abs val) is over 10 or under 1.
>
> Then you can just run a loop by multiplying/dividing by 10 until you're in that
> range, and then your exponent is the (signed) loop value.
>

Well, duh! That was an *excellent* suggestion. Forget my clumsy string-code
version; this one is certainly more compact and easy to grasp. It works with all
float values, as far as I know from many tests. I have included the code itself
and as a macro. The output is again as a #debug message.

I did have to add a slight kludge for an input value of exactly zero; it's
scientific notation initially ended up as 0.00000e-1, which is certainly not
correct. I'm not sure why that occurred in my code; it might be a subtle
'under the hood' error(?) Anyway, zero doesn't really need such notation, from
what I've read; so I eliminated its e exponent altogether. Problem solved! ;-)

---
definition of 'kludge' from Wikipedia:
"A kludge or kluge is a workaround or makeshift solution that is
clumsy, inelegant, inefficient...Its only benefit is that it
rapidly solves an important problem using available resources."
---

The code:

#local VAL = -.00067;
#local SIGNIFICANT_DIGITS =3;
#local ABS_VAL = abs(VAL);

// counters
#local C1 = 0;
#local C2 = 0;
#local C3 = 0;
#local C4 = 0;

#if(ABS_VAL <= 1.0 & ABS_VAL !=0.0 & ABS_VAL != -0.0)
 #while(C4 <= 25) // arbitrary large value
  #if(ABS_VAL < pow(10,C3))
  #local C3 = C3-1;
  #local C4 = C4+1;
  #else
  #local C4 = 1000; // to stop the while loop
  #end
 #end

 #local VAL_1 = VAL/pow(10,(C3));
 #debug concat("\n","VAL_1 as SCI NOTE = ",
 str(VAL_1,0,SIGNIFICANT_DIGITS),"e",str(C3,0,0),"\n")

#else // ABS_VAL > 1.0)
 #while(C2 <= 25) // arbitrary large value
  #if(ABS_VAL > pow(10,C1))
  #local C1 = C1+1;
  #local C2 = C2+1;
  #else
  #local C2 = 1000; // to stop the while loop
  #end
 #end

 #local VAL_2 = VAL/pow(10,(C1-1));
 #debug concat("\n","VAL_2 as SCI NOTE = ",
 str(VAL_2,0,SIGNIFICANT_DIGITS),
 #if(VAL_2 = 0) // a bandaid kludge for a problem when VAL = 0.
 "\n")
 #else
 "e",str(C1-1,0,0),"\n")
 #end

#end

//-------------------
//as a MACRO:
(Note: SD -- significant digits desired in the output)

#macro SCI_NOTA_CONVERS(VAL,SD)
#local ABS_VAL = abs(VAL);
#local C1 = 0;
#local C2 = 0;
#local C3 = 0;
#local C4 = 0;
#if(ABS_VAL <= 1.0 & ABS_VAL !=0.0 & ABS_VAL != -0.0)
 #while(C4 <= 25)
  #if(ABS_VAL < pow(10,C3))
  #local C3 = C3-1;
  #local C4 = C4+1;
  #else
  #local C4 = 1000;
  #end
 #end
 #local VAL_1 = VAL/pow(10,(C3));
 #debug concat("\n","VAL_1 as SCI NOTE = ",
 str(VAL_1,0,SIGNIFICANT_DIGITS),"e",str(C3,0,0),"\n")
#else // ABS_VAL > 1.0)
 #while(C2 <= 25)
  #if(ABS_VAL > pow(10,C1))
  #local C1 = C1+1;
  #local C2 = C2+1;
  #else
  #local C2 = 1000;
  #end
 #end
 #local VAL_2 = VAL/pow(10,(C1-1));
 #debug concat("\n","VAL_2 as SCI NOTE = ",
 str(VAL_2,0,SIGNIFICANT_DIGITS),
 #if(VAL_2 = 0)
 "\n")
 #else
 "e",str(C1-1,0,0),"\n")
 #end
#end
#end // of macro

// using it:
SCI_NOTA_CONVERS(467.00953,8)

[Bald Eagle] Re: scientific notation [201 days 12 hours and 20 minutes ago]

Tue, 23 Sep 2025 10:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> Here's my attempt, using string commands-- which are a bit tricky to implement;

I haven't read your code - have an unexpectedly busy morning here....

But why don't you just write a macro that takes your number as an argument, and
determines if its (abs val) is over 10 or under 1.

Then you can just run a loop by multiplying/dividing by 10 until you're in that
range, and then your exponent is the (signed) loop value.

Might be easier.
I recall I did something like this to buffer the str() output for a #debug
stream with spaces to make everything line up nicely.  No idea what scene code
that was in.

- BW

[Kenneth] Re: scientific notation [201 days 19 hours and 40 minutes ago]

Tue, 23 Sep 2025 03:20:00 GMT

Here's my attempt, using string commands-- which are a bit tricky to implement;
there are a few 'hidden rules' that I had to tease out, particularly for the
strlen(...) and substr(...) functions.

The output is in the form of a #debug.

The code is NOT yet completely finished-- and is certainly not elegant-- but I
wanted to post what I have. It works for all positive and negative floats,
*except* for values between +1.0 and -1.0 -- like .078463. No fatal errors for
those, but their resulting scientific notation output is not yet in the proper
form... like 0.078463e0 instead of 7.8463e-2. I'm still working on that; it's a
question of picking the correct *location* in the array of the value-as-strings,
for placing the added decimal point in the proper place for those. (The solution
probably lies in adding more conditionals in the final #debug section, although
I haven't yet figured out where.) The code does work fine for a zero value
though.

The code needs only two entries from the user: the float value to convert, and
the number of significant digits desired in the output.

//-----------
#declare VAL = 347.19054;
#declare SIGNIFICANT_DIGITS = 5; // MUST BE AT LEAST 1, otherwise the final
// result in #debug returns the wrong e exponential value.

#declare VAL_AS_STRING = str(VAL,0,SIGNIFICANT_DIGITS)
#declare STR_LENGTH = strlen(VAL_AS_STRING);
#declare DEC_POINT = "."

#declare C = 1; // a counter
#while(C <= STR_LENGTH)
#declare SS = substr(VAL_AS_STRING,C,1)
#if(SS=DEC_POINT)
#declare COUNT_AT_DECIMAL_POINT=C; // the decimal point position has been
// found at this position, counting from the left of the value.
#declare C = 1000; // to end the while loop
#else
#declare C = C+1;
#declare COUNT_AT_DECIMAL_POINT=0; // in case there is NO decimal point.
#end // of #if
#end // of #while loop

// The following sections recreate VAL (as a string) with the original
// decimal point eliminated and a new one inserted elsewhere.
#declare TEMP_ARRAY = array[STR_LENGTH]
#declare D = 0; // a counter
#while(D < STR_LENGTH)
#declare TEMP_ARRAY[D]= substr(VAL_AS_STRING,D+1,1)
#declare D = D+1;
#end

// The output:
#debug concat(
"\n",
#for(i,0,STR_LENGTH-1)
 #if(i=COUNT_AT_DECIMAL_POINT-1)
 #declare i = i+1; // gets rid of the current decimal point by skipping it
// in the array.
 #end

TEMP_ARRAY[i],
 #if(i=0 & TEMP_ARRAY[0] != "-")
 DEC_POINT, // adds a new decimal point.
 #else
  #if(i=1 & TEMP_ARRAY[0] = "-")
  DEC_POINT, // or ditto
  #end
 #end
 #end // of #for
 "e",

 #if(TEMP_ARRAY[0] != "-" & COUNT_AT_DECIMAL_POINT !=0)
 str(COUNT_AT_DECIMAL_POINT-2,0,0)
 #else
 #end

 #if(TEMP_ARRAY[0] = "-" & COUNT_AT_DECIMAL_POINT !=0)
 str(COUNT_AT_DECIMAL_POINT-3,0,0)
 #else
 #end
"\n") // end of #debug
// END OF FILE

[kurtz le pirate] scientific notation [204 days 6 hours and 15 minutes ago]

Sat, 20 Sep 2025 16:45:13 GMT

Hello,

Any way to format floating with scientifc notation for use in #debug() 
and/or #write() ?





-- 
kurtz le pirate
compagnie de la banquise

[Mr] Re: Where is a bug ? [216 days 10 hours and 35 minutes ago]

Mon, 8 Sep 2025 12:25:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> On 05/09/2025 22:15, William F Pokorny wrote:
>
> > Thank you - especially for taking the time to add the extra switch. :-)
>
> ho, yes. more easy than add/remove lines comments
>
> >
> > Disclaimer. I'm no expert with the SSLT feature / code.
>
> Me neither. I just wanted to explore this feature.
>
>
> >
> > 0) The far side artefacts are always there for both the merge{} and the
> > prism{} no matter the things tried.
> >
> > 1) I used only six digits of the coefficient value calculation, so the
> > first thing I tried was using the full double calculated value of
> > 0.5522847498307936 (a value accurate to maybe only about 7 or 8
> > significant digits in any case). No difference.
> >
> > 2) I tried yuqk versions with all the solver improvements over-Ray
> > releases(a). The artefact becomes slightly larger with the better solvers.
> >
> > (a) - Found too that yuqk change(s) after Nov 2021 (when yuqk was still
> > called povr) and all recent yuqk named versions, results in an infinite
> > parser hang any time global_settings{} uses subsurface{} and the scene
> > invokes ANY object - whether or not it is using SSLT... :-(
> >
> > 3) I tried a limited number of different camera positions and the
> > prism{} specific artefact was always there.
> >
> > 4) The far side artefacts can be reduced in size by reducing the
> > translucency via either the 'mm_per_unit' value or the per object
> > 'translucency' value. But, to my eye, the visual result is then not much
> > worth the cost of SSLT.
>
>  From what I've read, undersampling can result in visual noise.
>
>
>
> > As our documentation makes clear, the experimental SSLT feature is
> > there, but it's never been a polished implementation. For yuqk, it is a
> > feature I might delete.
> >
> > For the next yuqk release - unless I find the time to debug and fix the
> > yuqk SSLT parser hang - I'll make the feature illegal to use with a
> > message like "The SSLT feature is currently broken in the yuqk fork."
>
> Yes. it's a reasonable choice.
> Good implementation seems very hard to do.
>
>
>
>
> I've read several articles on this subject and it seems really
> complicated. Very few rendering engines handle this capability correctly.
>
> Some links :
>
<https://advances.realtimerendering.com/s2018/Efficient%20screen%20space%20subsurface%20scattering%20Siggraph%202018.
pdf>
> <https://www.iryoku.com/separable-sss/downloads/Separable-Subsurface-Scattering.pdf>
>
<https://agraphicsguynotes.com/posts/practical_tips_for_implementing_subsurface_scattering_in_a_ray_tracer/>
>
>
>
>
>
>
> --
> kurtz le pirate
> compagnie de la banquise

I love POV-Ray's SSLT. Any time I saw strange things occur... It was always
because the model was not physically correct... It's very slow, it's
unforgiving, but it might be one of the best around !

[kurtz le pirate] Re: Where is a bug ? [218 days 16 hours and 46 minutes ago]

Sat, 6 Sep 2025 06:14:16 GMT

On 05/09/2025 22:15, William F Pokorny wrote:

> Thank you - especially for taking the time to add the extra switch. :-)

ho, yes. more easy than add/remove lines comments

> 
> Disclaimer. I'm no expert with the SSLT feature / code.

Me neither. I just wanted to explore this feature.


> 
> 0) The far side artefacts are always there for both the merge{} and the 
> prism{} no matter the things tried.
> 
> 1) I used only six digits of the coefficient value calculation, so the 
> first thing I tried was using the full double calculated value of 
> 0.5522847498307936 (a value accurate to maybe only about 7 or 8 
> significant digits in any case). No difference.
> 
> 2) I tried yuqk versions with all the solver improvements over-Ray 
> releases(a). The artefact becomes slightly larger with the better solvers.
> 
> (a) - Found too that yuqk change(s) after Nov 2021 (when yuqk was still 
> called povr) and all recent yuqk named versions, results in an infinite 
> parser hang any time global_settings{} uses subsurface{} and the scene 
> invokes ANY object - whether or not it is using SSLT... :-(
> 
> 3) I tried a limited number of different camera positions and the 
> prism{} specific artefact was always there.
> 
> 4) The far side artefacts can be reduced in size by reducing the 
> translucency via either the 'mm_per_unit' value or the per object 
> 'translucency' value. But, to my eye, the visual result is then not much 
> worth the cost of SSLT.

 From what I've read, undersampling can result in visual noise.



> As our documentation makes clear, the experimental SSLT feature is 
> there, but it's never been a polished implementation. For yuqk, it is a 
> feature I might delete.
> 
> For the next yuqk release - unless I find the time to debug and fix the 
> yuqk SSLT parser hang - I'll make the feature illegal to use with a 
> message like "The SSLT feature is currently broken in the yuqk fork."

Yes. it's a reasonable choice.
Good implementation seems very hard to do.




I've read several articles on this subject and it seems really
complicated. Very few rendering engines handle this capability correctly.

Some links :
â€” <https://en.wikipedia.org/wiki/Subsurface_scattering>
â€” 
<https://advances.realtimerendering.com/s2018/Efficient%20screen%20space%20subsurface%20scattering%20Siggraph%202018.pdf>
â€” 
<https://www.iryoku.com/separable-sss/downloads/Separable-Subsurface-Scattering.pdf>
â€” 
<https://agraphicsguynotes.com/posts/practical_tips_for_implementing_subsurface_scattering_in_a_ray_tracer/>
â€” ...






-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Where is a bug ? [219 days 2 hours and 45 minutes ago]

Fri, 5 Sep 2025 20:15:40 GMT

On 9/5/25 04:31, kurtz le pirate wrote:
> With my merged shape, i have no artifact in the lower right.
> 
> My code is attached. Play wit it !
> 
> You can see differences with useWFPObject = true or false

Thank you - especially for taking the time to add the extra switch. :-)

I believe the short of it is that the corner rounding with the bezier 
spline is a approximation of what the equivalent cylinder radius is. 
Meaning there is tiny, but real, relative, discontinuity where the 
straight segments join the rounded ones. The SSLT feature doesn't like 
it in a way similar to how it doesn't like other 'tight' features / 
paths through the object.

---

More detail.

Disclaimer. I'm no expert with the SSLT feature / code.

0) The far side artefacts are always there for both the merge{} and the 
prism{} no matter the things tried.

1) I used only six digits of the coefficient value calculation, so the 
first thing I tried was using the full double calculated value of 
0.5522847498307936 (a value accurate to maybe only about 7 or 8 
significant digits in any case). No difference.

2) I tried yuqk versions with all the solver improvements over-Ray 
releases(a). The artefact becomes slightly larger with the better 
solvers.

(a) - Found too that yuqk change(s) after Nov 2021 (when yuqk was still 
called povr) and all recent yuqk named versions, results in an infinite 
parser hang any time global_settings{} uses subsurface{} and the scene 
invokes ANY object - whether or not it is using SSLT... :-(

3) I tried a limited number of different camera positions and the 
prism{} specific artefact was always there.

4) The far side artefacts can be reduced in size by reducing the 
translucency via either the 'mm_per_unit' value or the per object 
'translucency' value. But, to my eye, the visual result is then not much 
worth the cost of SSLT.

5) Played a little with adding a normal{} block as a way to mitigate the 
artefacts, but it didn't seem to change the SSLT result at all. Might be 
the perturbed normals are ignored by SSLT; Anyone know for sure?

---

FWIW.

As our documentation makes clear, the experimental SSLT feature is 
there, but it's never been a polished implementation. For yuqk, it is a 
feature I might delete.

For the next yuqk release - unless I find the time to debug and fix the 
yuqk SSLT parser hang - I'll make the feature illegal to use with a 
message like "The SSLT feature is currently broken in the yuqk fork."

Bill P.

[kurtz le pirate] Re: Where is a bug ? [219 days 14 hours and 28 minutes ago]

Fri, 5 Sep 2025 08:31:51 GMT

On 05/09/2025 00:31, William F Pokorny wrote:
> On 9/4/25 10:51, kurtz le pirate wrote:
>> Thanks Bill for your bezier_spline prism suggestion.
>> But it seems that there are also issues related to surface overlap, or 
>> the artifacts come only from the use of subsurface scattering ?
>> (still experimental, i know)
> 
> Thanks for posting your SSS result.
> 
> The far edge from the camera looks like artefacts I've seen the SSS 
> feature. My play with it (years ago) struggled where camera rays 
> traveled short distances within a shape.
> 
> The artefact in the lower right is new to me - a different look.
> 
> What version of POV-Ray are you using?
> 
> Did you see similar results with your merge{} of shapes?
> 
> I'd like to play with your scene (to the degree I can on my little 
> machine), if you're willing to post it.


With my merged shape, i have no artifact in the lower right.

My code is attached. Play wit it !

You can see differences with useWFPObject = true or false





-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Where is a bug ? [220 days and 29 minutes ago]

Thu, 4 Sep 2025 22:31:34 GMT

On 9/4/25 10:51, kurtz le pirate wrote:
> Thanks Bill for your bezier_spline prism suggestion.
> But it seems that there are also issues related to surface overlap, or 
> the artifacts come only from the use of subsurface scattering ?
> (still experimental, i know)

Thanks for posting your SSS result.

The far edge from the camera looks like artefacts I've seen the SSS 
feature. My play with it (years ago) struggled where camera rays 
traveled short distances within a shape.

The artefact in the lower right is new to me - a different look.

What version of POV-Ray are you using?

Did you see similar results with your merge{} of shapes?

I'd like to play with your scene (to the degree I can on my little 
machine), if you're willing to post it.

Bill P.

[kurtz le pirate] Re: Where is a bug ? [220 days 8 hours and 9 minutes ago]

Thu, 4 Sep 2025 14:51:22 GMT

On 03/09/2025 19:24, William F Pokorny wrote:

> 
> FWIW. An option, which might be faster than your merge{}, would be to 
> use a bezier_spline prism{}.
> 
> ...
> ...

Thanks Bill for your bezier_spline prism suggestion.
But it seems that there are also issues related to surface overlap, or 
the artifacts come only from the use of subsurface scattering ?
(still experimental, i know)

-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Where is a bug ? [220 days 21 hours and 24 minutes ago]

Thu, 4 Sep 2025 01:35:46 GMT

On 9/3/25 14:23, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> FWIW. An option, which might be faster than your merge{}, would be to
>> use a bezier_spline prism{}.
> 
> Dealing with chaos here, so I haven't thought this completely through...
> 
> But perhaps he could also use round box function / insert menu macro with
> intersection, or my "rounded_box" (apparently unposted) variant with a very tiny
> radius for the 2nd radius.
> 

Maybe... I thought too about the inbuilt f_rounded_box() function as an 
iso briefly, but to get the straight vertical sides I think we'd have to 
intersect with more or less the same corner shapes / box container being 
used in posted merge{}. Perhaps we could build up the isosurface with 
inbuilt, function similar shapes, matching what is in the merge. Whether 
that would faster than the merge{}, I don't know.

Bill P.

[Bald Eagle] Re: Where is a bug ? [221 days 4 hours and 35 minutes ago]

Wed, 3 Sep 2025 18:25:00 GMT

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

> FWIW. An option, which might be faster than your merge{}, would be to
> use a bezier_spline prism{}.

Dealing with chaos here, so I haven't thought this completely through...

But perhaps he could also use round box function / insert menu macro with
intersection, or my "rounded_box" (apparently unposted) variant with a very tiny
radius for the 2nd radius.

- BE

[William F Pokorny] Re: Where is a bug ? [221 days 5 hours and 36 minutes ago]

Wed, 3 Sep 2025 17:24:21 GMT

On 9/2/25 03:09, kurtz le pirate wrote:
> merge {
...
>  Â  }
> 
> 
> Now everything seems fine.
> I can restart my tests with SSS.

FWIW. An option, which might be faster than your merge{}, would be to 
use a bezier_spline prism{}.

Bill P.

//---
#version 3.8;
global_settings { assumed_gamma 1 }
#declare Grey50 = srgb <0.5,0.5,0.5>;
background { Grey50 }
#declare Camera00 = camera {
     perspective
     location <3,3,-3.001>
     sky y
     angle 35
     right x*(image_width/image_height)
     look_at <0,0,0>
}
#declare White = srgb <1,1,1>;
#declare Light00 = light_source { <50,150,-250>, White }
#declare Red = srgb <1,0,0>;
#declare CylinderX = cylinder { -1.1*x, 1.1*x, 0.01 pigment { Red } }
#declare Green = srgb <0,1,0>;
#declare CylinderY = cylinder { -1.1*y, 1.1*y, 0.01 pigment { Green } }
#declare Blue = srgb <0,0,1>;
#declare CylinderZ = cylinder { -1.1*z, 1.1*z, 0.01 pigment { Blue } }
#declare Orange = srgb <1,0.50196,0>;

//---
#declare Bot    = 0.0;           // Base of prism linear sweep
#declare Top    = 0.2;           // Top of prism linear sweep
#declare Frac   = 0.2;           // portion of +-1.0 edges rounded
#declare Shft   = 1.0-Frac;      // Normalize to 1x1 range
#declare ShftUR = <+Shft,+Shft>; // Shift up and right
#declare ShftUL = <-Shft,+Shft>; // Shift up and left
#declare ShftLL = <-Shft,-Shft>; // Shift lower and left
#declare ShftLR = <+Shft,-Shft>; // Shift lower and right
#declare Prism00 = prism {
     bezier_spline
     linear_sweep
     Bot, Top, 32,
     <1,0>*Frac+ShftUR,<1,0.552285>*Frac+ShftUR,
     <0.552285,1>*Frac+ShftUR,<0,1>*Frac+ShftUR,

     <+Shft,1>,<+Shft+Shft/3,1>,<-Shft+Shft/3,1>,<-Shft,1>,

     <0,1>*Frac+ShftUL,<-0.552285,1>*Frac+ShftUL,
     <-1,0.552285>*Frac+ShftUL,<-1,0>*Frac+ShftUL,

     <-1,+Shft>,<-1,+Shft-Shft/3>,<-1,-Shft+Shft/3>,<-1,-Shft>,

     <-1,0>*Frac+ShftLL,<-1,-0.552285>*Frac+ShftLL,
     <-0.552285,-1>*Frac+ShftLL,<0,-1>*Frac+ShftLL,

     <-Shft,-1>,<-Shft+Shft/3,-1>,<+Shft-Shft/3,-1>,<+Shft,-1>,

     <0,-1>*Frac+ShftLR,<0.552285,-1>*Frac+ShftLR,
     <1,-0.552285>*Frac+ShftLR,<1,0>*Frac+ShftLR

     <+1,-Shft>,<+1,-Shft+Shft/3>,<+1,+Shft-Shft/3>,<+1,+Shft>

     pigment { Orange }
}
#declare PrismCylinder = prism {  // Bezier spline cylinder approx
     bezier_spline
     linear_sweep
     Bot, Top, 16,
     <1,0>,<1,0.552285>,<0.552285,1>,<0,1>
     <0,1>,<-0.552285,1>,<-1,0.552285>,<-1,0>
     <-1,0>,<-1,-0.552285>,<-0.552285,-1>,<0,-1>
     <0,-1>,<0.552285,-1>,<1,-0.552285>,<1,0>
     pigment { Orange }
}

//--- scene ---
     camera { Camera00 }
     light_source { Light00 }
     object { CylinderX }
     object { CylinderY }
     object { CylinderZ }
     object { Prism00 }
//  object { PrismCylinder }  // Bezier spline cylinder approx
//---

[kurtz le pirate] Re: Where is a bug ? [222 days 15 hours and 51 minutes ago]

Tue, 2 Sep 2025 07:09:11 GMT

Thank you for all your answers.



In fact, it's still and still the same problem of surfaces coincidence. 
Two boxes and four cylinders give too many cases to manage with epsilon 
translation in y.


And as BE says, this object is â€œtooâ€ simple :(
So I started working on a new geometry with no overlap.


<sdl>
// --- a quarter circle
#declare corner = difference {
  cylinder { <0, -H, 0>, <0, 0, 0>, R }
  plane { z,0 }
  plane { x, 0 }
  }


merge {
   // central box
   box { <-S+R, -H, -S+R>, <+S-R, 0, +S-R> }

   // left/right box
   box { <-S+R, -H, -S>, <S-R, 0, -S+R> }
   box { <-S+R, -H, S-R>, <S-R, 0, S> }

   // front/rear box
   box { <S, -H, -S+R>, <S-R, 0, S-R> }
   box { <-S, -H, -S+R>, <-S+R, 0, S-R> }

   // corners
   object { corner translate <+(S-R), 0, +(S-R)> }
   object { corner scale <-1,1,1> translate <-(S-R), 0, +(S-R)> }
   object { corner scale <1,1,-1> translate <+(S-R), 0, -(S-R)> }
   object { corner scale <-1,1,-1> translate <-(S-R), 0, -(S-R)> }

   }
</sdl>


Now everything seems fine.
I can restart my tests with SSS.



-- 
kurtz le pirate
compagnie de la banquise

[Cousin Ricky] Re: Where is a bug ? [223 days 2 hours and 8 minutes ago]

Mon, 1 Sep 2025 20:52:37 GMT

On 2025-09-01 13:12 (-4), Bald Eagle wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> The attached image illustrates the issue well. Both objects are defined
>> in the same way, but one is a union{} (magenta) and the other is a
>> merge{} (cyan).
>>
>> It's a very very simple object: two boxes and four cylinders.
> 
> And that's the root of the problem:  it's TOO simple.
> 
> Remove the overlap of the two boxes by defining one central box, and adding FOUR
> "leaves" or "wings" filling in the edges between the cylinder "corners".
> 
> Then I think it should work . . .
> 
> However, you may need to convert your corners from full cylinders to "pie
> slices" by CSG - either home-rolled, or using Lohmueller's macro, which I
> believe is in the drop-down insert menu as "segment of a cylinder"

I'm not sure this will solve the problem; it may just result in a
different set of coincident surfaces.

If you want to see what I went through to build this shape without
coincident surfaces, take a look at macro RE__box_axis() in this file:
  https://github.com/CousinRicky/POV-RoundEdge/blob/main/roundedge.inc

[Cousin Ricky] Re: Where is a bug ? [223 days 2 hours and 18 minutes ago]

Mon, 1 Sep 2025 20:42:03 GMT

On 2025-09-01 12:23 (-4), Alain Martel wrote:
> Le 2025-09-01 Ã  11:54, kurtz le pirate a Ã©critÂ :
>>
>> #declare corner = cylinder { <0, -H, 0>, <0, 0, 0>, R }
>>
>> merge or union
>> Â Â  {
>> Â Â  box { <-S+R, -H, -S>, <+S-R, 0, +S> }
>> Â Â  box { <-S, -H, -S+R>, <+S, 0, +S-R> }
>>
>> Â Â  object { corner translate <+(S-R), 0, +(S-R)> }
>> Â Â  object { corner translate <-(S-R), 0, +(S-R)> }
>> Â Â  object { corner translate <+(S-R), 0, -(S-R)> }
>> Â Â  object { corner translate <-(S-R), 0, -(S-R)> }
>> Â Â  }
> 
> The noise in the hole lead me to think that it may be a coincident
> surface issue.
> The merge remove internal surfaces. When two surfaces are in the exact
> same location, you get all sort of glitches as the program can't tell
> witch one is inside and need to get removed.
> Try moving one of the box up or down by a very small amount, like :
> translate y*10^-7
> 
> Does that help ?

In fact, both boxes will need to be moved (one up, and one down),
because they also share coincident surfaces with the four cylinders.

P.S.  There is a typo: y*10^-7 should be y*10e-7.

[Alain Martel] Re: Where is a bug ? [223 days 2 hours and 47 minutes ago]

Mon, 1 Sep 2025 20:12:43 GMT

Le 2025-09-01 Ã  13:12, Bald Eagle a Ã©critÂ :
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> The attached image illustrates the issue well. Both objects are defined
>> in the same way, but one is a union{} (magenta) and the other is a
>> merge{} (cyan).
>>
>> It's a very very simple object: two boxes and four cylinders.
> 
> And that's the root of the problem:  it's TOO simple.
> 
> Remove the overlap of the two boxes by defining one central box, and adding FOUR
> "leaves" or "wings" filling in the edges between the cylinder "corners".
> 
> Then I think it should work . . .
> 
> However, you may need to convert your corners from full cylinders to "pie
> slices" by CSG - either home-rolled, or using Lohmueller's macro, which I
> believe is in the drop-down insert menu as "segment of a cylinder"
> 
> -BE
> 
> (Perhaps do some other simple overlap tests to demonstrate what happens.)

For the overlap test, just make one of the boxes a different colour in 
the union case. That will show the coincident surfaces.

union
   {
   box { <-S+R, -H, -S>, <+S-R, 0, +S> pigment{rgb<0,1,0>}}
   box { <-S, -H, -S+R>, <+S, 0, +S-R> pigment{rgb<1,0,0>}}

   object { corner translate <+(S-R), 0, +(S-R)> pigment{rgb<0,0,1>}}
   object { corner translate <-(S-R), 0, +(S-R)> pigment{rgb<0,0,1>}}
   object { corner translate <+(S-R), 0, -(S-R)> pigment{rgb<0,0,1>}}
   object { corner translate <-(S-R), 0, -(S-R)> pigment{rgb<0,0,1>}}
   }

This will make all coincident surfaces obvious.

[Bald Eagle] Re: Where is a bug ? [223 days 5 hours and 45 minutes ago]

Mon, 1 Sep 2025 17:15:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

> The attached image illustrates the issue well. Both objects are defined
> in the same way, but one is a union{} (magenta) and the other is a
> merge{} (cyan).
>
> It's a very very simple object: two boxes and four cylinders.

And that's the root of the problem:  it's TOO simple.

Remove the overlap of the two boxes by defining one central box, and adding FOUR
"leaves" or "wings" filling in the edges between the cylinder "corners".

Then I think it should work . . .

However, you may need to convert your corners from full cylinders to "pie
slices" by CSG - either home-rolled, or using Lohmueller's macro, which I
believe is in the drop-down insert menu as "segment of a cylinder"

-BE

(Perhaps do some other simple overlap tests to demonstrate what happens.)

[Alain Martel] Re: Where is a bug ? [223 days 6 hours and 37 minutes ago]

Mon, 1 Sep 2025 16:23:22 GMT

Le 2025-09-01 Ã  11:54, kurtz le pirate a Ã©critÂ :
> 
> Hello,
> 
> The holidays are over. I've started a new project... which has me 
> confused. I don't understand POV's behavior.
> 
> 
> The attached image illustrates the issue well. Both objects are defined 
> in the same way, but one is a union{} (magenta) and the other is a 
> merge{} (cyan).
> 
> It's a very very simple object: two boxes and four cylinders.
> 
> 
> So, why le merged object (in cyan) show a hole ?
> 
> 
> <sdl>
> 
> #declare S = 11.00;
> #declare R = 3.00;
> #declare H = 0.50;
> 
> #declare corner = cylinder { <0, -H, 0>, <0, 0, 0>, R }
> 
> merge or union
>  Â  {
>  Â  box { <-S+R, -H, -S>, <+S-R, 0, +S> }
>  Â  box { <-S, -H, -S+R>, <+S, 0, +S-R> }
> 
>  Â  object { corner translate <+(S-R), 0, +(S-R)> }
>  Â  object { corner translate <-(S-R), 0, +(S-R)> }
>  Â  object { corner translate <+(S-R), 0, -(S-R)> }
>  Â  object { corner translate <-(S-R), 0, -(S-R)> }
>  Â  }
> 
> </sdl>
> 
> For the rendering, I added a translate 15*y for the cyan object but the 
> problem is not here.
> 
> 
> 
> If you have an idea...
> Regards
> 
> 
> 
> ps : actually, I'm trying to understand how subsurface scattering works, 
> and I've already noticed that this feature requires merge{} because 
> union{} don't work, certainly due to surface coincidence.
> 
> 
> 

The noise in the hole lead me to think that it may be a coincident 
surface issue.
The merge remove internal surfaces. When two surfaces are in the exact 
same location, you get all sort of glitches as the program can't tell 
witch one is inside and need to get removed.
Try moving one of the box up or down by a very small amount, like :
translate y*10^-7

Does that help ?

[kurtz le pirate] Where is a bug ? [223 days 7 hours and 6 minutes ago]

Mon, 1 Sep 2025 15:54:34 GMT

Hello,

The holidays are over. I've started a new project... which has me 
confused. I don't understand POV's behavior.


The attached image illustrates the issue well. Both objects are defined 
in the same way, but one is a union{} (magenta) and the other is a 
merge{} (cyan).

It's a very very simple object: two boxes and four cylinders.


So, why le merged object (in cyan) show a hole ?


<sdl>

#declare S = 11.00;
#declare R = 3.00;
#declare H = 0.50;

#declare corner = cylinder { <0, -H, 0>, <0, 0, 0>, R }

merge or union
   {
   box { <-S+R, -H, -S>, <+S-R, 0, +S> }
   box { <-S, -H, -S+R>, <+S, 0, +S-R> }

   object { corner translate <+(S-R), 0, +(S-R)> }
   object { corner translate <-(S-R), 0, +(S-R)> }
   object { corner translate <+(S-R), 0, -(S-R)> }
   object { corner translate <-(S-R), 0, -(S-R)> }
   }

</sdl>

For the rendering, I added a translate 15*y for the cyan object but the 
problem is not here.



If you have an idea...
Regards



ps : actually, I'm trying to understand how subsurface scattering works, 
and I've already noticed that this feature requires merge{} because 
union{} don't work, certainly due to surface coincidence.



-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Parse error [302 days 20 hours and 30 minutes ago]

Sat, 14 Jun 2025 02:30:00 GMT

Well, you just have a finish statement hanging out in the middle of nothing.

If you wrap it in a default {} block, or apply that finish to your box by moving
inside the box {} statement's brackets, then all should be fine.

I incorporated both ways (plus newer requisite version and gamma) into the
following scene.

#version 3.8;

#include "colors.inc"
#global_settings {assumed_gamma 1.0}

#default {
 finish {
  reflection 0
  ambient 0.1
  specular 0.4
 }
}

camera {
 location <-14,5,15>
 look_at <0,0,0>
}

light_source {
 <4,7,8>
 White
}

sky_sphere {
 pigment {
 gradient y
  color_map {
  [0 color White]
  [1 color DarkTurquoise]
  }
 scale 2
 translate <0,1,0>
 }
}

box {
 <0,0,0>,<-3,3,3>
 pigment {
  rgb 1
 }
 finish {
  reflection 0
  ambient 0.1
  specular 0.4
 }
}


Hope that helps.

- BE

[SWG] Parse error [303 days 1 hour ago]

Fri, 13 Jun 2025 22:00:00 GMT

I was removing some stuff from a scene, tried to run it, but poof! I got an
error. "Expected object or directive, finish found instead" I tried to change up
the brackets, and everything seemed fine! But i keep getting the error.
the .pov:
#include "colors.inc"
finish {
  reflection 0
  ambient 0.1
  specular 0.4
}
camera {
 location <-14,5,15>
 look_at <0,0,0>
}
light_source {
 <4,7,8>
 White
}
sky_sphere {
 pigment {
  gradient y
  color_map {
   [0 color White]
   [1 color DarkTurquoise]
  }
  scale 2
  translate <0,1,0>
 }
}
box {
 <0,0,0>,<-3,3,3>
 pigment {
    Green
 }
}

[kurtz le pirate] Re: isosurface perturbation [319 days 14 hours and 31 minutes ago]

Wed, 28 May 2025 08:29:40 GMT

Thank you for your answers.
They gave me some new ideas.





-- 
kurtz le pirate
compagnie de la banquise

[Alain Martel] Re: isosurface perturbation [320 days 19 hours and 54 minutes ago]

Tue, 27 May 2025 03:05:58 GMT

Le 2025-05-26 Ã  13:40, kurtz le pirate a Ã©critÂ :
> 
> Hello,
> 
> Suppose we have a define a block with an isosurface whose surface is 
> perturbed by a pigment function like that in a macro :
> 
> 
> #macro CarvedRocks(xDim, yDim, zDim, Rad)
> isosurface {
>  Â function {
>  Â  f_rounded_box(x, y, z, Rad, xDim, yDim, zDim)
>  Â  -f_agate(x,y,z)
>  Â  }
> #end
> 
> 
> I can carve multiple stones :
> #declare block1 = CarvedRocks(x1, y1, z1, Rad)
> #declare block2 = CarvedRocks(x1, y1, z2, Rad)
> ...
> 
> 
> The problem is that the disturbance is the same for all blocks.
> This is not illogical, since the agate function always returns the same 
> values.
> 
> 
> Hence my question: how to obtain different blocks with the same agate 
> (or other) function ?
> 
> 
> Traditionally, by applying pigment before translations, box appear 
> different. But for an isosurface, I don't see how this can be done.
> 
> 
> 
> Any ideas ?
> THanks
> 
> 
You can feed the function some disturbed coordinates.

isosurface{f_leopar(x+f_granite(x,y,z), y+f_granite(x,y,z), 
y+f_granite(x,y,z)), contained_by{box{<-1000, -1.2, -1000><1000, 1.2, 
1000>}} <OtherIsodusfaceParameters>}

[Bald Eagle] Re: isosurface perturbation [321 days 5 hours ago]

Mon, 26 May 2025 18:00:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> Hello,
>
> Suppose we have a define a block with an isosurface whose surface is
> perturbed by a pigment function like that in a macro :
>
>
> #macro CarvedRocks(xDim, yDim, zDim, Rad)
> isosurface {
>   function {
>    f_rounded_box(x, y, z, Rad, xDim, yDim, zDim)
>    -f_agate(x,y,z)
>    }
> #end
>
>
> I can carve multiple stones :
> #declare block1 = CarvedRocks(x1, y1, z1, Rad)
> #declare block2 = CarvedRocks(x1, y1, z2, Rad)
> ...
>
>
> The problem is that the disturbance is the same for all blocks.
> This is not illogical, since the agate function always returns the same
> values.
>
>
> Hence my question: how to obtain different blocks with the same agate
> (or other) function ?
>
>
> Traditionally, by applying pigment before translations, box appear
> different. But for an isosurface, I don't see how this can be done.

It gets done in "exactly" the same way as you do with regular objects - you just
use math, not keywords to do it.

If you want to translate your box, you add or subtract to the x, y, or z going
into the function.

f_rounded_box(x-TransX, y-TransY, z-TransZ, Rad, xDim, yDim, zDim)

Same with the pigment function.

f_agate(x-TransX, y-TransY, z-TransZ)

If you wanted to use a keyword, you could undef your pigment function, and use

function (x, y, z, X, Y, Z) {pigment {agate translate <X, Y, Z>}}



- BW

[kurtz le pirate] isosurface perturbation [321 days 5 hours and 19 minutes ago]

Mon, 26 May 2025 17:40:51 GMT

Hello,

Suppose we have a define a block with an isosurface whose surface is 
perturbed by a pigment function like that in a macro :


#macro CarvedRocks(xDim, yDim, zDim, Rad)
isosurface {
  function {
   f_rounded_box(x, y, z, Rad, xDim, yDim, zDim)
   -f_agate(x,y,z)
   }
#end


I can carve multiple stones :
#declare block1 = CarvedRocks(x1, y1, z1, Rad)
#declare block2 = CarvedRocks(x1, y1, z2, Rad)
...


The problem is that the disturbance is the same for all blocks.
This is not illogical, since the agate function always returns the same 
values.


Hence my question: how to obtain different blocks with the same agate 
(or other) function ?


Traditionally, by applying pigment before translations, box appear 
different. But for an isosurface, I don't see how this can be done.



Any ideas ?
THanks


-- 
kurtz le pirate
compagnie de la banquise

[Leroy] Re: Greetings from Newcomer [344 days 6 hours and 20 minutes ago]

Sat, 3 May 2025 16:40:00 GMT

"netfoot" <nomail@nomail> wrote:
> Subject: Hello from a new user
>
> I last used POV-ray about 25 years ago and I'm giving it another whirl. It sure
> has changed since I was using DOS on an i386!
>

That's about the time I started with POV 3.1 dos. I think by then I had the 586.
 Glad to have you back! It seems you went one way and I went another. I dove
into POV to make graphics for PC games. Then used my knowledge of programing
games to make a front end for dos POV. Over the years the computers keep getting
upgraded and POV keep getting better and I learned a lot of more programing.
 I still have the code I wrote for 3.1 and all the files that came with it. So
when you talk about the scene your trying to reconstruct, I dug around and found
a scene wrote for 3.1 'WetPaint' that has most of what you described. I thought
it might have been one of the scenes files that came with 3.1 but it looks like
I made it. Here it is:

// scene: sign 'WET PAINT'on water
  #include "colors.inc"
    camera {
    location <0, 1, -10>
    look_at 0
    angle 35
  }
  light_source { <500,500,-1000> White }
  plane { y,0
     pigment { color SeaGreen }
    finish { reflection .35 specular 1 }
    normal { waves .5 }
    }

    text { ttf "timrom.ttf" "WET PAINT" 1, 0
      pigment { Gold }
      finish { metallic reflection .25 specular 1 }
      scale <1,2,1>
      translate -2.7*x
     }
  #include "skies.inc"
  sky_sphere { S_Cloud5 }

I hope this helps you on your come back to POV.
Also, You can visit my website: http://leroy.byethost15.com
You'll see some of what I've done over the last 25 years. There are some window
programs to help with prisms,lathes,height fields and so on. There are a few POV
object files and files to help with animations and more.

Have Fun!

[Cousin Ricky] Re: Greetings from Newcomer [344 days 20 hours and 11 minutes ago]

Sat, 3 May 2025 02:49:24 GMT

On 2025-05-02 19:47 (-4), netfoot wrote:
> 
> I last used POV-ray about 25 years ago and I'm giving it another whirl. It sure
> has changed since I was using DOS on an i386!

Welcome back!

These are the main changes that you need to know:

 - Scene description files are expected to start with a #version
   statement.

 - Scene description files are expected to have an assumed_gamma in the
   global_settings{} block.  The default is 1.0, but this has
   implications for the appearance of your scenes.  (See below.)

 - If you're using version 3.8 beta, the default finish ambient is
   changed to 0.0, making shadows completely black.

 - Using radiosity disables all finish ambients.  If you wish to define
   a glowing object, use the new 'emission' keyword in the finish block.

If your POV-Ray version was up-to-date as of 25 years ago, the following
features may be familiar; but these were new at the time.

 - All declarations of floats and vectors require a terminating semi-
   colon.

 - Refraction is no longer a finish feature; it is now handled by the
   interior{} block.

 - Halos are obsolete, and are replaced with media.

There are more neat toys--most notably, true caustics using photon
mapping--but you can ease into these at your leisure.

More remarks are apropos about assumed_gamma--a lot more.  Be sure to
read the documentation on gamma handling very carefully.  Prior to
version 3.7, there was no default assumed_gamma, meaning that the scene
defaulted to your monitor's gamma, typically around 2.2; and colors to
this day are typically defined with this assumption[1].  To correct the
mismatch with assumed_gamma 1.0, such colors will need to be defined
with the 'srgb' keyword or, in the case of the named colors in
colors.inc, prefixed with the 'srgbft' keyword.

Introduction to Gamma:
https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/

Gamma handling documentation:
https://wiki.povray.org/content/Documentation:Tutorial_Section_3.3#Gamma_Handling

How to use the sRGB keywords: https://github.com/CousinRicky/POV-Gamma-sRGB

_________________
[1] Actually, they tend to assume sRGB nowadays rather than 2.2, but the
principle is the same.

[Bald Eagle] Re: Greetings from Newcomer [344 days 21 hours and 30 minutes ago]

Sat, 3 May 2025 01:30:00 GMT

"netfoot" <nomail@nomail> wrote:

> I last used POV-ray about 25 years ago and I'm giving it another whirl.

Welcome back!  :)

> I'd show you the original image but I don't know how.

Click the [Choose File] button right below the message text entry box.

Ask away - we are all here to help - because we're all still learning.

-BW

Attach image like so:

[netfoot] Greetings from Newcomer [344 days 23 hours and 10 minutes ago]

Fri, 2 May 2025 23:50:00 GMT

Subject: Hello from a new user

Hi all,

I last used POV-ray about 25 years ago and I'm giving it another whirl. It sure
has changed since I was using DOS on an i386!

Back then I generated an image which I still have. But alas, the scene source
was lost a couple decades ago. It is a logo with the ocean below and patchy
clouds in the sky above. I'm trying to recreate that image now, with mixed
results. The CSG is challenging but fun. The sea and sky are a complete mystery.
I'd show you the original image but I don't know how.

I've already found the documentation helpful, but I'm sure I’ll have some
beginner questions as I go. Looking forward to learning from the community.

Thanks,
---
netfoot

[kurtz le pirate] Re: File handle and macros [345 days 5 hours and 11 minutes ago]

Fri, 2 May 2025 17:49:30 GMT

On 01/05/2025 19:59, Bald Eagle wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> Thank you for your advice but in what I was hoping to do "parse_string"
>> is not suitable.
> 
> Why not?
> 
>> #macro fwrite (FileHandleString, texte)
>>   #write (Parse_String (FileHandleString), concat(texte,"\n") )
>> #end
> 
> fwrite ("Filename", "Try this.")

I'll give this a try.



> Too much reading and writing to disk?

No. i/o disk are light.






-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: File handle and macros [346 days 5 hours ago]

Thu, 1 May 2025 18:00:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

> Thank you for your advice but in what I was hoping to do "parse_string"
> is not suitable.

Why not?

> #macro fwrite (FileHandleString, texte)
>  #write (Parse_String (FileHandleString), concat(texte,"\n") )
> #end

fwrite ("Filename", "Try this.")

Too much reading and writing to disk?

- BW

[Leroy] Re: File handle and macros [346 days 5 hours and 40 minutes ago]

Thu, 1 May 2025 17:20:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
>
>
> Of course this code work :
> --------------------------------------------------------------------------
> #fopen FileHandle1 "test1.txt" write
> #fopen FileHandle2 "test2.txt" write
> #fopen FileHandle3 "test3.txt" write
>
> #write (FileHandle1, "writing to test1\n")
> #write (FileHandle2, "writing to test2\n")
> #write (FileHandle3, "writing to test3\n")
>
> #fclose FileHandle3
> #fclose FileHandle2
> #fclose FileHandle1
> --------------------------------------------------------------------------
>
> ...but the advantages of having one and only one macro that writes to
> files are lost :(
>
>
You could put each of those sections in their own macro.
like:
macro OpenW(F,FileName)
 #switch(F)
  #case(1) #fopen Afile FileName write  #break
  #case(2) #fopen Bfile FileName write  #break
  #case(3) #fopen Cfile FileName write  #break
 #end
#macro Write(F,String)
 #switch(F)
  #case(1) #write(Afile,String,"\n") #break
  #case(2) #write(Bfile,String,"\n") #break
  #case(3) #write(Cfile,String,"\n") #break
 #end
#end
#macro Close(F)
 #switch(F)
  #case(1) #fclose Afile #break
  #case(2) #fclose Bfile #break
  #case(3) #fclose Cfile #break
 #end
#end
You'll notice different names here that because I tested the Idea and just
copied the code.
Have Fun

[kurtz le pirate] Re: File handle and macros [346 days 14 hours and 15 minutes ago]

Thu, 1 May 2025 08:44:55 GMT

On 30/04/2025 19:20, Bald Eagle wrote:
> kurtz le pirate <kur### [at] freefr> wrote:
> 
>> So we can't pass a file handle as a parameter ?
> 
> https://wiki.povray.org/content/Reference:File_I/O_Directives
> 
> 
> 
> You can use ifdef and defined, so I'm wondering if it's just a special kind of
> identifier that gets handled a little differently - just like things in the
> scene parser get handled differently by the function VM.
> 
> Try assigning another identifier the value of your file handle.
> 
> #declare Temp = FILE_HANDLE_IDENTIFIER;
> 
> try sending its value to the debug stream
> 
> basically try operating on it in any way that you can think of, and then maybe
> there's some sort of workaround that might be possible.
> 
> The other option is to use parse_string to use the literal name of the file
> handle as a string argument to your macro, and then parse it _inside_ your macro
> as an identifier.  Because the string and the identifier are two different
> things.


Thank you for your advice but in what I was hoping to do "parse_string" 
is not suitable.



An other test.
--------------------------------------------------------------------------
#macro fwrite (FileHandle, texte)
	#write (FileHandle, concat(texte,"\n") )
#end

#fopen FileHandle1 "test1.txt" write
#fopen FileHandle2 "test2.txt" write
#fopen FileHandle3 "test3.txt" write

fwrite (FileHandle1, "writing to test1")
fwrite (FileHandle2, "writing to test2")
fwrite (FileHandle3, "writing to test3")

#fclose FileHandle3
#fclose FileHandle2
#fclose FileHandle1
--------------------------------------------------------------------------

Give the same error : Parse Error: Expected 'macro parameter', file 
identifier found instead.



For #fopen, the doc say : "The file handle identifier created by #fopen 
is always global and remains in effect (and the file remains open) until 
the scene parsing is complete or until you #fclose the file."



Conclusion : The file handle is an IDENTIFIER, that we cannot store in 
variable.





Of course this code work :
--------------------------------------------------------------------------
#fopen FileHandle1 "test1.txt" write
#fopen FileHandle2 "test2.txt" write
#fopen FileHandle3 "test3.txt" write

#write (FileHandle1, "writing to test1\n")
#write (FileHandle2, "writing to test2\n")
#write (FileHandle3, "writing to test3\n")

#fclose FileHandle3
#fclose FileHandle2
#fclose FileHandle1
--------------------------------------------------------------------------

...but the advantages of having one and only one macro that writes to 
files are lost :(






-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: File handle and macros [347 days 5 hours and 35 minutes ago]

Wed, 30 Apr 2025 17:25:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:

> So we can't pass a file handle as a parameter ?

https://wiki.povray.org/content/Reference:File_I/O_Directives



You can use ifdef and defined, so I'm wondering if it's just a special kind of
identifier that gets handled a little differently - just like things in the
scene parser get handled differently by the function VM.

Try assigning another identifier the value of your file handle.

#declare Temp = FILE_HANDLE_IDENTIFIER;

try sending its value to the debug stream

basically try operating on it in any way that you can think of, and then maybe
there's some sort of workaround that might be possible.

The other option is to use parse_string to use the literal name of the file
handle as a string argument to your macro, and then parse it _inside_ your macro
as an identifier.  Because the string and the identifier are two different
things.

- BW

[kurtz le pirate] Re: File handle and macros [347 days 7 hours and 1 minute ago]

Wed, 30 Apr 2025 15:59:17 GMT

On 30/04/2025 11:48, jr wrote:
> hi,
> 
>> I have a problem with the file handle parameters in macros.
>> ...
>> So we can't pass a file handle as a parameter ?
> 
> I think that is correct.  in my 'Filed()' macro[*] I open & close a file within
> the same macro, the only way I could make it work.
> 


Thanks for this bad news (but I suspected it) :( :(

And yes, I already know filed.inc. Good job.




-- 
kurtz le pirate
compagnie de la banquise

[jr] Re: File handle and macros [347 days 13 hours and 10 minutes ago]

Wed, 30 Apr 2025 09:50:00 GMT

hi,

> I have a problem with the file handle parameters in macros.
> ...
> So we can't pass a file handle as a parameter ?

I think that is correct.  in my 'Filed()' macro[*] I open & close a file within
the same macro, the only way I could make it work.


regards, jr.

[*]
<https://drive.google.com/file/d/10pGH0yi_-8aBTQvTwQPB4AdfRl9JsTGg/view?usp=sharing>

[kurtz le pirate] File handle and macros [347 days 13 hours and 32 minutes ago]

Wed, 30 Apr 2025 09:28:18 GMT

Hello,


I have a problem with the file handle parameters in macros.

The following SDL shows the problem :
--------------------------------------------------------------------------
  1 : #macro fwrite (FILE, texte)
  2 : 	#write (FILE, concat(texte,"\n") )
  3 : #end
  4 :
  5 :
  6 : #macro OpenFile (FileName)
  7 : 	#fopen FILE_HANDLE_IDENTIFIER FileName write
  8 : 	fwrite (FILE_HANDLE_IDENTIFIER, "bla bla bla")
  9 : 	FILE_HANDLE_IDENTIFIER
10 : #end
11 :
12 :
13 : #declare MyFile1 = OpenFile ("testfile.txt");
14 :
--------------------------------------------------------------------------


Runnins this simple test raise this error :

line 8
Parse Error: Expected 'macro parameter', file identifier found instead


"fwrite" macro take two parameters : the file handle and a string.
On line 8, I call this macro with the two "correct" parameters.

I thought it was "correct" but POV no!

My idea for the fwrite() macro (simplified here) is that it allows you 
to write to different files open at the same time in the same way.


So we can't pass a file handle as a parameter ?
Thank you for your feedback.





-- 
kurtz le pirate
compagnie de la banquise

[Alain Martel] Re: bicubic patch editor [369 days 4 hours and 27 minutes ago]

Tue, 8 Apr 2025 18:33:10 GMT

Le 2025-04-05 Ã  17:15, gulino a Ã©critÂ :
> Thank you but I will try other things for now, I tried doing a tree but it
> didn't work out very well...

You could try with 1 to 3 other spheres inside that one, bound in an 
union and the texture applied at once.

Should be acceptable when viewed from a distance.
Closer ones having more spheres than the farther ones.

[William F Pokorny] Re: Transparent background [370 days 3 hours and 53 minutes ago]

Mon, 7 Apr 2025 19:07:20 GMT

On 4/7/25 14:37, Wilfree wrote:
> this line does not work for me
> 
> my .ini file contains
> 
> Output_Alpha=+UA

Hi,

Some of the error reporting for the options and ini settings could be 
better (Or work at all in this case. My yuqk fork misses the error 
too...). That last line above should have been:

Output_Alpha=on

   or

+ua

Here is a complete scene (use the default camera) showing the command 
line invocation to run it. It's set up for v3.7, but will work with v3.8 
releases too.

//--- this.pov
// Run with:
//      povray this.pov +ua +fn
// If running using an ini file the two key in options are:
//      Output_Alpha=on
//      Output_File_Type=N
#version 3.7;
background { rgbt <0,0,0,1> }
sphere {
     <0,0,2>, 0.2
     pigment { rgb <1,0,0> }
     finish { emission 1 }
}
//---

Bill P.

Aside: The options whether flag or ini formats can be used on either the 
command line or in ini files. Though, mostly, people stick to one method 
of specifying options.

[Wilfree] Re: Transparent background [370 days 4 hours and 20 minutes ago]

Mon, 7 Apr 2025 18:40:00 GMT

Bill P. wrote
try:
>
> background { colour rgbt <0,0,0,1> }
>
> Your three values get promoted to 4 and the 't' values becomes 0 - or no
> transparency. Remember to use +ua and the default png type output(1).
>
>

Wilfrieds reply

this line does not work for me

my .ini file contains

Output_Alpha=+UA                ;
Output_File_Type=N              ;

I want to use this image overlappimg with others to create a 3D game

Please send ma a simple COMPLETE code

[gulino] Re: bicubic patch editor [372 days 1 hour and 40 minutes ago]

Sat, 5 Apr 2025 21:20:00 GMT

Thank you but I will try other things for now, I tried doing a tree but it
didn't work out very well...

[William F Pokorny] Re: bicubic patch editor [373 days 20 hours and 7 minutes ago]

Fri, 4 Apr 2025 02:53:30 GMT

On 4/3/25 19:28, Tor Olav Kristensen wrote:
> The grass-like "texture" is made like Bald Eagle suggested,
> but the shape of the terrain is made with a sum of some simpler
> f_noise3d() functions at different sample frequencies.

Neat!

(Did you intend for Ka to be zero?)

Forgive me for running a yuqk experiment with your scene. I couldn't 
resist given your code.

In the yuqk fork, all the inbuilt functions support noise generator 
selection with an extra parameter - where the underlying code supports 
multiple noise generators.

Attached an image using noise generators 1,2 and 3 top sub-image, downward.

In the bottom sub-image I use all three noise generators in combination(*).

I did not change the 'bumps pattern' noise generator, so it's always 2.

Bill P.

(*) - The idea - hard coded too in yuqk's experimental, f_granite23() 
inbuilt function - uses noise generators in combination. One, so the 
buckles which are sometimes visible are much less likely to be, visible. 
Two, with the thought the result might look different / interesting - 
less like the usual noise based results.

[Tor Olav Kristensen] Re: bicubic patch editor [373 days 23 hours and 30 minutes ago]

Thu, 3 Apr 2025 23:30:00 GMT

Hi Gulino

Below is my suggestion for some code for you to start with.

The grass-like "texture" is made like Bald Eagle suggested,
but the shape of the terrain is made with a sum of some simpler
f_noise3d() functions at different sample frequencies.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

#include "functions.inc"
#include "colors.inc"

global_settings {
    assumed_gamma 1.0
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare GrassFn =
    function {
        pattern {
            bumps
            scale <1.0e-8, 1.0, 1.0e-8>
        }
    }
;

// Frequency multipliers
#declare Ma = pow(2, 0);
#declare Mb = pow(2, 1);
#declare Mc = pow(2, 2);
#declare Md = pow(2, 3);

// Noise sampling offsets
#declare Ya =  0.0;
#declare Yb = -1.2; // +2.0
#declare Yc =  0.0;
#declare Yd =  0.0;

#declare FnA = function { f_noise3d(Ma*x, Ya, Ma*z) };
#declare FnB = function { f_noise3d(Mb*x, Yb, Mb*z) };
#declare FnC = function { f_noise3d(Mc*x, Yc, Mc*z) };
#declare FnD = function { f_noise3d(Md*x, Yd, Md*z) };

// Frequency amplitudes
#declare Ka = 0.0;
#declare Kb = 2.0;
#declare Kc = 0.3; // 1.6
#declare Kd = 0.1;

#declare GrassHeight = 0.04;

#declare K = 1.0 + Ka + Kb + Kc + Kd + GrassHeight;

#declare TerrainFn =
    function {
        (
            1.0*y
            + Ka*FnA(x, 0.0, z)
            + Kb*FnB(x, 0.0, z)
            + Kc*FnC(x, 0.0, z)
            + Kd*FnD(x, 0.0, z)
            + GrassHeight*GrassFn(x, 0.0, z)
        )/K // To avoid "wrap around"
    }
;

union {
    height_field {
        function 1000, 1000 { TerrainFn(x, 0.0, 1.0 - y) }
        smooth
        pigment {
            function { FnC(x, 0, z) }
            color_map {
                [ 0.1 color rgb <1.0, 0.7, 0.0> ]
                [ 0.6 color rgb <0.3, 0.5, 0.0> ]
            }
        }
        // pigment { color rgb <0.6, 0.8, 0.0> }
        // no_shadow
    }
    union {
        #for (X, 0, 1, 1/32)
            #for (Z, 0, 1, 1/32)
                #declare Y = TerrainFn(X, 0, Z);
                sphere { <X, Y, Z>, 0.005 }
            #end // for
        #end // for
        pigment { color White }
    }
    translate -<1, 0, 1>/2
    scale 1000*<1, 1, 1>
}

box {
    <-1e8, -10, -1e8>, <+1e8, 0, +1e8>
    pigment { color SeaGreen }
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

sky_sphere {
    pigment { color SkyBlue }
}

light_source {
    1e8*<-2, +1, -7>
    color White
}

#declare AspectRatio = image_width/image_height;

camera {
    right AspectRatio*x
    location < 0, +700, -1400>*0.8
    look_at < 0,  +450,  0>
    // angle 40
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

[Bald Eagle] Re: bicubic patch editor [374 days 8 hours and 5 minutes ago]

Thu, 3 Apr 2025 14:55:00 GMT

"gulino" <nomail@nomail> wrote:
> Bozo instead of gradient y
> I think before was better
>
> pigment {
>         bozo scale 3 turbulence .9
>         pigment_map {
>             [0.00 color rgb <0.3, 0.5, 0.0>]
>             [0.50 color rgb <0.3, 0.6, 0.0>]
>             [1.00 color rgb <0.3, 0.7, 0.0>]
>         }
>     }

It all comes down to what you want it to look like, and what you're going to add
to it.

Suggestions for experiments to explore:

1. Layered textures.
You can do things like object {MyObject texture {Texture1} texture {Texture2}}
and Texture2 will be "on top of" Texture1 like a layer of paint over a coat of
primer.
If your Texture2 has rgbt 1 as an entry, it will be clear, and you can then see
Texture1.  That way you can keep your old grass texture and add some yellowish
stuff on top of it - but not everywhere.

2. uv_mapping
you can take textures or images and paste them onto your surface in a way that
follows the surface rather than being dependent on the <x, y, z> coordinates of
the space where your object's surface is at.

3. "Planting"
you can learn how to use the trace () function to "scan" the heightfield surface
and place an upright thin cylinder at the exact "ground level" at that location.
 Lots little green cylinders will add a grass effect.  Adding a gradient with
yellow at the top, and it might look even better.   Do the narrow triangle thing
like jr suggested, and it's more grass-blade like.  Rotate them so that they
lean, and then randomly rotate their orientation, and it makes for more
"realism".
(Also, since you have a function generating your height_field, you can skip
trace () altogether and just use the y-value of your function at that <x, z>
location.)

- BW

[gulino] Re: bicubic patch editor [374 days 8 hours and 30 minutes ago]

Thu, 3 Apr 2025 14:30:00 GMT

Bozo instead of gradient y
I think before was better

pigment {
        bozo scale 3 turbulence .9
        pigment_map {
            [0.00 color rgb <0.3, 0.5, 0.0>]
            [0.50 color rgb <0.3, 0.6, 0.0>]
            [1.00 color rgb <0.3, 0.7, 0.0>]
        }
    }

[MichaelJF] Re: bicubic patch editor [375 days 4 hours and 23 minutes ago]

Wed, 2 Apr 2025 18:36:46 GMT

Am 02.04.2025 um 17:20 schrieb gulino:
> What you think? Looks grass?
It looks like a well-tended green and would make a beautiful golf 
course. If you want to model a steppe, a prairie or a Spanish dehesa 
(that's what your picture reminds me most of), the grass texture should 
be randomly disturbed, for example by the bozo or the agate pattern as 
Bald Eagle suggested.

IMO you're making good progress.

Best regards
Michael

[Bald Eagle] Re: bicubic patch editor [375 days 7 hours and 15 minutes ago]

Wed, 2 Apr 2025 15:45:00 GMT

"gulino" <nomail@nomail> wrote:
> What you think? Looks grass?

It does - now maybe rather than just a green pigment, you can use a pigment
pattern like "bozo" and a color map that fades from green to yellowish-green, to
give some variety to the scene.

Then you can add a few isosurface boulders jutting up out of the ground, some
trees, a gradient sky_sphere (or an HDR light probe), trees...

I think you'll enjoy building it up piece by piece.

- BW

[gulino] Re: bicubic patch editor [375 days 7 hours and 35 minutes ago]

Wed, 2 Apr 2025 15:25:00 GMT

What you think? Looks grass?

[Bald Eagle] Re: bicubic patch editor [375 days 8 hours and 55 minutes ago]

Wed, 2 Apr 2025 14:05:00 GMT

"gulino" <nomail@nomail> wrote:
> Thanks for the help but what exactly is this? I was aiming to make a grass
> texture like this

I'm just getting the functions to work without any errors.
Scale the functions so that they make something along the lines of what you
want.

Do that by multiplying or dividing the x, y, and z in the function call.

You may find Mike Williams' isosurface tutorial helpful with regard to working
with functions in POV-Ray.
https://wiki.povray.org/content/User:BillW

Also, as jr said, if you can't get the function or the normal method to work,
then you can use a set of macros to model actual blades of grass to better give
you what you're looking for.

Also, like jr said, you have 30 years of people writing and posting scenes here.
Search for "grass", "landscape", "heightfield", etc and see what pops up.
Use the website search feature, but also use a search engine to see what people
have done and have posted elsewhere.

- BW

[jr] Re: bicubic patch editor [375 days 9 hours and 10 minutes ago]

Wed, 2 Apr 2025 13:50:00 GMT

hi,

"gulino" <nomail@nomail> wrote:
> Thanks for the help but what exactly is this? I was aiming to make a grass
> texture like this

individual grass blades (meshes) "planted" is one option, if you search for
"grass macro" or variations on this site, there'll be plenty of "hits", some
going back _years_ :-).  see for instance this thread:
<https://news.povray.org/povray.binaries.images/thread/%3C46972e23%40news.povray.org%3E/>.
 hth.

regards, jr.

[gulino] Re: bicubic patch editor [375 days 9 hours and 20 minutes ago]

Wed, 2 Apr 2025 13:40:00 GMT

Thanks for the help but what exactly is this? I was aiming to make a grass
texture like this

[Bald Eagle] Re: bicubic patch editor [375 days 12 hours and 15 minutes ago]

Wed, 2 Apr 2025 10:45:00 GMT

I got derailed last night, but did not forget.

Tested, working code:


#version 3.8;
global_settings {
 assumed_gamma 1.0
}

#include "functions.inc"

#declare E = 0.00001;


#declare Location = <0, 500, -1000>;
camera {
 location Location
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
}


sky_sphere {pigment {rgb 1}}

light_source {<3000, 2000, -2000> rgb 1}
sky_sphere {pigment {rgb 1}}

#declare Line = 0.01;

#declare E = 0.0000001;

#declare Plain = function (x, y, z, P0, P1, P2, P3, P4, P5) {f_ridged_mf (x,y,z,
P0, P1, P2, P3, P4, P5) }
#declare Grass = function {pigment {bumps}}
#declare GrassHeight = 10;
#declare PlainAndGrass = function (x, y, z, P0, P1, P2, P3, P4, P5) {Plain (x,
y, z, P0, P1, P2, P3, P4, P5) +
Grass (x, y,z).red*GrassHeight}


height_field {
   function 1000, 2000 {PlainAndGrass (x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
   smooth
    pigment {
       color rgb <0.3, 0.5, 0.0>
    }
    translate <-0.5, 0, -0.5>
    scale <1000, 100, 1300>
}

[Bald Eagle] Re: bicubic patch editor [376 days 3 hours and 10 minutes ago]

Tue, 1 Apr 2025 19:50:00 GMT

"gulino" <nomail@nomail> wrote:

> #declare Plain = function {f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
> #declare Grass = function {pigment {bumps}
> #declare GrassHeight = 10;
> #declare PlainAndGrass = function {Plain (x, y, z) +
> Grass (x, y,z).red*GrassHeight}
>
> "Invalid number of parameters, 3 suplied, 8 required"

Then like I said, try:

#declare Plain = function {f_ridged_mf(x,y,z, P0, P1, P2, P3, P4, P5) }
#declare Grass = function {pigment {bumps}} // <--- you need a closing curly
brace
#declare GrassHeight = 10;
#declare PlainAndGrass = function {Plain (x, y, z, 2.3, 7.0, 5.0, -2, 1, 3.0) +
Grass (x, y,z).red*GrassHeight}


Then declare Pattern = pigment {function {PlainAndGrass (x, y, z, P0, P1, P2,
P3, P4, P5)}}
(Thanks for your patience. ;) This is easier when I'm home and can provide
functional, tested code that I can run through the parser.)

- BW

[gulino] Re: bicubic patch editor [376 days 3 hours and 35 minutes ago]

Tue, 1 Apr 2025 19:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> {sigh}
> Since you're supplying the other 6 parameters as numeric values in your function
> declaration, you don't need to supply them as actual parameters when you call
> the function.
>
> try:
> #declare PlainAndGrass = function {Plain (x, y, z) +
> Grass (x, y,z).red*GrassHeight}
>
> If you want to keep it like it is in the final function, rewrite Plain using
> (x, y, z, P0, P1, P2, P3, P4, P5) in both parentheses and curly braces.
>
> But just try x,y, z for now.
>
> - BW

#declare Plain = function {f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
#declare Grass = function {pigment {bumps}
#declare GrassHeight = 10;
#declare PlainAndGrass = function {Plain (x, y, z) +
Grass (x, y,z).red*GrassHeight}

"Invalid number of parameters, 3 suplied, 8 required"
what

[Bald Eagle] Re: bicubic patch editor [376 days 4 hours ago]

Tue, 1 Apr 2025 19:00:00 GMT

{sigh}
Since you're supplying the other 6 parameters as numeric values in your function
declaration, you don't need to supply them as actual parameters when you call
the function.

try:
#declare PlainAndGrass = function {Plain (x, y, z) +
Grass (x, y,z).red*GrassHeight}

If you want to keep it like it is in the final function, rewrite Plain using
(x, y, z, P0, P1, P2, P3, P4, P5) in both parentheses and curly braces.

But just try x,y, z for now.

- BW

[gulino] Re: bicubic patch editor [376 days 4 hours and 15 minutes ago]

Tue, 1 Apr 2025 18:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "gulino" <nomail@nomail> wrote:
>
> > but I have a error in
> > Grass (x, y,z)*GrassHeight}
> >
> > "Expected '.', * found instead"
>
> Yeah - inbuilt pigment functions return a full rgbft vector, so you have to
> specify which vector component you want to use in the crippled user-defined
> scalar function you're writing.
>
> So, just do:
> Grass (x, y,z).red*GrassHeight
>
> - BW


#declare PlainAndGrass = function {Plain (x, y, z, 2.3, 7.0, 5.0, -2, 1, 3.0) +
Grass (x, y,z).red*GrassHeight}

"Invalid number of parameters 9 supplied, 3 required"

[Bald Eagle] Re: bicubic patch editor [376 days 4 hours and 45 minutes ago]

Tue, 1 Apr 2025 18:15:00 GMT

"gulino" <nomail@nomail> wrote:

> but I have a error in
> Grass (x, y,z)*GrassHeight}
>
> "Expected '.', * found instead"

Yeah - inbuilt pigment functions return a full rgbft vector, so you have to
specify which vector component you want to use in the crippled user-defined
scalar function you're writing.

So, just do:
Grass (x, y,z).red*GrassHeight

- BW

[Alain Martel] Re: bicubic patch editor [376 days 4 hours and 55 minutes ago]

Tue, 1 Apr 2025 18:05:18 GMT

Le 2025-04-01 Ã  10:52, gulino a Ã©critÂ :

> height_field {
>    function 1, 2 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }
>    smooth
>    scale <400, 100, 400>
>     pigment { checker rgb 0.05 rgb 1 scale <20, 20, 20>}
>     translate <-200, -120, -200>
> }
> 
> error in: function 1, 2 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }
> 
> "Expected 'operator', ( found instead"
> 
> What is wrong?
> 
> 
1) You need to #include functions.inc before.

2) The numbers after function are the U and V resolution, or number of 
samples, used to evaluate the function when creating the height field.
Values of 1,2 mean 1 sample in the U axis and 2 samples in the V axis, 
or a line single between two points. You won't even see that in a scene. 
You need a strict minimum of 2,2.

In order to have something acceptable, a reasonable starting point would 
be something like 100,100.

[gulino] Re: bicubic patch editor [376 days 5 hours and 15 minutes ago]

Tue, 1 Apr 2025 17:45:00 GMT

> The other thing you could do is add/subtract a scaled bumps/spotted pigment as
> part of your heightfield function to get an actual physical displacement.
>
> #declare Plain = function {f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
> #declare Grass = function {pigment {bumps}
> #declare GrassHeight = 10;
> #declare PlainAndGrass = function {Plain (x, y, z, ....) + Grass (x, y,
> z)*GrassHeight}
>
> height_field {function 100, 200 { PlainAndGrass (....)} ....
>
> Hope that makes sense.
>
> - BW

I tried to do this,

#declare Plain = function {f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
#declare Grass = function {pigment {bumps}
#declare GrassHeight = 10;
#declare PlainAndGrass = function {Plain (x, y, z, 2.3, 7.0, 5.0, -2, 1, 3.0) +
Grass (x, y,z)*GrassHeight}


height_field {
   function 100, 200 {PlainAndGrass (x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
   smooth
   scale <1000, 100, 1300>
    pigment {
       color rgb <0.3, 0.5, 0.0>
    }
    translate <-500, -120, -1000>
}

but I have a error in
Grass (x, y,z)*GrassHeight}

"Expected '.', * found instead"

[Bald Eagle] Re: bicubic patch editor [376 days 5 hours and 50 minutes ago]

Tue, 1 Apr 2025 17:10:00 GMT

"gulino" <nomail@nomail> wrote:
> Thanks for the help, I managed to get this result with these values:
>
> height_field {
>    function 100, 200 { f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
>    smooth
>    scale <1000, 100, 1300>
>     pigment {
>        color rgb <0.3, 0.5, 0.0>
>     }
>     normal {
>         bumps 0.3 scale 0.4
>     }
>     translate <-500, -120, -1000>
> }
>
> It can be better but looks like a plain at least. Also I put normal bumps to
> make it more like grass but it didn't work so well, do you guys have some idea
> how to it?

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

The relative bump size can be scaled using the bump_size modifier. The bump size
number can be any number other than 0 but typical values are from about 0.1 to
as high as 4.0 or 5.0.

normal {
  bump_map {
    gif "stuff.gif"
    bump_size 5.0
    }
  }

Originally bump_size could only be used inside a bump map but it can now be used
with any normal.

You can also move the camera back a bit, and perhaps move your light source to
give a more raking angle to make some more shadows and give a more defined
texture/normal.

The other thing you could do is add/subtract a scaled bumps/spotted pigment as
part of your heightfield function to get an actual physical displacement.

#declare Plain = function {f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
#declare Grass = function {pigment {bumps}
#declare GrassHeight = 10;
#declare PlainAndGrass = function {Plain (x, y, z, ....) + Grass (x, y,
z)*GrassHeight}

height_field {function 100, 200 { PlainAndGrass (....)} ....

Hope that makes sense.

- BW

[gulino] Re: bicubic patch editor [376 days 6 hours and 10 minutes ago]

Tue, 1 Apr 2025 16:50:00 GMT

Thanks for the help, I managed to get this result with these values:

height_field {
   function 100, 200 { f_ridged_mf(x,y,z, 2.3, 7.0, 5.0, -2, 1, 3.0) }
   smooth
   scale <1000, 100, 1300>
    pigment {
       color rgb <0.3, 0.5, 0.0>
    }
    normal {
        bumps 0.3 scale 0.4
    }
    translate <-500, -120, -1000>
}

It can be better but looks like a plain at least. Also I put normal bumps to
make it more like grass but it didn't work so well, do you guys have some idea
how to it?

[Bald Eagle] Re: bicubic patch editor [376 days 6 hours and 45 minutes ago]

Tue, 1 Apr 2025 16:15:00 GMT

"gulino" <nomail@nomail> wrote:

> error in: function 1, 2 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }
>
> "Expected 'operator', ( found instead"
>
> What is wrong?

Like MichaelJF pointed out, you need to put
#include "functions.inc" in a line preceding your use of the function.

Why?
Because all functions.inc does is give a more human-readable and memorable name
to internal function #59:
#declare f_ridged_mf = function { internal(59) }

So, alternatively, you could just get right down to it and use
#declare f_ridged_mf = function { internal(59) }
in your scene _instead of_
#include "functions.inc"

You can't do BOTH, unless you
#undef _ridged_mf
since you can't declare a function twice.

With regard to the number of arguments in your function call, when I'm using a
new language, syntax, or function with a large number of anonymous/magic
arguments, I tend to copy/paste the documentation for the function into my
scene, and then I have some identification/explanation/meaning for each of the
arguments, as well as a proper count.

So I would
#declare P0 = 0.5;  // explanatory comment
.....
#declare P5 = 3; // noise generator

And then you can easily use and edit your function call as you experiment with
your scene:

f_ridged_mf(x,y,z, P0, P1, P2, P3, P4, P5):

I also tend to just copy the documentation into a comment block at the end of my
scene so I don't have to constantly be switching editor windows to go look up
what the heck the 7th argument in my function controls (in case I read it wrong
or misunderstood the first time)...

/*
P0 : H is the negative of the exponent of the basic noise frequencies used in
building these functions (each frequency f's amplitude is weighted by the factor
fE- H ). When H is 1, the fractalization is relatively smooth. As H nears 0, the
high frequencies contribute equally with low frequencies
P1 : Lacunarity is the multiplier used to get from one octave to the next in the
fractalization. This parameter affects the size of the frequency gaps in the
pattern. (Use values greater than 1.0)
P2 : Octaves is the number of different frequencies added to the fractal. Each
octave frequency is the previous one multiplied by Lacunarity. So, using a large
number of octaves can get into very high frequencies very quickly
P3 : Offset gives a fractal whose fractal dimension changes from altitude to
altitude. The high frequencies at low altitudes are more damped than at higher
altitudes, so that lower altitudes are smoother than higher areas
P4 : Gain weights the successive contributions to the accumulated fractal result
to make creases stick up as ridges
P5 : Generator type used to generate the noise3d. 0, 1, 2 and 3 are legal
values.
*/

- Hang in there - you'll get it.  :)

- BE

[MichaelJF] Re: bicubic patch editor [376 days 7 hours and 55 minutes ago]

Tue, 1 Apr 2025 15:05:09 GMT

Am 01.04.2025 um 16:52 schrieb gulino:

> height_field {
>    function 1, 2 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }
>    smooth
>    scale <400, 100, 400>
>     pigment { checker rgb 0.05 rgb 1 scale <20, 20, 20>}
>     translate <-200, -120, -200>
> }

You should include "functions.inc" first to define the function 
f_ridged_mf. In addition, you should specify a higher resolution and 
shorten your parameter list one parameter. Soemthing like:

#include "functions.inc"

height_field {
   function 100, 200 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0) }
   smooth
   scale <400, 100, 400>
    pigment { checker rgb 0.05 rgb 1 scale <20, 20, 20>}
    translate <-200, -120, -200>
}

Best regards
Michael

[gulino] Re: bicubic patch editor [376 days 8 hours and 5 minutes ago]

Tue, 1 Apr 2025 14:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "gulino" <nomail@nomail> wrote:
> >  can someone make a
> > simple example for me to see?
>
> There were several examples in the thread I posted:
>
https://news.povray.org/povray.general/thread/%3Cweb.63ea928499ce13121f9dae3025979125%40news.povray.org%3E/?ttop=4449
70
> &toff=150&mtop=439826
>
>   height_field {
>     function 500,500 { pattern { bozo scale 0.08 } }
>     smooth
>     pigment {rgb z}
>     scale <1,0.4,1>
>     }

height_field {
  function 1, 2 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }
  smooth
  scale <400, 100, 400>
   pigment { checker rgb 0.05 rgb 1 scale <20, 20, 20>}
   translate <-200, -120, -200>
}

error in: function 1, 2 { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }

"Expected 'operator', ( found instead"

What is wrong?

[Bald Eagle] Re: bicubic patch editor [377 days 4 hours and 45 minutes ago]

Mon, 31 Mar 2025 18:15:00 GMT

"gulino" <nomail@nomail> wrote:
>  can someone make a
> simple example for me to see?

There were several examples in the thread I posted:
https://news.povray.org/povray.general/thread/%3Cweb.63ea928499ce13121f9dae3025979125%40news.povray.org%3E/?ttop=444970
&toff=150&mtop=439826

  height_field {
    function 500,500 { pattern { bozo scale 0.08 } }
    smooth
    pigment {rgb z}
    scale <1,0.4,1>
    }

[gulino] Re: bicubic patch editor [377 days 5 hours and 15 minutes ago]

Mon, 31 Mar 2025 17:45:00 GMT

Sorry but I am really struggling with this, I have no idea how to put a function
in a heightfield because I only find examples with images, can someone make a
simple example for me to see?
I tried this just to test:

height_field {
   function {
    sin(x * 0.1) * 5
  }
  smooth
  scale <100, 100, 100>

}
but it give me a error in "funcion {"
error:
expected numeric expression, { found instead

[kurtz le pirate] Re: bicubic patch editor [377 days 6 hours and 12 minutes ago]

Mon, 31 Mar 2025 16:48:03 GMT

On 31/03/2025 18:00, Alain Martel wrote:
> Le 2025-03-31 Ã  10:17, gulino a Ã©critÂ :
> 
>> I want to make a plain like this image, I think heightfields will not 
>> work
>> because it's for mountains. I am not sure how many patches but for 
>> sure more
>> than one. It would be nice if there is a program that for example can 
>> make these
>> and give me the value of the points because it seems very hard doing 
>> by hand
> Heightfields can be used for mountains, but, that's just one of the many 
> way they can be used.
> What you show here can perfectly be done using a heightfield.


Yes, heightfield is a good candidate.

I also think that an isosurface using one of pov's internal functions 
should also do the trick.


#declare plain = height_field {
  function Res,Res {
    <<function here>>
    }
   smooth
   translate <-0.50, 0, -0.50>
   }


All that's left is to find the right function and parameters ;)
<https://www.povray.org/documentation/view/3.60/449/>
<https://www.povray.org/documentation/view/3.60/448/>


Simple combinaison of trigonometrics functions and/or f_ridged_mf() can 
be used as a base.





-- 
kurtz le pirate
compagnie de la banquise

[Alain Martel] Re: bicubic patch editor [377 days 7 hours ago]

Mon, 31 Mar 2025 16:00:03 GMT

Le 2025-03-31 Ã  10:17, gulino a Ã©critÂ :

> I want to make a plain like this image, I think heightfields will not work
> because it's for mountains. I am not sure how many patches but for sure more
> than one. It would be nice if there is a program that for example can make these
> and give me the value of the points because it seems very hard doing by hand
Heightfields can be used for mountains, but, that's just one of the many 
way they can be used.
What you show here can perfectly be done using a heightfield.

[Bald Eagle] Re: bicubic patch editor [377 days 7 hours and 15 minutes ago]

Mon, 31 Mar 2025 15:45:00 GMT

"gulino" <nomail@nomail> wrote:

> Then there is no reason to use patches. Can you help me how to do it with
> heightfield?

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

You can use either an image file or a pigment pattern to control the elevation,
or you can use a function if you have an equation that would give you the kind
of surface that you want.

f_hetero_mf(x,y,z, P0, P1, P2, P3, P4, P5): f_hetero_mf (x,0,z) makes
multifractal height fields and patterns of 1/f noise. Multifractal refers to
their characteristic of having a fractal dimension which varies with altitude.
Built from summing noise of a number of frequencies, the hetero_mf parameters
determine how many, and which frequencies are to be summed. An advantage to
using these instead of a height_field {} from an image (a number of height field
programs output multifractal types of images) is that the hetero_mf function
domain extends arbitrarily far in the x and z directions so huge landscapes can
be made without losing resolution or having to tile a height field. Other
functions of interest are f_ridged_mf and f_ridge.

P0 : H is the negative of the exponent of the basic noise frequencies used in
building these functions (each frequency f's amplitude is weighted by the factor
f - H ). In landscapes, and many natural forms, the amplitude of high frequency
contributions are usually less than the lower frequencies. When H is 1, the
fractalization is relatively smooth (1/f noise). As H nears 0, the high
frequencies contribute equally with low frequencies as in white noise.
P1 : Lacunarity is the multiplier used to get from one octave to the next. This
parameter affects the size of the frequency gaps in the pattern. Make this
greater than 1.0
P2 : Octaves is the number of different frequencies added to the fractal. Each
Octave frequency is the previous one multiplied by Lacunarity, so that using a
large number of octaves can get into very high frequencies very quickly.
P3 : Offset is the base altitude (sea level) used for the heterogeneous scaling
P4 : T scales the heterogeneity of the fractal. T=0 gives straight 1/f (no
heterogeneous scaling). T=1 suppresses higher frequencies at lower altitudes
P5 : Generator type used to generate the noise3d. 0, 1, 2 and 3 are legal
values.

https://wiki.povray.org/content/Reference:Functions.inc

https://news.povray.org/povray.general/thread/%3Cweb.63ea928499ce13121f9dae3025979125%40news.povray.org%3E/?ttop=444970
&toff=150&mtop=439826

See what you can to work with that, and then come back with any questions.
Also there are the files in the example directories supplied with your POV-Ray
distribution, and also the drop-down Insert Menu in the editor.
Probably under Special Shapes > Isosurfaces and Height_Fields, ....

- BW

[gulino] Re: bicubic patch editor [377 days 7 hours and 45 minutes ago]

Mon, 31 Mar 2025 15:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "gulino" <nomail@nomail> wrote:
>
> > I want to make a plain like this image, I think heightfields will not work
> > because it's for mountains. I am not sure how many patches but for sure more
> > than one. It would be nice if there is a program that for example can make these
> > and give me the value of the points because it seems very hard doing by hand
>
> I would think that a heightfield would be perfectly fine for that.
>
> You can model anything from a perfectly flat plane to a very rough mountainous
> terrain with a detailed enough heightfield.
>
> But if you want to do the Bezier patches - that's a topic we can get into in
> more detail.
>
> - BW

Then there is no reason to use patches. Can you help me how to do it with
heightfield?

[Bald Eagle] Re: bicubic patch editor [377 days 8 hours ago]

Mon, 31 Mar 2025 15:00:00 GMT

"gulino" <nomail@nomail> wrote:

> I want to make a plain like this image, I think heightfields will not work
> because it's for mountains. I am not sure how many patches but for sure more
> than one. It would be nice if there is a program that for example can make these
> and give me the value of the points because it seems very hard doing by hand

I would think that a heightfield would be perfectly fine for that.

You can model anything from a perfectly flat plane to a very rough mountainous
terrain with a detailed enough heightfield.

But if you want to do the Bezier patches - that's a topic we can get into in
more detail.

- BW

[gulino] Re: bicubic patch editor [377 days 8 hours and 40 minutes ago]

Mon, 31 Mar 2025 14:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "gulino" <nomail@nomail> wrote:
> > Hello, there is a program that can make bicubic patches for Povray?
>
> I guess also the question(s) should be - how many patches do you need to model,
> and what is your goal?  Do you need to interactively model the patches, or do
> you need to have the patches pass through certain points?
>
> Can you use heightfields?
>
> If you can use heightfields or functions, then you can craft the heightfields
> using SDL in POV-Ray itself.
>
> - BW

I want to make a plain like this image, I think heightfields will not work
because it's for mountains. I am not sure how many patches but for sure more
than one. It would be nice if there is a program that for example can make these
and give me the value of the points because it seems very hard doing by hand

[Bald Eagle] Re: bicubic patch editor [377 days 10 hours and 15 minutes ago]

Mon, 31 Mar 2025 12:45:00 GMT

"gulino" <nomail@nomail> wrote:
> Hello, there is a program that can make bicubic patches for Povray?

I guess also the question(s) should be - how many patches do you need to model,
and what is your goal?  Do you need to interactively model the patches, or do
you need to have the patches pass through certain points?

Can you use heightfields?

If you can use heightfields or functions, then you can craft the heightfields
using SDL in POV-Ray itself.

- BW

[MichaelJF] Re: bicubic patch editor [377 days 18 hours and 59 minutes ago]

Mon, 31 Mar 2025 04:00:52 GMT

Am 30.03.2025 um 23:39 schrieb gulino:
> Hello, there is a program that can make bicubic patches for Povray?
> 

Please look at the discussion in:

https://news.povray.org/povray.binaries.images/thread/%3Cweb.67368d2782bd3fc14c71940bedfc8715%40news.povray.org%3E/

Best regaqrds
Michael

[yesbird] Re: bicubic patch editor [377 days 23 hours and 43 minutes ago]

Sun, 30 Mar 2025 23:17:07 GMT

On 31/03/2025 00:39, gulino wrote:
> Hello, there is a program that can make bicubic patches for Povray?
> 

I am not sure about bicubic patches, but Blender has a rich editor
and supports Povray:
https://docs.blender.org/manual/en/4.1/addons/render/povray.html

Also you can check my plugin for C4D, if you have one:
https://github.com/syanenko/cinema2pov
-- 
YB

[yesbird] Re: bicubic patch editor [377 days 23 hours and 48 minutes ago]

Sun, 30 Mar 2025 23:12:28 GMT

On 31/03/2025 00:39, gulino wrote:
> Hello, there is a program that can make bicubic patches for Povray?
> 

I am not sure about bicubic patches, but Blender has a reach editor
and supports Povray:
https://docs.blender.org/manual/en/4.1/addons/render/povray.html
-- 
YB

[gulino] bicubic patch editor [378 days 1 hour and 20 minutes ago]

Sun, 30 Mar 2025 21:40:00 GMT

Hello, there is a program that can make bicubic patches for Povray?

[ingo] Re: Program to make SOR, spline etc [378 days 7 hours and 10 minutes ago]

Sun, 30 Mar 2025 15:50:00 GMT

"gulino" <nomail@nomail> wrote:
> "ingo" <nomail@nomail> wrote:
> > Spilineditor

>
> This can do prism?

Yes, on export you can choose the shape type.

ingo

[gulino] Re: Program to make SOR, spline etc [378 days 7 hours and 30 minutes ago]

Sun, 30 Mar 2025 15:30:00 GMT

"ingo" <nomail@nomail> wrote:
> Spilineditor
>
>
https://web.archive.org/web/20050212112645/http://www.flashnet.it/users/fn027571/spil/index.html
>
> Simple and straight forward. Just tested it under win11 and it still works
> fine,,
>
> Ingo

This can do prism?

[Bald Eagle] Re: Conversione file .stl in .inc per povray [379 days 10 hours and 10 minutes ago]

Sat, 29 Mar 2025 12:50:00 GMT

As MichaelJF pointed out, you need to have some sort of LIGHT source to be able
to see your mesh.

Try this:


#version 3.8;
global_settings {
 assumed_gamma 1.0
}

#declare Location = <0, -12, -40>;
camera {
 location Location
 right x*image_width/image_height
 up y
 look_at <0, -12, 0>
}

sky_sphere {pigment {rgb 1}}
light_source {<20, 0, -50> rgb 1}

#declare E = 0.00001;
#include "l383hdt.inc"

#declare Min = min_extent (m_L383HDT);
#declare Max = max_extent (m_L383HDT);

#debug concat ("Min = ", vstr(3, Min, ", ", 0, 3), " \n")
#debug concat ("Max = ", vstr(3, Max, ", ", 0, 3), " \n")

object {m_L383HDT texture {pigment {rgb z*0.2} finish {specular 0.2}} rotate
x*90 translate y*Max.y }

- Bill

[MichaelJF] Re: Conversione file .stl in .inc per povray [379 days 16 hours and 20 minutes ago]

Sat, 29 Mar 2025 06:40:25 GMT

Am 29.03.2025 um 06:53 schrieb Ignax:
> Uso Sketchup per costruire il mio modello; esporto il file ottenuto in formato
> "STL". Poi uso "stl2pov" per convertire il file "STL" in file"INC"senza
> apparenti problemi. Quando carico il file INC ottenuto in Povray, render tutto
> nero. Cosa sbaglio? Devo usare altre strategie per costruire i miei modelli?
> Grazie
I hope

  https://www.deepl.com/de/translator

gave the right translation.

Your file declars an object only. You can use it in your scene with an 
object-Statement and adding some kind of texture. The definiton of a 
camera and a light_source will help as well.

For example:

light_source { <0,100,0>, <1,1,1> }
include "L383HDT.inc"

camera {
    location <50,15,18>
    look_at <0,0,18>
}


object { m_L383HDT
    pigment { colour rgb <0,1,1> }
}

Best regards
Michael

[Ignax] Re: Conversione file .stl in .inc per povray [379 days 17 hours and 5 minutes ago]

Sat, 29 Mar 2025 05:55:00 GMT

"Ignax" <ign### [at] liberoit> wrote:
Uso Sketchup per costruire il mio modello; esporto il file ottenuto in formato
"STL". Poi uso "stl2pov" per convertire il file "STL" in file"INC"senza
apparenti problemi. Quando carico il file INC ottenuto in Povray, render tutto
nero. Cosa sbaglio? Devo usare altre strategie per costruire i miei modelli?
Grazie

[Ignax] Conversione file .stl in .inc per povray [379 days 17 hours and 20 minutes ago]

Sat, 29 Mar 2025 05:40:00 GMT

Sto cercando di utilizzare "stl2pov" per convertire degli oggetti creati con
Sketchup ed ottenere il contenitore per Povray. Una volta creato il solido in
Sketchup, lo converto in .stl con l'estensione apposita. Utilizzo poi "stl2pov"
mediante comando "dos" ed ottengo il file .inc senza apparenti problemi. Quando
poi carico il file ottenuto in Povray ed eseguo il comando "run", ottengo, come
risultato, una schermata nera. Qualcuno può spiegarmi cosa sbaglio? Devo usare
altre strategie per costruire i miei modelli? Grazie a chi mi potrà aiutare.

[Bald Eagle] Re: Media woes [411 days 9 hours and 10 minutes ago]

Tue, 25 Feb 2025 13:50:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> You forgot to give your big media box a transparent pigment-- rgbt 1. Otherwise,
> when the camera is outside of it, it sees a 'solid black' opaque box, the black
> most likely being v3.7's default black pigment. (The v3.8 betas changed that to
> white, btw.) When the camera is inside the box, it has no black walls to look
> through, and sees the media anyway.

I'm wondering if WFP can have yuqk issue a warning if an object has an interior
block assigned to it with media.

Because I knew what I was looking for and read straight through it at least 3
times.

[William F Pokorny] Re: Trouble cutting objects (I'm going crazy) [411 days 12 hours and 49 minutes ago]

Tue, 25 Feb 2025 10:11:11 GMT

On 2/24/25 10:32, kurtz le pirate wrote:
> Attached is a summary of this "magnificent" scene.
> 
> Do you see the problem ?
> The issue I mentioned earlier has disappeared !
> 
> What is the relationship between the "--disable-no-lc-identifiers" and 
> the differenceÂ  { } opÃ©ration ?
> 
> A new leap into the 5th dimension ðŸ™
> 

"Don't worry, be happy?"

No idea why behavior might have changed. It' very unlikely to be related 
to "--disable-no-lc-identifiers", but stranger things have happened...

Bill (Already crazy) P.

[Kenneth] Re: Media woes [411 days 19 hours and 20 minutes ago]

Tue, 25 Feb 2025 03:40:00 GMT

You forgot to give your big media box a transparent pigment-- rgbt 1. Otherwise,
when the camera is outside of it, it sees a 'solid black' opaque box, the black
most likely being v3.7's default black pigment. (The v3.8 betas changed that to
white, btw.) When the camera is inside the box, it has no black walls to look
through, and sees the media anyway.

[Bald Eagle] Re: Media woes [411 days 22 hours and 50 minutes ago]

Tue, 25 Feb 2025 00:10:00 GMT

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

> If I have the opportunity, I'll post a trimmed-down scene later this evening.


Here you go.

[Bald Eagle] Re: Media woes [412 days 5 hours and 15 minutes ago]

Mon, 24 Feb 2025 17:45:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> Does increasing the mat_trace_level help ? It defaults to 5. Try
> something like 7 or 8.

Perhaps.
If it does, then I don't recall there being anything in the documentation or any
newsgroups threads mentioning this problem or this solution.

It's also perplexing, because I see no significant difference between the
interior block for the huge box, and those of the few test scenes that I've run
where the camera is outside of the media container.

If I have the opportunity, I'll post a trimmed-down scene later this evening.
(Unless 00face beats me to it)

- BW

[Alain Martel] Re: Media woes [412 days 5 hours and 54 minutes ago]

Mon, 24 Feb 2025 17:05:59 GMT

Le 2025-02-24 Ã  09:16, Bald Eagle a Ã©critÂ :
> Following up on this, as I was debugging / rewriting one of 00face's scenes (to
> better learn about handling media myself), I ran into a curious problem where
> when I halved the unnecessarily gigantic media container, it all went black.
> 
> After much experimenting, I determined that when the camera was inside the
> container, it all looked fine.
> When the box edge was moved in front of the camera to exclude it, the container
> looked black.
> 
> I was in the middle of 3 other things at the time, and didn't have the
> opportunity to whittle down the complex scene to a minimum, showing the problem
> - but maybe tonight.
> 
> Until then - can anyone speculate on a potential cause?
> 
> Basically just a big box with scattering media and some light coming through a
> ceiling with a lot of holes.
> 
> - BW
> 
Does increasing the mat_trace_level help ? It defaults to 5. Try 
something like 7 or 8.

[kurtz le pirate] Re: Trouble cutting objects (I'm going crazy) [412 days 7 hours and 27 minutes ago]

Mon, 24 Feb 2025 15:32:45 GMT

On 23/02/2025 22:17, William F Pokorny wrote:
> On 2/23/25 15:27, William F Pokorny wrote:
>> If not a problematic version of POV-Ray, I'd bet next on something 
>> with the mesh, but...?
> 
> Another upfront question is: Are you sure the mesh is really closed?
> 
> The 'Solid' part of Constructive Solid Geometry is often important - 
> though you can get away with quite a bit in practice.
> 
> And, have you tried an intersection{} instead?
> 
> intersection {
>  Â  object { Screw }
>  Â  plane { -y, 0 }
> }

I rebuilt yuqk with the right option (THANKS Jr).

I went back to my 3.8 source code, added the right lines for version 
3.8.0-x.yuqk_a5c25dda and re-rendered. As expected, the names of my 
variables are accepted without any problem.

I'm happy.
Attached is a summary of this "magnificent" scene.

Do you see the problem ?
The issue I mentioned earlier has disappeared !

What is the relationship between the "--disable-no-lc-identifiers" and 
the difference  { } opÃ©ration ?

A new leap into the 5th dimension :(

-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Media woes [412 days 8 hours and 40 minutes ago]

Mon, 24 Feb 2025 14:20:00 GMT

Following up on this, as I was debugging / rewriting one of 00face's scenes (to
better learn about handling media myself), I ran into a curious problem where
when I halved the unnecessarily gigantic media container, it all went black.

After much experimenting, I determined that when the camera was inside the
container, it all looked fine.
When the box edge was moved in front of the camera to exclude it, the container
looked black.

I was in the middle of 3 other things at the time, and didn't have the
opportunity to whittle down the complex scene to a minimum, showing the problem
- but maybe tonight.

Until then - can anyone speculate on a potential cause?

Basically just a big box with scattering media and some light coming through a
ceiling with a lot of holes.

- BW

[kurtz le pirate] Re: Trouble cutting objects [412 days 11 hours and 29 minutes ago]

Mon, 24 Feb 2025 11:30:45 GMT

On 23/02/2025 21:27, William F Pokorny wrote:

> I'll take you to mean no point of the triangles has a value >= a surface 
> of the cylinder containing the mesh.

yes

> And, you've specified an inside_vector <> in your mesh definition? One 
> NOT axis aligned (<0,0,1>) as recommended by our documentation at:
> 
>  Â  https://wiki.povray.org/content/Reference:Mesh#Solid_Mesh

Ho yes, I tried several inside_vector without further luck.





 > Another upfront question is: Are you sure the mesh is really closed?

A very good point.
I also think the problem lies here



> Use something more random and unlikely to run near parallel with any 
> triangle's surface in your mesh (*) - there are some epsilon tolerance 
> values when testing whether inside the mesh.
> 
> Bill P.
> 
> (*)- There is too a narrow / unlikely potential bug when translating a 
> mesh with an originally valid inside_vector, which is fixed in the yuqk 
> fork.

Here, the same things rendered with yuqk* :(






* : look in p.b.programming. I have strange errors with yuqk

-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Trouble cutting objects [413 days 1 hour and 43 minutes ago]

Sun, 23 Feb 2025 21:17:01 GMT

On 2/23/25 15:27, William F Pokorny wrote:
> If not a problematic version of POV-Ray, I'd bet next on something with 
> the mesh, but...?

Another upfront question is: Are you sure the mesh is really closed?

The 'Solid' part of Constructive Solid Geometry is often important - 
though you can get away with quite a bit in practice.

And, have you tried an intersection{} instead?

intersection {
   object { Screw }
   plane { -y, 0 }
}

Bill P.

[William F Pokorny] Re: Trouble cutting objects [413 days 2 hours and 33 minutes ago]

Sun, 23 Feb 2025 20:27:04 GMT

On 2/23/25 09:30, kurtz le pirate wrote:
>> If not a problematic version of POV-Ray, I'd bet next on something 
>> with the mesh, but...?
> 
> Yes, me too
> But the mesh is simple "ï»¿ï»¿concatenation" of
triangles.
> 
> The max/min values off the mesh are :
> Max = < 7.00, 31.00, 7.00>
> Min = <-7.00, -1.00, -7.00>
> 
> These values are consistent with the calculations and the drawing.
> 
> No point of the triangles has a value greater than the cylinder 
> containing the mesh

I'll take you to mean no point of the triangles has a value >= a surface 
of the cylinder containing the mesh.

And, you've specified an inside_vector <> in your mesh definition? One 
NOT axis aligned (<0,0,1>) as recommended by our documentation at:

   https://wiki.povray.org/content/Reference:Mesh#Solid_Mesh

Use something more random and unlikely to run near parallel with any 
triangle's surface in your mesh (*) - there are some epsilon tolerance 
values when testing whether inside the mesh.

Bill P.

(*)- There is too a narrow / unlikely potential bug when translating a 
mesh with an originally valid inside_vector, which is fixed in the yuqk 
fork.

[kurtz le pirate] Re: Trouble cutting objects [413 days 8 hours and 29 minutes ago]

Sun, 23 Feb 2025 14:30:59 GMT

On 23/02/2025 13:36, William F Pokorny wrote:
> On 2/23/25 05:17, kurtz le pirate wrote:
>> Do you have any ideas for solving this issue ?
> 
> What version of POV-Ray are you using? There were v3.8 development 
> versions over time with difference issues.


Persistence of Vision(tm) Ray Tracer Version 3.8.0-beta.2.unofficial (
Compiler: Apple LLVM 12.0.5 (clang-1205.0.22.11))


> If not a problematic version of POV-Ray, I'd bet next on something with 
> the mesh, but...?

Yes, me too
But the mesh is simple "ï»¿ï»¿concatenation" of
triangles.

The max/min values off the mesh are :
Max = < 7.00, 31.00, 7.00>
Min = <-7.00, -1.00, -7.00>

These values are consistent with the calculations and the drawing.

No point of the triangles has a value greater than the cylinder 
containing the mesh



> I tried a simple cylinder scene and things look OK test one each of the 
> v3.7 and v3.8 compiles I have in hand.
> 
> //...
> #declare Cyl00 = cylinder {
>  Â Â Â  <0,-0.1,0>, <0,1,0>, 0.2
>  Â Â Â  pigment { rgb <0.3,0.5,0.6> }
>  Â Â Â  finish { emission 0.2 }
> }
> 
> difference {
>  Â  object { Cyl00 translate <-0.7,0,0> }
>  Â  plane { y,0 }
>  Â  cutaway_textures
> }
> 
> object { Cyl00 }
> //...
> 
> Bill P.

Yes, with simple objects, no issue.

I made others tests. The base object ranges from -1 to 31.
If I try with another y value (say 5) i get the same issue at y = 5.0 
has you can see.

I also added the cylinder object limits.

I'm still trying to figure out what's so special about this mesh ...





-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Trouble cutting objects [413 days 8 hours and 48 minutes ago]

Sun, 23 Feb 2025 14:12:05 GMT

On 23/02/2025 11:44, antoine wrote:

> Bonjour/Hello
> When you try to make a difference or merge CSG operation with isosurface 
> objects, you should use the "max trace 'intersections number'" (to write 
> in the isosurface statement at the end ideally) keyword so POVRay 
> doesn't stop at the first collision between rays and the isosurface 
> object. So far, I don't know if you used the max_trace keyword because 
> we don't have all the code.

Isosurface ?
There is no isosurface here ;)






-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Making a pigment or texture directly from te... [413 days 9 hours ago]

Sun, 23 Feb 2025 14:00:00 GMT

Thanks guys,

There's a much easier way to do it, and get full color as well.

repeat warp in z


------------------------------------------------------------------



#version 3.8;
global_settings {assumed_gamma 1.0 }



camera {
 location <0, 2, -10>
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
}

light_source {<0, 50, -100> rgb 1}
sky_sphere {pigment {rgb 1}}

#declare Text =
union {
 #local Scale = 1/6;
 text { ttf "arial.ttf", "Text Line1", 2, 0.0 translate y*2}
 text { ttf "arial.ttf", "Text Line2", 2, 0.0 translate y*1}
 text { ttf "arial.ttf", "Text Line3", 2, 0.0 }
 translate -z*1
 scale Scale
 translate x*Scale/2
}

#declare HollowP =
pigment {
 object {
  Text
  color rgb x+y   // outside
  color rgb 0    // inside
 }
}

//#declare FHollow = function {pigment {HollowP warp {repeat x*1} warp {repeat
y*0.5}}}
#declare Hollow = pigment {HollowP warp {repeat x*1} warp {repeat y*0.5} warp
{repeat z*0.1}}

#for (X, -10, 10)
 box {0, 1
  translate <X, 0, X*0.5>
  texture {pigment {Hollow}}
 }

#end

[William F Pokorny] Re: Making a pigment or texture directly from te... [413 days 10 hours and 7 minutes ago]

Sun, 23 Feb 2025 12:53:17 GMT

On 2/22/25 17:07, Bald Eagle wrote:
> if I want color, then I
> have to resort to making an average {} texture . . . and that starts to get
> involved and messy.

I doubt I completely understand what you want to do.

The yuqk fork has a list_object{} feature like bool_object{} - which in 
POV-Ray proper is called object{}). The list_object would let you define
up to 12 text objects, each supporting a texture (a 13th slot is the 
default texture for 3D points not inside any of the list's text-objects).

I'm not following the image_map part of the discussion. The image based 
/ driven textures / patterns are volumetric too - though in what way 
depends on the map type selected, for example. The object / inside tests
can be infinite in z, for example, by fixing the z coordinate at a value 
within the range of the text object's depth.

Aside: I believe clipka's uberpov had some sort of text page feature, 
though I confess to having never played with it. He posted an example 
image highlighting some SDL IIRC.

Bill P.

[William F Pokorny] Re: Trouble cutting objects [413 days 10 hours and 24 minutes ago]

Sun, 23 Feb 2025 12:36:05 GMT

On 2/23/25 05:17, kurtz le pirate wrote:
> Do you have any ideas for solving this issue ?

What version of POV-Ray are you using? There were v3.8 development 
versions over time with difference issues.

If not a problematic version of POV-Ray, I'd bet next on something with 
the mesh, but...?

I tried a simple cylinder scene and things look OK test one each of the 
v3.7 and v3.8 compiles I have in hand.

//...
#declare Cyl00 = cylinder {
     <0,-0.1,0>, <0,1,0>, 0.2
     pigment { rgb <0.3,0.5,0.6> }
     finish { emission 0.2 }
}

difference {
   object { Cyl00 translate <-0.7,0,0> }
   plane { y,0 }
   cutaway_textures
}

object { Cyl00 }
//...

Bill P.

[Kenneth] Re: Making a pigment or texture directly from te... [413 days 12 hours and 10 minutes ago]

Sun, 23 Feb 2025 10:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> >
> > Using the 'object' pattern should do the trick.
>
> Hmm.  Yes.
> However, that doesn't function like an image_map -
> it's a volumetric inside/outside test on 3D text.
> I can of course import that into a function and use a pigment {function {F(x, y,
> 0)}} to extend that infinitely in the z direction, but if I want color, then I
> have to resort to making an average {} texture . . . and that starts to get
> involved and messy.

I take it that you mean averaging three weighted color functions to get full
color. Yeah, it's involved.

I do sense your desire to somehow create an actual pigment pattern from text, to
be used like any other POV-ray pattern. I wouldn't know how to do that-- but as
a practical matter, it seems to me that Leroy's object pattern idea would
fulfill the goal, simply by scaling it VERY large in z. 'Infinitely' long, so to
speak. And the result can use actual colors.

I have attached a test scene; that's the first example.

My 2nd example is more involved, and makes use of a 'function image'-- which
produces an image_map of the text object. By nature, it is 'infinitely long' in
z, just like any other simple image_map application. But it has a problem, due
to one of the various function uses (probably the OBJ_PATT_TO_FUNC): The result
is strictly grayscale. I've tried different ways of adding colors at various
places, but they all fail. Even adding an inline color_map after

   image_map{
        function 600,600 {OBJ_PATT_TO_FUNC(x,y,z).green}

doesn't work like it usually does for averaged color functions, fatal error.
Maybe there is *some* other way of adding colors that I don't yet grasp.

Anyway, if you feel like experimenting, have fun with the code.

[antoine] Re: Trouble cutting objects [413 days 12 hours and 16 minutes ago]

Sun, 23 Feb 2025 10:44:11 GMT

Le 23/02/2025 Ã  11:17, kurtz le pirate a Ã©critÂ :
> 
> Hi,
> 
> 
> In the attached image (this is a view from below).
> 
> In the center, the object built from the union of a cylinder and a mesh.
> 
> On the right, the same object â€œcutâ€ at the base by
a plane
> difference {
>  Â object { Screw }
>  Â plane { y,0 }
>  Â }
> 
> 
> 
> And then, as you can see, something â€œweirdâ€
happens.
> 
> If I make the difference with a box, it's the same thing.
> And, if instead of â€œcuttingâ€ at the bottom, I cut
at the top, the same 
> thing happens. It can't be a problem of surface coincidence. The values 
> are quite different, in fact.
> 
> 
> Do you have any ideas for solving this issue ?
> 
> 
> 
> nb: the vertical black line with the balls is simplyÂ  gauge to check the 
> screw pitch and has nothing to do with the problem.
> 
Bonjour/Hello
When you try to make a difference or merge CSG operation with isosurface 
objects, you should use the "max trace 'intersections number'" (to write 
in the isosurface statement at the end ideally) keyword so POVRay 
doesn't stop at the first collision between rays and the isosurface 
object. So far, I don't know if you used the max_trace keyword because 
we don't have all the code.

[kurtz le pirate] Trouble cutting objects [413 days 12 hours and 42 minutes ago]

Sun, 23 Feb 2025 10:17:46 GMT

Hi,


In the attached image (this is a view from below).

In the center, the object built from the union of a cylinder and a mesh.

On the right, the same object â€œcutâ€ at the base by a
plane
difference {
  object { Screw }
  plane { y,0 }
  }



And then, as you can see, something â€œweirdâ€ happens.

If I make the difference with a box, it's the same thing.
And, if instead of â€œcuttingâ€ at the bottom, I cut at
the top, the same 
thing happens. It can't be a problem of surface coincidence. The values 
are quite different, in fact.


Do you have any ideas for solving this issue ?



nb: the vertical black line with the balls is simply  gauge to check the 
screw pitch and has nothing to do with the problem.

-- 
kurtz le pirate
compagnie de la banquise

[kurtz le pirate] Re: Making a pigment or texture directly from te... [413 days 12 hours and 47 minutes ago]

Sun, 23 Feb 2025 10:13:18 GMT

On 22/02/2025 23:07, Bald Eagle wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> Is there a way to do this?
>>>
>>> object texture?
>>> function?
>>> Some way to internally generate an image_map?
>>>
>>> Seems like it ought to be possible, but I'm not seeing the path to a solution.
>>>
>>> - BE
>>
>> If I understand you right you want to turn a text object into a pigment or
>> texture
>>
>> Using the 'object' pattern should do the trick.
> 
> Hmm.  Yes.
> However, that doesn't function like an image_map - it's a volumetric
> inside/outside test on 3D text.
> I can of course import that into a function and use a pigment {function {F(x, y,
> 0)}} to extend that infinitely in the z direction, but if I want color, then I
> have to resort to making an average {} texture . . . and that starts to get
> involved and messy.
> 


Not sure if I'm really answering your question, but yes, texture { 
pigment { object { text { ... should meet your needs.

I pulled out an old test scene with this :

// ---------------------------------------------------------------------

union {
cone { <0, 0, 0>, Rad, <0, 0, -0.50>, Rad-0.50 }
cylinder { <0, 0, 0>, <0, 0, Len>, Rad }
cone { <0, 0, Len>, Rad, <0, 0, Len+0.50>, Rad-0.50 }

texture {
pigment {
object {
#declare Texte = text {
ttf FontName Str 1, <0, 0, 0>
scale FontScale
rotate -90*y
}
#declare TexteMax = max_extent(Texte);
#declare TexteMin = min_extent(Texte);
#declare Translation = 0.50*<2*Rad, 
TexteMin.y-((TexteMax.y-TexteMin.y)*0.50), Len-TexteMax.z>;
text {
ttf  FontName  Str 1, <0, 0, 0>
scale FontScale
rotate -90*y
translate Translation
} // end of text
pigment { color White*0.25 }
pigment { color Orange*1.15 }
} // end of object
//			turbulence <0.10, 0.20, 0.05>
} // end of pigment


finish { phong 0.90 phong_size 8 }
// normal { cells bump_size 0.15 no_bump_scale scale 0.50 turbulence 0.15 }
} // end of texture
} // end of union


// ---------------------------------------------------------------------


that give the image



-- 
kurtz le pirate
compagnie de la banquise

[Kenneth] Re: Media woes [413 days 22 hours and 35 minutes ago]

Sun, 23 Feb 2025 00:25:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> This plane needs to be made 'hollow' for the media to appear:
>       plane {z,  2... }
>
> That's because the spheres are located 'inside' it. (The same effect could be
> achieved by using 'inverse' instead.)
>
> Whereas, the plane{y, -2...} doesn't need the hollow keyword, as the spheres
> are 'outside' it.
>

I just discovered something interesting, that I didn't know until now.

Given your enclosed 'universe' of two planes, where the media spheres (and
camera) are inside one plane (z) but outside the other (y):

If I add 'hollow' to the z-plane as mentioned, the media shows up. HOWEVER, if I
also 'inverse' the y-plane-- thus making the enclosed space 'inside' from *both*
plane's perspectives-- the media disappears again. Apparently, the space is now
sort of a mix of hollow and non-hollow. I have to add 'hollow' to the inverted
y-plane as well, to get the media to reappear.

Naively, I would have assumed that the z-plane's sole 'hollow' would have
sufficed to make the space 'safe for media' (ha), and that it would somehow
override the non-hollow y-plane space. But not so!

I'm not so sure that using planes that enclose small media objects is a good
idea anyway, but for a different reason: AFAIU, every camera-ray/pixel shot into
such a scene would have to be tested for the presence of media-- not just by
testing the small spheres themselves, but over the entire camera view. Lots of
unnecessary computational overhead, in other words. But I could be wrong(?)

[Bald Eagle] Re: Making a pigment or texture directly from te... [414 days and 50 minutes ago]

Sat, 22 Feb 2025 22:10:00 GMT

"Leroy" <whe### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > Is there a way to do this?
> >
> > object texture?
> > function?
> > Some way to internally generate an image_map?
> >
> > Seems like it ought to be possible, but I'm not seeing the path to a solution.
> >
> > - BE
>
> If I understand you right you want to turn a text object into a pigment or
> texture
>
> Using the 'object' pattern should do the trick.

Hmm.  Yes.
However, that doesn't function like an image_map - it's a volumetric
inside/outside test on 3D text.
I can of course import that into a function and use a pigment {function {F(x, y,
0)}} to extend that infinitely in the z direction, but if I want color, then I
have to resort to making an average {} texture . . . and that starts to get
involved and messy.

[Leroy] Re: Making a pigment or texture directly from te... [414 days 2 hours ago]

Sat, 22 Feb 2025 21:00:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Is there a way to do this?
>
> object texture?
> function?
> Some way to internally generate an image_map?
>
> Seems like it ought to be possible, but I'm not seeing the path to a solution.
>
> - BE

If I understand you right you want to turn a text object into a pigment or
texture

Using the 'object' pattern should do the trick.

[Bald Eagle] Making a pigment or texture directly from text {} [414 days 4 hours and 35 minutes ago]

Sat, 22 Feb 2025 18:25:00 GMT

Is there a way to do this?

object texture?
function?
Some way to internally generate an image_map?

Seems like it ought to be possible, but I'm not seeing the path to a solution.

- BE

[Kenneth] Re: Media woes [416 days and 15 minutes ago]

Thu, 20 Feb 2025 22:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > Personally, I have always wondered why a z-plane doesn't have it's 'outside'
> > facing the -z direction by default, rather than the other way around. I
> > suppose that there are old and deep reasons for this.

Hmm, not so deep as I thought. In the documentation for a plane:

"...most planes are defined with surface normals in the direction of an axis
[meaning the positive direction, which is not specifically mentioned.]"

"By definition the normal vector points to the outside of the plane."

So all of the three (simple) x-y-z planes have their 'outsides' in the positive
directions of the axes. That's logically consistent-- but has to be taken into
account when media is used *inside* the planes. It's a subtle "Gotcha!"

>
> I also didn't quite know that any overlapping container needed to be hollow as
> well.
>

Yeah, this situation has tripped me up in the past as well, when using planes.
We don't usually run into such problems with typical media-filled objects, or
even CSG constructs that have the proper 'master' hollow keyword.

[Bald Eagle] Re: Media woes [416 days 6 hours and 15 minutes ago]

Thu, 20 Feb 2025 16:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> This plane needs to be made 'hollow' for the media to appear:
>       plane {z,  2... }
>
> That's because the spheres are located 'inside' it. (The same effect could be
> achieved by using 'inverse' instead.)
>
> Whereas, the plane{y, -2...} doesn't need the hollow keyword, as the spheres are
> 'outside' it.
>
> Personally, I have always wondered why a z-plane doesn't have it's 'outside'
> facing the -z direction by default, rather than the other way around. I suppose
> that there are old and deep reasons for this.

Aha.
I snoozed and forgot that a plane is actually a half-space with an inside and an
outside...
So I needed a hollow plane, as ridiculous as that first sounds.
I also didn't quite know that any overlapping container needed to be hollow as
well.

I was actually starting to make some helper macros to make using media easier,
and keep track of all of the recommendations that Alain has offered over the
years.

Thanks, Kenneth!

- BW

[Kenneth] Re: Media woes [416 days 17 hours ago]

Thu, 20 Feb 2025 06:00:00 GMT

This plane needs to be made 'hollow' for the media to appear:
      plane {z,  2... }

That's because the spheres are located 'inside' it. (The same effect could be
achieved by using 'inverse' instead.)

Whereas, the plane{y, -2...} doesn't need the hollow keyword, as the spheres are
'outside' it.

Personally, I have always wondered why a z-plane doesn't have it's 'outside'
facing the -z direction by default, rather than the other way around. I suppose
that there are old and deep reasons for this.

[Bald Eagle] Media woes [416 days 23 hours and 30 minutes ago]

Wed, 19 Feb 2025 23:30:00 GMT

Can someone tell me why this virtually identical scene to that in the docs
doesn't show the 2 media spheres?

#version 3.8;
global_settings {assumed_gamma 1.0 }

camera {
 location <0, 10, -20>
 right x*image_width/image_height
 up y
 look_at <0, 0, 0>
}

light_source {<100, 50, -100> rgb 1}


#declare BS = 1;
plane {z,  2 texture {pigment {checker rgb 0, rgb 1 scale BS} finish {diffuse
1}} }

plane {y, -2 texture {pigment {checker rgb 0, rgb 1 scale BS} finish {diffuse
1}} }

// show all permutations of solo and mixed media

// Emitting, Absorbing, Scattering
// 15 combinations
// 5 across, 3 down

sphere {0, 1
 hollow
 pigment {rgbt 1}
 interior {
  media {
  emission 1
   density {
    spherical
    density_map {
     [0 rgb 0]
     [0.4 rgb <1,0,0>]
     [0.8 rgb <1,1,0>]
     [1 rgb 1]
    }
   }
  }
 }
 translate -x*2
}

sphere {0, 1 texture {pigment {rgb 1} finish {emission 1}} }

sphere {0, 1
 pigment {rgbt 1}
 hollow
 interior {
  media {
  absorption 1
   density {
    spherical
    density_map {
     [0 rgb 0]
     [0.4 rgb <1,0,0>]
     [0.8 rgb <1,1,0>]
     [1 rgb 1]
    }
   }
  }
 }
 translate x*2
}

[Bald Eagle] Re: Program to make SOR, spline etc [421 days 4 hours and 45 minutes ago]

Sat, 15 Feb 2025 18:15:00 GMT

"stevenvh" <nomail@nomail> wrote:
>
> I tried the Inkscape route. Had a spline of 32 points, which I could indeed save
> in POVray format. But when I tried to render over half of the points gave an
> error. With one exception they were all duplicate points. Others with a similar
> experience?

I'm working on something else at the moment --- does this help any?
https://news.povray.org/povray.general/thread/%3C6690ef12%241%40news.povray.org%3E/

[ingo] Re: Program to make SOR, spline etc [421 days 4 hours and 50 minutes ago]

Sat, 15 Feb 2025 18:10:00 GMT

Spilineditor

https://web.archive.org/web/20050212112645/http://www.flashnet.it/users/fn027571/spil/index.html

Simple and straight forward. Just tested it under win11 and it still works
fine,,

Ingo

[kurtz le pirate] Re: Program to make SOR, spline etc [421 days 5 hours and 50 minutes ago]

Sat, 15 Feb 2025 17:10:16 GMT

On 15/02/2025 17:02, stevenvh wrote:

> 
> I tried the Inkscape route. Had a spline of 32 points, which I could indeed save
> in POVray format. But when I tried to render over half of the points gave an
> error. With one exception they were all duplicate points. Others with a similar
> experience?
> 

I've never had a problem between inkscape and povray, apart from object 
naming. POVRay doesn't accept names with hyphens.

Try to be a little more precise by giving a simple example with the 
POVRay error message.

We'll be able to help you.

-- 
kurtz le pirate
compagnie de la banquise

[stevenvh] Re: Program to make SOR, spline etc [421 days 6 hours and 55 minutes ago]

Sat, 15 Feb 2025 16:05:00 GMT

kurtz le pirate <kur### [at] freefr> wrote:
> On 19/01/2025 21:25, gulino wrote:
> > What program do you guys recommend to make the spline lines and SOR objects?
> > like in this image from the tutorial which you put the points and it traces the
> > line
>
>
> Inkscape
>
>
> --
> kurtz le pirate
> compagnie de la banquise

I tried the Inkscape route. Had a spline of 32 points, which I could indeed save
in POVray format. But when I tried to render over half of the points gave an
error. With one exception they were all duplicate points. Others with a similar
experience?

[Bald Eagle] Small helpful basic scene layout tips [444 days 7 hours and 55 minutes ago]

Thu, 23 Jan 2025 15:05:00 GMT

Been a while since I ran across something basic that I felt would be good for
this group.

Son and I were discussing polar vs rectilinear coordinates, and we got into cos
and sin, and then I pulled up an animation of cos & sin vs the unit circle, and
then I pulled up an animation of all 6 trigonometric functions to show their
geometric meaning.

Lo and behold, the very next day, I am wanting to diagram out a difference {} of
a wedge-shape from the edge of a box {}.  The axis-aligned length of my adjacent
cathetus is a known length, but when I rotate it around the angle's vertex . . .
what length does the cylinder {} need to be for it to still touch the edge of
the box {} once it's been rotated by angle Theta?  What is the length of that
hypotenuse?

It's the adjacent cathetus length times the secant of Theta, or 1/cos(Theta).
Just realizing this off the top of my head saved me what would have an awful lot
of unnecessary figuring.

Do you have a similar helpful little tip?   Post it here.  :)


- BE

[kurtz le pirate] Re: Program to make SOR, spline etc [445 days 13 hours and 6 minutes ago]

Wed, 22 Jan 2025 09:54:14 GMT

On 19/01/2025 21:25, gulino wrote:
> What program do you guys recommend to make the spline lines and SOR objects?
> like in this image from the tutorial which you put the points and it traces the
> line


Inkscape


-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: Program to make SOR, spline etc [446 days 5 hours and 55 minutes ago]

Tue, 21 Jan 2025 17:05:00 GMT

"gulino" <nomail@nomail> wrote:
> What program do you guys recommend to make the spline lines and SOR objects?
> like in this image from the tutorial which you put the points and it traces the
> line

TOK and I helped Novado create PointWriter to do this kind of thing.
https://news.povray.org/povray.binaries.utilities/thread/%3Cweb.54310e519ace5296dce1a360%40news.povray.org%3E/

To make jr happy, I'll suggest that you could use VISIO from M$ Office to draw a
series of line segments.
Maybe the nice people over at visguy.com could slap together a nice little tool
to apply the appropriate spline type, and output a snippet of code to directly
paste into a scene file.

- BE

[nagris] Re: Program to make SOR, spline etc [446 days 6 hours and 45 minutes ago]

Tue, 21 Jan 2025 16:15:00 GMT

"gulino" <nomail@nomail> wrote:
> What program do you guys recommend to make the spline lines and SOR objects?
> like in this image from the tutorial which you put the points and it traces the
> line

WIP

[nagris] Re: Program to make SOR, spline etc [446 days 6 hours and 50 minutes ago]

Tue, 21 Jan 2025 16:10:00 GMT

[gulino] Re: Program to make SOR, spline etc [447 days 5 hours and 25 minutes ago]

Mon, 20 Jan 2025 17:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "gulino" <nomail@nomail> wrote:
> > What program do you guys recommend to make the spline lines and SOR objects?
> > like in this image from the tutorial which you put the points and it traces the
> > line
>
> EP Spline by Ed Hynan
>
>
https://web.archive.org/web/20140813192600/http://agalena.nfshost.com/b1/epspline-prism-and-lathe-editor/
>
> https://stuff.mit.edu/afs/athena/software/povray_v3.7.0a/epspline.pdf
>
> https://github.com/ehy/epspline
>
>
http://news.povray.org/povray.binaries.utilities/thread/%3C540e3651%241%40news.povray.org%3E/
>
> - BE

I tried it and it works well, thank you

[Bald Eagle] Re: Program to make SOR, spline etc [448 days and 45 minutes ago]

Sun, 19 Jan 2025 22:15:00 GMT

"gulino" <nomail@nomail> wrote:
> What program do you guys recommend to make the spline lines and SOR objects?
> like in this image from the tutorial which you put the points and it traces the
> line

EP Spline by Ed Hynan

https://web.archive.org/web/20140813192600/http://agalena.nfshost.com/b1/epspline-prism-and-lathe-editor/

https://stuff.mit.edu/afs/athena/software/povray_v3.7.0a/epspline.pdf

https://github.com/ehy/epspline

http://news.povray.org/povray.binaries.utilities/thread/%3C540e3651%241%40news.povray.org%3E/

- BE

[gulino] Program to make SOR, spline etc [448 days 2 hours and 30 minutes ago]

Sun, 19 Jan 2025 20:30:00 GMT

What program do you guys recommend to make the spline lines and SOR objects?
like in this image from the tutorial which you put the points and it traces the
line

[Alain Martel] Re: Images are pixelated [477 days 9 hours ago]

Sat, 21 Dec 2024 13:59:44 GMT

Le 2024-12-20 Ã  14:34, Bald Eagle a Ã©critÂ :
> Alain Martel <kua### [at] videotronca> wrote:
> 
>> Mine have at least double the number of entries of the default one,
>> including wide screen, double screen, double wide, triple screen and
>> triple wide options.
> 
> Whoa.
> "Double screen"?  "Triple screen"?  We can do that?!  :O
> 
4800 by 1200 (triple) and 5760 by 1080 (triple wide).
I actually rendered an RSOCP at 4800 by 1200.

[Bald Eagle] Re: Images are pixelated [478 days 3 hours and 25 minutes ago]

Fri, 20 Dec 2024 19:35:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> Mine have at least double the number of entries of the default one,
> including wide screen, double screen, double wide, triple screen and
> triple wide options.

Whoa.
"Double screen"?  "Triple screen"?  We can do that?!  :O

[Alain Martel] Re: Images are pixelated [478 days 4 hours and 9 minutes ago]

Fri, 20 Dec 2024 18:50:52 GMT

Le 2024-12-20 Ã  12:42, Kenneth a Ã©critÂ :
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "gulino" <nomail@nomail> wrote:
> 
>>> I didn't do anything, I downloaded povray yesterday and it was already
>>> like this when I tested the example models. The resolution is 512 x 384, is
>>> this normal?
>>> Can I change this?
>>
>> if it's on Windows, you have the drop-down menu to select the resolution and
>> stock anti-aliasing settings.
> 
> Yes, and the drop-down menu has all of the various resolutions that are included
> in a file called 'quickres.inc'. You can add to or change those default
> resolutions by editing that file. If it is not already open in your POV-ray
> editor window in the Windows GUI, go to the 'Tools' tab at the top and select
> 'Edit resolution INI file.' That will open quickres.ini. Then you can write-in
> other resolutions.
> 
> For example, the following is, I think, one of the default resolution blocks
> there:
> 
> [512x384]
> Width=512
> Height=384
> Antialias=On
> Antialias_Threshold=0.3
> 
> You can write a new one:
> 
> [1920X1080 widescreen]
> Width=1920
> Height=1080
> ;Antialias=On
> ;Antialias_Threshold=0.3
> 
> Then the drop-down resolution menu will include that for your later use. (The
> semicolons can be used to commment-out those particular entries, just like using
> double-slashes // for comments in a scene file.)
> 
> My own quickres.ini file is chock-full of customized entries!
> 
> 
> 
> 
Mine have at least double the number of entries of the default one, 
including wide screen, double screen, double wide, triple screen and 
triple wide options.

[Kenneth] Re: Images are pixelated [478 days 5 hours and 15 minutes ago]

Fri, 20 Dec 2024 17:45:00 GMT

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

> > I didn't do anything, I downloaded povray yesterday and it was already
> > like this when I tested the example models. The resolution is 512 x 384, is
> > this normal?
> > Can I change this?
>
> if it's on Windows, you have the drop-down menu to select the resolution and
> stock anti-aliasing settings.

Yes, and the drop-down menu has all of the various resolutions that are included
in a file called 'quickres.inc'. You can add to or change those default
resolutions by editing that file. If it is not already open in your POV-ray
editor window in the Windows GUI, go to the 'Tools' tab at the top and select
'Edit resolution INI file.' That will open quickres.ini. Then you can write-in
other resolutions.

For example, the following is, I think, one of the default resolution blocks
there:

[512x384]
Width=512
Height=384
Antialias=On
Antialias_Threshold=0.3

You can write a new one:

[1920X1080 widescreen]
Width=1920
Height=1080
;Antialias=On
;Antialias_Threshold=0.3

Then the drop-down resolution menu will include that for your later use. (The
semicolons can be used to commment-out those particular entries, just like using
double-slashes // for comments in a scene file.)

My own quickres.ini file is chock-full of customized entries!

[gulino] Re: Images are pixelated [481 days 7 hours and 30 minutes ago]

Tue, 17 Dec 2024 15:30:00 GMT

Ok problem solved, merci
I am using +a0.01 +am2 +r3 with 1028x768 No AA and looks good.

[Alain Martel] Re: Images are pixelated [481 days 7 hours and 52 minutes ago]

Tue, 17 Dec 2024 15:08:25 GMT

Le 2024-12-17 Ã  08:31, gulino a Ã©critÂ :
> 
>> From: antoine
> where exactly do I put this? I tried to write +a0.01 +am2 +r3 in the .pov file
> but it gave an error

Those are Command Line parameters.
You don't write Â«+a0.01 +am2 +r3Â» in the scene file itself. You
write it 
in the Â«Command lineÂ» box located right from the resolution Drop
list.

> 
>> From: Alain Martel
> I didn't do anything, I downloaded povray yesterday and it was already like this
> when I tested the example models. The resolution is 512 x 384, is this normal?
> Can I change this?
> 
That resolution, [512x384, No AA], is the one selected by default when 
you render your first scene. You can easily change it. Just click on it 
and select the resolution that you want to use.
The one just under is [512x384, AA 0.3]. The Â«AA 0.3Â» mean
antialias 
enabled with threshold set at 0.3.
On Windows ? Look at the line just above the editor, all the way to the 
left. That's a drop list from where you can select carious resolutions 
and enable AA.
You can change it's content by editing the quickres.ini file. From the 
menu bar : Tools|Edit resolution INI file.

[jr] Re: Images are pixelated [481 days 7 hours and 55 minutes ago]

Tue, 17 Dec 2024 15:05:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "gulino" <nomail@nomail> wrote:
> > > From: antoine
> > where exactly do I put this? I tried to write +a0.01 +am2 +r3 in the .pov file
> > but it gave an error
> >
> > > From: Alain Martel
> > I didn't do anything, I downloaded povray yesterday and it was already like this
> > when I tested the example models. The resolution is 512 x 384, is this normal?
> > Can I change this?

<https://wiki.povray.org/content/Documentation:Tutorial_Section_2.2#Setting_POV-Ray_Options>

the 'povray.ini' file, for instance, is a "good place" to set your preferred
default resolution, and other stuff.


regards, jr.

[Bald Eagle] Re: Images are pixelated [481 days 8 hours and 10 minutes ago]

Tue, 17 Dec 2024 14:50:00 GMT

"gulino" <nomail@nomail> wrote:
> > From: antoine
> where exactly do I put this? I tried to write +a0.01 +am2 +r3 in the .pov file
> but it gave an error
>
> > From: Alain Martel
> I didn't do anything, I downloaded povray yesterday and it was already like this
> when I tested the example models. The resolution is 512 x 384, is this normal?
> Can I change this?

if it's on Windows, you have the drop-down menu to select the resolution and
stock anti-aliasing settings.

you also have the "command line" section at the top of the editor to input any
render control settings.

Linux users can chime in, or you can check out the instructions on
wiki.povray.org

https://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options

- BE

[gulino] Re: Images are pixelated [481 days 9 hours and 25 minutes ago]

Tue, 17 Dec 2024 13:35:00 GMT

> From: antoine
where exactly do I put this? I tried to write +a0.01 +am2 +r3 in the .pov file
but it gave an error

> From: Alain Martel
I didn't do anything, I downloaded povray yesterday and it was already like this
when I tested the example models. The resolution is 512 x 384, is this normal?
Can I change this?

[Alain Martel] Re: Images are pixelated [481 days 10 hours and 47 minutes ago]

Tue, 17 Dec 2024 12:13:01 GMT

Le 2024-12-16 Ã  22:51, gulino a Ã©critÂ :
> Hello, the images are pixelated for some reason
> How I correct this? I am using povray 3.7

How did you manage to get that pixelation ? Did you double the size of 
the image after rendering ?

You should do :
1) Render directly at the desired resolution.
1.1) Some will render at double resolution then scale down by one half.
2) Use antialiasing. The presets do include some antialiased options.

The usual antialiasing use +a0.3 +am1 +r3. That's acceptable in high 
contrast scenes.
In most cases, it's better to use more aggressive settings, like :
+a0.1 +am2 +r3
You may want to go farther, and use +a0.05 all the way down to +a0.001.

Using +am1 will often cause some glitches at the edges of the render 
blocks. +am2 is much better as it never cause any glitches in those areas.

[antoine] Re: Images are pixelated [481 days 14 hours and 55 minutes ago]

Tue, 17 Dec 2024 08:05:29 GMT

Le 17/12/2024 Ã  04:51, gulino a Ã©critÂ :
> Hello, the images are pixelated for some reason
> How I correct this? I am using povray 3.7

I think this is because Antialiasing is not active by default, you 
should enable it.
For example, with these flags, you get a quality antialiasing:
+a0.01 +am2 +r3

If rendering takes to much time (especially if you use radiosity), you 
can set +r3 to +r2 or +r1 to decrease traced rays.

More infos on this wiki page:
http://www.povray.org/documentation/view/3.6.2/223/

[gulino] Images are pixelated [481 days 19 hours and 5 minutes ago]

Tue, 17 Dec 2024 03:55:00 GMT

Hello, the images are pixelated for some reason
How I correct this? I am using povray 3.7

[Mr] Re: normal [496 days 11 hours and 55 minutes ago]

Mon, 2 Dec 2024 11:05:00 GMT

"folkert" <fol### [at] vanheusdencom> wrote:
> Hello,
>
> I'm trying to add normals to triangles.
>
> Let's say I've got this mesh2 object:
>
>
> mesh2 {
>   vertex_vectors {
>     4
> , <-4.22827, 3.07201, 49.7261>, <-3.49716, 3.88399, 49.7261>, <-10.3386,
> 11.4822, 47.5528>, <-12.5, 9.08178, 47.5528>  }
>   face_indices {
>     2
> , <2, 0, 1>, <0, 2, 3>
>   }
>
>   texture { pigment { color rgbf <0.976471, 0.843137, 0.172549, 0> } }
>   finish { MATERIAL } interior { MATERIAL_INT }
> }
>
> This renders fine.
> So next step, adding normals.
>
> Am I right that I need to do the following:
> - for each triangle, e.g.:
>   p1: <-10.3386, 11.4822, 47.5528>, p2: <-4.22827, 3.07201, 49.7261>, p3:
> <-3.49716, 3.88399, 49.7261>
>   and
>   q1: <-4.22827, 3.07201, 49.7261>, q2: <-10.3386, 11.4822, 47.5528>, q3:
> <-12.5, 9.08178, 47.5528>
>   calculate the normals:
>     normal 1 = (p2 - p1) * (p3 - p1)
>     normal 2 = (p3 - p2) * (p2 - p1)
>     normal 3 = (p2 - p3) * (p2 - p1)
>     normal 4 = (q2 - q1) * (q3 - q1)
>     normal 5 = (q3 - q2) * (q2 - q1)
>     normal 6 = (q2 - q3) * (q2 - q1)
> - then put those normals in a:
>   normals_vectors {
>      6, (normal 1), (normal 2), etc.
>   }
>
> But then I'm lost. What should I put in normal_indices { } ?

Normal indices list is optional if there is the same number of normals and
vertices. If so, the indices from the face_indices{} list are used instead.
Otherwise, each entry of the normals list points to what vertices a normal
should be applied. thus providing "shared normals" groups usefull in case of
partly smooth partly flat models... cf docs:
https://www.povray.org/documentation/view/3.60/68/

[Bald Eagle] Re: normal [497 days 22 hours and 5 minutes ago]

Sun, 1 Dec 2024 00:55:00 GMT

"folkert" <fol### [at] vanheusdencom> wrote:

> But then I'm lost. What should I put in normal_indices { } ?

Look this over, and see if that helps you any.

https://news.povray.org/povray.general/thread/%3Cweb.6394bb44855140c41f9dae3025979125%40news.povray.org%3E/

- BW

[folkert] normal [497 days 23 hours and 5 minutes ago]

Sat, 30 Nov 2024 23:55:00 GMT

Hello,

I'm trying to add normals to triangles.

Let's say I've got this mesh2 object:


mesh2 {
  vertex_vectors {
    4
, <-4.22827, 3.07201, 49.7261>, <-3.49716, 3.88399, 49.7261>, <-10.3386,
11.4822, 47.5528>, <-12.5, 9.08178, 47.5528>  }
  face_indices {
    2
, <2, 0, 1>, <0, 2, 3>
  }

  texture { pigment { color rgbf <0.976471, 0.843137, 0.172549, 0> } }
  finish { MATERIAL } interior { MATERIAL_INT }
}

This renders fine.
So next step, adding normals.

Am I right that I need to do the following:
- for each triangle, e.g.:
  p1: <-10.3386, 11.4822, 47.5528>, p2: <-4.22827, 3.07201, 49.7261>, p3:
<-3.49716, 3.88399, 49.7261>
  and
  q1: <-4.22827, 3.07201, 49.7261>, q2: <-10.3386, 11.4822, 47.5528>, q3:
<-12.5, 9.08178, 47.5528>
  calculate the normals:
    normal 1 = (p2 - p1) * (p3 - p1)
    normal 2 = (p3 - p2) * (p2 - p1)
    normal 3 = (p2 - p3) * (p2 - p1)
    normal 4 = (q2 - q1) * (q3 - q1)
    normal 5 = (q3 - q2) * (q2 - q1)
    normal 6 = (q2 - q3) * (q2 - q1)
- then put those normals in a:
  normals_vectors {
     6, (normal 1), (normal 2), etc.
  }

But then I'm lost. What should I put in normal_indices { } ?

[mirrorguy] Re: trace pixels to object they represent in sce... [621 days 9 hours and 5 minutes ago]

Tue, 30 Jul 2024 13:55:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "mirrorguy" <nomail@nomail> wrote:
> > Hello again, thanks for the responses. I don't think I quite get the photon
> > thing, but the trace suggestion sounds simple enough for me (no real experience
> > with 3d rendering). I think color coding a preliminary run to select some pixels
> > to analyze, then generating a scene that uses the trace process you describe
> > would be pretty workable. Thanks again.
>
> I mean, that's for a very analytical approach.
> If you just want to see what gets reflected through a chain of mirrors, then you
> could just apply primary, integer-valued colors to objects and see what comes
> out the other side to hit the camera.
>
> You could do several renders with an orthographic camera looking at every mirror
> individually, and see what those mirrors are reflecting.
>
> A diagram or something would really help specify what the necessary and
> sufficient conditions of your project are.
>
> - BW

The overall idea is to create images and videos with reflections of several
visually similar objects with labels distinguishing among them and their
reflections (with reflections labeled by path of reflection). It's an experiment
in machine learning.

I like the trace idea, seems like it will work. It sounds like I can just write
all the data generated in the tracing process to an ascii file and I'm set.
Thanks a lot.

[Bald Eagle] Re: trace pixels to object they represent in sce... [623 days 2 hours and 35 minutes ago]

Sun, 28 Jul 2024 20:25:00 GMT

"mirrorguy" <nomail@nomail> wrote:
> Hello again, thanks for the responses. I don't think I quite get the photon
> thing, but the trace suggestion sounds simple enough for me (no real experience
> with 3d rendering). I think color coding a preliminary run to select some pixels
> to analyze, then generating a scene that uses the trace process you describe
> would be pretty workable. Thanks again.

I mean, that's for a very analytical approach.
If you just want to see what gets reflected through a chain of mirrors, then you
could just apply primary, integer-valued colors to objects and see what comes
out the other side to hit the camera.

You could do several renders with an orthographic camera looking at every mirror
individually, and see what those mirrors are reflecting.

A diagram or something would really help specify what the necessary and
sufficient conditions of your project are.

- BW

[mirrorguy] Re: trace pixels to object they represent in sce... [623 days 7 hours and 40 minutes ago]

Sun, 28 Jul 2024 15:20:00 GMT

Hello again, thanks for the responses. I don't think I quite get the photon
thing, but the trace suggestion sounds simple enough for me (no real experience
with 3d rendering). I think color coding a preliminary run to select some pixels
to analyze, then generating a scene that uses the trace process you describe
would be pretty workable. Thanks again.

[Bald Eagle] Re: trace pixels to object they represent in sce... [624 days 1 hour and 50 minutes ago]

Sat, 27 Jul 2024 21:10:00 GMT

"mirrorguy" <nomail@nomail> wrote:
> hello all. I have an application where I would like to render scenes involving
> multiple mirrors and I would like to be able to trace which object is
> represented by a given pixel or region of pixels in a rendered image and if
> possible get some kind of backtrace of mirrored surfaces the raytracer
> encountered while rendering the pixel(s).
>
> Is there a way to do this and if so where would I look to find out how? Thanks.

So, it sounds to me like you want to look at the trace () function.

https://wiki.povray.org/content/Reference:Vector_Expressions#Functions

trace(OBJECT_IDENTIFIER, A, B, [VECTOR_IDENTIFIER]). trace helps you finding the
exact location of a ray intersecting with an object's surface. It traces a ray
beginning at the point A in the direction specified by the vector B. If the ray
hits the specified object, this function returns the coordinate where the ray
intersected the object. If not, it returns <0,0,0>. If a fourth parameter in the
form of a vector identifier is provided, the normal of the object at the
intersection point (not including any normal perturbations due to textures) is
stored into that vector. If no intersection was found, the normal vector is
reset to <0,0,0>.

Note: Checking the normal vector for <0,0,0> is the only reliable way to
determine whether an intersection has actually occurred, intersections can and
do occur anywhere, including at <0,0,0>.

Example:

#declare MySphere = sphere { <0, 0, 0>, 1 }
#declare Norm = <0, 0, 0>;
#declare Start = <1, 1, 1>;
#declare Inter=
trace ( MySphere, Start, <0, 0, 0>-Start, Norm );

object {
  MySphere
  texture {
    pigment { rgb 1}
    }
  }

#if (vlength(Norm)!=0)
cylinder {
  Inter, Inter+Norm, .1
  texture {
    pigment {color red 1}
    }
  }
#end

What you may have to do is write a scene where you simulate the entire backward
raytracing process, and have an array of reflecting objects that you check with
the trace() function and if you get a hit, store that in a 1D array.
Daisy-chain your way into the scene until you either hit some sort of background
object, or a reflected object.  Store that 1D array of objects reflected off of
into a 2D array with indices of the x, y screen coordinates.
Then move on to the next pixel.
Then you can write the array to a text file, and maybe place a 1-pixel cube at
that point, with a color code or something.
You might also be able to do something with a spline and use that as a function
in a pigment{} statement to texture a plane....   details for later.

What you might do is put all of your mirrors into a union {} and use that as
your initial trace() target, and if it gets hit, then you can use the
intersection point to cycle through your array of objects and do an inside ()
test on each of them until you get a hit.

https://wiki.povray.org/content/Reference:Numeric_Expressions#Functions

inside(O,V)
It returns either 0.0, when the vector V is outside the object, specified by the
object-identifier O, or 1.0 if it is inside.

Very interesting idea, and it may be slow, but if you decide to implement it, I
can offer advice and guidance - I'm interested in seeing this work.

- Bill

Note: The inside keyword does not accept object-identifiers to non-solid
objects.

[Bald Eagle] Re: trace pixels to object they represent in sce... [624 days 3 hours and 50 minutes ago]

Sat, 27 Jul 2024 19:10:00 GMT

Alain Martel <kua### [at] videotronca> wrote:

> The illumination of the ground will show the path from the camera
> through the mirrors and the final destination.
> The object, or parts of objects, illuminated will show you what the
> camera actually see.


:O   Really?
We can do that?

Can you make a simple scene with 2 mirrors and a box showing this?

- BW

[Alain Martel] Re: trace pixels to object they represent in sce... [624 days 4 hours and 58 minutes ago]

Sat, 27 Jul 2024 18:02:07 GMT

Le 2024-07-26 Ã  15:20, mirrorguy a Ã©critÂ :
> hello all. I have an application where I would like to render scenes involving
> multiple mirrors and I would like to be able to trace which object is
> represented by a given pixel or region of pixels in a rendered image and if
> possible get some kind of backtrace of mirrored surfaces the raytracer
> encountered while rendering the pixel(s).
> 
> Is there a way to do this and if so where would I look to find out how? Thanks.
> 
> 
For the back trace, you should use photon mapping.
Place a light at the camera location.
Make the mirrors that you can see directly as target.
Making mirrors that you can't see directly as target only make the 
photons mapping take longer as photons will get shot at them but get 
intercepted on the way.
Now, move the camera up to get a plunging view.
Render.

To make an object a target, add this in it's description :
photons{target 1} //This allow photons to get shot at the object

To turn photon mapping, add this in the global_settings block :
(minimal)
photons{spacing 0.1}// set to 10 photons per linear unit
// 100 per square unit
// feel free to increase if needed.

You may use count instead of spacing, but, with multiple targets, the 
required value often get frighteningly large.

By default, ALL light will shoot photons at all target objects.
This can be turned off with this in the light's definition :
photons{reflection off refraction off}// default is both ON

You may want your light and reflections to go farther than the default 
of 5 surfaces. For that, add this to the global_settings :
max_trace_level 10 // allow a ray to interact with 10 surfaces
// may get up to 255

You may want to give the ground a finish with Â«brilliance 0Â» so
that the 
light from a light set low to the ground will fully illuminate is from 
far away.

The illumination of the ground will show the path from the camera 
through the mirrors and the final destination.
The object, or parts of objects, illuminated will show you what the 
camera actually see.

[mirrorguy] trace pixels to object they represent in scenes ... [625 days 3 hours and 35 minutes ago]

Fri, 26 Jul 2024 19:25:00 GMT

hello all. I have an application where I would like to render scenes involving
multiple mirrors and I would like to be able to trace which object is
represented by a given pixel or region of pixels in a rendered image and if
possible get some kind of backtrace of mirrored surfaces the raytracer
encountered while rendering the pixel(s).

Is there a way to do this and if so where would I look to find out how? Thanks.

[yesbird] Re: Preferred Modeling Program? [650 days 15 hours and 48 minutes ago]

Mon, 1 Jul 2024 07:12:20 GMT

On 01/07/2024 07:43, Rick Rude wrote:
> Which 3D modeling program, if any, do you use to generate your scenes?

Hi, Rick !

Try Blender - it is very popular, has a large community and
supports POV-Ray: https://www.blender.org

Good luck with blending,
--
YB

[Rick Rude] Preferred Modeling Program? [650 days 18 hours and 17 minutes ago]

Mon, 1 Jul 2024 04:43:19 GMT

Hello All,
I am still learning the basics of POVRay and I am greatly enjoying it so 
far. One thing I have noticed, however, is that the scene description 
language is fairly limiting to those of us lacking the ability to 
perfectly mentally visualize mathematical representations of geometric 
structures in 3D space. For simple scenes, it no doubt gets the job 
done, but I imagine the more sophisticated pieces, such as those made by 
Gilles Tran, have to be created in some type of separate modeling 
program, which brings me to the crux of this post: Which 3D modeling 
program, if any, do you use to generate your scenes? I know MORAY used 
to have its adherents, but it seems to be stuck in copyright limbo for 
the time being.

[Rudy] Preferred Modeler? [650 days 18 hours and 29 minutes ago]

Mon, 1 Jul 2024 04:31:11 GMT

Hello All,
I am still learning the basics of POVRay and I am greatly enjoying it so 
far. One thing I have noticed, however, is that the scene description 
language is fairly limiting to those of us lacking the ability to 
perfectly mentally visualize mathematical representations of geometric 
structures in 3D space. For simple scenes, it no doubt gets the job 
done, but I imagine the more sophisticated pieces, such as those made by 
Gilles Tran, have to be created in some type of separate modeling 
program, which brings me to the crux of this post: Which 3D modeling 
program, if any, do you use to generate your scenes? I know MORAY used 
to have its adherents, but it seems to be stuck in copyright limbo for 
the time being.

[hanna baltrukevich] Re: Undeclared identifier 'nan' found [667 days 9 hours and 15 minutes ago]

Fri, 14 Jun 2024 13:45:00 GMT

Thank you a lot for the reply! Indeed, the problem was with the files generated
via external program, so not related to POV-Ray.

Thank you again,
Best wishes,
Hanna

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "hanna.baltrukevich" <han### [at] gmailcom> wrote:
> > Hi all,
> > I am a new user of Pov-Ray,
>
> great.  welcome.
>
>
> > and I had this error. I have the .pov file generated
> > from the other program, but when I try to render it in POV-Ray, I get the error:
> > "Parse Error: Expected 'numeric expression', undeclared identifier 'nan' found
> > instead". Did anybody solve this issue already? Thank you a lot in advance.
>
> just a "shot in the dark", but could it be that the generating program, for some
> reason, cannot compute some value and outputs a "Not a Number" result ?  it
> might help if you could post the scene, or the relevant bits from it.
>
>
> regards ,jr.

[jr] Re: Undeclared identifier 'nan' found [669 days 5 hours and 45 minutes ago]

Wed, 12 Jun 2024 17:15:00 GMT

hi,

"hanna.baltrukevich" <han### [at] gmailcom> wrote:
> Hi all,
> I am a new user of Pov-Ray,

great.  welcome.

> and I had this error. I have the .pov file generated
> from the other program, but when I try to render it in POV-Ray, I get the error:
> "Parse Error: Expected 'numeric expression', undeclared identifier 'nan' found
> instead". Did anybody solve this issue already? Thank you a lot in advance.

just a "shot in the dark", but could it be that the generating program, for some
reason, cannot compute some value and outputs a "Not a Number" result ?  it
might help if you could post the scene, or the relevant bits from it.

regards ,jr.

[hanna baltrukevich] Undeclared identifier 'nan' found [669 days 6 hours and 25 minutes ago]

Wed, 12 Jun 2024 16:35:00 GMT

Hi all,

I am a new user of Pov-Ray, and I had this error. I have the .pov file generated
from the other program, but when I try to render it in POV-Ray, I get the error:
"Parse Error: Expected 'numeric expression', undeclared identifier 'nan' found
instead". Did anybody solve this issue already? Thank you a lot in advance.

Best,
Hanna

[William F Pokorny] Re: question about user defined float functions [681 days 7 hours and 58 minutes ago]

Fri, 31 May 2024 15:01:58 GMT

On 5/31/24 09:46, Jonathan Bush wrote:
> Okay, if I understand this correctly, if the input parameter A is boolean, I can
> provide any value I want for B, and C is the value returned when A is false, and
> D is the value when A is true. I hope I got that right.

I'll add, folks sometimes lose track of the fact the virtual machine 
(VM) select() functionality is mirrored in the Scene Description 
Language (SDL). In other words, you can test your logic outside of the 
function {} wrapper prior to use in the function itself - or alongside.

Bill P.


//---
#version 3.8;

#declare A=-1;
#declare B=-2;
#declare Z=0;
#declare C=+2;

#declare Fn_select3 = function (_a,_b,_c)    { select(_a,_b,_c) }
#declare Fn_select4 = function (_a,_b,_z,_c) { select(_a,_b,_z,_c) }

#debug concat("A = ",str(A,3,1),"\n")
#debug concat("B = ",str(B,3,1),"\n")
#debug concat("Z = ",str(Z,3,1),"\n")
#debug concat("C = ",str(C,3,1),"\n")
#debug "\n"
#debug concat("select(A,B,C)       = ",str(select(A,B,C),3,1),"\n")
#debug concat("Fn_select3(A,B,C)   = ",str(Fn_select3(A,B,C),3,1),"\n")
#debug "\n"
#debug concat("select(A,B,Z,C)     = ",str(select(A,B,Z,C),3,1),"\n")
#debug concat("Fn_select4(A,B,Z,C) = ",str(Fn_select4(A,B,Z,C),3,1),"\n")
#debug "\n"

#error "Stop early\n"
//---

[Jonathan Bush] Re: question about user defined float functions [681 days 9 hours and 10 minutes ago]

Fri, 31 May 2024 13:50:00 GMT

"ingo" <nomail@nomail> wrote:
> "Jonathan Bush" <djb### [at] gmxcom> wrote:
> > Is there any way to create a float function which is a conditional expression?
> > Thank you.
>
> You may look at: select(A, B, C [,D])
>
> ingo

Okay, if I understand this correctly, if the input parameter A is boolean, I can
provide any value I want for B, and C is the value returned when A is false, and
D is the value when A is true. I hope I got that right. Thanks for the tip!

[ingo] Re: question about user defined float functions [681 days 10 hours and 50 minutes ago]

Fri, 31 May 2024 12:10:00 GMT

"Jonathan Bush" <djb### [at] gmxcom> wrote:
> Is there any way to create a float function which is a conditional expression?
> Thank you.

You may look at: select(A, B, C [,D])

ingo

[Jonathan Bush] question about user defined float functions [681 days 11 hours and 45 minutes ago]

Fri, 31 May 2024 11:15:00 GMT

In the reference manual I do not find a formal definition of a user defined
float function. Instead, several examples are provided. I assumed a conditional
expression could be used to define a function, but apparently I was mistaken. I
get an error "Parse Error: Expected 'operator', ? found instead"

Is there any way to create a float function which is a conditional expression?
Thank you.

[kurtz le pirate] Re: Transparent Round_Box has many artifacts [776 days 12 hours and 17 minutes ago]

Mon, 26 Feb 2024 10:43:39 GMT

On 26/02/2024 09:16, ceving wrote:
> kurtz le pirate <kur### [at] gmailcom> wrote:
>> Do you really have to use a macro for such a simple object ?
>>
>> Back to basics csg : a simple merge { sphere{} sphere{} cylinder{} } is
>> more than enough, but maybe I've missed something?
> 
> I have no idea. I am a "newuser". I started with the boxes first

Welcome


> and did the player later on. But your suggestion sounds right. I will try it.
> 
> There is also another optimization I need to add. Right now I create the
> different colors with a Makefile and sed:
> 
> https://github.com/ceving/breakout/blob/main/Makefile

Makefile ans sed  are powerful tools on Linux...



> But I think Povray's DSL should be sufficient to do the iteration. I still need
> to find out how.
... but POVRay makes it easy

How ? have a look at the animations and the demo scenes in portfolio
folder like allpatterns.pov, t_textures_.pov, ...







-- 
Kurtz le pirate
Compagnie de la Banquise

[ceving] Re: Transparent Round_Box has many artifacts [776 days 14 hours and 40 minutes ago]

Mon, 26 Feb 2024 08:20:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> Do you really have to use a macro for such a simple object ?
>
> Back to basics csg : a simple merge { sphere{} sphere{} cylinder{} } is
> more than enough, but maybe I've missed something?

I have no idea. I am a "newuser". I started with the boxes first

https://ceving.github.io/breakout/

and did the player later on. But your suggestion sounds right. I will try it.

There is also another optimization I need to add. Right now I create the
different colors with a Makefile and sed:

https://github.com/ceving/breakout/blob/main/Makefile

But I think Povray's DSL should be sufficient to do the iteration. I still need
to find out how.

[Bald Eagle] Re: Transparent Round_Box has many artifacts [777 days 2 hours and 40 minutes ago]

Sun, 25 Feb 2024 20:20:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> Do you really have to use a macro for such a simple object ?

> Back to basics csg : a simple merge { sphere{} sphere{} cylinder{} } is
> more than enough, but maybe I've missed something?

Depends on how many you want to make, or how many adjustments you want to do, or
if you're going to use it in an animation, where it needs to be parameterized.

A macro taking Start, End, and Radius as arguments would save a lot of work.

- BW

[Alain Martel] Re: Transparent Round_Box has many artifacts [777 days 4 hours and 27 minutes ago]

Sun, 25 Feb 2024 18:33:29 GMT

Le 2024-02-25 Ã  12:35, kurtz le pirate a Ã©critÂ :
> On 24/02/2024 20:36, ceving wrote:
>> Thanks! RE_Cylinder works fine.
>>
>> https://ceving.github.io/breakout/Player.png
>>
>> There are some minor artifacts on both ends, but maybe they are normal, I don't
>> know.
> 
> 
> Do you really have to use a macro for such a simple object ?
No, but the macro do exist.
> 
> 
> Back to basics csg : a simple merge { sphere{} sphere{} cylinder{} } is
> more than enough, but maybe I've missed something?
> 

You didn't miss anything.

[kurtz le pirate] Re: Transparent Round_Box has many artifacts [777 days 5 hours and 25 minutes ago]

Sun, 25 Feb 2024 17:35:13 GMT

On 24/02/2024 20:36, ceving wrote:
> Thanks! RE_Cylinder works fine.
> 
> https://ceving.github.io/breakout/Player.png
> 
> There are some minor artifacts on both ends, but maybe they are normal, I don't
> know.

Do you really have to use a macro for such a simple object ?

Back to basics csg : a simple merge { sphere{} sphere{} cylinder{} } is
more than enough, but maybe I've missed something?

-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Transparent Round_Box has many artifacts [778 days and 30 minutes ago]

Sat, 24 Feb 2024 22:30:00 GMT

"ceving" <nomail@nomail> wrote:

> I used the gamma value just as a brightness slider. The images were too dark
> with 1.

Well yeah, you had a black background.
use
sky_sphere {pigment {rgb 1}}
and see the dramatic difference.

[ceving] Re: Transparent Round_Box has many artifacts [778 days 3 hours and 20 minutes ago]

Sat, 24 Feb 2024 19:40:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> I have created a set of macros that avoids redundant spheres and cylinders:
>
>   https://github.com/CousinRicky/POV-RoundEdge/releases
>
> Macros RE_Box() and RE_Cylinder will both work for this object, using
> UseMerge = true.

Thanks! RE_Cylinder works fine.

https://ceving.github.io/breakout/Player.png

There are some minor artifacts on both ends, but maybe they are normal, I don't
know.

> I don't normally give advice that asked (I prefer to let new users deal
> with problems one at a time), but Alain is correct about assumed_gamma 1.

I used the gamma value just as a brightness slider. The images were too dark
with 1.

[Kenneth] Re: Transparent Round_Box has many artifacts [778 days 8 hours and 55 minutes ago]

Sat, 24 Feb 2024 14:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Can we rehash gamma and srgb conversion again?   *PLEASE*?
>
> That's totally one of my favorite topics!

Personally, I would rather dance on a bed of hot coals instead; it would
probably be less painful, and far less confusing...

;-)

[Bald Eagle] Re: Transparent Round_Box has many artifacts [778 days 22 hours and 55 minutes ago]

Sat, 24 Feb 2024 00:05:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
>  This is a whole bed of weeds that you
> need to understand before taking advice blindly.

YESSSS!!!!

Can we rehash gamma and srgb conversion again?   *PLEASE*?

That's totally one of my favorite topics!

[Cousin Ricky] Re: Transparent Round_Box has many artifacts [779 days 1 hour and 7 minutes ago]

Fri, 23 Feb 2024 21:53:29 GMT

On 2024-02-23 17:41 (-4), Cousin Ricky wrote:
> 
> I don't normally give advice that asked (I prefer to let new users deal
> with problems one at a time), but Alain is correct about assumed_gamma 1.

*wasn't asked.

[Cousin Ricky] Re: Transparent Round_Box has many artifacts [779 days 1 hour and 18 minutes ago]

Fri, 23 Feb 2024 21:41:59 GMT

On 2024-02-23 05:38 (-4), ceving wrote:
> I tried to create a transparent cylinder with spherical ends. I used Round_Box,
> but I get many strange artifacts. I am not sure why. Can anybody explain why or
> how I can produce this object in another way?

Round_Cylinder() doesn't solve the problem; I tried it with UseMerge =
true, and that caused the object to vanish entirely.  But using UseMerge
= true with Round_Box() got rid of the artifacts.

I have created a set of macros that avoids redundant spheres and cylinders:

  https://github.com/CousinRicky/POV-RoundEdge/releases

Macros RE_Box() and RE_Cylinder will both work for this object, using
UseMerge = true.

I don't normally give advice that asked (I prefer to let new users deal
with problems one at a time), but Alain is correct about assumed_gamma 1.

However, I disagree with a blanket statement about rgbt vs. srgbt.  For
your particular example, it makes no difference, but the truth is that
srgbt is more likely to give you the colors that you expect, regardless
of your assumed_gamma setting. This is a whole bed of weeds that you
need to understand before taking advice blindly.

[Alain Martel] Re: Transparent Round_Box has many artifacts [779 days 6 hours and 57 minutes ago]

Fri, 23 Feb 2024 16:03:11 GMT

Le 2024-02-23 Ã  04:38, ceving a Ã©critÂ :
> I tried to create a transparent cylinder with spherical ends. I used Round_Box,
> but I get many strange artifacts. I am not sure why. Can anybody explain why or
> how I can produce this object in another way?
> 
> This is what I have done:
> 
> #version 3.7;
> #include "colors.inc"
> #include "shapes.inc"
> global_settings {
>   assumed_gamma 0.4
> }
> background { colour srgbt <0.0, 0.0, 0.0, 1.0> }
> camera {
>    location <0, 5, 0>
>    look_at  <0, -1, 0>
> }
> 
> #declare pA = <-1.5,  0, -0.5>;  // A corner
> #declare pB = <+1.5, -1, +0.5>;  // The opposite corner
> #declare EdgeAndcornerRadius = 0.5;
> #declare UseMerge = false;
> 
> object {
>    Round_Box(pA, pB, EdgeAndcornerRadius, UseMerge)
>    texture {
>      pigment { color srgbt <0.0, 0.0, 0.0, 0.5> }
>    }
>    finish {
>      ambient .1
>      diffuse .3
>      specular 1
>      roughness .01
>      metallic
>      reflection {
>        .75
>        metallic
>      }
>    }
> }


Instead of Round_Box, you should use the Round_Cylinder for what you 
want to do here.
As Bald Eagle mentioned, you need to use
#declare UseMerge = true;
With UseMerge = false, the inner surfaces are still there. Perfect when 
the object is opaque, bad for any transparent object. merge remove the 
internal surfaces.

Unless you start with a colour from a colour picker or an external 
source, you should use rgbt instead of srgbt.
Why use assumed_gamma 0.4 ?
To have consistent results, you should use assumed_gamma 1.

Round_Cylinder(EndA, EndB, Radius, EdgeRadius, UseMerge)

[Bald Eagle] Re: Transparent Round_Box has many artifacts [779 days 11 hours and 25 minutes ago]

Fri, 23 Feb 2024 11:35:00 GMT

"ceving" <nomail@nomail> wrote:
> I tried to create a transparent cylinder with spherical ends. I used Round_Box,
> but I get many strange artifacts. I am not sure why. Can anybody explain why

use:
#declare UseMerge = true;

or
> how I can produce this object in another way?

The Round_Box macro is going to make 8 cylinders and 8 spheres.  You only need 1
cylinder and 2 spheres, so just do that using merge {}

- BE

[ceving] Transparent Round_Box has many artifacts [779 days 13 hours and 20 minutes ago]

Fri, 23 Feb 2024 09:40:00 GMT

I tried to create a transparent cylinder with spherical ends. I used Round_Box,
but I get many strange artifacts. I am not sure why. Can anybody explain why or
how I can produce this object in another way?

This is what I have done:

#version 3.7;
#include "colors.inc"
#include "shapes.inc"
global_settings {
 assumed_gamma 0.4
}
background { colour srgbt <0.0, 0.0, 0.0, 1.0> }
camera {
  location <0, 5, 0>
  look_at  <0, -1, 0>
}

#declare pA = <-1.5,  0, -0.5>;  // A corner
#declare pB = <+1.5, -1, +0.5>;  // The opposite corner
#declare EdgeAndcornerRadius = 0.5;
#declare UseMerge = false;

object {
  Round_Box(pA, pB, EdgeAndcornerRadius, UseMerge)
  texture {
    pigment { color srgbt <0.0, 0.0, 0.0, 0.5> }
  }
  finish {
    ambient .1
    diffuse .3
    specular 1
    roughness .01
    metallic
    reflection {
      .75
      metallic
    }
  }
}

light_source { <-2, 4, 4> color White}

[William F Pokorny] Re: Wave type [885 days 11 hours and 15 minutes ago]

Thu, 9 Nov 2023 11:45:35 GMT

On 11/8/23 16:44, Bald Eagle wrote:
> #declare Onion = function {pigment {onion} color_map {[0 rgb 0] [1 rgb 1]}}

FWIW. A better option, when all you want is a pattern's scalar value for 
a function is:

#declare Onion = function {pattern {onion}}

It avoids the conversion to grey - and, of course, no worries about the 
default color map.

---
Aside: I saw your other posts on select() and yuqk/v4 ideas, but it'll 
be a bit before I can even read through them. I'm still working through 
tuple / batch assignment issues. Once I manage that bit, 
'local'/'global' pseudo dictionary and 'optional' issues will pop off 
the debug stack.

Busy with real life later today too.

Bill P.

[Bald Eagle] Re: Wave type [886 days 1 hour and 15 minutes ago]

Wed, 8 Nov 2023 21:45:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> The ideal solution (for me) would be :
> pigment {
>  onion
>  color_map { ... }
>  myWaveTypeFn // for the wave
>  }
>
> myWaveTypeFn same as standard cubic_wave, poly_wave, ...

I think this might work:

Take onion, and make it

#declare Onion = function {pigment {onion}}

Now define a user-defined wave function to apply to the domain of the original
pigment function

#declare Wave = function {sin (Onion (x, y, z)*tau)}

 pigment {
  Onion
  color_map { ... }
  // and now the wave function is already built into the pigment pattern
  }

You just need to use the 0-1 values returned by your pigment pattern as the
input for your wave function.

If you're going to be using a pigment pattern that POV-Ray assigns an in-built
color_map to, then you need to override that in your original pigment function
with a user-defined color map going from black (1) to white (1).

#declare Onion = function {pigment {onion} color_map {[0 rgb 0] [1 rgb 1]}}

- BW

[William F Pokorny] Re: Wave type [886 days 4 hours and 30 minutes ago]

Wed, 8 Nov 2023 18:30:10 GMT

On 11/8/23 10:27, kurtz le pirate wrote:
> The ideal solution (for me) would be :
> pigment {
> 	onion
> 	color_map { ... }
> 	myWaveTypeFn // for the wave
> 	}
> 
> myWaveTypeFn same as standard cubic_wave, poly_wave, ...

I confess I'm, unsure what you are trying to do.

The code below works today, FWIW.

Aside: One of the changes yuqk made was so that poly_wave always chains 
after the other wave modifiers. Meaning you can use, for example, 
'triangle_wave poly_wave 2' and the code runs both modifiers with
poly_wave always being executed last.

Bill P.

     // Sample scene. 'povray onion.pov +w800 +h800 +p +mv3.8'
     global_settings { assumed_gamma 1.0 }
     #declare VarOrthoMult =
         3.0/max(image_width/image_height,image_height/image_width);
     #declare Camera01z = camera {
         orthographic
         location <0,0,-2>
         direction z
         right VarOrthoMult*x*max(1,image_width/image_height)
         up VarOrthoMult*y*max(1,image_height/image_width)
     }
     #declare FnOnion = function { pattern { onion triangle_wave } }
     #declare Fn = function {
         FnOnion(x,y,z) * 6.0 // = 'frequency 6'
     }
     plane { -z 0
         pigment {
             function { Fn(x,y,z) }
             poly_wave 2
             // I'm using the default color map, but you can chain
             // the functions as deep as you want and each chain
             // could be a color channel in a user_defined pigment.
         }
         finish { emission 1 }
     }
     camera { Camera01z }

     // If you want to see linear values in the preview display
     // over gamma corrected ones, add display_gamma=1.0 to the
     // command line.

[kurtz le pirate] Re: Wave type [886 days 7 hours and 33 minutes ago]

Wed, 8 Nov 2023 15:27:30 GMT

On 08/11/2023 12:58, Bald Eagle wrote:
> kurtz le pirate <kur### [at] gmailcom> wrote:
>> Hello
>>
>> Is it possible to customize "wave_form" in color patterns ?
>> Thanks
> 
> 
> Well, ... yes, but as far as I know, you can only do it in the TOK / Bald Eagle
> over-complicated "write the whole thing yourself from scratch" method.
> 
> You know that you can use a function to define a pigment pattern,
> pigment {function {}}
> and that you can have POV-Ray convert any inbuilt pigment pattern into a
> function.
> function {pigment {}}
> 
> So what you do, is you take your pattern, convert it into a function, and then
> use a user-defined function to modulate that 0-1 range according to the
> wave_type that you implement in your function.
> 
> #declare f_Pattern = function {pigment {}}
> #declare f_Wave = function {my_wave_type}
> #declare WavePattern = function {f_Pattern * f_Wave}
> 
> Then you make a texture using the "average" pattern, and use the product of your
> pattern function and wave function to control the rgbft values in the average
> texture.
> 
>  #declare WaveModifiedPigment =
>   texture {
>    pigment {
>           average
>           pigment_map {
>               [
>                   function { WavePattern (x, y, z).red }
>                   color_map {
>                       [ 0 red 0 ]
>                       [ 1 red 5 ]
>                   }
>           ... etc
>                  }
> 
> Depending upon your exact needs, you _might_ need to create a special cumulative
> distribution function (cdf) using a spline, and then employ importance sampling
> by writing a probability density function (pdf) to return your color_map value
> from the cdf for any given pattern value.  And THAt will be your actual f_Wave
> function that you use in the average texture.
> 
> Hope that "helps".
> 
> - Bill
> 

Always there to help ;)

I've already found one method :
pigment {
	user_defined {
		function { f_sinc (x)*2 } // only red
		}
	...
	} // end of pigment

This is a partial answer to what I wanted to do, but this method can't
be combined (at least not yet) with existing patterns.

The ideal solution (for me) would be :
pigment {
	onion
	color_map { ... }
	myWaveTypeFn // for the wave
	}

myWaveTypeFn same as standard cubic_wave, poly_wave, ...


Your (and TOK) suggestion with :
pigment { average pigment_map { [ function ...
is very good and well know.
I use it to color the plane and TOK does the same.
See previous messages about domain coloring and complex numbers.

I'll keep searching ...





-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Wave type [886 days 11 hours ago]

Wed, 8 Nov 2023 12:00:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello
>
> Is it possible to customize "wave_form" in color patterns ?
> Thanks

Well, ... yes, but as far as I know, you can only do it in the TOK / Bald Eagle
over-complicated "write the whole thing yourself from scratch" method.

You know that you can use a function to define a pigment pattern,
pigment {function {}}
and that you can have POV-Ray convert any inbuilt pigment pattern into a
function.
function {pigment {}}

So what you do, is you take your pattern, convert it into a function, and then
use a user-defined function to modulate that 0-1 range according to the
wave_type that you implement in your function.

#declare f_Pattern = function {pigment {}}
#declare f_Wave = function {my_wave_type}
#declare WavePattern = function {f_Pattern * f_Wave}

Then you make a texture using the "average" pattern, and use the product of your
pattern function and wave function to control the rgbft values in the average
texture.

 #declare WaveModifiedPigment =
  texture {
   pigment {
          average
          pigment_map {
              [
                  function { WavePattern (x, y, z).red }
                  color_map {
                      [ 0 red 0 ]
                      [ 1 red 5 ]
                  }
          ... etc
                 }

Depending upon your exact needs, you _might_ need to create a special cumulative
distribution function (cdf) using a spline, and then employ importance sampling
by writing a probability density function (pdf) to return your color_map value
from the cdf for any given pattern value.  And THAt will be your actual f_Wave
function that you use in the average texture.

Hope that "helps".

- Bill

[kurtz le pirate] Wave type [886 days 13 hours and 44 minutes ago]

Wed, 8 Nov 2023 09:16:22 GMT

Hello

Is it possible to customize "wave_form" in color patterns ?
Thanks



-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Dumb newbie here! How to use PovRay [895 days 11 hours and 55 minutes ago]

Mon, 30 Oct 2023 11:05:00 GMT

Right, so:
"RaySAR can be run on Windows / Linux and is based on an adapted version of the
open-source ray tracer POV-Ray."

Presumably Dr. Auer isn't going to just send you off to perform some ill-defined
task with a piece of software that he (likely) knows you know nothing about.
(Although having been through several (technically 5) universities, it wouldn't
be something I'd dismiss out-of-hand ;) )

"...but i need opposite"

I'd say that what you need to do is rigorously define the task and what the
input and output need to be.  Clearly, RADAR is very much like light in that it
can travel in straight lines and bounce - so with POV-Ray, you are going to use
a lightsource and objects, and presumably a reflective surface to mimic RADAR
signals.

Draw a labeled diagram to illustrate what you need to do.

- BW

IIRC, you can use Poseray software to convert your .obj to a mesh2 object.
You might want to find a much smaller .obj file to set up a sample scene and
work out all of the details, before running it on a huge file.

(I for one, would love to have some folks from your group contribute some
practical photogrammetry resources to our community (equations, code), since I
and a few others have a long standing interest in the subject.)

We'd love to help further develop POV-Ray as a useful photogrammetry-related
software package and extend its present sphere of use!

"Archadas" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Archadas" <nomail@nomail> wrote:
> > > Hello everyone.
> >
> > Hello, and welcome.
> >
> > > I need to solve how to usue raytracing on my 3d .obj models and get result and
> > > use those results in RaySAR.

> Hello Bill
> Thank you for your reply
> i can send my obj file in following days if it could be useful.
> https://github.com/StefanJAuer/RaySAR
> this is the link of RaySAR from Stefan JAuer. My duty is using RaySAR to get SAR
>  simulation results of my 3d model. I need to find the way to do it and start
> using it on my 3d models as soon as possible for my studies.
>
> As i mentioned before, all the tutorials are writing the code and getting the
> image but i need opposite. Sorry everyone if im getting something wrong, maybe
> thats how its done or how its start, i just dont really know.
>
> Thank you so much for your welcoming message :)

[Archadas] Re: Dumb newbie here! How to use PovRay [895 days 16 hours and 15 minutes ago]

Mon, 30 Oct 2023 06:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Archadas" <nomail@nomail> wrote:
> > Hello everyone.
>
> Hello, and welcome.
>
> > I need to solve how to usue raytracing on my 3d .obj models and get result and
> > use those results in RaySAR.
>
> Perhaps post a link or an attachment of your .obj (depending on size) and give
> us some background on RaySAR and what you need to do with POV-Ray to make it all
> work.
>
> > So first thing is i need to understand how to use PovRay. I am someone who
> > doesnt have any knowledge about coding, neither matlab or python etc.
>
> There are some videos about basic POV-Ray usage on Youtube, and there are plenty
> of example scenes, and (in windows) the drop-down Insert menu in the editor to
> paste in snippets of useful code.
> As with everything, pick some very simple task as your goal, and then
> progressively add levels of complexity.
>
> > Im having a hard time understanding how to use it.
>
> Welcome to the POV-Ray new user club  ;)
>
> Try out some simple scenes, and post your full test scene and the problems
> you're having, and we can get you pointed in the right direction.
>
> - Bill

Hello Bill
Thank you for your reply
i can send my obj file in following days if it could be useful.
https://github.com/StefanJAuer/RaySAR
this is the link of RaySAR from Stefan JAuer. My duty is using RaySAR to get SAR
 simulation results of my 3d model. I need to find the way to do it and start
using it on my 3d models as soon as possible for my studies.

As i mentioned before, all the tutorials are writing the code and getting the
image but i need opposite. Sorry everyone if im getting something wrong, maybe
thats how its done or how its start, i just dont really know.

Thank you so much for your welcoming message :)

[Archadas] Re: Dumb newbie here! How to use PovRay [895 days 16 hours and 20 minutes ago]

Mon, 30 Oct 2023 06:40:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2023-10-26 à 04:45, Archadas a écrit :
> > Hello everyone.
> > I need to solve how to usue raytracing on my 3d .obj models and get result and
> > use those results in RaySAR.
> > So first thing is i need to understand how to use PovRay. I am someone who
> > doesnt have any knowledge about coding, neither matlab or python etc.
> >
> > Im having a hard time understanding how to use it. Is there any walkthrough or
> > video shows how to use PovRay and get the results ?
> >
> > Im sorry if i missed any topic in the website, im just newbie here.
> >
> > Thank you so much in advance
> >
> > Archadas
> >
>
> First thing : Get in the tutorial that come with POV-Ray and follow it.
> It's part of the included help file. Open the help and look for the
> second item : POV-Ray Tutorial | Getting Started.
>
> It starts with some basic principles and some very simple scenes for you
> to type in and render. Then, change something, render again and see the
> change. Take your time. Don't be afraid to experiment.
> It progressively get you to create some more complex and detailed scenes
> and images.
>
> Enter the following in the editor and click the «Run» button.
>
> #version 3.7;
>   #include "colors.inc"
> // The include files contain basic colour definitions
> // A simple pinhole camera
>    camera {
>      location <0, 2, -3>
>      look_at  <0, 1,  2>
>    }
> // A plain yellow sphere
>    sphere {
>      <0, 1, 2>, 2
>      texture {
>        pigment { Yellow }
>      }
>    }
> // Let shed some light in the sphere
> light_source { <2, 4, -3> White}

Hello Alain Martel,
Thank you for your reply. I did what you told me and followed tutorial from wiki
as well. Created different shapes images etc. Changed the code and get different
results and all. But i still didnt understand how to do `opposite` of this. What
i need is (as far as i know, still not sure) using povray on my 3d model scene
and get the raytracing results and use those results in RaySAR to get Sar image
simulation results. Still dont know how to manage it since i am not good with
coding
Thank you again

[Archadas] Re: Dumb newbie here! How to use PovRay [895 days 16 hours and 25 minutes ago]

Mon, 30 Oct 2023 06:35:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Archadas" <nomail@nomail> wrote:
> > Hello everyone.
> > I need to solve how to usue raytracing on my 3d .obj models and get result and
> > use those results in RaySAR.
>
> there's no direct import of .obj format files in "stock" POV-Ray.
>
>
> > So first thing is i need to understand how to use PovRay. I am someone who
> > doesnt have any knowledge about coding, neither matlab or python etc.
> > Im having a hard time understanding how to use it. Is there any walkthrough or
> > video shows how to use PovRay and get the results ?
>
> to get you started, hope you'll "find your feet":
>
> <https://wiki.povray.org/content/Documentation:Tutorial_Section_2#Getting_Started>
>
<https://wiki.povray.org/content/Documentation:Tutorial_Section_3.8#SDL_tutorial:_A_raytracer>
>
> the wiki always has the most up-to-date "official" documentation.
>
>
> regards, jr.

Hello Jr.
Thank you for your reply. I though i could import it but if there is no, i
should find a way then.

I followed the links you shared and i liked how it went but the thing is what we
doing here is mostly writing the code and receiving the model/image. What i need
is giving the model/image and receiving the code (as far as i understand) to use
in RaySar.

[Bald Eagle] Re: Dumb newbie here! How to use PovRay [899 days 2 hours and 35 minutes ago]

Thu, 26 Oct 2023 20:25:00 GMT

"Archadas" <nomail@nomail> wrote:
> Hello everyone.

Hello, and welcome.

> I need to solve how to usue raytracing on my 3d .obj models and get result and
> use those results in RaySAR.

Perhaps post a link or an attachment of your .obj (depending on size) and give
us some background on RaySAR and what you need to do with POV-Ray to make it all
work.

> So first thing is i need to understand how to use PovRay. I am someone who
> doesnt have any knowledge about coding, neither matlab or python etc.

There are some videos about basic POV-Ray usage on Youtube, and there are plenty
of example scenes, and (in windows) the drop-down Insert menu in the editor to
paste in snippets of useful code.
As with everything, pick some very simple task as your goal, and then
progressively add levels of complexity.

> Im having a hard time understanding how to use it.

Welcome to the POV-Ray new user club  ;)

Try out some simple scenes, and post your full test scene and the problems
you're having, and we can get you pointed in the right direction.

- Bill

[Alain Martel] Re: Dumb newbie here! How to use PovRay [899 days 3 hours and 33 minutes ago]

Thu, 26 Oct 2023 19:27:42 GMT

Le 2023-10-26 Ã  04:45, Archadas a Ã©critÂ :
> Hello everyone.
> I need to solve how to usue raytracing on my 3d .obj models and get result and
> use those results in RaySAR.
> So first thing is i need to understand how to use PovRay. I am someone who
> doesnt have any knowledge about coding, neither matlab or python etc.
> 
> Im having a hard time understanding how to use it. Is there any walkthrough or
> video shows how to use PovRay and get the results ?
> 
> Im sorry if i missed any topic in the website, im just newbie here.
> 
> Thank you so much in advance
> 
> Archadas
> 

First thing : Get in the tutorial that come with POV-Ray and follow it. 
It's part of the included help file. Open the help and look for the 
second item : POV-Ray Tutorial | Getting Started.

It starts with some basic principles and some very simple scenes for you 
to type in and render. Then, change something, render again and see the 
change. Take your time. Don't be afraid to experiment.
It progressively get you to create some more complex and detailed scenes 
and images.

Enter the following in the editor and click the Â«RunÂ» button.

#version 3.7;
  #include "colors.inc"
// The include files contain basic colour definitions
// A simple pinhole camera
   camera {
     location <0, 2, -3>
     look_at  <0, 1,  2>
   }
// A plain yellow sphere
   sphere {
     <0, 1, 2>, 2
     texture {
       pigment { Yellow }
     }
   }
// Let shed some light in the sphere
light_source { <2, 4, -3> White}

[jr] Re: Dumb newbie here! How to use PovRay [899 days 9 hours and 20 minutes ago]

Thu, 26 Oct 2023 13:40:00 GMT

hi,

"Archadas" <nomail@nomail> wrote:
> Hello everyone.
> I need to solve how to usue raytracing on my 3d .obj models and get result and
> use those results in RaySAR.

there's no direct import of .obj format files in "stock" POV-Ray.


> So first thing is i need to understand how to use PovRay. I am someone who
> doesnt have any knowledge about coding, neither matlab or python etc.
> Im having a hard time understanding how to use it. Is there any walkthrough or
> video shows how to use PovRay and get the results ?

to get you started, hope you'll "find your feet":

<https://wiki.povray.org/content/Documentation:Tutorial_Section_2#Getting_Started>
<https://wiki.povray.org/content/Documentation:Tutorial_Section_3.8#SDL_tutorial:_A_raytracer>

the wiki always has the most up-to-date "official" documentation.


regards, jr.

[Archadas] Dumb newbie here! How to use PovRay [899 days 14 hours and 10 minutes ago]

Thu, 26 Oct 2023 08:50:00 GMT

Hello everyone.
I need to solve how to usue raytracing on my 3d .obj models and get result and
use those results in RaySAR.
So first thing is i need to understand how to use PovRay. I am someone who
doesnt have any knowledge about coding, neither matlab or python etc.

Im having a hard time understanding how to use it. Is there any walkthrough or
video shows how to use PovRay and get the results ?

Im sorry if i missed any topic in the website, im just newbie here.

Thank you so much in advance

Archadas

[Alain Martel] Re: transparent background [903 days 1 hour and 53 minutes ago]

Sun, 22 Oct 2023 21:07:34 GMT

Le 2023-10-22 Ã  16:49, LAze a Ã©critÂ :
> Hi,
> I want to render an image with a transparent background while keeping the
> lighting of my object intact as if there was a background.
You may try using a fake background. It could be a large sphere with the 
no_image and no_shadow attributes.

With no_image, that object remains invisible from direct view.
The no_shadow is to prevent it from interfering with your lighting.
You may add no_radiosity if your scene use radiosity.
That object will act as the background and show in the reflection.

[LAze] transparent background [903 days 2 hours and 10 minutes ago]

Sun, 22 Oct 2023 20:50:00 GMT

Hi,
I want to render an image with a transparent background while keeping the
lighting of my object intact as if there was a background.

[kurtz le pirate] Re: Calculation errors [940 days 16 hours and 3 minutes ago]

Fri, 15 Sep 2023 06:57:36 GMT

_
          | )
          | |
          | |_____
         /    (]__)
        /    (]___)
       /    (]___)
          ___(]_)
         /
        /
Thanks a lot guys !


Reading the docs we don't pay enough attention to these kinds of details
but it's really jackasses of Microsoft to reverse the arguments.

Microsoft always faithful to its stupidity...



-- 
Kurtz le pirate
Compagnie de la Banquise

[Thorsten] Re: Degree symbol [941 days 4 hours and 26 minutes ago]

Thu, 14 Sep 2023 18:34:41 GMT

On 14.09.2023 15:31, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] gmailcom> wrote:
>> Hello,
>>
>> Cannot use degrees "Â°" symbol in POV. In UTF8, the code is 176/0xB0.
>> ...
>> The sign never appears...
>> Any help ?
> 
> no help (sorry), just confirmation that the same is true for beta.2 (without
> graphical i/f, self-compiled, on a Linux box), I can render the char to appear
> in an image[*], but cannot get it to file or console.
> 
> [*] interestingly, 'povray' shows a different gylph (infinity, number 8
> rotated), while WFP's 'povr' displays the degree symbol.

The Unicode handling in POV-Ray for fonts is rather old and had to work 
with a lot of buggy fonts back in prehistoric times (read: 2007). Hence 
it on the one hand doesn't know all the font options and on the other 
hand the one it selects to find the character may be the wrong one or 
just broken or incomplete in that particular font.

Thorsten

[Thorsten] Re: Degree symbol [941 days 4 hours and 28 minutes ago]

Thu, 14 Sep 2023 18:32:35 GMT

On 14.09.2023 14:51, kurtz le pirate wrote:
> Hello,
> 
> Cannot use degrees "Â°" symbol in POV. In UTF8, the code is 176/0xB0.
> 
> In global_settings, I've added the option "charset utf8".
> 
> I defined: #declare DEGREE_SIGN = chr(176);
> 
> Both in the console (#debug") and in a :
> #declare DEStr = concat(str(DECDeg,-2,0), DEGREE_SIGN,
> str(DECMinute,-2,3),"'")
> #write (OUTFILE, concat(DateStr,"\t", RAStr,"\t", DEStr,"\n") )
> 
> 
> The sign never appears...
> Any help ?

The charset only affects the rendering of text. Console output is ASCII.

Thorsten

[Droj] Re: Calculation errors [941 days 4 hours and 30 minutes ago]

Thu, 14 Sep 2023 18:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> kurtz le pirate <kur### [at] gmailcom> wrote:
> > Hello,
> >
> > I'm trying to adapt an Excel spreadsheet in POV. I've got a strange problem.
>
> Are you trying to do atan2 like sane people do?
> Because the jackasses at Microsoft reversed the arguments.
>
>
https://news.povray.org/povray.binaries.images/message/%3C58f61085%40news.povray.org%3E/#%3C58f61085%40news.povray.or
g%
> 3E
>
> -BW

Hi BE,

we had a similar problem a while ago with the tube-kind-of-thing:
'the atan2 mystery' and you found the right track.

But see what Povray 3.7 documentation uses:
<< 3.3.1.5.4 Functions
atan2(A,B)
Arc-tangent of (A/B). Returns the angle, measured in radians, whose tangent is
(A/B)....>>

So in your words and accepted by the rest of the world - except Microsoft - it
should read atan2(B,A).

It's always good to have you around.

-Droj

[Bald Eagle] Re: Calculation errors [941 days 5 hours and 5 minutes ago]

Thu, 14 Sep 2023 17:55:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello,
>
> I'm trying to adapt an Excel spreadsheet in POV. I've got a strange problem.

Are you trying to do atan2 like sane people do?
Because the jackasses at Microsoft reversed the arguments.

https://news.povray.org/povray.binaries.images/message/%3C58f61085%40news.povray.org%3E/#%3C58f61085%40news.povray.org%
3E

-BW

[kurtz le pirate] Re: Degree symbol [941 days 7 hours and 36 minutes ago]

Thu, 14 Sep 2023 15:23:55 GMT

On 14/09/2023 15:31, jr wrote:

> no help (sorry), just confirmation that the same is true for beta.2 (without
> graphical i/f, self-compiled, on a Linux box), I can render the char to appear
> in an image[*], but cannot get it to file or console.



I feel less alone


-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Calculation errors [941 days 7 hours and 37 minutes ago]

Thu, 14 Sep 2023 15:23:06 GMT

Hello,

I'm trying to adapt an Excel spreadsheet in POV. I've got a strange problem.

In Excel
Cell E19 = 280.8191102;
Cell E20 = 23.43825611;
Cell E21 = DEGRES ( ATAN2 ( COS(RADIANS(E19));
COS(RADIANS(E20))*SIN(RADIANS(E19) ) ) )

E21 = -78.23396726


In POV
#declare E19 = 280.8191102;
#declare E20 = 23.43825611;
#declare RESULT =degrees(atan2(cos(radians(E19)),
cos(radians(E20))*sin(radians(E19))));

RESULT = 168.233967


No obvious relationship between this -78.2 and +168.2
How to explain this difference ?

Especially since the correct value is -78.2 or 281.7 !
(Note that the numbers after the decimal point are exactly the same.)

Are the origins of angles and rotation direction in Excel and POV
different ?

help apprecied

-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: Degree symbol [941 days 8 hours and 20 minutes ago]

Thu, 14 Sep 2023 14:40:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...I can render the char to appear
> in an image[*], but cannot get it to file or console.

and, fwiw, reading a string with the utf8 char in it from file gives me:
"Possible Parse Error: Non-ASCII character has been replaced by space character"


regards, jr.

[jr] Re: Degree symbol [941 days 9 hours and 25 minutes ago]

Thu, 14 Sep 2023 13:35:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello,
>
> Cannot use degrees "°" symbol in POV. In UTF8, the code is 176/0xB0.
> ...
> The sign never appears...
> Any help ?

no help (sorry), just confirmation that the same is true for beta.2 (without
graphical i/f, self-compiled, on a Linux box), I can render the char to appear
in an image[*], but cannot get it to file or console.

[*] interestingly, 'povray' shows a different gylph (infinity, number 8
rotated), while WFP's 'povr' displays the degree symbol.

regards, jr.

[kurtz le pirate] Degree symbol [941 days 10 hours and 9 minutes ago]

Thu, 14 Sep 2023 12:51:18 GMT

Hello,

Cannot use degrees "Â°" symbol in POV. In UTF8, the code is 176/0xB0.

In global_settings, I've added the option "charset utf8".

I defined: #declare DEGREE_SIGN = chr(176);

Both in the console (#debug") and in a :
#declare DEStr = concat(str(DECDeg,-2,0), DEGREE_SIGN,
str(DECMinute,-2,3),"'")
#write (OUTFILE, concat(DateStr,"\t", RAStr,"\t", DEStr,"\n") )


The sign never appears...
Any help ?



-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Re: Problem with macros and translate function :/ [962 days 13 hours and 28 minutes ago]

Thu, 24 Aug 2023 09:32:08 GMT

On 23/08/2023 18:52, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] gmailcom> wrote:
>> ...
>> Quickly:
> 
> should have stopped for coffee.  </grin>
> 

You're a thousand times right.
I'm going back for another coffee.

Sorry :(



-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Problem with macros and translate function :/ [963 days 4 hours and 50 minutes ago]

Wed, 23 Aug 2023 18:10:00 GMT

"aysays" <nomail@nomail> wrote:
> Hello I'm new to Pov-Ray and am trying to write a broccoli fractal code however
> I'm having problems with the translate function. If I understood it correctly,
> translate only accepts numerical values. I tried writing a macro but that didn't
> work either. How am I supposed to write a recursive function that utilizes
> translate?

The first thing I noticed when trying to format/indent your code (and
simultaneously make jr twitch by using TAB characters to denote whitespace) was
that you cone definition and while loop are .... disjoint.

Also, sin and cos expect angle expressed in radians.

I don't see much of a difference when changing the camera location, so something
strange is going on.  I also don't get much of a difference when I multiply your
x and y values in the translate function by as much as 10.   So you may not be
translating as much as you think you ought to be.
Scaling that cone after translating causes an(other), probably unintentional
translation, due to the offset from the origin.
Scaling by 0.15 100 times is going to make those other cones SMALL, probably to
the point of invisibility, especially since they are currently (?) hidden by the
first cone, since all the others don't get translated far enough away from the
first one. (speculating)

What you want to do is plan out a little more clearly what ought to be
happening.
Include some comments describing exactly what you want to happen at each stage,
and then comment each line to describe what each line actually does.

I'd probably make the macro determine the location and scale of the cone, and
instantiate it, an put the macro call(s) in the while loop.  Just to make things
clearer.  Maybe calculate the translate and scaling separately, and output those
values to the debug stream, so you can see what's _actually_ happening
(numerically)

I'd also calculate your n value, check to make sure it's non-zero, and THEN call
the macro recursively if that's the case.  seems clearer.

- BW

I think you're close, but the logic of the scene needs to be cleaned up a bit.

[jr] Re: Problem with macros and translate function :/ [963 days 6 hours and 5 minutes ago]

Wed, 23 Aug 2023 16:55:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> Quickly:

should have stopped for coffee.  </grin>

> the trans() macro doesn't know the values of 'i' and 'ang'.
> Either declare these variables globally, or pass them as parameters.

'ang' is global, '#declare'd.  but (sorry) you're wrong re the 'i', see below.
without passing it as an argument cannot modify it though.

and to clarify:
> use '#local' inside macros, rather than '#declare's.

unless you do want to modify global variables.

regards, jr.

-----<snip>-----
#version 3.7;

global_settings {assumed_gamma 1}
box {0,1}

#declare foo_ = 12345;

#macro m_b()
  #debug concat("foo ",str(foo_,0,0)," bar ",str(bar_,0,0),".\n")
#end

#macro m_a()
  #local bar_ = 67890;
  m_b()
#end

m_a()

[kurtz le pirate] Re: Problem with macros and translate function :/ [963 days 7 hours and 37 minutes ago]

Wed, 23 Aug 2023 15:22:47 GMT

On 23/08/2023 13:57, aysays wrote:
> Hello I'm new to Pov-Ray and am trying to write a broccoli fractal code however
> I'm having problems with the translate function. If I understood it correctly,
> translate only accepts numerical values. I tried writing a macro but that didn't
> work either. How am I supposed to write a recursive function that utilizes
> translate? :/ Here is my code:
> 
> .. 
> 
> Thanks in advance :)
> 
> 

Quickly: the trans() macro doesn't know the values of 'i' and 'ang'.
Either declare these variables globally, or pass them as parameters.


-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: Problem with macros and translate function :/ [963 days 9 hours and 50 minutes ago]

Wed, 23 Aug 2023 13:10:00 GMT

hi,

"aysays" <nomail@nomail> wrote:
> Hello I'm new to Pov-Ray and am trying to write a broccoli fractal code however

great.  enjoy!

> I'm having problems with the translate function. If I understood it correctly,
> translate only accepts numerical values. I tried writing a macro but that didn't
> work either. How am I supposed to write a recursive function that utilizes
> translate? :/ Here is my code:

have not the time to delve deeply, right now, just a couple of things (as you're
"new").

scene files ought to have a '#version' directive as (one of) their first lines.
re variable names, I too am all for lowercase but you will have to be very
careful, using capitalised or pre/post-fixed names is recommended and "safe".
use '#local' inside macros, rather than '#declare's.

re the recursive macro.  I'd be uncomfortable trying to create, um, a cone of
cones, inline, suggest a macro which expands to one cone, and call/place that
from within the loop  in 'frac()'.  hth.

regards, jr.

[aysays] Problem with macros and translate function :/ [963 days 11 hours ago]

Wed, 23 Aug 2023 12:00:00 GMT

Hello I'm new to Pov-Ray and am trying to write a broccoli fractal code however
I'm having problems with the translate function. If I understood it correctly,
translate only accepts numerical values. I tried writing a macro but that didn't
work either. How am I supposed to write a recursive function that utilizes
translate? :/ Here is my code:

#include "colors.inc"

global_settings {
    ambient_light rgb <1, 1, 1>
    assumed_gamma 1.0
}

camera {
    location <0, 0, -25>
    look_at <0, 0, 0>
}

light_source {
    <-100, -100, -100>
    color rgb <1, 1, 1>
}

#declare phi = (1 + sqrt(5))/2;
#declare ang = 360 * (1 - 1/phi);




#macro trans()
    translate< sqrt(i)* cos(i * ang),
           sqrt(i) * sin(i * ang),
           10-sqrt(pow(sqrt(i)* cos(i * ang),2) + pow(sqrt(i) * sin(i *
ang),2))>
#end

#macro frac(n)
    #if(n > 0)
        cone {
            <0, 10, 0>, 10
            <0, 0, 0>, 0
            texture {
                pigment { Green }
                finish { ambient 0.2 }
            }


        #declare i = 1;
        #while (i <= 100)
            //#declare theta = i * ang;
            //#declare r = sqrt(i);
            //#declare a = r * cos(theta);
            //#declare b = r * sin(theta);


            trans()



            scale 0.15
       }
            frac(n - 1)

            #declare i = i + 1;
        #end
    #end
#end

frac(3);



Thanks in advance :)

[Cousin Ricky] Re: Confusing error when trying to use brick pat... [981 days 23 hours and 3 minutes ago]

Fri, 4 Aug 2023 23:56:57 GMT

On 2023-08-04 18:44 (-4), Bald Eagle wrote:
> "kirbyanddee" <nomail@nomail> wrote:
> 
>>  pigment {
>>    brick pigment{Jade}, pigment{Black_Marble}
>>  }
> 
> Also, if those things are textures, you may have to use texture {brick ....} in
> order for it to work properly.

Jade is a pigment, defined in textures.inc.  Black_Marble is not defined
anywhere, but there are 3 other marble pigments defined in textures.inc.
 No 'texture' keyword is needed.

[Bald Eagle] Re: Confusing error when trying to use brick pat... [982 days and 15 minutes ago]

Fri, 4 Aug 2023 22:45:00 GMT

"kirbyanddee" <nomail@nomail> wrote:

>  pigment {
>    brick pigment{Jade}, pigment{Black_Marble}
>  }

Also, if those things are textures, you may have to use texture {brick ....} in
order for it to work properly.

- BW

[Cousin Ricky] Re: Confusing error when trying to use brick pat... [982 days and 59 minutes ago]

Fri, 4 Aug 2023 22:01:09 GMT

On 2023-08-04 16:39 (-4), kirbyanddee wrote:
> Hi, I'm very new to POV-Ray so i've been looking at the reference docs to find
> out what I can do. this code is present in the docs:
> 
> pigment {
>   brick pigment{Jade}, pigment{Black_Marble}
>   }
> 
> but i can't seem to get it working in a file. here's an example:
> 
> [snip]
> 
> the render fails and it leaves this error:
> 
> File 'firstimg.pov' line 13: Possible Parse Error: Unmatched {
> File 'firstimg.pov' line 14: Parse Error: No matching }, pigment identifier
>  found instead
> Fatal error in parser: Cannot parse input.

This appears to be an error in the documentation, as there is no such
pigment Black_Marble.  Try Red_Marble, White_Marble, or Blood_Marble.

[kirbyanddee] Confusing error when trying to use brick pattern [982 days 2 hours and 20 minutes ago]

Fri, 4 Aug 2023 20:40:00 GMT

Hi, I'm very new to POV-Ray so i've been looking at the reference docs to find
out what I can do. this code is present in the docs:

pigment {
  brick pigment{Jade}, pigment{Black_Marble}
  }

but i can't seem to get it working in a file. here's an example:

#include "colors.inc"
#include "textures.inc"
#include "shapes.inc"

background { color Cyan }
camera {
  location <0, 2, -3>
  look_at  <0, 1,  2>
}
sphere {
  <0, 1, 2>, 2

 pigment {
   brick pigment{Jade}, pigment{Black_Marble}
 }

}

light_source { <5, 30, -30> color White }



the render fails and it leaves this error:

File 'firstimg.pov' line 13: Possible Parse Error: Unmatched {
File 'firstimg.pov' line 14: Parse Error: No matching }, pigment identifier
 found instead
Fatal error in parser: Cannot parse input.


I can't get the brick pattern to work with two pigments, so i'm kind of confused
here, especially since this code was copy-pasted from the docs. Could I get some
help with this? Thank you (:

[Bald Eagle] Re: functions and macros [1022 days 11 hours and 30 minutes ago]

Sun, 25 Jun 2023 11:30:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> indeed, converting the macro into functions is the best solution ... but
> functions also have limitations.

They do, but you can still do a surprising amount with them.

I've converted your macro to a set of two daisy-chained functions to show you
how that would work.

However, you only need a single stock function, instead of an
algorithmic/programmatic approach.  mod (N, 1) returns the fractional part of
any value, which is what you're looking for.



#macro limit_zero2one(_value)
 #local limited = _value - floor(_value);
 #if (limited < 0)
  #local limited = limited + 1.0;
 #end

 limited

#end

#declare precalc = function (_value) {_value - floor(_value)}

#declare Limit_zero2one = function (_value) {select (precalc (_value), precalc
(_value) + 1, precalc (_value), precalc (_value) )}


#local Seed = seed (123);
#for (N, 0, 10)
 #local N2 = rand (Seed) * N + rand (Seed);

 #debug concat( " Initial value = ", str(N2, 0, 3),  " Function result = ",
str(Limit_zero2one (N2), 0, 3), "\n")

#end

#debug "\n"


#for (N, 0, 10)
 #local N2 = rand (Seed) * N + rand (Seed);

 #debug concat( " Initial value = ", str(N2, 0, 3),  " Function result = ",
str(mod (N2, 1), 0, 3), "\n")

#end

#debug "\n"


#error "No objects in scene."


- BW

[kurtz le pirate] Re: functions and macros [1022 days 14 hours and 12 minutes ago]

Sun, 25 Jun 2023 08:48:18 GMT

On 18/06/2023 16:58, kurtz le pirate wrote:

> Hence the question : Can a function call a macro ?
> 

ok, it's clear.

indeed, converting the macro into functions is the best solution ... but
functions also have limitations.

thanks @Leroy for the translation. but given what i have to write, it's
going to be complicated and, I think, not always possible.

I'll have to find the "right balance".

-- 
Kurtz le pirate
Compagnie de la Banquise

[Cousin Ricky] Re: functions and macros [1029 days and 16 minutes ago]

Sun, 18 Jun 2023 22:44:01 GMT

On 2023-06-18 10:58 (-4), kurtz le pirate wrote:
> 
> 114:#declare dayfrac_to_local_hr = function (df, tz) {
> 115:  24.0*limit_zero2one(df + (tz/24.0))
> 116:  }
> 
> and i get this error :
> line 115
> Parse Error: Cannot pass uninitialized identifier as non-optional macro
> parameter.
> 
> [snip]
> 
> Hence the question : Can a function call a macro ?

As Leroy said, the short answer is no.

Technically, it is possible to include a macro in a function definition,
but the macro is evaluated only in the process of defining the function.
 Thereafter, whatever the macro was expanded to *at that particular
time* becomes a permanent part of the function definition.  The macro is
never called from the function itself.

In your case, this means that the parser tries to evaluate df and tz
during the *definition* of the function, at which point df and tz are
undefined because the function is not in the process of being called.
(In Computerese, they are mere formal parameters, with no actual
arguments to back them up.)

So, a macro can be included in the function definition, but it cannot do
what you are trying to do.

[Bald Eagle] Re: functions and macros [1029 days 4 hours and 45 minutes ago]

Sun, 18 Jun 2023 18:15:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello,
>
>
> Can a function call a macro ?

Hi Kurtz,

You cannot use macros or arrays in functions.
Heck, there are even certain "functions" that you can't use in functions
(vlength, etc).

Under certain circumstances, you can write macros that assemble a function, and
while doing that, the macro can plug in the results of macro calls.

Or you can declare a set of values that are the result of macro call
evaluations, and use those values in your function.

The key concept is that any non-argument values in a function have to be
completely static.  So if you have a function of t, and want to do t*2, then 2
will be a static value, and can never change once the function is declared.

If you can express the types of variable results you want as separate functions,
then you can daisy-chain your functions together, such that you can write
formulas such as t*f(x).

Things can get pretty challenging trying to get the syntax right, and the
functions can get long, since we don't have vector functions, but a lot of
things are doable if you just keep trying to make it work and ask for help.

- BW

[Leroy] Re: functions and macros [1029 days 5 hours and 25 minutes ago]

Sun, 18 Jun 2023 17:35:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hence the question : Can a function call a macro ?
>
Sorry, I was working on a function for you and while going back to the message I
got happy fingers and hit Preview then Post before adding the function.
here it is:
#declare Fnc=function(a){a-floor(a)+(a-floor(a)<0)}

Have Fun!

[Leroy] Re: functions and macros [1029 days 5 hours and 50 minutes ago]

Sun, 18 Jun 2023 17:10:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello,
>
>
> Can a function call a macro ?
>
> I have defined this function :
>
> 114:#declare dayfrac_to_local_hr = function (df, tz) {
> 115:  24.0*limit_zero2one(df + (tz/24.0))
> 116:  }
>
> and i get this error :
> line 115
> Parse Error: Cannot pass uninitialized identifier as non-optional macro
> parameter.
>
>
>
> Of course the macro is defined before
>
> 73:#macro limit_zero2one(_value)
> 74:  #local limited = _value - floor(_value);
> 75:  #if (limited < 0)
> 76:    #local limited = limited + 1.0;
> 77:  #end
> 78:  limited
> 79: #end
>
>
>
> Hence the question : Can a function call a macro ?
>
>
>
> --
> Kurtz le pirate
> Compagnie de la Banquise

short answer: NO
Long answer: If you can turn that macro into a function then you can call that
function.

[kurtz le pirate] functions and macros [1029 days 8 hours and 2 minutes ago]

Sun, 18 Jun 2023 14:58:34 GMT

Hello,


Can a function call a macro ?

I have defined this function :

114:#declare dayfrac_to_local_hr = function (df, tz) {
115:  24.0*limit_zero2one(df + (tz/24.0))
116:  }

and i get this error :
line 115
Parse Error: Cannot pass uninitialized identifier as non-optional macro
parameter.



Of course the macro is defined before

73:#macro limit_zero2one(_value)
74:  #local limited = _value - floor(_value);
75:  #if (limited < 0)
76:    #local limited = limited + 1.0;
77:  #end
78:  limited
79: #end



Hence the question : Can a function call a macro ?



-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Re: Image function [1046 days 6 hours and 16 minutes ago]

Thu, 1 Jun 2023 16:44:28 GMT

Thanks guys. Two leads to explore
and in 2006... i don't think i already knew "functions" !




-- 
Kurtz le pirate
Compagnie de la Banquise

[Tor Olav Kristensen] Re: Image function [1047 days 22 hours and 40 minutes ago]

Wed, 31 May 2023 00:20:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > ...
> > The code here may be relevant for what you are trying to achieve:
>
> neat, thanks for posting this link.

No problem jr. I am glad if I can help with solving someone's problem.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: Image function [1048 days 5 hours and 20 minutes ago]

Tue, 30 May 2023 17:40:00 GMT

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> ...
> The code here may be relevant for what you are trying to achieve:

neat, thanks for posting this link.


regards, jr.

[Tor Olav Kristensen] Re: Image function [1048 days 22 hours and 35 minutes ago]

Tue, 30 May 2023 00:25:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> On 28/05/2023 22:06, Bald Eagle wrote:
> > Once again, I'm asking WHY?
>
> apologies...
>
> I didn't describe what I wanted to do very well.
> I'll try to be clearer.
>
> a) I recover the color of a point <x,0,z> of a source image.
> b) I transform this point into a new point <x1,0,z1>.
> c) I give this new point the color taken in a)
>
> In fact, I already have a code that does this, but only with the checker
> pattern. Not very sexy !
>
> For the moment the plan is drawn like this :
> plane {
>   y,0
>   pigment { function { fnPigment(x,z) } }
>   }
>
> hence my request for a function()
>
> Instead of the checker, the original distorted image.
>...

Hi Kurtz

The code here may be relevant for what you are trying to achieve:

From: Tor Olav Kristensen
Subject: Source code for "Using functions to distort images"
Date: 2006-05-12 18:48:59
http://news.povray.org/povray.text.scene-files/thread/%3C4470ee5b%40news.povray.org%3E

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: Image function [1049 days 5 hours and 5 minutes ago]

Mon, 29 May 2023 17:55:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:
> On 28/05/2023 22:06, Bald Eagle wrote:
> > Once again, I'm asking WHY?
>
> apologies...
>
> I didn't describe what I wanted to do very well.
> I'll try to be clearer.
>
> a) I recover the color of a point <x,0,z> of a source image.
> b) I transform this point into a new point <x1,0,z1>.
> c) I give this new point the color taken in a)
>
> In fact, I already have a code that does this, but only with the checker
> pattern. Not very sexy !


Ah, excellent.
This makes much more sense now.

> The "geometric" transformation is the result of applying function.
> Two examples with f(z) = z^2 and f(z) = sin(z)/(z+1).
>
> Brighter ?

Much better.
Have coded a geometric inversion function?   I would be highly interested in
that for use with Clifford tori and such.

Anyway, here's what I think you need to do if you want to modify an image_map
using a function, and still have the full color.

Then all you have to do is modify the function.

------------------------------------------------------------------------



#version 3.8;
global_settings {assumed_gamma 1.0}
default {finish {diffuse 1}}

// +am3 +a0.01 +ac0.90 +r3


camera {
 location <0, 5, -0.01>
 right     x*image_width/image_height
 up y
 look_at <0, 0, 0>
}

light_source {<0, 100, 0> rgb 1.0}

sky_sphere {pigment {rgb 1}}


#declare ImageMap = function {pigment {image_map {png "plasma2.png"} rotate
x*90} }


#declare FullColorTexture =
  texture {
   pigment {
          average
          pigment_map {
              [
                  function { ImageMap (x, y, z).red }
                  color_map {
                      [ 0 red 0 ]
                      [ 1 red 5 ]
                  }
              ]
              [
                  function { ImageMap (x, y, z).green }
                  color_map {
                      [ 0 green 0 ]
                      [ 1 green 5 ]
                  }
              ]
              [
                  function { ImageMap (x, y, z).blue }
                  color_map {
                      [ 0 blue 0 ]
                      [ 1 blue 5 ]
                  }
              ]
                [
                  function { ImageMap (x, y, z).filter }
                  color_map {
                      [ 0 blue 0 ]
                      [ 1 blue 5 ]
                  }
              ]
                [
                  function { ImageMap (x, y, z).transmit }
                  color_map {
                      [ 0 blue 0 ]
                      [ 1 blue 5 ]
                  }
              ]
    } // end pigment map
   } // end pigment
  } // end layered texture

plane {
 y, 0
 texture {FullColorTexture }
}


Hope that works the way you want.

- BW

[kurtz le pirate] Re: Image function [1049 days 6 hours and 49 minutes ago]

Mon, 29 May 2023 16:10:57 GMT

On 28/05/2023 22:06, Bald Eagle wrote:
> Once again, I'm asking WHY?

apologies...

I didn't describe what I wanted to do very well.
I'll try to be clearer.

a) I recover the color of a point <x,0,z> of a source image.
b) I transform this point into a new point <x1,0,z1>.
c) I give this new point the color taken in a)

In fact, I already have a code that does this, but only with the checker
pattern. Not very sexy !

For the moment the plan is drawn like this :
plane {
  y,0
  pigment { function { fnPigment(x,z) } }
  }

hence my request for a function()

Instead of the checker, the original distorted image.



The "geometric" transformation is the result of applying function.
Two examples with f(z) = z^2 and f(z) = sin(z)/(z+1).

Brighter ?




ps : I'm going to watch "Eval_pigmentTest_carpet.pov". Thanks Thomas

-- 
Kurtz le pirate
Compagnie de la Banquise

[Thomas de Groot] Re: Image function [1049 days 16 hours and 30 minutes ago]

Mon, 29 May 2023 06:30:33 GMT

Op 28/05/2023 om 17:22 schreef Thomas de Groot:
> Op 28-5-2023 om 16:49 schreef kurtz le pirate:
>> Hello,
>>
>>
>> I'm racking my brain over this problem :
>> I'd like to have a function that can give me the color of a pixel in an
>> image (the equivalent of "eval_pigment") to fill a plane.
>>
> Why not use eval_pigment? See:
> 
>
https://news.povray.org/povray.binaries.images/thread/%3Cweb.52ede41cd6fcc84f7a3e03fe0%40news.povray.org%3E/?mtop=395729
> 
> I must have the macro somewhere... I shall send it tomorrow from my 
> other machine.
> 

I don't know if this is what you want to do, but provide an image map 
and play with this test scene...


-- 
Thomas

[Bald Eagle] Re: Image function [1050 days 2 hours and 50 minutes ago]

Sun, 28 May 2023 20:10:00 GMT

Once again, I'm asking WHY?

Kenneth tried to do this circular process a while back - but if all you're doing
is tiling a plane with an image, then just use an image_map pigment and don't
specify "once".

If you do, however, have some future use for the function version, then you need
to invoke it like this:

plane {
  y, 0
  pigment { function { imageFunction (x,y,z) } }
  }

eval_pigment is just a macro wrapper for the same kinda thing, which means that
will be an extra layer, and another layer on top of that to un-macro-ify it (if
even possible) for use in the way you want.

- BE

kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello,
>
>
> I'm racking my brain over this problem :
> I'd like to have a function that can give me the color of a pixel in an
> image (the equivalent of "eval_pigment") to fill a plane.
>
>
> I've tried a lot of things but none of them work.
>
> What I would like :
>
> plane {
>  y, 0
>  pigment { color imageFunction(x,y,z) }
>  }
>
> With the function like that :
> #declare imageFunction = function {
>  pigment {
>   image_map { jpeg imageName }
>   rotate -x*90
>   translate <-0.5, 0, -0.5>
>   scale <imageWidth, 1, imageHeight>
>   }
>  }
>
> Of corse, this does not work and i get parse errors but the idea is here.
>
> So can you tell me if this "kind of thing" is possible or not before I
> go *crazy* ?
>
>
>
> (@﹏@)
>
>
> --
> Kurtz le pirate
> Compagnie de la Banquise

[Thomas de Groot] Re: Image function [1050 days 7 hours and 37 minutes ago]

Sun, 28 May 2023 15:22:48 GMT

Op 28-5-2023 om 16:49 schreef kurtz le pirate:
> Hello,
> 
> 
> I'm racking my brain over this problem :
> I'd like to have a function that can give me the color of a pixel in an
> image (the equivalent of "eval_pigment") to fill a plane.
> 
Why not use eval_pigment? See:

https://news.povray.org/povray.binaries.images/thread/%3Cweb.52ede41cd6fcc84f7a3e03fe0%40news.povray.org%3E/?mtop=395729

I must have the macro somewhere... I shall send it tomorrow from my 
other machine.

-- 
Thomas

[kurtz le pirate] Image function [1050 days 8 hours and 10 minutes ago]

Sun, 28 May 2023 14:49:57 GMT

Hello,


I'm racking my brain over this problem :
I'd like to have a function that can give me the color of a pixel in an
image (the equivalent of "eval_pigment") to fill a plane.


I've tried a lot of things but none of them work.

What I would like :

plane {
 y, 0
 pigment { color imageFunction(x,y,z) }
 }

With the function like that :
#declare imageFunction = function {
 pigment {
  image_map { jpeg imageName }
  rotate -x*90
  translate <-0.5, 0, -0.5>
  scale <imageWidth, 1, imageHeight>
  }
 }

Of corse, this does not work and i get parse errors but the idea is here.

So can you tell me if this "kind of thing" is possible or not before I
go *crazy* ?



(@ï¹@)


-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: Parametric Object [1102 days 5 hours and 5 minutes ago]

Thu, 6 Apr 2023 17:55:00 GMT

kurtz le pirate <kur### [at] gmailcom> wrote:

> Find the solution.
>
> #declare fnK = function(u,v) { ... }
> parametric {
>  function { fnK(u,v)*(...) }
>  function { fnK(u,v)*(...) }
>  function { fnK(u,v)*(...) }
>
> Must also specify the parameters for fnK().

Yes.   This is what I often refer to as "daisy-chaining".

https://www.props4shows.co.uk/Portals/1/product/images/prd35729f1d-79d7-4e7b-9f10-8aa76ed62377.jpg

One function depends on the result of another function, which may depend on yet
another function....

[kurtz le pirate] Re: Parametric Object [1102 days 8 hours and 9 minutes ago]

Thu, 6 Apr 2023 14:51:35 GMT

On 06/04/2023 16:15, kurtz le pirate wrote:
> 
> I have to add the complete calculation of the parameter 'K' in the three
> functions ?
> 

Find the solution.

#declare fnK = function(u,v) { ... }
parametric {
 function { fnK(u,v)*(...) }
 function { fnK(u,v)*(...) }
 function { fnK(u,v)*(...) }

Must also specify the parameters for fnK().


-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Parametric Object [1102 days 8 hours and 45 minutes ago]

Thu, 6 Apr 2023 14:15:15 GMT

Hello,


Documentation POVRay 2.4.5 :

parametric {
 function { FUNCTION_ITEMS },
 function { FUNCTION_ITEMS },
 function { FUNCTION_ITEMS }
 <u1,v1>, <u2,v2>
 ...
 }

I run into the following problem : how to introduce in the three
functions f(x), g(y) and h(z), a parameter that also depends
on u and v ?


For exemple :
parametric {
 function { sin(u)*cos(v)*K }
 function { sin(u)*sin(v)*K }
 function { cos(u)/K }
 ...
 }
with K = k*sin(2*u)*sin(nv)
'k' and 'n' are constants.


I have to add the complete calculation of the parameter 'K' in the three
functions ?





-- 
Kurtz le pirate
Compagnie de la Banquise

[Leroy] Re: Generating animation [1142 days 21 hours and 15 minutes ago]

Sat, 25 Feb 2023 01:45:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> >
> > So you're using the quickres.ini as "the" .ini file to run the animation?
> > That's pretty slick.
>
> Gee, I thought *everyone* did it that way, by default! I've been using that
> set-up ever since I made my first animation. Yes, I use it as a container for
> almost every kind of command and switch that I need-- like Work_Threads,
> Output_File_Type, Verbose, Output_Alpha, etc etc. Then I just comment them
> on/off when needed (using a semicolon of course, not slash marks.) It seems to
> be a nice quick way to invoke these things for me, even faster than command-line
> settings.
> >
> > Is that in the docs somewhere, or did you find that in a post, or come up with
> > it yourself?
>
> I wish I could remember how I arrived at the idea; maybe it just seemed natural
> at the time, instead of writing specific .ini files for specific scenes. Back
> then, I probably didn't know much about .ini files themselves or how to use
> them... so maybe it was a lucky discovery, by pure guesswork.
>
> Yet, I've always wondered if my use of quickres.ini is an efficient way to
> invoke these commands, compared to others' strategies.

I usually make an ini file for each project. I have several kind of
things(height_fields,prisms,color_maps,...) stored in in there own folders and
set Library_Path to what ever I need. I have window version and set the option
commands to what is best to what I need to do.
Have Fun!

[Kenneth] Re: [1148 days 4 hours and 20 minutes ago]

Sun, 19 Feb 2023 18:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I just noticed something peculiar when looking for this previous post in
> 'message digest'-- it shows up as <no subject> there

Oh, never mind. The OP's original subject header was <no subject>.

[Kenneth] Re: [1148 days 4 hours and 25 minutes ago]

Sun, 19 Feb 2023 18:35:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > It's also easier to test your code if you attach the .pov file to the post
> > instead of pasting the code.
> >
>
> Hmm. I have the opposite opinion-- IF the code example is not too lengthy, of
> course. I'm using the web portal though...

I just noticed something peculiar when looking for this previous post in
'message digest'-- it shows up as <no subject> there (using the web portal)
instead of with the name of the OP's main-post as the subject.  I haven't seen
that happen before. I'm pretty sure that I replied and posted in my usual
manner.

I wonder if Thunderbird users see the same  <no subject> ?

[Kenneth] Re: [1148 days 5 hours and 25 minutes ago]

Sun, 19 Feb 2023 17:35:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> It's also easier to test your code if you attach the .pov file to the post
> instead of pasting the code.
>

Hmm. I have the opposite opinion-- IF the code example is not too lengthy, of
course. I'm using the web portal though.

Posting the code in the body of the message works for me, because I can see it
immediately, in relation to the question posed. THEN, if the answer is a bit
mysterious, I'll just cut-and-paste the example into a new scene file to run (or
even some handy old scene file temporarily, if I'm in a hurry.)

Naturally, this assumes that I make no cut-and-paste errors during the process--
which has been known to happen. ;-)

[Bald Eagle] Re: [1149 days and 45 minutes ago]

Sat, 18 Feb 2023 22:15:00 GMT

"yesbird" <nomail@nomail> wrote:
> Thanks a lot, it works, but I still don't know how :)

* it's a "netscape" email address

As a first approximation, consider what you'd need to get a zero result for
every point along the parabola y = f(x) = pow(x,2).

It's y-f(x), which is y-y.

but you're doing that in 3D, which means you need the distance from the origin,
not the distance along any single axis.   Therefore the distance formula, since
for whatever reason, we can't use vlength() in functions.

* on the ".net"

> > If you email me, I can can send you a PDF copy of Mike Williams' Isosurface
> > Tutorial.
>
> I would like to, because  really need to know more about IS, but can't find
> your email. As to posts and attachments, I will take it into account, and
> install old-good Thunderbird now.

* and you can reach me @ there as "creativechemist"

Or hit reply to one of my posts and it should quote my email at the top.  ;)

- BW

[yesbird] Re: [1149 days 1 hour and 15 minutes ago]

Sat, 18 Feb 2023 21:45:00 GMT

Thanks a lot, it works, but I still don't know how :)

> If you email me, I can can send you a PDF copy of Mike Williams' Isosurface
> Tutorial.

I would like to, becauseÂ  really need to know more about IS, but can't find
your email. As to posts and attachments, I will take it into account, and
install old-good Thunderbird now.
--
YB
Â

[Bald Eagle] Re: [1149 days 1 hour and 40 minutes ago]

Sat, 18 Feb 2023 21:20:00 GMT

It's also easier to test your code if you attach the .pov file to the post
instead of pasting the code.

If you want to post both the image and the .pov file, you can do that with a
newsreader like Thunderbird.

[Bald Eagle] Re: [1149 days 1 hour and 45 minutes ago]

Sat, 18 Feb 2023 21:15:00 GMT

"yesbird" <nomail@nomail> wrote:
> Hi,
>
> Can anybody explain me, please, how 'isosurface' works ?
> I am trying to render:
>
> V = cos(x) + cos(y) + cos(z); // Attached

So, IIRC that's like a gyroid or something...

If you email me, I can can send you a PDF copy of Mike Williams' Isosurface
Tutorial.

But the key idea is that it's an ISOsurface.

Very often what you need to do is subtract your function result from a space
coordinate so that when the function's surface point is AT that space point, the
result is zero - or whatever you set your threshold to.

After a few quick experiments, I established that you like want to "check" the
distance of your curve from a sphere, so I used that.  You can probably use the
in-built f_sphere as well.

So try:

camp (7,0,-7, 0,0.3,0, 55)

//-------------  Objects --------------------------------------------

//
// FUnction
//
// #declare f = function { f_sphere(x,y,z,0.8) - pow(f_noise3d(x,y,z),2) } // Ok
#declare f = function { cos(x) + cos(y) + cos(z) } // Not displayed (?)

//
// Surface
//
#declare R = 1;
isosurface {
  function { sqrt (x*x+y*y+z*z)/8 - f(x, y, z)}

   threshold 0
 accuracy 0.0001
 max_gradient 1.6
 open
 contained_by {box {-4, +4}}

  pigment { rgbft <0,0.5,0,0.6,0>
            scale 2
            translate 1}

}

[yesbird] [1149 days 2 hours and 35 minutes ago]

Sat, 18 Feb 2023 20:25:00 GMT

Hi,

Can anybody explain me, please, how 'isosurface' works ?
I am trying to render:

V = cos(x) + cos(y) + cos(z); // Attached

but see nothing, except the axis. At the same time function from tutorial works
fine (see code below).

Thanks in advance,
--
YB

#version 3.8;
global_settings { assumed_gamma 1 }

#include "functions.inc"

//
// Axis textures
//
#declare fin_axis = finish { phong 1 reflection {0.10 metallic 0.4 }}
#declare tex_axis_common = texture {
           pigment { rgb <0.70, 0.70, 0.70> }
           finish  { fin_axis }}
#declare tex_axis_x = texture { pigment { rgb x} finish { fin_axis }}
#declare tex_axis_y = texture { pigment { rgb y} finish { fin_axis }}
#declare tex_axis_z = texture { pigment { rgb z} finish { fin_axis }}


//
// Axis
//
#macro axis_base( len, rad, tex_odd, tex_even )
union{
    cylinder { <0, -len, 0>,<0, len, 0>, rad
               texture{ checker texture{ tex_odd } texture{ tex_even }
               translate <0.1, 0, 0.1> }}

    cone{<0, len, 0>, rad * 2, <0, len + rad * 7, 0>, 0 texture{tex_even} }}
#end

#macro axis_xyz( len_x, len_y, len_z, rad, tex_common, tex_x, tex_y, tex_z)
union{
    #if (len_x != 0) object { axis_base(len_x, rad, tex_common, tex_x) rotate<
0, 0,-90>} #end
    #if (len_y != 0) object { axis_base(len_y, rad, tex_common, tex_y) rotate<
0, 0,  0>} #end
    #if (len_z != 0) object { axis_base(len_z, rad, tex_common, tex_z) rotate<
90, 0,  0>} #end }
#end

#macro axis(len_x, len_y, len_z, rad)
    axis_xyz( len_x, len_y, len_z, rad, tex_axis_common, tex_axis_x, tex_axis_y,
tex_axis_z)
#end


//
// Perspective camera
//
#macro camp (_x, _y, _z, _lx, _ly, _lz, _ang)
camera
  { perspective
    location < _x,  _y,  _z>
    look_at  <_lx, _ly, _lz>
    angle _ang
  }
#end

//
// Lights
//
#declare luminosity = 1.7;
light_source {<0,  10, 0>, rgb <1,1,1> * luminosity }
light_source {<0, -10, 0>, rgb <1,1,1> * luminosity }

light_source {< 10, 0, 0>, rgb <1,1,1> * luminosity }
light_source {<-10, 0, 0>, rgb <1,1,1> * luminosity }

light_source {<0, 0,  10>, rgb <1,1,1> * luminosity }
light_source {<0, 0, -10>, rgb <1,1,1> * luminosity }


axis (3,3,3,0.02)
camp (5,5,5, 0,0.3,0, 55)


//-------------  Objects --------------------------------------------

//
// FUnction
//
// #declare f = function { f_sphere(x,y,z,0.8) - pow(f_noise3d(x,y,z),2) } // Ok
#declare f = function { cos(x) + cos(y) + cos(z) } // Not displayed (?)

//
// Surface
//
isosurface {
  function { f(x,y,z) }

  pigment { rgbft <0,0.5,0,0.6,0>
            scale 2
            translate 1}

  scale 1.5 }
//-------------------------------------------------------------------

[seNex] Re: object parameters [1150 days 9 hours and 30 minutes ago]

Fri, 17 Feb 2023 13:30:00 GMT

thanks alot!! The latest answers solved my problem completely! :D

[Bald Eagle] Re: object parameters [1152 days 3 hours and 20 minutes ago]

Wed, 15 Feb 2023 19:40:00 GMT

"seNex" <nomail@nomail> wrote:

> thanks for the quick reply. The underlying problem is, I wanted to track the
> center of the sphere after applying transformations to it. It seems to me from
> the documentation, that there is no way to apply transformations to the vector,
> but only to objects.

Well, that's not completely true.
I have asked this question before, and here's what you can do:

#include "transforms.inc"
// Translate a "point"
#declare Translate = transform { translate { <x, y, z> } }
#declare NewPoint = vtransform (OldPoint, Translate);

And you can do that with any transformation.

Now, that's not very convenient when you want to just have the information
"attached" to the sphere, but I think I've found a way to do that.   POV-Ray
does not complain when you create a box {} with the two diagonal corners being
the same vector.

So, you can probably just write a little macro that applies whatever
transformations to your sphere, but also applies the transformations to the
zero-dimensional "box".  But you do it in a way where you don't just transform
the box, you redefine the old box as the box with the transform applied.

like:  #declare Box = vtransform (Box, Translate);

Then you can use min_extent and max_extent to get the coordinates of the point.
It's convoluted, but it gets the job done.

- BE

snippets:

#declare Box = box {1, 1}
#declare Min = min_extent (Box);
#declare Max = max_extent (Box);

// {Be sure to include debug.inc file!}

#debug concat( "Min = ", vstr(3, Min, ", ", 3, 0), " \n")
#debug concat( "Max = ", vstr(3, Max, ", ", 3, 0), " \n")

[William F Pokorny] Re: object parameters [1152 days 7 hours and 7 minutes ago]

Wed, 15 Feb 2023 15:53:05 GMT

On 2/15/23 07:20, William F Pokorny wrote:
> #declare Vec00_Xfrmed =
> <FnXfrm00(Vec00.x,Vec00.y,Vec00.z).x,
> FnXfrm00(Vec00.x,Vec00.y,Vec00.z).y,
> FnXfrm00(Vec00.x,Vec00.y,Vec00.z).z>;

The light went on in my head a minute ago that I'd coded the part above 
without thinking. It can be just:

#declare Vec00_Xfrmed = FnXfrm00(Vec00.x,Vec00.y,Vec00.z);

---

That said, Tor Olav's suggestions are the cleaner method from the users 
perspective. Internally those macros use the function based code too.

The best approach for performance depends on what you are doing. Using a 
single transform against a lot of vectors will favor raw coding approach 
where the transform function can be parsed, compiled and defined once. 
If many transforms against few vectors, the macro's are the way to go.

Bill P.

[Tor Olav Kristensen] Re: object parameters [1152 days 10 hours ago]

Wed, 15 Feb 2023 13:00:00 GMT

"seNex" <nomail@nomail> wrote:
>...
> The underlying problem is, I wanted to track the
> center of the sphere after applying transformations to it. It seems to me from
> the documentation, that there is no way to apply transformations to the vector,
> but only to objects.

You can use vtransform() which is documented here:

https://www.povray.org/documentation/view/3.7.0/488/

- or VectorTransform() which can be found here:

https://github.com/t-o-k/Useful-POV-Ray-macros

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[William F Pokorny] Re: object parameters [1152 days 10 hours and 40 minutes ago]

Wed, 15 Feb 2023 12:20:40 GMT

On 2/15/23 05:38, seNex wrote:
> thanks for the quick reply. The underlying problem is, I wanted to track the
> center of the sphere after applying transformations to it. It seems to me from
> the documentation, that there is no way to apply transformations to the vector,
> but only to objects.

You can do something like:

#version 3.8;
global_settings { assumed_gamma 1 }

#declare Vec00 = <0,0,0>;
#declare Xfrm00 = transform {
     translate <0.5,0.0,0.0>
     rotate z*30.0
}
#declare FnXfrm00 = function { transform {Xfrm00} }

// You might need to use 'inverse', if result is to be used in a
// isosurface function , for example.
// #declare FnXfrm00 = function { transform {Xfrm00 inverse} }

#debug concat("Vec00.x --> ",str(Vec00.x,0,-1)," transformed to --> ",
     str(FnXfrm00(Vec00.x,Vec00.y,Vec00.z).x,0,-1),".\n")
#debug concat("Vec00.y --> ",str(Vec00.y,0,-1)," transformed to --> ",
     str(FnXfrm00(Vec00.x,Vec00.y,Vec00.z).y,0,-1),".\n")
#debug concat("Vec00.z --> ",str(Vec00.z,0,-1)," transformed to --> ",
     str(FnXfrm00(Vec00.x,Vec00.y,Vec00.z).z,0,-1),".\n")

#declare Vec00_Xfrmed =
<FnXfrm00(Vec00.x,Vec00.y,Vec00.z).x,
FnXfrm00(Vec00.x,Vec00.y,Vec00.z).y,
FnXfrm00(Vec00.x,Vec00.y,Vec00.z).z>;

#debug concat("\nXfrmed vector <",
     vstr(3,Vec00_Xfrmed, ",", 0, 3), ">\n\n")

#error "\nStopping by #error after parse"

---

If you want to capture a more complete set of 'coordinate modifiers', 
for example, turbulence or warps along with transforms, you are stuck 
in any official POV-Ray release as far as I know.

The povr fork introduced a vector function called pattern_modifiers 
which captures a complete sequence of positional modifiers as a function 
which then can be used as FnXfrm00 is up top.

#declare FnXfrm00 = function {
     pattern_modifiers { Pigment00 }
}

However, at best, such functionality wouldn't show up until a v4.0 
official release.

Bill P.

[seNex] Re: object parameters [1152 days 12 hours and 20 minutes ago]

Wed, 15 Feb 2023 10:40:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2023-02-13 à 11:26, seNex a écrit :
> > is there a way to get the parameter of an object after its declaration? For
> > example if I create a sphere named mysphere with center <x,y,z> and radius 1,
> > can I use a
> > function to write these to new variables? Like:
> >
> >
> > #declare mysphere=sphere{<x,y,z>,1};
> >
> > #declare sphere_center=centerfunction(mysphere);
> > #declare sphere_radius=radiusfunktion(mysphere);
> >
> >
>
> There are no such function. Those values are never visible from the SDL
> perspective. The recommended thing to do is to declare the centre and
> radius then to use those declared value when you #declare your object :
>
> #declare Sphere_centre= Some_location;
> #declare Sphere_radius= Some_Radius;
> #declare Mysphere=sphere{Sphere_centre, Sphere_radius}

thanks for the quick reply. The underlying problem is, I wanted to track the
center of the sphere after applying transformations to it. It seems to me from
the documentation, that there is no way to apply transformations to the vector,
but only to objects.

[seNex] Re: object parameters [1152 days 12 hours and 25 minutes ago]

Wed, 15 Feb 2023 10:35:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2023-02-13 12:26(-4), seNex wrote:
> > is there a way to get the parameter of an object after its declaration? For
> > example if I create a sphere named mysphere with center <x,y,z> and radius 1,
> > can I use a
> > function to write these to new variables? Like:
> >
> >
> > #declare mysphere=sphere{<x,y,z>,1};
> >
> > #declare sphere_center=centerfunction(mysphere);
> > #declare sphere_radius=radiusfunktion(mysphere);
>
> There are no direct functions of this kind in POV-Ray, but you can
> estimate the parameters by taking the bounding extents of the object:
>
> #declare mysphere_center =
>   (max_extent (mysphere) + min_extent (mysphere)) / 2;
> #declare sphere_radius =
>   (max_extent (mysphere).x - min_extent (mysphere).x) / 2;
>
> Be aware that this is not perfectly reliable.  The functions
> max_extent() and min_extent() are only estimates, and tend to grow
> larger than the objects as transformations and CSG operations are
> applied to the object.  But for a simple primitive such as a sphere, it
> should work.

Thanks for the quick reply. I had tried this myself before but thought there
ought to be a more elegant solution.

[Alain Martel] Re: object parameters [1154 days 5 hours and 37 minutes ago]

Mon, 13 Feb 2023 17:23:39 GMT

Le 2023-02-13 Ã  11:26, seNex a Ã©critÂ :
> is there a way to get the parameter of an object after its declaration? For
> example if I create a sphere named mysphere with center <x,y,z> and radius 1,
> can I use a
> function to write these to new variables? Like:
> 
> 
> #declare mysphere=sphere{<x,y,z>,1};
> 
> #declare sphere_center=centerfunction(mysphere);
> #declare sphere_radius=radiusfunktion(mysphere);
> 
> 

There are no such function. Those values are never visible from the SDL 
perspective. The recommended thing to do is to declare the centre and 
radius then to use those declared value when you #declare your object :

#declare Sphere_centre= Some_location;
#declare Sphere_radius= Some_Radius;
#declare Mysphere=sphere{Sphere_centre, Sphere_radius}

[Cousin Ricky] Re: object parameters [1154 days 5 hours and 44 minutes ago]

Mon, 13 Feb 2023 17:16:40 GMT

On 2023-02-13 12:26(-4), seNex wrote:
> is there a way to get the parameter of an object after its declaration? For
> example if I create a sphere named mysphere with center <x,y,z> and radius 1,
> can I use a
> function to write these to new variables? Like:
> 
> 
> #declare mysphere=sphere{<x,y,z>,1};
> 
> #declare sphere_center=centerfunction(mysphere);
> #declare sphere_radius=radiusfunktion(mysphere);

There are no direct functions of this kind in POV-Ray, but you can
estimate the parameters by taking the bounding extents of the object:

#declare mysphere_center =
  (max_extent (mysphere) + min_extent (mysphere)) / 2;
#declare sphere_radius =
  (max_extent (mysphere).x - min_extent (mysphere).x) / 2;

Be aware that this is not perfectly reliable.  The functions
max_extent() and min_extent() are only estimates, and tend to grow
larger than the objects as transformations and CSG operations are
applied to the object.  But for a simple primitive such as a sphere, it
should work.

[seNex] object parameters [1154 days 6 hours and 30 minutes ago]

Mon, 13 Feb 2023 16:30:00 GMT

is there a way to get the parameter of an object after its declaration? For
example if I create a sphere named mysphere with center <x,y,z> and radius 1,
can I use a
function to write these to new variables? Like:


#declare mysphere=sphere{<x,y,z>,1};

#declare sphere_center=centerfunction(mysphere);
#declare sphere_radius=radiusfunktion(mysphere);

[Kenneth] Re: Generating animation [1156 days 23 hours and 20 minutes ago]

Fri, 10 Feb 2023 23:40:00 GMT

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

>
> So you're using the quickres.ini as "the" .ini file to run the animation?
> That's pretty slick.

Gee, I thought *everyone* did it that way, by default! I've been using that
set-up ever since I made my first animation. Yes, I use it as a container for
almost every kind of command and switch that I need-- like Work_Threads,
Output_File_Type, Verbose, Output_Alpha, etc etc. Then I just comment them
on/off when needed (using a semicolon of course, not slash marks.) It seems to
be a nice quick way to invoke these things for me, even faster than command-line
settings.
>
> Is that in the docs somewhere, or did you find that in a post, or come up with
> it yourself?

I wish I could remember how I arrived at the idea; maybe it just seemed natural
at the time, instead of writing specific .ini files for specific scenes. Back
then, I probably didn't know much about .ini files themselves or how to use
them... so maybe it was a lucky discovery, by pure guesswork.

Yet, I've always wondered if my use of quickres.ini is an efficient way to
invoke these commands, compared to others' strategies.

[Bald Eagle] Re: Generating animation [1157 days 3 hours and 55 minutes ago]

Fri, 10 Feb 2023 19:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:

> In Windows, there is an included file called 'quickres.ini.' It holds a lot of
> pre-written render resolutions for you. But it's also the place where I put all
> of my animation commands-- like Start_Frame, Final_Frame, etc. There, you would
> simply write
>            Final_Frame=100  (no spaces)
>
> This will automatically turn on the animation mechanism, ready and waiting.

No. Way.

So you're using the quickres.ini as "the" .ini file to run the animation?
That's pretty slick.

Is that in the docs somewhere, or did you find that in a post, or come up with
it yourself?   Because that's pretty darned handy.
If you have any other interesting things in your quickres, could you post a copy
here?

First the #if block in a function, now this.
Any other neat little tricks that you've got squirreled away somewhere?

Did you know that New Hampshire used to be named "Northern Virginia"?  :D

- BW

[Kenneth] Re: Generating animation [1157 days 9 hours ago]

Fri, 10 Feb 2023 14:00:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> And in your scene file, you would use the 'clock' keyword to create movement...

I forgot to mention that, by default, 'clock' always increments from 0.0 to 1.0,
no matter how many animation frames you render.  Its behavior can be changed, of
course-- but leave that for another day ;-)

[Kenneth] Re: Generating animation [1157 days 9 hours and 10 minutes ago]

Fri, 10 Feb 2023 13:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Once you write your .pov file, which should render without error all
> by itself,
> then you write an .ini file which is like a script that renders your .pov file
> over and over again with an increasing clock variable value.   Then you get a
> bunch of still renders that you convert into a video file with some sort of
> video processing software / command-line utility, and you have your animation.
>
> I'll let you look all of that over and you can try it out / ask more questions.
>

Hi, Aj! Welcome to the crazy world of POV-ray animation. ;-) It is actually
easier to accomplish than what you might think.

In addition to Bald Eagle's good comments, here's a quick explanation of what is
meant by the 'ini.file'.

In Windows, there is an included file called 'quickres.ini.' It holds a lot of
pre-written render resolutions for you. But it's also the place where I put all
of my animation commands-- like Start_Frame, Final_Frame, etc. There, you would
simply write
           Final_Frame=100  (no spaces)

This will automatically turn on the animation mechanism, ready and waiting.

And in your scene file, you would use the 'clock' keyword to create movement (or
'frame_number' if you want to actuate your animation that way instead.) Like,

object{ // optional
    sphere{<0,0,0>, 1 texture{...} translate 12*clock*x}
      }

Then hit the usual 'Run' command button, and POV-ray will automatically create
100 animation-frame renders, with the sphere moving 12 units in the +x
direction. That's your animation! -- ready to be assembled in your external
video-processing app.

For the many useful animation commands for doing things, take a look in v3.7's
included(?) 'help' file at the section called
          2.3.9 Making Animations

or just look up 'clock' or 'Final_Frame'. That should put you in the right place
in the documentation.

(I happen to be running a newer 3.8 version of POV-ray, so my help file may not
be exactly the same as yours.)

[yesbird] Re: Generating animation [1158 days 1 hour and 10 minutes ago]

Thu, 9 Feb 2023 21:50:00 GMT

"Aj" <nomail@nomail> wrote:

Hi,Aj.

I am new to POV'a animation techniques, but quick googling make me think that
POV is right in this case: there is no 'animation' no 'clip' keywords in this
list:
https://wiki.povray.org/content/Reference:Keywords

When I am following this section, everything works fine:
https://wiki.povray.org/content/HowTo:Create_animations#Animating_objects

All the best,
--
YB

[Bald Eagle] Re: Generating animation [1158 days 1 hour and 20 minutes ago]

Thu, 9 Feb 2023 21:40:00 GMT

"Aj" <nomail@nomail> wrote:
> Hi everyone,
>
> I really appreciate that you take a moment from your important time to resolve
> our issues.
>
> I am trying to animate an oscillating beam and this is what i wrote:

So what you need to do is look at the basic setup for rendering a scene, and
then how to run an animation from an .ini file using the clock variable.

https://wiki.povray.org/content/Documentation:Tutorial_Section_3.7#Making_Animations

> #declare time = 0;

Nope.  POV-Ray uses a variable called "clock" that is a built-in keyword, and
changes when your .pov file is rendered multiple times from the .ini file.

> #declare oscillation = sin(time);

That will probably work if you replace "time" with "clock", or just:
#declare time = clock;
so that you don't have to change any code.

> camera {
>   location <0, 0, 20>
>   look_at <0, 0, 0>
> }
>
> light_source {
>   <10, 10, 20>
>   color rgb <1, 1, 1>
> }
>
> background { color rgb <0.8, 0.9, 1> }
>
> box {
>   <0, -1, 0>, <2, 1, 0.2>
>   texture {
>     pigment { color rgb <0.7, 0.7, 0.7> }
>     finish { ambient 0.2 diffuse 0.8 }
>   }
> }
>
> cylinder {
>   <0, 0, 0>, <0, 0.1+5 * oscillation, 0>, 0.1
>   texture {
>     pigment { color rgb <0.9, 0.2, 0.2> }
>     finish { ambient 0.2 diffuse 0.8 }
>   }
> }
>
> animation {
>   camera {
>     rotation 0
>     location <0, 0, 20>
>     look_at <0, 0, 0>
>   }
>   clip {
>     frames 200
>     fps 30
>     input_file_name "oscillation-#.pov"
>     output_file_name "oscillation-#.png"
>     render_image_size <600, 600>
>     #declare time = clock;
>     #declare oscillation = sin(2*pi*time);
>   }
> }
>
> I get an error in the animation saying it is not a directive. I am using POV-Ray
> 3.7 on windows 10

"it", what is not a directive?

animation isn't a keyword, nor is clip, frames, fps, etc.

Very curious where you got the instructions and those commands from?

Once you write your .pov file, which should render without error all by itself,
then you write an .ini file which is like a script that renders your .pov file
over and over again with an increasing clock variable value.   Then you get a
bunch of still renders that you convert into a video file with some sort of
video processing software / command-line utility, and you have your animation.

I'll let you look all of that over and you can try it out / ask more questions.

- BE

[Aj] Generating animation [1158 days 1 hour and 40 minutes ago]

Thu, 9 Feb 2023 21:20:00 GMT

Hi everyone,

I really appreciate that you take a moment from your important time to resolve
our issues.

I am trying to animate an oscillating beam and this is what i wrote:

#declare time = 0;

#declare oscillation = sin(time);

camera {
  location <0, 0, 20>
  look_at <0, 0, 0>
}

light_source {
  <10, 10, 20>
  color rgb <1, 1, 1>
}

background { color rgb <0.8, 0.9, 1> }

box {
  <0, -1, 0>, <2, 1, 0.2>
  texture {
    pigment { color rgb <0.7, 0.7, 0.7> }
    finish { ambient 0.2 diffuse 0.8 }
  }
}

cylinder {
  <0, 0, 0>, <0, 0.1+5 * oscillation, 0>, 0.1
  texture {
    pigment { color rgb <0.9, 0.2, 0.2> }
    finish { ambient 0.2 diffuse 0.8 }
  }
}

animation {
  camera {
    rotation 0
    location <0, 0, 20>
    look_at <0, 0, 0>
  }
  clip {
    frames 200
    fps 30
    input_file_name "oscillation-#.pov"
    output_file_name "oscillation-#.png"
    render_image_size <600, 600>
    #declare time = clock;
    #declare oscillation = sin(2*pi*time);
  }
}

I get an error in the animation saying it is not a directive. I am using POV-Ray
3.7 on windows 10

Any suggestion would be really helpful

[Aj] Re: How to create 4x4 grid using bicubic patch [1220 days 9 hours and 55 minutes ago]

Fri, 9 Dec 2022 13:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Aj" <nomail@nomail> wrote:
> > Hello everyone,
> >
> > I was trying to create a grid of 4x4 using bicubic_patch but unfortunately, I
> > was unable to figure out how to achieve that. I was able to follow up with the
> > documentation and created a 3x3 grid, Any suggestion on how that can be achieved
> > would be really helpful.
>
> Do you want a 4 patch by 4 patch (16 patches total), or do you just want your
> patch to have a 4x4 grid as its pattern?
>
> The former is going to require some learning about the underlying
> Bezier/Bernstein splines that form the patches. I can email you the PDF, which
> is currently too large to post as an attachment here (which is why jr can't find
> it).
>
> But if all you want is the pattern, then simple replace
>
> >          scale 1/3
>
> with scale 1/4

Thank you so much, I think that has solved the problem.

[Bald Eagle] Re: Transforming transformation matrix to POV-ra... [1222 days 4 hours and 20 minutes ago]

Wed, 7 Dec 2022 18:40:00 GMT

So, it looks to me like you're trying to take a mesh bottle and put it in the
same place as the bottle in the image.
I'm also assuming that your image is on the xz plane.

I think what you ought to do is take your mesh, determine the bounding box, and
then position the mesh so that it is centered on the y axis, and its bottom is
at y=0.

#declare Min = min_extent {your mesh};
#declare Max = max_extent {your mesh};

#declare Center = (x+z)*(Min+Max)/2;
#declare Y_adjust = (Max.y-Min.y)/2;
object {your mesh translate -Center translate y*Y_adjust}

(That's all untested, so check it)

Then you can just translate the object to anywhere you want, knowing that it's
now centered, with the bottom at the origin.

If you're trying to flip something from right to left, the easiest way is to
just scale -x.

[StoicGilgamesh] Re: Transforming transformation matrix to POV-ra... [1222 days 9 hours and 20 minutes ago]

Wed, 7 Dec 2022 13:40:00 GMT

"StoicGilgamesh" <Gup### [at] acintuwienacat> wrote:

[StoicGilgamesh] Re: Transforming transformation matrix to POV-ra... [1222 days 9 hours and 20 minutes ago]

Wed, 7 Dec 2022 13:40:00 GMT

[StoicGilgamesh] Re: Transforming transformation matrix to POV-ra... [1222 days 9 hours and 20 minutes ago]

Wed, 7 Dec 2022 13:40:00 GMT

[StoicGilgamesh] Re: Transforming transformation matrix to POV-ra... [1222 days 9 hours and 20 minutes ago]

Wed, 7 Dec 2022 13:40:00 GMT

"StoicGilgamesh" <Gup### [at] acintuwienacat> wrote:
>

[StoicGilgamesh] Re: Transforming transformation matrix to POV-ra... [1222 days 9 hours and 25 minutes ago]

Wed, 7 Dec 2022 13:35:00 GMT

[StoicGilgamesh] Transforming transformation matrix to POV-ray fo... [1222 days 9 hours and 30 minutes ago]

Wed, 7 Dec 2022 13:30:00 GMT

I am surely doing something wrong here, any advice or help would be highly
appreciated.

GOAL:
I want to transform the object mesh (.inc) in the same pose as the object in the
captured image and then render it on the object in the captured image.

that is, I would like this rendered object by pov-ray to alight exactly with the
object in the captured image.


--------------------------------------------------------------------------------
DESCRIPTION:
I get my object mesh from the keypose/ BOP dataset, with its corresponding
ground-truth object pose in the form of a Transformation matrix(Original
Transformation matrix.png). This is in the Right Hand Coordinate system.

Since POV-ray operates in the Left-hand coordinate system I tried to convert the
transformation matrix ( the ground-truth pose provided by the dataset) to the
right hand by following suggestions:

https://stackoverflow.com/questions/1263072/changing-a-matrix-from-right-handed-to-left-handed-coordinate-system


That is from the original transformation matrix:

{ rx, ry, rz, 0 }
{ ux, uy, uz, 0 }
{ lx, ly, lz, 0 }
{ px, py, pz, 1 }

To change it from left to right or right to left, flip it like this:

{ rx, rz, ry, 0 }
{ lx, lz, ly, 0 }
{ ux, uz, uy, 0 }
{ px, pz, py, 1 }


But this leads to the following result (image).

Since this throws the object out of the image, i change the "CamLoc" from
"<0,0,0>" to "<0,0,-2>" in the script below (image).



--------------------------------------------------------------------------------

THE SCRIPT I AM USING IS:

#version 3.7;
global_settings {max_trace_level 40 }

#include "colors.inc"
#include "shapes.inc"

#ifdef (cl_x) #declare CamLoc=<0,0,0>; #end // Camera Location
#ifdef (lk_x) #declare LookAt=<0,0,1>;    #end // Look at
#ifdef (cs_x) #declare CamSky=<0.0,   1,   0>;    #end // Camera Sky
#declare CamDir = vnormalize(LookAt - CamLoc);
#declare CamR   = vnormalize(vcross(CamSky,CamDir));
#declare CamUp  = vnormalize(vcross(CamDir,CamR));

#ifdef (cam_a) #declare CamA = cam_a; #else #declare CamA = 1;   #end // Aspect
ratio
#ifdef (cam_z) #declare CamZ = cam_z; #else #declare CamZ = 1.5; #end // Zoom
#ifdef (bg_sc) #declare BgSc = bg_sc; #else #declare BgSc = 3;   #end //
Background scale

#ifndef (IOR)   #declare IOR   = 1.5; #end // Index of refraction
#ifndef (Trans) #declare Trans = 1;   #end // Transmit
#ifndef (Dim)   #declare Dim   = 1;   #end // Ambient intensity

camera {
    location CamLoc
    direction CamDir * CamZ
    angle 86.9
    right CamR * CamA
    up CamUp
}

#macro OrientZ(p1,p2,cs)
    #local nz = vnormalize(p2-p1);
    #local nx = vnormalize(vcross(cs,nz));
    #local ny = vcross(nz,nx);
    matrix <nx.x, nx.y, nx.z,
            ny.x, ny.y, ny.z,
            nz.x, nz.y, nz.z,
            p1.x, p1.y, p1.z>
#end

#ifdef (Calib) // Render objects with graycode patterns
    #declare pigmentStructure = pigment {
        #if (clock <= 2)
            #if (clock = 1) #declare mask = 1; #end color White
        #else
            image_map { png concat(${ImageName}, str(clock-2,1,0), ".png")
map_type 0 interpolate 2 }
        #end
    }
#else
    #declare pigmentImage = pigment {
        #ifdef (mask)
            color White
        #else
            #ifdef (rho) color White #else image_map { jpeg ${ImageName}
map_type 0 interpolate 2 } #end
        #end
    }
#end

box { <0,0,0> <1,1,0.01>
    #ifdef (Calib)
        pigment { pigmentStructure }
        finish { ambient 1 }
    #else
        pigment { pigmentImage }
        finish { ambient Dim }
    #end
    translate <-0.5,-0.5,0>
    scale <CamA, 1, 1>
    translate <0, 0, CamZ>
    scale BgSc
    OrientZ(CamLoc,LookAt,CamSky)
}

#ifndef (Empty)
object {
    shape
    #ifdef (mask)
        pigment {color Black}
    #else
        texture {
            pigment{
                color filter 1
                #ifdef (Calib) transmit 1 #else transmit Trans #end
            }
        }
        interior {
            ior IOR
            #ifndef (Calib)
                #ifdef (FadeD) fade_distance FadeD fade_power FadeP #end
            #end
        }
    #end

    matrix <0.9985836 , -0.03011384, -0.04386286,
        -0.05320521, -0.56519264, -0.82324145,
        0.        ,  0.82440915, -0.56599431,
         -0.03461049,  0.7220574 ,  0.08761759>


}
#end

PROBLEM:

As you can see this particular transform throws the object out of the image.

Ideally, i would like this rendered object by pov-ray to alight exactly with the
object in the image.

I have also tried a few other transforms but they also do not seem to work.


for reference, i also add the result of the pov-ray rendered image using the
original transform given by the dataset (attached image: )


Any help would be greatly appreciated!

[Bald Eagle] Re: How to create 4x4 grid using bicubic patch [1222 days 11 hours and 25 minutes ago]

Wed, 7 Dec 2022 11:35:00 GMT

"Aj" <nomail@nomail> wrote:
> Hello everyone,
>
> I was trying to create a grid of 4x4 using bicubic_patch but unfortunately, I
> was unable to figure out how to achieve that. I was able to follow up with the
> documentation and created a 3x3 grid, Any suggestion on how that can be achieved
> would be really helpful.

Do you want a 4 patch by 4 patch (16 patches total), or do you just want your
patch to have a 4x4 grid as its pattern?

The former is going to require some learning about the underlying
Bezier/Bernstein splines that form the patches. I can email you the PDF, which
is currently too large to post as an attachment here (which is why jr can't find
it).

But if all you want is the pattern, then simple replace

>          scale 1/3

with scale 1/4

[ingo] Re: How to create 4x4 grid using bicubic patch [1222 days 15 hours and 15 minutes ago]

Wed, 7 Dec 2022 07:45:00 GMT

"Aj" <nomail@nomail> wrote:

You have knots ('fixed points') and handles. Define a grid of fixed points. Now
you can think of each row and column as the fixed points in a bezier curve. The
handles of the bezier curves have to be equally long and need to have the
opposite direction to keep the curve smooth. A Bezier patch is just a lattice of
Bezier curves, the same rules apply.

Altough I don't think it is helpfull, I dug op some very old code t create a
bezier cylinder with dimples:
---%<------%<------%<----

// Ingo Janssen
// 1999-04-22
// bicubic patch generation

#version 3.1;
global_settings{assumed_gamma 1.0}
light_source{<100,50,-500> rgb 1}

camera{
   location <0,0,-20.0>
   look_at  <0,0, 0.0>
}

#macro GetRadius1(R)
   #local Range=R*0.1;
   #local Variation=Range+(((-Range)-Range)*rand(S));
   #declare Rr=R+Variation;
#end

#macro BuildArray(H,R,NrBPH,NrBPC)
// H= height; R= radius
// NrBPH= number of patches in height
// NrBPC= number of patches in circumference
   #local PH=((NrBPH*4)-NrBPH)+1;
   #local PC=((NrBPC*4)-NrBPC)+1;
   #local Ystep=H/PH;
// need one extra element in the array for C1 continuity.
   #local BP_arr=array[PH+1][PC+1]
   #local Ypos=0;
   #local I=0;
   #local J=0;
   #while (I<PH+1)
      #while (J<PC-1)
         #local Phi=(J*(360/PC));//+(I*((-180+clock*360)/PH));
         GetRadius1(R)
         #declare BP_arr[I][J]=vrotate(<Rr,Ypos,0>,<0,Phi,0>);
         #local J=J+1;
      #end //while
// closed shape so last point is first point.
      #local BP_arr[I][J]= BP_arr[I][0];
// the last-plus-one point must be the same as the second point, too.
      #local BP_arr[I][J+1]= BP_arr[I][1];
      #local J=0;
      #local Ypos=Ypos+Ystep;
      #local I=I+1;
   #end //while
   #declare OutArray= BP_arr
#end //macro

#macro BuildPatch(InArray)
// the arrays were made an element larger, so here we must compensate.
   #local PH= dimension_size (InArray,1)-1;
   #local PC= dimension_size (InArray,2)-1;
   #local I= 0;
   #local J= 0;
   #while (I<PH-1)
      #while (J<PC-1)
         bicubic_patch {
            type 1
            u_steps 4
            v_steps 4,
            InArray[I][J],
            InArray[I][J+1],
// notice that the third point in each row is constrained such
// that it, the last point in the row, and the second point
// in the equivalent row in the next patch are in a straight line.(Ron Parker)
            2*InArray[I][J+3]-InArray[I][J+4],
            InArray[I][J+3],

            InArray[I+1][J],
            InArray[I+1][J+1],
            2*InArray[I+1][J+3]-InArray[I+1][J+4],
            InArray[I+1][J+3],

// notice, too, that each point in the entire third row is
// constrained in this way with respect to the last row and
// to the second row of the next patch.  Note the lack of any
// +2 terms in the whole patch definition.  We calculated them
// above, but we never use them because we no longer have as
// much freedom as we did before we wanted smoothness.(Ron Parker)

            2*InArray[I+3][J]-InArray[I+4][J],
            2*InArray[I+3][J+1]-InArray[I+4][J+1],

2*(2*InArray[I+3][J+3]-InArray[I+4][J+3])-(2*InArray[I+3][J+4]-InArray[I+4][J+4]),
            2*InArray[I+3][J+3]-InArray[I+4][J+3],

            InArray[I+3][J],
            InArray[I+3][J+1],
            2*InArray[I+3][J+3]-InArray[I+3][J+4],
            InArray[I+3][J+3]

            pigment {rgb 1}
         }
         #local J=J+3;
      #end //while
      #local J=0;
      #local I=I+3;
   #end //while
#end //macro


#macro ScaleArray(InArray)
   #local PH= dimension_size (InArray,1);
   #local PC= dimension_size (InArray,2);
   #local I= 0;
   #local J= 0;
   #local Phi= 0;
   #while (I<PH)
      #while (J<PC)

         #local Scale=sin(Phi)+0.5;
         #local InArray[I][J]=InArray[I][J]*<Scale,1,Scale>;

         #local J= J+1;
      #end //while
      #local J= 0;
      #local Phi=Phi+(pi/(PH-2));
      #local I= I+1;
   #end //while
   #declare OutArray= InArray
#end //macro


#declare S=seed(7);
BuildArray(15,5,25,15)
ScaleArray(OutArray)
union{
   BuildPatch(OutArray)
   rotate <0,0,90>
   translate <7.5,0,0>
}

---%<------%<------%<----

> I was trying to create a grid of 4x4 using bicubic_patch but unfortunately, I
> was unable to figure out how to achieve that. I was able to follow up with the
> documentation and created a 3x3 grid, Any suggestion on how that can be achieved
> would be really helpful.

[jr] Re: How to create 4x4 grid using bicubic patch [1222 days 16 hours and 10 minutes ago]

Wed, 7 Dec 2022 06:50:00 GMT

hi,

"Aj" <nomail@nomail> wrote:
> Hello everyone,
>
> I was trying to create a grid of 4x4 using bicubic_patch ...

user Bald Eagle did this, comprehensively.  cannot currently find the thread
where he published a PDF on the subject, only this:
<http://news.povray.org/povray.binaries.tutorials/attachment/%3Cweb.56e6e3e9eb37b7785e7df57c0%40news.povray.org%3E/bezi
er%20uv%20mapping.png>

regards, jr.

[Aj] How to create 4x4 grid using bicubic patch [1222 days 16 hours and 40 minutes ago]

Wed, 7 Dec 2022 06:20:00 GMT

Hello everyone,

I was trying to create a grid of 4x4 using bicubic_patch but unfortunately, I
was unable to figure out how to achieve that. I was able to follow up with the
documentation and created a 3x3 grid, Any suggestion on how that can be achieved
would be really helpful.

I have attached the rendered image of the 3x3 grid along with the code.

//code


global_settings {assumed_gamma 1.0}
background {rgb <1,0.9,0.9>}
camera { location <3.1,7,-8> look_at <3,-2,1.5> angle 40 }
light_source {<500,500,-500> rgb 1 }

#declare B11=<0,0,3>; #declare B12=<1,0,3>; #declare B13=<2,0,3>; #declare
B14=<3,0,3>;// row 1

#declare B21=<0,0,2>; #declare B22=<1,0,2>; #declare B23=<2,0,2>; #declare
B24=<3,0,2>; // row 2

#declare B31=<0,0,1>; #declare B32=<1,0,1>; #declare B33=<2,0,1>; #declare
B34=<3,0,1>; // row 3

#declare B41=<0,0,0>; #declare B42=<1,0,0>; #declare B43=<2,0,0>; #declare
B44=<3,0,0>; // row 4





bicubic_patch {
   type 1 flatness 0.001
   u_steps 128 v_steps 128
   uv_vectors
   <0,0> <1,0> <1,1> <0,1>
   B11, B12, B13, B14//, B14
   B21, B22, B23, B24//, B25
   B31, B32, B33, B34//, B35
   B41, B42, B43, B44//, B45
   uv_mapping
   texture {
      pigment {
         checker
         color rgbf <1,1,1,0.5>
         color rgbf <0,0,1,0.7>
         scale 1/3


      }
      finish {phong 0.6 phong_size 20}
   }
   no_shadow

}

[Alain Martel] Re: "Floor" plane with tiled/checkered image [1264 days 8 hours and 10 minutes ago]

Wed, 26 Oct 2022 14:50:25 GMT

Le 2022-10-25 Ã  19:49, neri-engineering a Ã©critÂ :
>> Ah, this makes sense.  I will try that.  The strange behavior I'm seeing is
>> consistent with your explanation.
> 
> I got it.  The snippet below works as expected.  The 'emission' is because I'm
> using radiosity and want the shadow cast onto the floor to be a tad less dark,
> 'diffuse' limits how bright the floor is.  Thanks for the help

You should not use emission for that purpose. What you do actually mean 
that the floor is a source of illumination. Don't take bad habits.
The purpose of emission is to have some object actually emit light. It 
allow the creation of scenes where there are no light_source to get 
illuminated.
With radiosity, you need an environment outside the visible part of the 
scene.

For a room, that normally mean having all the walls and ceiling present. 
That way, the light bouncing off the other walls and ceiling will 
illuminate the areas that are in the shadow from regular lights.
Make the ceiling white or light grey as most of the ceilings are. Use 
recursion_limit 2 or 3.
For outdoor scenes, that's done with a sky_sphere or a huge sphere 
surrounding the scene.

[neri-engineering] Re: "Floor" plane with tiled/checkered image [1264 days 23 hours and 10 minutes ago]

Tue, 25 Oct 2022 23:50:00 GMT

> Ah, this makes sense.  I will try that.  The strange behavior I'm seeing is
> consistent with your explanation.

I got it.  The snippet below works as expected.  The 'emission' is because I'm
using radiosity and want the shadow cast onto the floor to be a tad less dark,
'diffuse' limits how bright the floor is.  Thanks for the help.
========================================================

plane {
  y, -4
  pigment {
    image_map {
      jpeg "wood.jpg"
      map_type 0
    }
    rotate 90 * x
  }
  finish {
    specular 0.0
    diffuse 0.45
    emission 0.06
  }
  scale <53, 1, 53>
  rotate <0, 65, 0>
}

[neri-engineering] Re: "Floor" plane with tiled/checkered image [1265 days 1 hour and 10 minutes ago]

Tue, 25 Oct 2022 21:50:00 GMT

> Initially, image_map are applied in the X-Y plane.
> To apply them to your floor, you need to rotate it.
>
> Just add : rotate 90*x
>
> plane{y,0
>  pigment{image_map {jpeg "wood.jpg" scale Something} rotate 90*x}
> }
> The image will repeat infinitely to cover all of the plane.
> scale Something is used to adjust the size of the image if it's not
> square or need to be larger than a 1x1 repeating tile.

Ah, this makes sense.  I will try that.  The strange behavior I'm seeing is
consistent with your explanation.

Thank you also to the other user who suggested using macros.  I'm not that far
into my studies yet.  I will get there - to using macros that is.

[Alain Martel] Re: "Floor" plane with tiled/checkered image [1265 days 7 hours and 14 minutes ago]

Tue, 25 Oct 2022 15:46:06 GMT

Le 2022-10-25 Ã  00:20, neri-engineering a Ã©critÂ :
> I'm just trying to create an infinite "floor" (plane) which uses a JPEG image,
> attached for reference, and named "wood.jpg".
> 
> For example I can create a floor of two difference colors in a checkered pattern
> like this:
> 
> plane {
>    y, 0
>    pigment {
>      checker color Brown, color Violet
>      scale 13
>    }
> }
> 
> I've been banging my head against the wall trying to use the image "wood.jpg"
> for each of the checker boxes.  Tried using "checker" keyword, tried various
> other things, I can create mesh2 objects with UV-mappings and apply a custom
> texture like so:
> 
> mesh2 {
>    mesh_name
>    uv_mapping
>    pigment {
>      image_map {
>        png "cut-chapstick-label.png"
>        map_type 0
>      }
>    }
> }
> 
> But the moment I try to apply a similar strategy to my floor, I get stretched
> image in one of the directions.
> 
> Normally I would find the answer by experimentation and/or research but in this
> case I feel like I'm on the brink of insanity trying to do this.
> 
> Thanks for the help.

Initially, image_map are applied in the X-Y plane.
To apply them to your floor, you need to rotate it.

Just add : rotate 90*x

plane{y,0
	pigment{image_map {jpeg "wood.jpg" scale Something} rotate 90*x}
}
The image will repeat infinitely to cover all of the plane.
scale Something is used to adjust the size of the image if it's not 
square or need to be larger than a 1x1 repeating tile.

[William F Pokorny] Re: "Floor" plane with tiled/checkered image [1265 days 13 hours and 24 minutes ago]

Tue, 25 Oct 2022 09:35:53 GMT

On 10/25/22 00:20, neri-engineering wrote:
> I've been banging my head against the wall trying to use the image "wood.jpg"
> for each of the checker boxes.

Perhaps something like:

..
#declare Plane00 = plane { y, 0 }
#macro ImageMap00(_HF) // Macro due my tcl command wrapper of SDL...
   #if (_HF=0)
     image_map { "wood.jpg"
   #else
      "wood.jpg"
   #end
   #if (_HF=0)
      map_type 0
      interpolate 2
     }
   #end
#end
#declare Pigment00 = pigment { ImageMap00(0) rotate x*90 }
#declare Pigment01 = pigment { Pigment00 rotate y*90 }
#declare Pigment02 = pigment {
     checker
     pigment { Pigment00 }
     pigment { Pigment01 }
}
#declare Texture02 = texture {
     pigment { Pigment02 }
     normal { granite 0.2 scale 0.3 }
     finish { phong 0.6}
//  scale 0.5
}
#declare Obj02 = object { Plane00 texture { Texture02 } }

//--- scene ---
//  camera... light...
     object { Obj02 }
..

Bill P.

[neri-engineering] "Floor" plane with tiled/checkered image [1265 days 18 hours and 35 minutes ago]

Tue, 25 Oct 2022 04:25:00 GMT

I'm just trying to create an infinite "floor" (plane) which uses a JPEG image,
attached for reference, and named "wood.jpg".

For example I can create a floor of two difference colors in a checkered pattern
like this:

plane {
  y, 0
  pigment {
    checker color Brown, color Violet
    scale 13
  }
}

I've been banging my head against the wall trying to use the image "wood.jpg"
for each of the checker boxes.  Tried using "checker" keyword, tried various
other things, I can create mesh2 objects with UV-mappings and apply a custom
texture like so:

mesh2 {
  mesh_name
  uv_mapping
  pigment {
    image_map {
      png "cut-chapstick-label.png"
      map_type 0
    }
  }
}

But the moment I try to apply a similar strategy to my floor, I get stretched
image in one of the directions.

Normally I would find the answer by experimentation and/or research but in this
case I feel like I'm on the brink of insanity trying to do this.

Thanks for the help.

[m@b] Re: Scene enquiry [1269 days 6 hours and 38 minutes ago]

Fri, 21 Oct 2022 16:22:20 GMT

On 20/10/2022 10:57 AM, santividal wrote:
> Thank you so much m@b, that was exactly what I was looking for. What if I wanted
> to continue drawing my droplets in the lower level of the fountain? Where should
> I declare the distance from the Y axis so that the droplets appear as a
> continuation of the upper level?
> 
> Thank you in advance for any help

You could just add a second sphere and translate it before rotation:

#declare Rotation=0;
#declare Rotation_angle=12;


#while (Rotation < 360)
     #declare posX = 0.02;
     #declare posY = 0.82;
     #declare dy = 0.055;
     #while (posX < 0.3)
         sphere {<posX,posY,0>, 0.01 pigment{rgb<0,1,0>} 
       rotate<0,Rotation,0>}
         sphere {<posX,posY,0>, 0.01 pigment{rgb<0,0,1>} 
translate<0.2,-0.3,0> rotate<0,Rotation,0> }
         #declare dy = dy - 0.01;
         #declare posX = posX + 0.02;
         #declare posY = (posY + dy);
     #end
     #declare Rotation = (Rotation + Rotation_angle);
#end

[santividal] Re: Scene enquiry [1270 days 13 hours ago]

Thu, 20 Oct 2022 10:00:00 GMT

Thank you so much m@b, that was exactly what I was looking for. What if I wanted
to continue drawing my droplets in the lower level of the fountain? Where should
I declare the distance from the Y axis so that the droplets appear as a
continuation of the upper level?

Thank you in advance for any help


"m@b" <sai### [at] googlemailcom> wrote:
> On 19/10/2022 5:39 PM, santividal wrote:
> > Him I am trying to replicate this water droplets all around the tap, so maybe a
> > series of droplets every 12 or 24 degrees around z axis. How should I do. that?
> > I know it is a beginner trick, but I am trying different #while sentences and it
> > doesn't seem to work out. Could somebody help me? Here is the code I am using to
> > achieve the droplets look like a trajectory.
> >
> > Thanks in advance for any help,
> >
> >
> > // FUENTE SUPERIOR
> >
> > #declare posX = 0.02;
> > #declare posY = 0.82;
> > #declare dy = 0.055;
> > #declare posZ=0;
> > #declare posZ= <0,0,posZ+12>;
> >
> >
> >      #while (posX < 0.3)
> >      sphere {
> >      <posX,posY,0>, 0.01
> >      material { agua }  }
> >      #declare dy = dy - 0.01;
> >      #declare posX = posX + 0.02;
> >      #declare posY = (posY + dy);
> >      #end
> >
> >
>
>
> #declare Rotation=0;
> #declare Rotation_angle=12;
>
> #while (Rotation < 360)
>      #declare posX = 0.02;
>      #declare posY = 0.82;
>      #declare dy = 0.055;
>      #while (posX < 0.3)
>          sphere {
>          <posX,posY,0>, 0.01
>          // material { agua }
>          rotate<0,Rotation,0>
>          }
>          #declare dy = dy - 0.01;
>          #declare posX = posX + 0.02;
>          #declare posY = (posY + dy);
>      #end
>      #declare Rotation = (Rotation + Rotation_angle);
> #end

[m@b] Re: Scene enquiry [1271 days 5 hours and 33 minutes ago]

Wed, 19 Oct 2022 17:27:27 GMT

On 19/10/2022 5:39 PM, santividal wrote:
> Him I am trying to replicate this water droplets all around the tap, so maybe a
> series of droplets every 12 or 24 degrees around z axis. How should I do. that?
> I know it is a beginner trick, but I am trying different #while sentences and it
> doesn't seem to work out. Could somebody help me? Here is the code I am using to
> achieve the droplets look like a trajectory.
> 
> Thanks in advance for any help,
> 
> 
> // FUENTE SUPERIOR
> 
> #declare posX = 0.02;
> #declare posY = 0.82;
> #declare dy = 0.055;
> #declare posZ=0;
> #declare posZ= <0,0,posZ+12>;
> 
> 
>      #while (posX < 0.3)
>      sphere {
>      <posX,posY,0>, 0.01
>      material { agua }  }
>      #declare dy = dy - 0.01;
>      #declare posX = posX + 0.02;
>      #declare posY = (posY + dy);
>      #end
> 
> 


#declare Rotation=0;
#declare Rotation_angle=12;

#while (Rotation < 360)
     #declare posX = 0.02;
     #declare posY = 0.82;
     #declare dy = 0.055;
     #while (posX < 0.3)
         sphere {
         <posX,posY,0>, 0.01
         // material { agua }
         rotate<0,Rotation,0>
         }
         #declare dy = dy - 0.01;
         #declare posX = posX + 0.02;
         #declare posY = (posY + dy);
     #end
     #declare Rotation = (Rotation + Rotation_angle);
#end

[Bald Eagle] Re: Scene enquiry [1271 days 5 hours and 35 minutes ago]

Wed, 19 Oct 2022 17:25:00 GMT

I think if you look at code used to model the physics of a falling object, or
better yet, a bouncing ball - you will get the deceleration on the upward
"bounce" and the acceleration on the subsequent fall.


Attached, find a scene I wrote to do the bouncing ball, hope it helps - ask if
you have any questions.

[santividal] Scene enquiry [1271 days 6 hours and 20 minutes ago]

Wed, 19 Oct 2022 16:40:01 GMT

Him I am trying to replicate this water droplets all around the tap, so maybe a
series of droplets every 12 or 24 degrees around z axis. How should I do. that?
I know it is a beginner trick, but I am trying different #while sentences and it
doesn't seem to work out. Could somebody help me? Here is the code I am using to
achieve the droplets look like a trajectory.

Thanks in advance for any help,


// FUENTE SUPERIOR

#declare posX = 0.02;
#declare posY = 0.82;
#declare dy = 0.055;
#declare posZ=0;
#declare posZ= <0,0,posZ+12>;


    #while (posX < 0.3)
    sphere {
    <posX,posY,0>, 0.01
    material { agua }  }
    #declare dy = dy - 0.01;
    #declare posX = posX + 0.02;
    #declare posY = (posY + dy);
    #end

[Bald Eagle] Re: Improving resolution in povray images [1277 days 4 hours and 45 minutes ago]

Thu, 13 Oct 2022 18:15:00 GMT

"vishesh saxena" <sax### [at] gmailcom> wrote:
> Hello all,
>
> I am using povray to generate png images of spin textures from another program
> called as VAMPIRE. The generated png files are blurred. I cannot see the spins
> properply when I zoom in.
>
> I am very new to povray. Any suggestions on how to increase the resolution?
>
> Best regards,
> Vishesh

Hi Vishesh,

This is a very interesting program.   I'm particularly interested in the Monte
Carlo methods section - particularly the sampling algorithm.
Our developer at the time was trying to come up with a way to preferentially
sample in the areas where an attribute's density was the highest, while ignoring
most or all of the areas where it was low or nonexistent.
https://vampire.york.ac.uk/images/features/sampling.jpg

http://news.povray.org/povray.advanced-users/thread/%3C57bf8a2f%241%40news.povray.org%3E/?ttop=433049&toff=150&mtop=410
480

Perhaps you have some of the mathematical expertise - or connections who, that
can offer some advice in that area.

As for not being able to see what you want in your spin texture, what you want
to do - as others have suggested - is to increase the render image size in
POV-Ray before rendering your image, which essentially increases the resolution.
 You will then be rendering the same scene over a larger number of pixels.
Depending on how you have everything set up, you might need to adjust your
camera angle or distance to get your scene to fill the entire render window
again.

BEFORE you jump ahead to a very large image, be aware that this can massively
slow down the render time, due to technical under-the-hood details.
http://news.povray.org/povray.windows/thread/%3Cweb.56edd77df9a19c455e7df57c0%40news.povray.org%3E/

The solution probably lies in tailoring the render block size to the scene:

Render Block Size
POV-Ray provides a mechanism to specify the render block size via either an
INI-style option Render_Block_Size=n or on the command-line +BSn, where n is an
integer larger than or equal to 4. This represents the edge size of the square
used to distribute work to the render threads, and thus the number of pixels in
each block will be n squared. The default value is 32. If you specify a value
that is greater than the larger of the width or height of the image being
rendered, it is clipped to that value. Using render block sizes of less than
eight can impact performance, particularly on large images that render quickly,
as it significantly increases the amount of message traffic between the render
back-end and the graphical front-end, which communicate using a shared-memory
queue.

https://wiki.povray.org/content/Reference:Tracing_Options#Render_Block_Size

- Bill

[kurtz le pirate] Re: Improving resolution in povray images [1277 days 6 hours and 15 minutes ago]

Thu, 13 Oct 2022 16:45:06 GMT

On 12/10/2022 16:09, vishesh saxena wrote:
> Hello all,
> 
> I am using povray to generate png images of spin textures from another program
> called as VAMPIRE. The generated png files are blurred. I cannot see the spins
> properply when I zoom in.
> 
> I am very new to povray. Any suggestions on how to increase the resolution?
> 
> Best regards,
> Vishesh
> 

Can you share the generated pov file ?


-- 
Kurtz le pirate
Compagnie de la Banquise

[Alain Martel] Re: Improving resolution in povray images [1278 days 5 hours and 24 minutes ago]

Wed, 12 Oct 2022 17:36:19 GMT

Le 2022-10-12 Ã  10:09, vishesh saxena a Ã©critÂ :
> Hello all,
> 
> I am using povray to generate png images of spin textures from another program
> called as VAMPIRE. The generated png files are blurred. I cannot see the spins
> properply when I zoom in.
> 
> I am very new to povray. Any suggestions on how to increase the resolution?
> 
> Best regards,
> Vishesh

In the Windows version, there is a resolution drop down menu at the left 
side of the tool bar. It propose a set of default dimensions and 
anti-aliasing settings.
You can easily expand it, it's an ini file,a simple text file following 
a simple set of rules.

You can also enter any arbitrary dimension in the text box just next to 
the drop menu.
Use +wnnn to set the width.
+hnnn to set the heigth
+a is used to turn on anti-aliasing followed with some options to fine 
tune it
Ex.: +a0.01 +am2 +r3
Turn anti-aliasing on with a trigger delta of 1% in the sum of the 
difference in the value of neighbour pixels, using anti-aliasing method 
2 and a recursion level of 3.

[Cousin Ricky] Re: Improving resolution in povray images [1278 days 7 hours and 40 minutes ago]

Wed, 12 Oct 2022 15:20:00 GMT

"vishesh saxena" <sax### [at] gmailcom> wrote:
> Hello all,
>
> I am using povray to generate png images of spin textures from another program
> called as VAMPIRE. The generated png files are blurred. I cannot see the spins
> properply when I zoom in.
>
> I am very new to povray. Any suggestions on how to increase the resolution?

Since POV-Ray creates raster images, rather than vector images, increasing the
image size cannot increase its resolution.  You must use the height and width
output options to create a large image.  For example,

  +H1000 +W750

Also, if you aren't doing so already, use anti-aliasing: +A

[jr] Re: Improving resolution in povray images [1278 days 7 hours and 50 minutes ago]

Wed, 12 Oct 2022 15:10:00 GMT

hi,

"vishesh saxena" <sax### [at] gmailcom> wrote:
> Hello all,
>
> I am using povray to generate png images of spin textures from another program
> called as VAMPIRE. The generated png files are blurred. I cannot see the spins
> properply when I zoom in.
>
> I am very new to povray. Any suggestions on how to increase the resolution?

you can choose the output resolution freely, see link.  in fact, it often helps
to render at a high(er) resolution and resize the image afterwards.  another
thing to bear in mind is the camera's aspect, make sure image size and camera
"agree" on the ratio.  hth.

<https://wiki.povray.org/content/Reference:General_Output_Options#Height_and_Width_of_Output>

regards, jr.

[vishesh saxena] Improving resolution in povray images [1278 days 8 hours and 50 minutes ago]

Wed, 12 Oct 2022 14:10:00 GMT

Hello all,

I am using povray to generate png images of spin textures from another program
called as VAMPIRE. The generated png files are blurred. I cannot see the spins
properply when I zoom in.

I am very new to povray. Any suggestions on how to increase the resolution?

Best regards,
Vishesh

[kurtz le pirate] Re: Inverse Kinematics neck (ot IKN) macro [1296 days 9 hours and 28 minutes ago]

Sat, 24 Sep 2022 13:32:09 GMT

On 19/09/2022 19:34, Aj wrote:
> Hello everyone,
> 
> I was wondering if there is a tutorial for the macro mentioned in the subject.
> I looked up and could not find any. Any recommendations or suggestions on how to
> create a spline passing through 6 points using this macro would be really
> helpful.
> 
> Thank you.
> 

Explanations are here :

<https://runevision.com/3d/include/include.asp>


-- 
Kurtz le pirate
Compagnie de la Banquise

[Thomas de Groot] Re: Sphere sweep appears to be thicker at the ba... [1296 days 11 hours and 53 minutes ago]

Sat, 24 Sep 2022 11:07:11 GMT

Op 23-9-2022 om 20:39 schreef jr:
> hi,
> 
> "Aj" <nomail@nomail> wrote:
>> Hello everyone,
>>
>> I am trying to fix this problem with my sphere sweep object ...
>> If you look at the base of the object and compare it with the tip, you will
>> notice that the tip appears to be thinner than the base, any suggestion on how
>> to fix this problem would be very helpful.
> 
> two things I can think of:
>    (a) use an orthographic type camera.
>    (b) ensure the points lie in a plane wrt perspective camera.
> 

I agree with jr. I think this is a perspective "problem" as I do not 
really "see" the sphere sweep getting thinner.

-- 
Thomas

[jr] Re: Sphere sweep appears to be thicker at the ba... [1297 days 4 hours and 15 minutes ago]

Fri, 23 Sep 2022 18:45:00 GMT

hi,

"Aj" <nomail@nomail> wrote:
> Hello everyone,
>
> I am trying to fix this problem with my sphere sweep object ...
> If you look at the base of the object and compare it with the tip, you will
> notice that the tip appears to be thinner than the base, any suggestion on how
> to fix this problem would be very helpful.

two things I can think of:
  (a) use an orthographic type camera.
  (b) ensure the points lie in a plane wrt perspective camera.


regards, jr.

[Aj] Sphere sweep appears to be thicker at the base a... [1297 days 5 hours and 10 minutes ago]

Fri, 23 Sep 2022 17:50:00 GMT

Hello everyone,

I am trying to fix this problem with my sphere sweep object as mentioned in the
subject. I am not sure if it has to do with the camera positioning or some other
setting.

I have attached the code and corresponding rendered image.

If you look at the base of the object and compare it with the tip, you will
notice that the tip appears to be thinner than the base, any suggestion on how
to fix this problem would be very helpful.

Thank you.

#include "colors.inc"

camera {

        location <5,30,-50>
        look_at <10,10,10>
        angle 80
        }

light_source {
                <1,10,-10>
                color White
             }




background {color rgb<1,1,1> }


#declare Scale = 20*<40,10,1.5>;
#declare Radius = 1;
#declare P1  = Scale*<0,0,0>;
#declare P2  = Scale*<0.00011003,-9.7009e-05,0.010001>;
#declare P3  = Scale*<0.00021841,-0.00019256,0.020002>;
#declare P4  = Scale*<0.00032347,-0.00028519,0.030003>;
#declare P5  = Scale*<0.00042358,-0.00037345,0.040004>;
#declare P6  = Scale*<0.00051706,-0.00045587,0.050005>;
#declare P7  = Scale*<0.00060227,-0.000531,0.060006>;
#declare P8  = Scale*<0.00067755,-0.00059737,0.070007>;
#declare P9  = Scale*<0.00074126,-0.00065353,0.080007>;
#declare P10  = Scale*<0.00079172,-0.00069803,0.090008>;
#declare P11  = Scale*<0.0008273,-0.00072939,0.10001>;
#declare P12  = Scale*<0.00084632,-0.00074617,0.11001>;
#declare P13  = Scale*<0.00084715,-0.0007469,0.12001>;
#declare P14  = Scale*<0.00082812,-0.00073012,0.13001>;
#declare P15  = Scale*<0.00078759,-0.00069438,0.14001>;
#declare P16  = Scale*<0.00072388,-0.00063822,0.15001>;
#declare P17  = Scale*<0.00063536,-0.00056017,0.16001>;
#declare P18  = Scale*<0.00052037,-0.00045879,0.17001>;
#declare P19  = Scale*<0.00037725,-0.0003326,0.18>;
#declare P20  = Scale*<0.00020434,-0.00018016,0.19>;
#declare P21  = Scale*<-1.5898e-10,2.9055e-10,0.2>;
#declare P22  = Scale*<-1.688e-10,2.9921e-10,0.2>;
#declare P23  = Scale*<-1.688e-10,2.9921e-10,0.2>;
#declare P24  = Scale*<-0.00023666,0.0002093,0.21>;
#declare P25  = Scale*<-0.00050341,0.00044902,0.21999>;
#declare P26  = Scale*<-0.00079727,0.00072041,0.22999>;
#declare P27  = Scale*<-0.0011152,0.0010247,0.23999>;
#declare P28  = Scale*<-0.0014543,0.0013632,0.24998>;
#declare P29  = Scale*<-0.0018115,0.0017371,0.25997>;
#declare P30  = Scale*<-0.0021837,0.0021476,0.26996>;
#declare P31  = Scale*<-0.0025682,0.002596,0.27995>;
#declare P32  = Scale*<-0.0029617,0.0030836,0.28994>;
#declare P33  = Scale*<-0.0033613,0.0036116,0.29992>;
#declare P34  = Scale*<-0.0037641,0.0041812,0.3099>;
#declare P35  = Scale*<-0.004167,0.0047937,0.31988>;
#declare P36  = Scale*<-0.0045671,0.0054504,0.32985>;
#declare P37  = Scale*<-0.0049613,0.0061524,0.33982>;
#declare P38  = Scale*<-0.0053466,0.0069011,0.34979>;
#declare P39  = Scale*<-0.0057201,0.0076976,0.35975>;
#declare P40  = Scale*<-0.0060788,0.0085433,0.36971>;
#declare P41  = Scale*<-0.0064195,0.0094393,0.37966>;
#declare P42  = Scale*<-0.0067395,0.010387,0.38961>;
#declare P43  = Scale*<-0.0070356,0.011387,0.39955>;
#declare P44  = Scale*<-0.0070356,0.011387,0.39955>;
#declare P45  = Scale*<-0.0070356,0.011387,0.39955>;
#declare P46  = Scale*<-0.0073058,0.012441,0.40949>;
#declare P47  = Scale*<-0.0075512,0.013546,0.41942>;
#declare P48  = Scale*<-0.0077741,0.014699,0.42935>;
#declare P49  = Scale*<-0.0079765,0.015897,0.43927>;
#declare P50  = Scale*<-0.0081606,0.017136,0.44919>;
#declare P51  = Scale*<-0.0083285,0.018414,0.45911>;
#declare P52  = Scale*<-0.0084824,0.019727,0.46902>;
#declare P53  = Scale*<-0.0086244,0.021073,0.47893>;
#declare P54  = Scale*<-0.0087566,0.022449,0.48883>;
#declare P55  = Scale*<-0.0088811,0.02385,0.49873>;
#declare P56  = Scale*<-0.0090002,0.025275,0.50863>;
#declare P57  = Scale*<-0.0091158,0.026719,0.51853>;
#declare P58  = Scale*<-0.0092301,0.028181,0.52843>;
#declare P59  = Scale*<-0.0093454,0.029656,0.53832>;
#declare P60  = Scale*<-0.0094636,0.031143,0.54821>;
#declare P61  = Scale*<-0.009587,0.032636,0.5581>;
#declare P62  = Scale*<-0.0097176,0.034135,0.56799>;
#declare P63  = Scale*<-0.0098576,0.035634,0.57788>;
#declare P64  = Scale*<-0.010009,0.037133,0.58777>;
#declare P65  = Scale*<-0.010174,0.038626,0.59766>;
#declare P66  = Scale*<-0.010174,0.038626,0.59766>;
#declare P67  = Scale*<-0.010174,0.038626,0.59766>;
#declare P68  = Scale*<-0.010355,0.040112,0.60755>;
#declare P69  = Scale*<-0.01055,0.041591,0.61744>;
#declare P70  = Scale*<-0.010759,0.043063,0.62733>;
#declare P71  = Scale*<-0.010981,0.044529,0.63722>;
#declare P72  = Scale*<-0.011215,0.045988,0.64712>;
#declare P73  = Scale*<-0.011459,0.047443,0.65701>;
#declare P74  = Scale*<-0.011714,0.048892,0.6669>;
#declare P75  = Scale*<-0.011977,0.050337,0.67679>;
#declare P76  = Scale*<-0.012248,0.051778,0.68668>;
#declare P77  = Scale*<-0.012527,0.053216,0.69657>;
#declare P78  = Scale*<-0.012811,0.05465,0.70647>;
#declare P79  = Scale*<-0.0131,0.056083,0.71636>;
#declare P80  = Scale*<-0.013393,0.057513,0.72625>;
#declare P81  = Scale*<-0.013688,0.058942,0.73614>;
#declare P82  = Scale*<-0.013986,0.06037,0.74603>;
#declare P83  = Scale*<-0.014285,0.061797,0.75593>;
#declare P84  = Scale*<-0.014584,0.063224,0.76582>;
#declare P85  = Scale*<-0.014882,0.064652,0.77571>;
#declare P86  = Scale*<-0.015178,0.066081,0.7856>;
#declare P87  = Scale*<-0.015471,0.067511,0.7955>;
#declare P88  = Scale*<-0.015471,0.067511,0.7955>;
#declare P89  = Scale*<-0.015471,0.067511,0.7955>;
#declare P90  = Scale*<-0.01576,0.068943,0.80539>;
#declare P91  = Scale*<-0.016045,0.070377,0.81528>;
#declare P92  = Scale*<-0.016327,0.071813,0.82517>;
#declare P93  = Scale*<-0.016606,0.07325,0.83506>;
#declare P94  = Scale*<-0.016881,0.074689,0.84496>;
#declare P95  = Scale*<-0.017154,0.07613,0.85485>;
#declare P96  = Scale*<-0.017423,0.077572,0.86474>;
#declare P97  = Scale*<-0.01769,0.079015,0.87463>;
#declare P98  = Scale*<-0.017955,0.080459,0.88452>;
#declare P99  = Scale*<-0.018218,0.081905,0.89441>;
#declare P100  = Scale*<-0.018478,0.083351,0.90431>;
#declare P101  = Scale*<-0.018737,0.084798,0.9142>;
#declare P102  = Scale*<-0.018994,0.086246,0.92409>;
#declare P103  = Scale*<-0.01925,0.087695,0.93398>;
#declare P104  = Scale*<-0.019505,0.089144,0.94387>;
#declare P105  = Scale*<-0.019758,0.090594,0.95376>;
#declare P106  = Scale*<-0.020011,0.092044,0.96365>;
#declare P107  = Scale*<-0.020264,0.093495,0.97354>;
#declare P108  = Scale*<-0.020516,0.094945,0.98344>;
#declare P109  = Scale*<-0.020767,0.096396,0.99333>;

union {

    cylinder{

             <0,-100,0>,
             <0,100,0>,
             0.1
             texture { pigment {Red} }


             }


    cylinder{

             <-100,0,0>,
             <100,0,0>,
             0.1
             texture { pigment {Green} }


             }




    cylinder{

             <0,0,-100>,
             <0,0,100>,
             0.1
             texture { pigment {Blue} }


             }


    sphere_sweep {
                    b_spline,
                    109
                    P1,Radius,
                    P2,Radius,
                    P3,Radius,
                    P4,Radius,
                    P5,Radius,
                    P6,Radius,
                    P7,Radius,
                    P8,Radius,
                    P9,Radius,
                    P10,Radius,
                    P11,Radius,
                    P12,Radius,
                    P13,Radius,
                    P14,Radius,
                    P15,Radius,
                    P16,Radius,
                    P17,Radius,
                    P18,Radius,
                    P19,Radius,
                    P20,Radius,
                    P21,Radius,
                    P22,Radius,
                    P23,Radius,
                    P24,Radius,
                    P25,Radius,
                    P26,Radius,
                    P27,Radius,
                    P28,Radius,
                    P29,Radius,
                    P30,Radius,
                    P31,Radius,
                    P32,Radius,
                    P33,Radius,
                    P34,Radius,
                    P35,Radius,
                    P36,Radius,
                    P37,Radius,
                    P38,Radius,
                    P39,Radius,
                    P40,Radius,
                    P41,Radius,
                    P42,Radius,
                    P43,Radius,
                    P44,Radius,
                    P45,Radius,
                    P46,Radius,
                    P47,Radius,
                    P48,Radius,
                    P49,Radius,
                    P50,Radius,
                    P51,Radius,
                    P52,Radius,
                    P53,Radius,
                    P54,Radius,
                    P55,Radius,
                    P56,Radius,
                    P57,Radius,
                    P58,Radius,
                    P59,Radius,
                    P60,Radius,
                    P61,Radius,
                    P62,Radius,
                    P63,Radius,
                    P64,Radius,
                    P65,Radius,
                    P66,Radius,
                    P67,Radius,
                    P68,Radius,
                    P69,Radius,
                    P70,Radius,
                    P71,Radius,
                    P72,Radius,
                    P73,Radius,
                    P74,Radius,
                    P75,Radius,
                    P76,Radius,
                    P77,Radius,
                    P78,Radius,
                    P79,Radius,
                    P80,Radius,
                    P81,Radius,
                    P82,Radius,
                    P83,Radius,
                    P84,Radius,
                    P85,Radius,
                    P86,Radius,
                    P87,Radius,
                    P88,Radius,
                    P89,Radius,
                    P90,Radius,
                    P91,Radius,
                    P92,Radius,
                    P93,Radius,
                    P94,Radius,
                    P95,Radius,
                    P96,Radius,
                    P97,Radius,
                    P98,Radius,
                    P99,Radius,
                    P100,Radius,
                    P101,Radius,
                    P102,Radius,
                    P103,Radius,
                    P104,Radius,
                    P105,Radius,
                    P106,Radius,
                    P107,Radius,
                    P108,Radius,
                    P109,Radius

                  tolerance 0.1
                  texture{ pigment{ color rgb<0.69,0.99,0.15>}
      finish { phong 1
       ambient 0.3
     }
     }

     }
      rotate -90*x
      rotate 150*y

     translate -20*y


}// end of union

[Aj] Inverse Kinematics neck (ot IKN) macro [1301 days 5 hours and 25 minutes ago]

Mon, 19 Sep 2022 17:35:00 GMT

Hello everyone,

I was wondering if there is a tutorial for the macro mentioned in the subject.
I looked up and could not find any. Any recommendations or suggestions on how to
create a spline passing through 6 points using this macro would be really
helpful.

Thank you.

[ingo] Re: Length of spline object changes during anima... [1301 days 9 hours and 45 minutes ago]

Mon, 19 Sep 2022 13:15:00 GMT

"Aj" <nomail@nomail> wrote:

> So basically the < x, y, z > coordinates are coming from a numerically simulated
> soft robot and the entire shape of the robot changes over time. So I was trying
> to create a spline through these points that move in the 3d space. I agree that
> the splines will be of different lengths depending on the location of control
> points but this is what I am trying to fix. As the spline represents a soft
> robot that is capable of only changing its shape keeping the length constant.
> I hope this clears some of your doubts.

A possible way is to "resample" your found spline with n pieces of cylinder with
the same length. Think of a "swan neck" sphere-cylinder-sphere-cylinder-sphere
etc. All depends on the smoothness you strive for.

ingo

[Thomas de Groot] Re: Length of spline object changes during anima... [1301 days 10 hours and 47 minutes ago]

Mon, 19 Sep 2022 12:13:10 GMT

Op 19-9-2022 om 08:48 schreef Aj:
> A tutorial to the Inverse Kinematics Neck will be very helpful as I am still a
> beginner user.
> 

What you need can be found here:

https://runevision.com/3d/include/

-- 
Thomas

[Bald Eagle] Re: Length of spline object changes during anima... [1301 days 11 hours and 40 minutes ago]

Mon, 19 Sep 2022 11:20:00 GMT

"Aj" <nomail@nomail> wrote:

> Thank you for taking the time to go through the problem.
> So basically the < x, y, z > coordinates are coming from a numerically simulated
> soft robot and the entire shape of the robot changes over time. So I was trying
> to create a spline through these points that move in the 3d space. I agree that
> the splines will be of different lengths depending on the location of control
> points but this is what I am trying to fix. As the spline represents a soft
> robot that is capable of only changing its shape keeping the length constant.
> I hope this clears some of your doubts.

The problem here is that you need to be able to create a smooth spline that you
can calculate the length of.  And Cousin Ricky will tell you that calculating
the length of many mathematical curves with some sort of implicit or parametric
equation is - impossible.

What you'd probably need to do is find some numeric method to approximate the
length based on linear line segments (or just use a linear spline).  Then you'd
need a way to take the soft-robot control points and iteratively adjust their
positions so that they converge to a spline with a fixed length, while still
maintaining the overall correct pose of the character.

This is a raytracing forum, and the experience and expertise of the people here
is pretty random.
I would suggest that you take a good while to research approximating
curve/spline lengths, and contact people whose expertise this is.   There are
graduate students, engineers, professors, CG professionals, youtubers, bloggers,
and textbook authors who could give you advice and point you in the right
direction.

Try to find people who like a graphics or coding challenge.   Art of Code
(Martijn Steinrucker), Coding Train (Daniel Shiffman), Inigo Quilez (Shadertoy),
are all places I frequent to stretch my horizons and learn new and different
approaches to CG and coding problems.

Always look to see if anyone has already done this type of thing, albeit in a
different, seemingly unrelated field. You may find an academic paper, a textbook
chapter, a Graphics Gem article, or actual code posted on a website.   Don't aim
for perfect - you likely just need "good 'nuff".

[Aj] Re: Length of spline object changes during anima... [1301 days 16 hours and 10 minutes ago]

Mon, 19 Sep 2022 06:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Aj" <nomail@nomail> wrote:
> > I am pretty new to povray and I have the following code, ...
>
> as you're "new", I take the liberty of a couple of remarks regarding the code.
>
>
> > Here is my code:
>
> first off, it's good that you've posted an example, always helpful, I think.
>
> when rendering a scene, it pays to read povray's warnings (and pay heed ;-)).
> your code should have a '#version' (often the first instruction in the scene),
> and a 'global_settings' with 'assumed_gamma'.  the newer version also likes an
> 'emission 0' when you use 'ambient' in the finish.
>
> your 'union' is meant to include the sphere?  (the program warns about needing
> two or more objects)
>
> try to keep things .. simple, eg there are "better" places to apply the 'Scale',
> once.
>
> since you're dealing with collections/lists of points/coords, consider using one
> or more arrays to store those.  you could then, for instance, write a loop
> inside the 'sphere_sweep' declaration to "fill in" the points.  (less
> duplication and editing)
>
>
> > I have been trying to do something like shown in this video:
>
> nice.  hope the "Inverse Kinematics" AM pointed out will help to "get you
> there".
>
>
> regards, jr.

A tutorial to the Inverse Kinematics Neck will be very helpful as I am still a
beginner user.

[Aj] Re: Length of spline object changes during anima... [1301 days 16 hours and 50 minutes ago]

Mon, 19 Sep 2022 06:10:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Aj" <nomail@nomail> wrote:
> > Hello everyone,
> >
> > I am pretty new to povray and I have the following code, where I get the x,y,
> > and z coordinates of 6 different points from a simulation and then create a
> > sphere sweep through these points. But the problem is the length of this object
> > changes with time i.e. as the points move, the sphere sweep object appears to
> > change size. If you look at the picture attached then the white and green
> > objects appear to be of different lengths.
> >
> > Any suggestion will be really helpful.
>
>
> > I have been trying to do something like shown in this video:
> >
> > https://www.cosseratrods.org/videos/RALvideos/Case2-front_view_web.mp4
>
> So, without any real idea what's going on, an in the absence of any detailed
> explanation, I'll speculate that you're trying to model some kind of
> semi-flexible/stretchable filament that's supposed to move around based on some
> kind of movement of the endpoint, or a physical particle system (your
> "simulation").
>
> So,
>
> Either all of your <x, y, z> data is coming straight from the simulation, or
>
> You need to calculate the (approximate) length of your spline, and then after
> moving the control points, find some way to jimmy them so that you're preserving
> the overall length within some constraints as defined by the elasticity of the
> filament, etc. before rendering the next frame of the animation.   And that sure
> doesn't sound trivial.


Thank you for taking the time to go through the problem.
So basically the < x, y, z > coordinates are coming from a numerically simulated
soft robot and the entire shape of the robot changes over time. So I was trying
to create a spline through these points that move in the 3d space. I agree that
the splines will be of different lengths depending on the location of control
points but this is what I am trying to fix. As the spline represents a soft
robot that is capable of only changing its shape keeping the length constant.
I hope this clears some of your doubts.

[Thomas de Groot] Re: Length of spline object changes during anima... [1332 days 15 hours and 8 minutes ago]

Fri, 19 Aug 2022 07:52:07 GMT

Op 18-8-2022 om 19:18 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 17/08/2022 om 17:29 schreef Alain Martel:
>>> You should try the inverse kynetic neck (ot IKN) macro ...
>> I think that the macro mentioned here is by Rune Johansen, ...
> 
> ah, thanks.  I had assumed Alain meant ingo's work.  (I'm "too young" ;-) to
> remember that far back)  (serious website)
> 

<grin> Happily, I have a kind of database which 'remembers' for me.

-- 
Thomas

[jr] Re: Length of spline object changes during anima... [1333 days 5 hours and 40 minutes ago]

Thu, 18 Aug 2022 17:20:00 GMT

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 17/08/2022 om 17:29 schreef Alain Martel:
> > You should try the inverse kynetic neck (ot IKN) macro ...
> I think that the macro mentioned here is by Rune Johansen, ...

ah, thanks.  I had assumed Alain meant ingo's work.  (I'm "too young" ;-) to
remember that far back)  (serious website)

regards, jr.

[Thomas de Groot] Re: Length of spline object changes during anima... [1333 days 16 hours and 9 minutes ago]

Thu, 18 Aug 2022 06:50:52 GMT

As the mind appears to be sluggish today, I just remembered Tim Nikias' 
work:

https://www.nolights.de/downloads.html

Look for the Cubic Bezier-Spline section (but his other macros are worth 
investigating too, just out of curiosity).

-- 
Thomas

[Thomas de Groot] Re: Length of spline object changes during anima... [1333 days 16 hours and 32 minutes ago]

Thu, 18 Aug 2022 06:28:27 GMT

Op 17/08/2022 om 17:29 schreef Alain Martel:
> You should try the inverse kynetic neck (ot IKN) macro that was 
> published in one of the news groups. It takes two end points, a 
> stiffness parameter at both ends, a twist value at each end, and a total 
> length as input. It returns a spline of the correct length connecting 
> the end points, or an error message if the end points are to far apart.

I think that the macro mentioned here is by Rune Johansen, and can be 
found at this page:

https://runevision.com/3d/include/

-- 
Thomas

[jr] Re: Length of spline object changes during anima... [1334 days and 50 minutes ago]

Wed, 17 Aug 2022 22:10:00 GMT

hi,

"Aj" <nomail@nomail> wrote:
> I am pretty new to povray and I have the following code, ...

as you're "new", I take the liberty of a couple of remarks regarding the code.

> Here is my code:

first off, it's good that you've posted an example, always helpful, I think.

when rendering a scene, it pays to read povray's warnings (and pay heed ;-)).
your code should have a '#version' (often the first instruction in the scene),
and a 'global_settings' with 'assumed_gamma'.  the newer version also likes an
'emission 0' when you use 'ambient' in the finish.

your 'union' is meant to include the sphere?  (the program warns about needing
two or more objects)

try to keep things .. simple, eg there are "better" places to apply the 'Scale',
once.

since you're dealing with collections/lists of points/coords, consider using one
or more arrays to store those.  you could then, for instance, write a loop
inside the 'sphere_sweep' declaration to "fill in" the points.  (less
duplication and editing)

> I have been trying to do something like shown in this video:

nice.  hope the "Inverse Kinematics" AM pointed out will help to "get you
there".

regards, jr.

[Bald Eagle] Re: Length of spline object changes during anima... [1334 days 3 hours and 40 minutes ago]

Wed, 17 Aug 2022 19:20:00 GMT

"Aj" <nomail@nomail> wrote:
> Hello everyone,
>
> I am pretty new to povray and I have the following code, where I get the x,y,
> and z coordinates of 6 different points from a simulation and then create a
> sphere sweep through these points. But the problem is the length of this object
> changes with time i.e. as the points move, the sphere sweep object appears to
> change size. If you look at the picture attached then the white and green
> objects appear to be of different lengths.
>
> Any suggestion will be really helpful.

> I have been trying to do something like shown in this video:
>
> https://www.cosseratrods.org/videos/RALvideos/Case2-front_view_web.mp4

So, without any real idea what's going on, an in the absence of any detailed
explanation, I'll speculate that you're trying to model some kind of
semi-flexible/stretchable filament that's supposed to move around based on some
kind of movement of the endpoint, or a physical particle system (your
"simulation").

So,

Either all of your <x, y, z> data is coming straight from the simulation, or

You need to calculate the (approximate) length of your spline, and then after
moving the control points, find some way to jimmy them so that you're preserving
the overall length within some constraints as defined by the elasticity of the
filament, etc. before rendering the next frame of the animation.   And that sure
doesn't sound trivial.

[jr] Re: Length of spline object changes during anima... [1334 days 7 hours and 5 minutes ago]

Wed, 17 Aug 2022 15:55:00 GMT

hi,

Alain Martel <kua### [at] videotronca> wrote:
> Le 2022-08-17 à 10:37, Aj a écrit :
> > ...
> You should try the inverse kynetic neck (ot IKN) macro that was
> published in one of the news groups.

<http://news.povray.org/XnsA9BDC915FAF25seed7%40news.povray.org>


regards, jr.

[Alain Martel] Re: Length of spline object changes during anima... [1334 days 7 hours and 30 minutes ago]

Wed, 17 Aug 2022 15:30:00 GMT

Le 2022-08-17 Ã  10:37, Aj a Ã©critÂ :
> Hello everyone,
> 
> I am pretty new to povray and I have the following code, where I get the x,y,
> and z coordinates of 6 different points from a simulation and then create a
> sphere sweep through these points. But the problem is the length of this object
> changes with time i.e. as the points move, the sphere sweep object appears to
> change size. If you look at the picture attached then the white and green
> objects appear to be of different lengths.
> 
> Any suggestion will be really helpful.
> 

They appear to be of different length because they ARE of different length.

You should try the inverse kynetic neck (ot IKN) macro that was 
published in one of the news groups. It takes two end points, a 
stiffness parameter at both ends, a twist value at each end, and a total 
length as input. It returns a spline of the correct length connecting 
the end points, or an error message if the end points are to far apart.

[Aj] Length of spline object changes during animation [1334 days 8 hours and 20 minutes ago]

Wed, 17 Aug 2022 14:40:00 GMT

Hello everyone,

I am pretty new to povray and I have the following code, where I get the x,y,
and z coordinates of 6 different points from a simulation and then create a
sphere sweep through these points. But the problem is the length of this object
changes with time i.e. as the points move, the sphere sweep object appears to
change size. If you look at the picture attached then the white and green
objects appear to be of different lengths.

Any suggestion will be really helpful.

Here is my code:

"""
#include"colors.inc"
 camera {
  location <0,0,-1000>
  look_at <0,0,0>
   angle 22
  }
light_source { <100,100,-100>  color rgb<1,1,1> }
background {color rgb<0.0,0.0,0.0> }
#declare Scale = 3.11*< 4200,210,50 >;
#declare Radius = 10.9;
#declare P01 = Scale*<0,0,-14.2857>;
#declare P02 = Scale*<0,0,0.2>;
#declare P03 = Scale*<0,0,0.4>;
#declare P04 = Scale*<0,0,0.6>;
#declare P05 = Scale*<0,0,0.8>;
#declare P06 = Scale*<0,0,1>;
#declare Thing = union{




  sphere_sweep {
  b_spline
  6,
   P01,Radius,
   P02,Radius,
   P03,Radius,
   P04,Radius,
   P05,Radius,
   P06,Radius
  tolerance 0.1
  texture{ pigment{ color rgb<0.69,0.99,0.15>}
  finish { phong 1
   ambient 0.3
 }
 }


 }
rotate<-90,0,0>
}
 #declare Thing_max = max_extent(Thing);
 #declare Thing_min = min_extent(Thing);
 #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;
sphere{Thing_centre, 1.5 pigment{rgb<1,0,0>} rotate<0,360*clock,0>}


object{Thing rotate<0,360*clock,0>}



#declare Scale =  3.11*< 4200,210,2>;

#declare P001 = 3.11*< 4200,210,50>*<0,0,-20.2857>;
#declare P002 = Scale*<8.6101e-11,-9.0312e-10,0.2>;
#declare P003 = Scale*<0.0025215,-0.030611,0.39763>;
#declare P004 = Scale*<0.0025633,-0.079185,0.59164>;
#declare P005 = Scale*<-0.0050769,-0.14013,0.78198>;
#declare P006 = Scale*<-0.012717,-0.20107,0.97231>;
#declare Thing2 = sphere_sweep {




  b_spline
  6,
   P001,Radius,
   P002,Radius,
   P003,Radius,
   P004,Radius,
   P005,Radius,
   P006,Radius
  tolerance 0.1
  texture{ pigment{ color rgb<1,1,1>}
  finish { phong 1
   ambient 0.3
 }
 }


 }
object{Thing2 rotate<-90,0,0> translate <0,-3,0>}

"""


I have been trying to do something like shown in this video:

https://www.cosseratrods.org/videos/RALvideos/Case2-front_view_web.mp4

[Le Forgeron] Re: import point cloud data in POV-Ray [1336 days 7 hours and 29 minutes ago]

Mon, 15 Aug 2022 15:30:58 GMT

Le 15/08/2022 Ã  07:40, Tako a Ã©critÂ :
> I generated a dense point cloud data for the forest scenario(.las format), how
> can
> I import the point cloud data of the forest in POV-ray, or what type of object
> do I need to define the point cloud data as?
> 
> 

what do you want to visualize ?

Looking up for las format, I found lidar related data, is that correct ?

https://en.wikipedia.org/wiki/LAS_file_format


Which of the eleven point data format did you use ?

You are of course aware that the header of the file *does* scale and 
move the points ?

It's a binary format, not the best one to work with (first of all, 
endianess is not always the same everywhere)

Save some time, here are the 11 variants:


     0: Core-0. 20 bytes. Includes x,y,z values, intensity of pulse 
return, return identification, classification (see below), scan angle, 
and identifier for the source for this point data, if derived from an 
earlier dataset.
     1: Core-0 + GPS time
     2: Core-0 + three 16-bit color channels
     3: Core-0 + GPS time and three 16-bit color channels
     4: Type 1 + wave packets. Wave packets may be stored in the file or 
in an auxiliary file with the same name and extension .wdp.
     5: Type 3 + wave packets
     6: Core-6 (allowing more bits for return data, and making GPS time 
mandatory)
     7: Core-6 + three 16-bit color channels
     8: Type 7 + NIR (near infra-red) channel
     9: Core-6 + wave packets
     10: Type 9 + three color channels and NIR channel.

(from
https://www.loc.gov/preservation/digital/formats/fdd/fdd000418.shtml
)

[Tako] import point cloud data in POV-Ray [1336 days 17 hours and 15 minutes ago]

Mon, 15 Aug 2022 05:45:00 GMT

I generated a dense point cloud data for the forest scenario(.las format), how
can
I import the point cloud data of the forest in POV-ray, or what type of object
do I need to define the point cloud data as?

[kurtz le pirate] Re: conversion [1346 days 5 hours and 41 minutes ago]

Fri, 5 Aug 2022 17:19:32 GMT

On 03/08/2022 18:50, David Kraics wrote:
> How do I convert from the 255 scale rgb numbers to decimal numbers used by
> POV-Ray? Apparently dividing the number by 255 doesn't work.
> 

What do you mean by "number" ?

Alain answered precisely and we can add that :
if c = red 0..255 green 0..255 blue 0..255, then the division of c/255
will give well the color with the values between 0.0 and 1.0.

And "pigment { color c }" will be interpreted correctly by POVRay

-- 
Kurtz le pirate
Compagnie de la Banquise

[Alain Martel] Re: conversion [1347 days 11 hours and 45 minutes ago]

Thu, 4 Aug 2022 11:15:21 GMT

Le 2022-08-03 Ã  12:50, David Kraics a Ã©critÂ :
> How do I convert from the 255 scale rgb numbers to decimal numbers used by
> POV-Ray? Apparently dividing the number by 255 doesn't work.
> 

Normally, 0..255 scale rgb values are in the sRGB space.
To use them, you need to do this :
1) In the global_settings block, set assumed_gamma 1
2) In your pigment, use srgb instead of just rgb.

When you use rgb, POV-Ray use linear range.
When you use srgb, POV-Ray use the sRGB tranfert formula to convert the 
non-linear ranges of the sRGB colour space into the linear range of the 
rgb colour space.

The format is :

pigment{ srgb sRGB_Colour/255 }

[David Kraics] conversion [1348 days 6 hours and 5 minutes ago]

Wed, 3 Aug 2022 16:55:00 GMT

How do I convert from the 255 scale rgb numbers to decimal numbers used by
POV-Ray? Apparently dividing the number by 255 doesn't work.

[Aj] Re: Camera position for spline object [1363 days 4 hours and 40 minutes ago]

Tue, 19 Jul 2022 18:20:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> On 23/05/2022 1:08 am, Aj wrote:
> > Hello everyone,
> >
> > I created a spline object using the following code, but I could not get the
> > proper camera position. I was wondering if there is some systematic way to
> > figure out the camera position, and angle and look at vectors for a given shape.
> > Or is it just trial and error? Can someone please help me to get the proper
> > camera setup so as to obtain the figure attached:
> >
> >
>
> The points in your sphere_sweep don't plot the figure in the screen
> shot, the points form a more or less straight line in the z direction.
> (1.png) (Points 5 & 6 are the same.)
>
> Looking again at the screen shot, I notice that the 3 axes are at
> different scales. If I apply scaling and rotation to the points I can
> get something like your figure. Scale = <200,10,1> rotate<0,90,0> (2.png)
>
> Note that I have moved the camera to <0,0,-200>, looking at <0,0,0>. I
> find it easier to keep track of x,y,z if the camera is in the minus z
> position.
>
> If you want a point for the camera to look at, you can find the mean
> center of your plot thus:
>
>   #declare Thing_max = max_extent(Thing);
>   #declare Thing_min = min_extent(Thing);
>   #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;
>
> (Red sphere)
>
> ---------------------------------------------------------------
> #include"colors.inc"
>   camera {
>      //location <-0.0872 , -1.8850 ,   4.8301 >*3.5
>      location <0,0,-200>
>      look_at <0,0,0>
>      angle 22
>      }
>
>
> light_source { <100,100,-100>  color rgb<1,1,1> }
>
> background {color rgb<0.5,0.5,0.5> }
>
> #declare Scale = <200,10,1>;
> //#declare Scale = <1,1,1>;
>
> #declare P01 = Scale*< 0,         0,         -20>;
> #declare P02 = Scale*< 2.583e-09,-2.7093e-08, 3>;
> #declare P03 = Scale*< 0.075646, -0.91834,    8.9288>;
> #declare P04 = Scale*< 0.076898, -2.3756,    14.7492>;
> #declare P05 = Scale*<-0.15231,  -4.2038,    20.4593>;
> #declare P06 = Scale*<-0.15231,  -4.2038,    20.4593>;
>
> #declare Thing = union{
>
>      sphere{P01 0.9 pigment{rgb<0,1,0>}}
>      sphere{P02 0.9 pigment{rgb<0,1,0>}}
>      sphere{P03 0.9 pigment{rgb<0,1,0>}}
>      sphere{P04 0.9 pigment{rgb<0,1,0>}}
>      sphere{P05 0.9 pigment{rgb<0,1,0>}}
>      sphere{P06 0.5 pigment{rgb<0,1,0>}}
>
>
>          sphere_sweep {
>           //b_spline
>           linear_spline
>           6,
>               P01,0.5,
>               P02,0.5,
>               P03,0.5,
>               P04,0.5,
>               P05,0.5,
>               P06,0.5
>           tolerance 0.1
>           texture{ pigment{ color rgb<0.69,0.99,0.15>}
>            finish { phong 1
>             ambient 0.3
>           }
>           }
>           //scale<2,2,0.35>   rotate<-90,0,0>  translate<0,-2,3>
>
>          }
>
>
>
> //rotate<0,90,0>
> rotate<-90,0,0>
> }
>
>
>   #declare Thing_max = max_extent(Thing);
>   #declare Thing_min = min_extent(Thing);
>   #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;
>
> sphere{Thing_centre, 1.5 pigment{rgb<1,0,0>} rotate<0,360*clock,0>}
>
> //box{Thing_min, Thing_max pigment{rgbt<1,0,0,0.8>}
> rotate<0,360*clock,0>}
>
> object{Thing rotate<0,360*clock,0>}

Thank you so much for the help and really sorry I was not able to reply to
everyone as I met with an accident and now I am fit to work. So, I made the
changes in my code and got the following results( please refer to the picture
attached ). So if you see the green object appears to be smaller in length
compared to the white object. Is there a way to restrict the length of the
spline object such that it does not change when the control points move and only
the curvature changes?
To make more sense of what I mean by that, please refer to the website :
https://www.cosseratrods.org/videos/RALvideos/Case2-front_view_web.mp4

[Aj] Re: Camera position for spline object [1412 days 13 hours and 45 minutes ago]

Tue, 31 May 2022 09:15:00 GMT

Thank you so much for the help, I really appreciate it. The idea is to create a
smooth curve passing  through the 6 control points. The screenshot that I posted
was a 3d plot obtained using matlab.Now all I need is to shit the the first
point in the negative z direction so that upper half doesn't look larger than
the upper half.
A better version of what I am trying to do can be found in this video.

https://www.cosseratrods.org/videos/RALvideos/Case2-front_view_web.mp4

I have a small favor to ask. any advice on how to make this close to the model
in the video would be great.

Thank you once again.








"m@b" <sai### [at] googlemailcom> wrote:
> On 23/05/2022 1:08 am, Aj wrote:
> > Hello everyone,
> >
> > I created a spline object using the following code, but I could not get the
> > proper camera position. I was wondering if there is some systematic way to
> > figure out the camera position, and angle and look at vectors for a given shape.
> > Or is it just trial and error? Can someone please help me to get the proper
> > camera setup so as to obtain the figure attached:
> >
> >
>
> The points in your sphere_sweep don't plot the figure in the screen
> shot, the points form a more or less straight line in the z direction.
> (1.png) (Points 5 & 6 are the same.)
>
> Looking again at the screen shot, I notice that the 3 axes are at
> different scales. If I apply scaling and rotation to the points I can
> get something like your figure. Scale = <200,10,1> rotate<0,90,0> (2.png)
>
> Note that I have moved the camera to <0,0,-200>, looking at <0,0,0>. I
> find it easier to keep track of x,y,z if the camera is in the minus z
> position.
>
> If you want a point for the camera to look at, you can find the mean
> center of your plot thus:
>
>   #declare Thing_max = max_extent(Thing);
>   #declare Thing_min = min_extent(Thing);
>   #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;
>
> (Red sphere)
>
> ---------------------------------------------------------------
> #include"colors.inc"
>   camera {
>      //location <-0.0872 , -1.8850 ,   4.8301 >*3.5
>      location <0,0,-200>
>      look_at <0,0,0>
>      angle 22
>      }
>
>
> light_source { <100,100,-100>  color rgb<1,1,1> }
>
> background {color rgb<0.5,0.5,0.5> }
>
> #declare Scale = <200,10,1>;
> //#declare Scale = <1,1,1>;
>
> #declare P01 = Scale*< 0,         0,         -20>;
> #declare P02 = Scale*< 2.583e-09,-2.7093e-08, 3>;
> #declare P03 = Scale*< 0.075646, -0.91834,    8.9288>;
> #declare P04 = Scale*< 0.076898, -2.3756,    14.7492>;
> #declare P05 = Scale*<-0.15231,  -4.2038,    20.4593>;
> #declare P06 = Scale*<-0.15231,  -4.2038,    20.4593>;
>
> #declare Thing = union{
>
>      sphere{P01 0.9 pigment{rgb<0,1,0>}}
>      sphere{P02 0.9 pigment{rgb<0,1,0>}}
>      sphere{P03 0.9 pigment{rgb<0,1,0>}}
>      sphere{P04 0.9 pigment{rgb<0,1,0>}}
>      sphere{P05 0.9 pigment{rgb<0,1,0>}}
>      sphere{P06 0.5 pigment{rgb<0,1,0>}}
>
>
>          sphere_sweep {
>           //b_spline
>           linear_spline
>           6,
>               P01,0.5,
>               P02,0.5,
>               P03,0.5,
>               P04,0.5,
>               P05,0.5,
>               P06,0.5
>           tolerance 0.1
>           texture{ pigment{ color rgb<0.69,0.99,0.15>}
>            finish { phong 1
>             ambient 0.3
>           }
>           }
>           //scale<2,2,0.35>   rotate<-90,0,0>  translate<0,-2,3>
>
>          }
>
>
>
> //rotate<0,90,0>
> rotate<-90,0,0>
> }
>
>
>   #declare Thing_max = max_extent(Thing);
>   #declare Thing_min = min_extent(Thing);
>   #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;
>
> sphere{Thing_centre, 1.5 pigment{rgb<1,0,0>} rotate<0,360*clock,0>}
>
> //box{Thing_min, Thing_max pigment{rgbt<1,0,0,0.8>}
> rotate<0,360*clock,0>}
>
> object{Thing rotate<0,360*clock,0>}

[Tor Olav Kristensen] Re: Camera position for spline object [1415 days 3 hours and 5 minutes ago]

Sat, 28 May 2022 19:55:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2022-05-26 10:17 (-4), Tor Olav Kristensen wrote:
> >
> > But I'm now wondering if the original poster used another spline type in the
> > other tool. The spline type in the POV-Ray code is "b_spline". But I've not been
> > able to find out what spline type that is supposed to be. I very much doubt that
> > it is the B-splines described here:
> >
> > https://en.wikipedia.org/wiki/B-spline
> >
> > Perhaps the b stands for Bezier (?) Maybe someone can verify this...
>
> POV-Ray's b_spline is indeed a 3rd degree B-spline.  I verified this a
> few years ago by plotting points derived by de Boor's algorithm against
> a POV-Ray b_spline.

Ok. I did the same test as you. It seems to be b-splines with a closed knot
vector. Their order is 4, i.e. 3rd degree (as you found) plus 1.


> I have a very poor understanding of what is going
> on mathematically, but I do know that b_spline is not a Bezier curve.

As Bill mentioned; B-spline curves are a superset of Bezier curves.


> I found the Wikipedia article quite confusing, especially since all of
> the illustrations have the curves intersecting the endpoints, yet de
> Boor's algorithm, which the article links to, does not produce this
> result.  I know that Bezier curves are related to B-splines, but I
> haven't figured out how.

To make B-splines intersect the endpoints, you can use open knot vectors.

Alternatively you can repeat the endpoints. To see how to do this,
have a look at the source code below and the attached image.

The file NURBS_29.inc in below can be found here:
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.4c327e199f459e99c734aecd0%40news.povray.org%3E/


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

global_settings { assumed_gamma 1.0 }

#include "colors.inc"
#include "NURBS_29.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

default {
    texture {
        pigment { color White }
        finish {
            diffuse 0
            emission color White
        }
    }
}

background { color Gray10 }

camera {
    orthographic
    location -5*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare Size = 7;

#declare PP =
    array[Size] {
        <-3, +2,  0>, // 0
        <-3, -1,  0>, // 1
        <-1, -2,  0>, // 2
        <-1, +2,  0>, // 3
        <+1, +2,  0>, // 4
        <+2, -2,  0>, // 5
        <+3,  0,  0>  // 6
    }
;

#declare Radius = 0.01;

union {
    ShowPoints1A3D(
        PP,  // Points1A3D
        false, // WrapU
        6*Radius  // Radius
    )
    pigment { color Gray40 }
    translate +5*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Uniform B-Spline of order 4 with closed knot vector

sphere_sweep {
    b_spline
    Size,
    #for (I, 0, Size - 1)
        PP[I], 8*Radius
    #end // for
    tolerance 0.1
    pigment { color Cyan }
    translate +4*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare Order = 4;
#declare Open = false;

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// The circumstantial way

#macro B_Spline_Function1A(OrderU, KnotsU, Values1A)

    #local SizeU = Size1A(Values1A);
    #local BlendU_Fns = BlendFunctions(SizeU, OrderU, KnotsU);

    function(_t) {
        0
        #for (I, 0, SizeU - 1)
            #local C = Values1A[I];
            #switch (C)
                #case (-1)
                    -BlendU_Fns[I](_t)
                    #break
                #case (0)
                    #break
                #case (+1)
                    +BlendU_Fns[I](_t)
                    #break
                #else
                    +BlendU_Fns[I](_t)*C
            #end // switch
        #end // for
    }

#end // macro B_Spline_Function1A


#declare KK =
    UniformKnotVector(
        Open,  // Open
        Order,  // Order
        Size  // NrOfPoints
    )
;
// Closed: { -3/4,-2/4,-1/4, 0/4, 1/4, 2/4, 3/4, 4/4, 5/4, 6/4, 7/4 }
// Open:   {  0/4, 0/4, 0/4, 0/4, 1/4, 2/4, 3/4, 4/4, 4/4, 4/4, 4/4 }

#declare PPx = ExtractComponent1A(PP, x);
#declare PPy = ExtractComponent1A(PP, y);
#declare PPz = ExtractComponent1A(PP, z);

#declare B_Spline_FnX =
    B_Spline_Function1A(
        Order,  // OrderU
        KK,  // KnotsU
        PPx  // Values1A
    )
;
#declare B_Spline_FnY =
    B_Spline_Function1A(
        Order,  // OrderU
        KK,  // KnotsU
        PPy  // Values1A
    )
;
#declare B_Spline_FnZ =
    B_Spline_Function1A(
        Order,  // OrderU
        KK,  // KnotsU
        PPz  // Values1A
    )
;

union {
    ShowFunctions1A3D(
        B_Spline_FnX,  // xFn
        B_Spline_FnY,  // yFn
        B_Spline_FnZ,  // zFn
        false,  // WrapU
        0, // MinU
        1, // MaxU
        200,  // ResU
        6*Radius  // Radius
    )
    pigment { color Blue }
    translate +3*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Alternative way,
// but now with 2 repeated points in both the beginning and the end.

#declare NewSize = Size + 4;

#declare QQ =
    array[NewSize] {
        PP[0], //  0
        PP[0], //  1

        PP[0], //  2
        PP[1], //  3
        PP[2], //  4
        PP[3], //  5
        PP[4], //  6
        PP[5], //  7
        PP[6], //  8

        PP[6], //  9
        PP[6]  // 10
    }
;

// Uniform B-Spline
union {
    Show_UBS_1A3D(
        QQ,  // Points1A3D
        Open,  // OpenU
        Order,  // OrderU
        false,  // WrapU
        200,  // ResU
        2*Radius  // Radius
    )
    pigment { color Red }
    translate +1*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Now check if also the built in B-spline sphere sweep can be
// tricked into reaching the points in the beginning and the end.

sphere_sweep {
    b_spline
    NewSize,
    #for (I, 0, NewSize - 1)
        QQ[I], 4*Radius
    #end // for
    tolerance 0.1
    pigment { color Green }
    translate +2*z
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7


--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: Camera position for spline object [1416 days 21 hours and 40 minutes ago]

Fri, 27 May 2022 01:20:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> POV-Ray's b_spline is indeed a 3rd degree B-spline.  I verified this a
> few years ago by plotting points derived by de Boor's algorithm against
> a POV-Ray b_spline.  I have a very poor understanding of what is going
> on mathematically, but I do know that b_spline is not a Bezier curve.

It is not, necessarily, but I believe that all Bezier curves are b-splines.

> I found the Wikipedia article quite confusing, especially since all of
> the illustrations have the curves intersecting the endpoints, yet de
> Boor's algorithm, which the article links to, does not produce this
> result.  I know that Bezier curves are related to B-splines, but I
> haven't figured out how.

Yeah, you have to get into the details and have them fresh in your mind to have
most of the articles that purport to "explain" the difference to make any sense.
 It's more that they describe them - in the way the POV-Ray documentation
"explains" things.   It's a lot clearer and makes more sense if you already know
the answers...  :D

Try:
https://opensourc.es/blog/b-spline/

And also, I believe that The NURBS Book has a pretty comprehensive explanation
of what all the various splines types are that lead up to the development of
NURBS - Non Uniform Rational B-Splines.

IIRC, the key points have to due with multiplicity of knot vectors, and a lot
more localized influence of any given knot on the shape of the overall curve.

[Robert McGregor] Re: Camera position for spline object [1417 days 1 hour and 30 minutes ago]

Thu, 26 May 2022 21:30:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:

> I found the Wikipedia article quite confusing, especially since all of
> the illustrations have the curves intersecting the endpoints, yet de
> Boor's algorithm, which the article links to, does not produce this
> result.  I know that Bezier curves are related to B-splines, but I
> haven't figured out how.

This is very helpful, IMHO:

https://www.geeksforgeeks.org/difference-between-spline-b-spline-and-bezier-curves/

[Cousin Ricky] Re: Camera position for spline object [1417 days 7 hours and 22 minutes ago]

Thu, 26 May 2022 15:37:44 GMT

On 2022-05-26 10:17 (-4), Tor Olav Kristensen wrote:
> 
> But I'm now wondering if the original poster used another spline type in the
> other tool. The spline type in the POV-Ray code is "b_spline". But I've not been
> able to find out what spline type that is supposed to be. I very much doubt that
> it is the B-splines described here:
> 
> https://en.wikipedia.org/wiki/B-spline
> 
> Perhaps the b stands for Bezier (?) Maybe someone can verify this...

POV-Ray's b_spline is indeed a 3rd degree B-spline.  I verified this a
few years ago by plotting points derived by de Boor's algorithm against
a POV-Ray b_spline.  I have a very poor understanding of what is going
on mathematically, but I do know that b_spline is not a Bezier curve.

I found the Wikipedia article quite confusing, especially since all of
the illustrations have the curves intersecting the endpoints, yet de
Boor's algorithm, which the article links to, does not produce this
result.  I know that Bezier curves are related to B-splines, but I
haven't figured out how.

[Tor Olav Kristensen] Re: Camera position for spline object [1417 days 8 hours and 40 minutes ago]

Thu, 26 May 2022 14:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>
> > Hehe, there you tempted me to have a look at this.
> >
> > I opened the screenshot in gimp and copied the 3 axes around to check if the
> > camera used could be a orthographic camera. It seems so.
>
> Ah. It didn't seem to be a purely perspective view, but it was early and I was
> heading out.  It certainly had that "view-camera corrected film-plane" look, if
> you know what I mean.
>
> Perhaps some of the work done with Norbert Kern's 'Position-Finder' tool could
> be used to back-calculate points for the spline to get something that more
> closely resembles the posted 3rd-party software graphic.

I've now hat a look at his macro. It seems that what it could be used for in
this case, is to calculate the coordinates of the corners of the box projected
onto a plane.

But the same could be achieved with less work by loading the image into e.g.
Gimp and then finding the coordinates of the corners within the cameras view
plane.

From these coordinates, it may be possible to solve several equations with
several unknowns to find the possible camera vectors.

> .... or the original data set could be posted.   ;)

Yes.
But I'm now wondering if the original poster used another spline type in the
other tool. The spline type in the POV-Ray code is "b_spline". But I've not been
able to find out what spline type that is supposed to be. I very much doubt that
it is the B-splines described here:

https://en.wikipedia.org/wiki/B-spline

Perhaps the b stands for Bezier (?) Maybe someone can verify this...

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: Camera position for spline object [1420 days 3 hours and 50 minutes ago]

Mon, 23 May 2022 19:10:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> Hehe, there you tempted me to have a look at this.
>
> I opened the screenshot in gimp and copied the 3 axes around to check if the
> camera used could be a orthographic camera. It seems so.

Ah. It didn't seem to be a purely perspective view, but it was early and I was
heading out.  It certainly had that "view-camera corrected film-plane" look, if
you know what I mean.

Perhaps some of the work done with Norbert Kern's 'Position-Finder' tool could
be used to back-calculate points for the spline to get something that more
closely resembles the posted 3rd-party software graphic.

.... or the original data set could be posted.   ;)

[Tor Olav Kristensen] Re: Camera position for spline object [1420 days 5 hours and 35 minutes ago]

Mon, 23 May 2022 17:25:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
.....
> And here's some code ;-)
.....

Here's an image rendered with that code.

Btw.
I reached the same conclusion as m@b:
The posted spline code does not generate a spline with the same shape as the one
that is shown in the original screenshot.

Also, it does not fit inside the "wireframe" box in the attached image.

Further, the image is cropped a bit too tight:
On one of the axes we can see that there is a 10^-3 axis multiplier, but it is
not possible to see if this also applies to the other 2 axes.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Tor Olav Kristensen] Re: Camera position for spline object [1420 days 5 hours and 55 minutes ago]

Mon, 23 May 2022 17:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Aj" <nomail@nomail> wrote:
> > Hello everyone,
> >
> > I created a spline object using the following code, but I could not get the
> > proper camera position. I was wondering if there is some systematic way to
> > figure out the camera position, and angle and look at vectors for a given shape.
>
> Yours might be easier, given that you have the grid locations on axes to guide
> you.
>
> Try imagining how the image you posted could be rotated in reverse to straighten
> the axes in the camera frustrum, and use those transforms on the object.
> The actual camera position might be a bit of trial and error to get exactly
> right.
>
> The look_at position might be obtained by extrapolating the x/z grid ticks and
> applying that inverse rotate transform.
>
> Maybe Francois LeCoat has a clever solution, as this seems right up his alley,
> or TOK has some words/code lines of wisdom to offer.

Hehe, there you tempted me to have a look at this.

I opened the screenshot in gimp and copied the 3 axes around to check if the
camera used could be a orthographic camera. It seems so.

See the attached image.

And here's some code ;-)

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
// Render options: +w640 +h480 +a0.3

#version 3.7;

global_settings { assumed_gamma 1.0 }

#include "colors.inc"

default {
    texture {
        pigment { color White }
        finish {
            diffuse 0
            emission color White
        }
    }
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

// Extreme values on the axes
#declare XN0 = -14.00; // *1e-3
#declare XP0 =  +4.00; // *1e-3
#declare YN0 =   0.00; // *1e-3 ?
#declare YP0 =  +1.00; // *1e-3 ?
#declare ZN0 =  -0.25; // *1e-3 ?
#declare ZP0 =  +0.05; // *1e-3 ?

// Divisions on the axes
#declare DivX0 = 2.00; // *1e-3
#declare DivY0 = 0.20; // *1e-3 ?
#declare DivZ0 = 0.05; // *1e-3 ?

// Number of divisions from the center of
// each axis to the axis endpoints
#declare XN1 =  -4.5;
#declare XP1 =  +4.5;
#declare YN1 =  -2.5;
#declare YP1 =  +2.5;
#declare ZN1 =  -3.0;
#declare ZP1 =  +3.0;

// These were found by trail and error
#declare ScaleX = 1.10;
#declare ScaleY = 0.96;
#declare ScaleZ = 1.64;

#declare FnX =
    function(x) {
        ScaleX*(XN1 + (x - XN0)/(XP0 - XN0)*(XP1 - XN1))
    }
;
#declare FnY =
    function(y) {
        ScaleY*(YN1 + (y - YN0)/(YP0 - YN0)*(YP1 - YN1))
    }
;
#declare FnZ =
    function(z) {
        ScaleZ*(ZN1 + (z - ZN0)/(ZP0 - ZN0)*(ZP1 - ZN1))
    }
;

#declare XN2 =  FnX(XN0);
#declare XP2 =  FnX(XP0);
#declare YN2 =  FnY(YN0);
#declare YP2 =  FnY(YP0);
#declare ZN2 =  FnZ(ZN0);
#declare ZP2 =  FnZ(ZP0);

#declare pNNN = <XN2, YN2, ZN2>;
#declare pPNN = <XP2, YN2, ZN2>;
#declare pPNP = <XP2, YN2, ZP2>;
#declare pNNP = <XN2, YN2, ZP2>;
#declare pNPN = <XN2, YP2, ZN2>;
#declare pPPN = <XP2, YP2, ZN2>;
#declare pPPP = <XP2, YP2, ZP2>;
#declare pNPP = <XN2, YP2, ZP2>;

#declare CylinderRadius = 0.02;

union {
    union {
        cylinder { pNNN, pPNN, CylinderRadius }
        cylinder { pNNP, pPNP, CylinderRadius }
        cylinder { pNPN, pPPN, CylinderRadius }
        cylinder { pNPP, pPPP, CylinderRadius }
        pigment { color Red }
    }
    union {
        cylinder { pNNN, pNPN, CylinderRadius }
        cylinder { pPNN, pPPN, CylinderRadius }
        cylinder { pPNP, pPPP, CylinderRadius }
        cylinder { pNNP, pNPP, CylinderRadius }
        pigment { color Green }
    }
    union {
        cylinder { pPNN, pPNP, CylinderRadius }
        cylinder { pNNN, pNNP, CylinderRadius }
        cylinder { pPPN, pPPP, CylinderRadius }
        cylinder { pNPN, pNPP, CylinderRadius }
        pigment { color Blue }
    }
}

#declare TickRadius = 2*CylinderRadius;

#declare TicksX =
    union {
        #for (X, XN0 + DivX0, XP0 - DivX0, DivX0)
            sphere { FnX(X)*x, TickRadius }
        #end // for
    }
#declare TicksY =
    union {
        #for (Y, YN0 + DivY0, YP0 - DivY0, DivY0)
            sphere { FnY(Y)*y, TickRadius }
        #end // for
    }
#declare TicksZ =
    union {
        #for (Z, ZN0 + DivZ0, ZP0 - DivZ0, DivZ0)
            sphere { FnZ(Z)*z, TickRadius }
        #end // for
    }

union {
    object {
        TicksX
        translate <0, YN2, ZN2>
    }
    object {
        TicksX
        translate <0, YP2, ZN2>
    }
    object {
        TicksX
        translate <0, YP2, ZP2>
    }
    object {
        TicksX
        translate <0, YN2, ZP2>
    }
    pigment { color White }
}

union {
    object {
        TicksY
        translate <XN2, 0, ZN2>
    }
    object {
        TicksY
        translate <XP2, 0, ZN2>
    }
    object {
        TicksY
        translate <XP2, 0, ZP2>
    }
    object {
        TicksY
        translate <XN2, 0, ZP2>
    }
    pigment { color White }
}

union {
    object {
        TicksZ
        translate <XN2, YN2, 0>
    }
    object {
        TicksZ
        translate <XP2, YN2, 0>
    }
    object {
        TicksZ
        translate <XP2, YP2, 0>
    }
    object {
        TicksZ
        translate <XN2, YP2, 0>
    }
    pigment { color White }
}

#declare SphereRadius = 2*TickRadius;
union {
    sphere { pNNN, SphereRadius }
    sphere { pPNN, SphereRadius }
    sphere { pPNP, SphereRadius }
    sphere { pNNP, SphereRadius }
    sphere { pNPN, SphereRadius }
    sphere { pPPN, SphereRadius }
    sphere { pPPP, SphereRadius }
    sphere { pNPP, SphereRadius }
    pigment { color White }
}

background { color Gray20 }

camera {
    orthographic
    location <-10.8, +4.9, -14.0>*0.6 // Found by trail and error
    look_at < 0,  0,  0>

}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[m@b] Re: Camera position for spline object [1420 days 7 hours and 47 minutes ago]

Mon, 23 May 2022 15:13:21 GMT

On 23/05/2022 1:08 am, Aj wrote:
> Hello everyone,
> 
> I created a spline object using the following code, but I could not get the
> proper camera position. I was wondering if there is some systematic way to
> figure out the camera position, and angle and look at vectors for a given shape.
> Or is it just trial and error? Can someone please help me to get the proper
> camera setup so as to obtain the figure attached:
> 
> 

The points in your sphere_sweep don't plot the figure in the screen 
shot, the points form a more or less straight line in the z direction. 
(1.png) (Points 5 & 6 are the same.)

Looking again at the screen shot, I notice that the 3 axes are at 
different scales. If I apply scaling and rotation to the points I can 
get something like your figure. Scale = <200,10,1> rotate<0,90,0> (2.png)

Note that I have moved the camera to <0,0,-200>, looking at <0,0,0>. I 
find it easier to keep track of x,y,z if the camera is in the minus z 
position.

If you want a point for the camera to look at, you can find the mean 
center of your plot thus:

  #declare Thing_max = max_extent(Thing);
  #declare Thing_min = min_extent(Thing);
  #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;

(Red sphere)

---------------------------------------------------------------
#include"colors.inc"
  camera {
     //location <-0.0872 , -1.8850 ,   4.8301 >*3.5
     location <0,0,-200>
     look_at <0,0,0>
     angle 22
     }


light_source { <100,100,-100>  color rgb<1,1,1> }

background {color rgb<0.5,0.5,0.5> }

#declare Scale = <200,10,1>;
//#declare Scale = <1,1,1>;

#declare P01 = Scale*< 0,         0,         -20>;
#declare P02 = Scale*< 2.583e-09,-2.7093e-08, 3>;
#declare P03 = Scale*< 0.075646, -0.91834,    8.9288>;
#declare P04 = Scale*< 0.076898, -2.3756,    14.7492>;
#declare P05 = Scale*<-0.15231,  -4.2038,    20.4593>;
#declare P06 = Scale*<-0.15231,  -4.2038,    20.4593>;

#declare Thing = union{

     sphere{P01 0.9 pigment{rgb<0,1,0>}}
     sphere{P02 0.9 pigment{rgb<0,1,0>}}
     sphere{P03 0.9 pigment{rgb<0,1,0>}}
     sphere{P04 0.9 pigment{rgb<0,1,0>}}
     sphere{P05 0.9 pigment{rgb<0,1,0>}}
     sphere{P06 0.5 pigment{rgb<0,1,0>}}


         sphere_sweep {
          //b_spline
          linear_spline
          6,
              P01,0.5,
              P02,0.5,
              P03,0.5,
              P04,0.5,
              P05,0.5,
              P06,0.5
          tolerance 0.1
          texture{ pigment{ color rgb<0.69,0.99,0.15>}
           finish { phong 1
            ambient 0.3
          }
          }
          //scale<2,2,0.35>   rotate<-90,0,0>  translate<0,-2,3>

         }



//rotate<0,90,0>
rotate<-90,0,0>
}


  #declare Thing_max = max_extent(Thing);
  #declare Thing_min = min_extent(Thing);
  #declare Thing_centre = (max_extent(Thing) + min_extent(Thing))/2;

sphere{Thing_centre, 1.5 pigment{rgb<1,0,0>} rotate<0,360*clock,0>}

//box{Thing_min, Thing_max pigment{rgbt<1,0,0,0.8>}
rotate<0,360*clock,0>}

object{Thing rotate<0,360*clock,0>}

[Bald Eagle] Re: Camera position for spline object [1420 days 12 hours and 30 minutes ago]

Mon, 23 May 2022 10:30:00 GMT

"Aj" <nomail@nomail> wrote:
> Hello everyone,
>
> I created a spline object using the following code, but I could not get the
> proper camera position. I was wondering if there is some systematic way to
> figure out the camera position, and angle and look at vectors for a given shape.

Yours might be easier, given that you have the grid locations on axes to guide
you.

Try imagining how the image you posted could be rotated in reverse to straighten
the axes in the camera frustrum, and use those transforms on the object.
The actual camera position might be a bit of trial and error to get exactly
right.

The look_at position might be obtained by extrapolating the x/z grid ticks and
applying that inverse rotate transform.

Maybe Francois LeCoat has a clever solution, as this seems right up his alley,
or TOK has some words/code lines of wisdom to offer.

[Kenneth] Re: Camera position for spline object [1420 days 14 hours and 20 minutes ago]

Mon, 23 May 2022 08:40:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> Take a look at the 'Spline_Trans' macro in POV-ray's transforms.inc file, and
> the example camera scene called 'splinefollow.pov' in
> scenes/animations/splinefollow.
>

Sorry, I assumed that you wanted your camera to *follow* the spline shape,
during an animation. (I also forgot to mention that you would need to  #include
"transforms.inc" in your scene.)

[Kenneth] Re: Camera position for spline object [1420 days 14 hours and 30 minutes ago]

Mon, 23 May 2022 08:30:00 GMT

Take a look at the 'Spline_Trans' macro in POV-ray's transforms.inc file, and
the example camera scene called 'splinefollow.pov' in
scenes/animations/splinefollow.

The idea is that you pre-#declare your spline, stick that into the Spline_Trans
macro, then use the macro as your animated camera position. (No need to make an
actual spline object.) Here is the example as given in the 'splinefollow.pov'
scene file...

camera {
      location 0
      look_at z
      translate <0,0.4,0.4> // [probably optional]
      Spline_Trans (MySpline, clock*11, y, 0.5, 0.5)
   }

By the way, a spline's 'index list' is not confined to the range of 0.0-1.0
(although that's very convenient when using the 'clock' value for the animated
camera movement.)  For some scenes, I like to use frame_numbers for my spline
points instead, as it is more intuitive for me. For example, running a 200-frame
animation...

spline{
.....
1, <...>
37, <...>
135, <...>
200, <...>
}

Then the Spline_Trans macro would be used like this:
Spline_Trans (MySpline, frame_number, y, 0.5, 0.5)

[jr] Re: Camera position for spline object [1420 days 15 hours and 5 minutes ago]

Mon, 23 May 2022 07:55:00 GMT

hi,

"Aj" <nomail@nomail> wrote:
> Hello everyone,
>
> I created a spline object using the following code, but I could not get the
> proper camera position. I was wondering if there is some systematic way to
> figure out the camera position, and angle and look at vectors for a given shape.
> Or is it just trial and error?

the latter, I guess, based on knowledge of object's approximate location +
dimensions.  hope to find time to try your code, but for a simple, recent
animation I needed to move the camera back to accommodate the object growing
larger.  have a look at the camera in 'ulam2.pov' (at end of file), its location
is updated in every frame.  while different in detail, perhaps it can serve as
"food for thought".  hth.
<http://news.povray.org/povray.binaries.images/attachment/%3Cweb.6240f11b8a870000fc0c8de6cde94f1%40news.povray.org%3E/u
lam2.zip>

regards, jr.

[Aj] Camera position for spline object [1420 days 22 hours and 50 minutes ago]

Mon, 23 May 2022 00:10:00 GMT

Hello everyone,

I created a spline object using the following code, but I could not get the
proper camera position. I was wondering if there is some systematic way to
figure out the camera position, and angle and look at vectors for a given shape.
Or is it just trial and error? Can someone please help me to get the proper
camera setup so as to obtain the figure attached:


// code used


#include"colors.inc"
 camera {
location <-0.0872 , -1.8850 ,   4.8301 >*3.5
look_at <0,0,0> }
light_source {
<4,6,-10>
color rgb<1,1,1> }
background {
color rgb<0.5,0.5,0.5> }
sphere_sweep {
 b_spline
 6,
 <0,0,-20>,0.1,
 <2.583e-09,-2.7093e-08,3>,0.1,
 <0.075646,-0.91834,8.9288>,0.1,
 <0.076898,-2.3756,14.7492>,0.1,
 <-0.15231,-4.2038,20.4593>,0.1,
 <-0.15231,-4.2038,20.4593>,0.1
 tolerance 0.1
 texture{ pigment{ color rgb<0.69,0.99,0.15>}
  finish { phong 1
   ambient 0.3
 }
 }
 scale<2,2,0.35>   rotate<-90,0,0>  translate<0,-2,3>
 }

[Bald Eagle] Re: rendering images in reverse [1468 days 11 hours and 55 minutes ago]

Tue, 5 Apr 2022 11:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > instead of "right x" use "right -x" to reverse the camera view frustrum vector.
> >
>
> That is simple and elegant! And never occurred to me. It also works correctly
> even if the camera has an added 'rotation', like...
>
> camera {
>   perspective
>   location  <-.15, 1.48, -2>
>   look_at   <.35, 1.48,  0>
>   right     -x*image_width/image_height
>   angle 29
>   rotate 45*y
> }

Yeah, well, when I've screwed up the camera setup and/or position enough times,
I get to have a deeper appreciation of my little oopsies.  I've also had to
convert between the z-up and y-up vector spaces when modeling things, so that
"helped" too.  ;)

Playing with transforms and basis vectors let me sorta flesh all that out a bit.

Try:
up <1, 1, 0>

> ----
> I'm thinking that it would be nice to be able to render *both* standard and
> reversed views at the same time, side by side in the same image, but I have no
> idea how it could be done. I seem to recall that such a dual-camera(?) render
> may have been explained in an old newsgroup post... or maybe it's just my faulty
> old memory playing tricks on me...

That might have been a feature in Uberpov or Megapov ...

What I guess you could do is create a whole scene inside of a union:
#declare Scene = union {...}

And then do:
#declare Left  = object {Scene translate -x*VALUE}
#declare Right = object {Left scale <-1, 1, 1>}
object {Left}
object {Right}

To get both "views" in the same render.

[Kenneth] Re: rendering images in reverse [1469 days and 10 minutes ago]

Mon, 4 Apr 2022 22:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> instead of "right x" use "right -x" to reverse the camera view frustrum vector.
>

That is simple and elegant! And never occurred to me. It also works correctly
even if the camera has an added 'rotation', like...

camera {
  perspective
  location  <-.15, 1.48, -2>
  look_at   <.35, 1.48,  0>
  right     -x*image_width/image_height
  angle 29
  rotate 45*y
}

----
I'm thinking that it would be nice to be able to render *both* standard and
reversed views at the same time, side by side in the same image, but I have no
idea how it could be done. I seem to recall that such a dual-camera(?) render
may have been explained in an old newsgroup post... or maybe it's just my faulty
old memory playing tricks on me...

[Tor Olav Kristensen] Re: image_map to tilted and rotated triangle cen... [1470 days 22 hours and 10 minutes ago]

Sun, 3 Apr 2022 00:50:00 GMT

"Molly-J" <nomail@nomail> wrote:
> I am going mad trying to project image maps onto polygons that are not in the
> x-y plane or plumb to the y axis. I have 20 equilateral triangles forming a
> typical D20 shape (regular icosahedron). I have the XYZ coordinates for the
> points so all I have to do is create each triangle using sets of the 32
> vertices. BUT . . . .
>
> I cannot work out how to project the 20 image_map pigments properly. Image_map
> pigments only seem to work on polygons normal to the Z axis and left corner at
> 0,0 XY
>
> The suggestion that I create each triangle at 0,0 and then translate/rotate them
> to the icosahedron would be just fine if i had those numbers. (I do not)
>
> There must exist another way, as the current limitation is ludicrously
> un-useful. Everybody aplying pictures to polyhedra would have exactly the same
> problem.
> What am I missing?
>
> Is it possible to translate the triangle by translating its individual points?
> That I might be able to do, but I can't work out how.
>
>
> The ultimate goal is a Dymaxion type world map on an Icosahedron.

Hi again Molly

I've now made a couple of GitHub repositories that may be useful for you.

Here you can find the vertices and the triangles that you need:
https://github.com/t-o-k/POV-Ray-icosahedron

Here you can see how you can UV-map parts of an image onto a mesh2:
https://github.com/t-o-k/POV-Ray-UV-mapping-of-mesh2

And here you can download images suitable for being mapped onto an icosahedron:
https://solarviews.com/cap/ico/icoearth.htm

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: image_map to tilted and rotated triangle cen... [1473 days 4 hours and 35 minutes ago]

Thu, 31 Mar 2022 18:25:00 GMT

You might be able to use

f_th(x,y,z): f_th() is a function that is only useful when combined with other
surfaces. It produces a value which is equal to the theta angle, in radians, at
any point. The theta angle is like the longitude coordinate on the Earth. It
stays the same as you move north or south, but varies from east to west. Also
look at f_ph and f_r

and

f_ph(x,y,z): When used alone, the PH function gives a surface that consists of
all points that are at a particular latitude, i.e. a cone. If you use a
threshold of zero (the default) this gives a cone of width zero, which is
invisible. Also look at f_th and f_r

in Functions.inc

https://wiki.povray.org/content/Reference:Functions.inc

[jr] Re: image_map to tilted and rotated triangle cen... [1473 days 10 hours and 45 minutes ago]

Thu, 31 Mar 2022 12:15:00 GMT

hi,

"Molly-J" <nomail@nomail> wrote:
> ...
> Is there a povray function that returns polar coordinates of a surface's normal?
>
> eg. create a polygon my_polygon at xyz xyz xyz and then ask--
>
> let lat/lon = normal(my_polygon)

afaik, no.  (in fact, searching "polar" in the wiki only finds (fish-eye) camera
related mention)  however, if you have the maths, you can (and usually would, in
POV-Ray) write a macro[1], using 'trace()'[2] to find the surface normal, then
convert and return the (lat,lon).  Bald Eagle wrote some polar coord conversion
code[3], maybe it'll be of use to you.

[1]
<https://wiki.povray.org/content/Reference:User_Defined_Macros#The_macro_Directive>
[2] <https://wiki.povray.org/content/Reference:Vector_Expressions#Functions>
[3] <http://news.povray.org/web.58dc085aae95604bc437ac910%40news.povray.org>

regards, jr.

[m@b] Re: rendering images in reverse [1474 days 11 hours and 58 minutes ago]

Wed, 30 Mar 2022 11:02:10 GMT

On 30/03/2022 6:26 pm, Bald Eagle wrote:
> "Molly-J" <nomail@nomail> wrote:
>> I want povray to produce images in both correct and reversed aspect(mirror).
>> I thought I saw the keyword "invert" somewhere in the documentation but maybe it
>> was a dream. how can I reverse my output images or get my camera to behave like
>> a  mirror?
>>
>> Q) Why?
>> A) Because <REASONS>
> 
> suppose you want to reverse everything left-right.
> 
> instead of "right x" use "right -x" to reverse the camera view frustrum vector.
> 
> 
> https://wiki.povray.org/content/Reference:Camera
> 
> 

To mirror an object (with image map):  scale<1,1,-1>

m@

[Bald Eagle] Re: rendering images in reverse [1474 days 12 hours and 30 minutes ago]

Wed, 30 Mar 2022 10:30:00 GMT

"Molly-J" <nomail@nomail> wrote:
> I want povray to produce images in both correct and reversed aspect(mirror).
> I thought I saw the keyword "invert" somewhere in the documentation but maybe it
> was a dream. how can I reverse my output images or get my camera to behave like
> a  mirror?
>
> Q) Why?
> A) Because <REASONS>

suppose you want to reverse everything left-right.

instead of "right x" use "right -x" to reverse the camera view frustrum vector.


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

[Molly-J] rendering images in reverse [1474 days 18 hours and 45 minutes ago]

Wed, 30 Mar 2022 04:15:00 GMT

I want povray to produce images in both correct and reversed aspect(mirror).
I thought I saw the keyword "invert" somewhere in the documentation but maybe it
was a dream. how can I reverse my output images or get my camera to behave like
a  mirror?

Q) Why?
A) Because <REASONS>

[Molly-J] Re: image_map to tilted and rotated triangle cen... [1474 days 18 hours and 55 minutes ago]

Wed, 30 Mar 2022 04:05:00 GMT

In case someone in the distant future is searching for the pitch angles on the
facets of an icosahedron standing on a vertex, they are:


+52.62263186 degrees from vertical on the five topmost facets

+/- 10.81231696 degrees from vertical for the 10 facets around the equator

-52.62263186 degrees from vertical on the five lowermost facets

[Molly-J] Re: image_map to tilted and rotated triangle cen... [1475 days 2 hours and 45 minutes ago]

Tue, 29 Mar 2022 20:15:00 GMT

Thank you everyone for all that help.
I worked out how to do it after re-reading your posts carefully. I had to break
out the geometry/trigonometry skills to derive the angles from xyz coordinates.
there seems to be no other way.
unless there is . . . .

Is there a povray function that returns polar coordinates of a surface's normal?

eg. create a polygon my_polygon at xyz xyz xyz and then ask--

let lat/lon = normal(my_polygon)

[Alain Martel] Re: image map and batch render [1475 days 5 hours and 39 minutes ago]

Tue, 29 Mar 2022 17:20:51 GMT

Le 2022-03-28 Ã  14:59, Leroy a Ã©critÂ :

>   Here something if the files you want to include aren't ordered as above or even
> named the same. Make a file containing all the filenames you want. Then read
> that file up to the current frame in the animation. That will be the your
> include file.
> I have winXP and I use this dos bat file to copy all the files in a directory.
> 
> REM make the file 'AAA_List.txt'  of 'txt' files from the directory where it
> this is located
> dir *.txt /A:-D/B/O:N > AAA_List.txt
> 
> just save in the directory where the files are and run
> then I use POV win editor to add a quotes before and after the file name & a
> comma at the end of each line
> 
> 
> 
> 
This .bat file will work from MS DOS 3 up to Windows 11 and probably 
beyond. MS DOS did not support folders before version 3.

[Leroy] Re: image map and batch render [1476 days 4 hours ago]

Mon, 28 Mar 2022 19:00:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> > On 04/03/2022 19:55, Bald Eagle wrote:
> >
> >> If you name all of your files in sequential numerical order, you can use the
> >> animation feature, and use the frame number or the clock value to choose the
> >> right file.  Just concatenate everything into a string and use that for the
> >> filename.
> >>
> >
> > As Bill say, animation feature is a key.
> >
> > -> Name yours file sequential : File1.inc, File2.inc, ... File1500.inc
> > -> In your SDL code, build the file name string :
> >     #declare fileName = concat("File",str(frame_number,0,0),".inc");
> > -> Include the file :
> >     #include fileName
> > -> Of corse, turn on animation and set
> >     Initial_Frame=1 and Final_Frame=1500
> >
> >
> >
<https://wiki.povray.org/content/Reference:Animation_Options#Internal_Animation_Loop>
> >
> >
> >
> In this case, it's usually better to use constant file name length. So...
> #declare fileName = concat("File",str(frame_number,-4,0),".inc");
> The -4 means at least four digits and left padded with zeros.
> The zero mean no decimal part.
>
> File0001.inc, File0002.inc, ... File1500.inc

 Here something if the files you want to include aren't ordered as above or even
named the same. Make a file containing all the filenames you want. Then read
that file up to the current frame in the animation. That will be the your
include file.
I have winXP and I use this dos bat file to copy all the files in a directory.

REM make the file 'AAA_List.txt'  of 'txt' files from the directory where it
this is located
dir *.txt /A:-D/B/O:N > AAA_List.txt

just save in the directory where the files are and run
then I use POV win editor to add a quotes before and after the file name & a
comma at the end of each line

[Leroy] Re: image_map to tilted and rotated triangle cen... [1476 days 4 hours and 30 minutes ago]

Mon, 28 Mar 2022 18:30:00 GMT

"Molly-J" <nomail@nomail> wrote:
> I am going mad trying to project image maps onto polygons that are not in the
> x-y plane or plumb to the y axis. I have 20 equilateral triangles forming a
> typical D20 shape (regular icosahedron). I have the XYZ coordinates for the
> points so all I have to do is create each triangle using sets of the 32
> vertices. BUT . . . .
>
> I cannot work out how to project the 20 image_map pigments properly. Image_map
> pigments only seem to work on polygons normal to the Z axis and left corner at
> 0,0 XY
>
> The suggestion that I create each triangle at 0,0 and then translate/rotate them
> to the icosahedron would be just fine if i had those numbers. (I do not)
>
> There must exist another way, as the current limitation is ludicrously
> un-useful. Everybody aplying pictures to polyhedra would have exactly the same
> problem.
> What am I missing?
>
> Is it possible to translate the triangle by translating its individual points?
> That I might be able to do, but I can't work out how.
>
>
> The ultimate goal is a Dymaxion type world map on an Icosahedron.

My first thought is use a mesh2 with UV mapping. It may be a little hard to do
it by hand. But you only have 32 points to worry about. Try looking at the mesh2
documentation to see if you want to try that.

[Alain Martel] Re: image_map to tilted and rotated triangle cen... [1476 days 7 hours and 37 minutes ago]

Mon, 28 Mar 2022 15:23:31 GMT

Le 2022-03-27 Ã  22:18, Molly-J a Ã©critÂ :
> I am going mad trying to project image maps onto polygons that are not in the
> x-y plane or plumb to the y axis. I have 20 equilateral triangles forming a
> typical D20 shape (regular icosahedron). I have the XYZ coordinates for the
> points so all I have to do is create each triangle using sets of the 32
> vertices. BUT . . . .
> 
> I cannot work out how to project the 20 image_map pigments properly. Image_map
> pigments only seem to work on polygons normal to the Z axis and left corner at
> 0,0 XY
> 
> The suggestion that I create each triangle at 0,0 and then translate/rotate them
> to the icosahedron would be just fine if i had those numbers. (I do not)
> 
> There must exist another way, as the current limitation is ludicrously
> un-useful. Everybody aplying pictures to polyhedra would have exactly the same
> problem.
> What am I missing?
> 
> Is it possible to translate the triangle by translating its individual points?
> That I might be able to do, but I can't work out how.
> 
> 
> The ultimate goal is a Dymaxion type world map on an Icosahedron.
> 

In your case, it may be OK to use the spherical mapping for your 
image_map, making sure that the isocahedron is modelled centred at the 
origin. For that you need a single image showing every faces. Ideally, 
that image will have a 2:1 aspect ratio.

Add Â«map_type 1Â» at the beginning of the image_map statement.
There will 
be some distortion, but, in this case, it'll be minimal.

Another option is to use UV mapping. For that, you need to declare your 
icosahedron as a mesh object.

If that's not an option, like you have individual images for each faces, 
you need to create each triangles at the origin parallel to the X-Y 
plane, rotate them correctly, then translate them to their final location.

[Tor Olav Kristensen] Re: image_map to tilted and rotated triangle cen... [1476 days 9 hours and 25 minutes ago]

Mon, 28 Mar 2022 13:35:00 GMT

"Molly-J" <nomail@nomail> wrote:
> I am going mad trying to project image maps onto polygons that are not in the
> x-y plane or plumb to the y axis. I have 20 equilateral triangles forming a
> typical D20 shape (regular icosahedron). I have the XYZ coordinates for the
> points so all I have to do is create each triangle using sets of the 32
> vertices. BUT . . . .
>
> I cannot work out how to project the 20 image_map pigments properly. Image_map
> pigments only seem to work on polygons normal to the Z axis and left corner at
> 0,0 XY
>
> The suggestion that I create each triangle at 0,0 and then translate/rotate them
> to the icosahedron would be just fine if i had those numbers. (I do not)
>
> There must exist another way, as the current limitation is ludicrously
> un-useful. Everybody aplying pictures to polyhedra would have exactly the same
> problem.
> What am I missing?
>
> Is it possible to translate the triangle by translating its individual points?
> That I might be able to do, but I can't work out how.
>
>
> The ultimate goal is a Dymaxion type world map on an Icosahedron.

Hi Molly

Perhaps the code I posted in this thread can be useful for you:

From: Tor Olav Kristensen
Subject: How to transform a triangle into another
Date: 2002-10-02 19:41:55
http://news.povray.org/povray.text.tutorials/thread/%3C3D9B843D.E5392CD0%40hotmail.com%3E/

If so, then it is important to replace the 4 first lines in the
Triangle2Triangle_Trans macro (and probably in the Pyramid2Pyramid_Trans macro)
with the corrected ones in my second post.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[jr] Re: image_map to tilted and rotated triangle cen... [1476 days 10 hours and 15 minutes ago]

Mon, 28 Mar 2022 12:45:00 GMT

hi,

"Molly-J" <nomail@nomail> wrote:
> I am going mad trying to project image maps onto polygons that are not in the
> x-y plane or plumb to the y axis. I have 20 equilateral triangles forming a
> typical D20 shape (regular icosahedron). I have the XYZ coordinates for the
> points so all I have to do is create each triangle using sets of the 32
> vertices. BUT . . . .
>
> I cannot work out how to project the 20 image_map pigments properly. Image_map
> pigments only seem to work on polygons normal to the Z axis and left corner at
> 0,0 XY

<https://wiki.povray.org/content/Reference:Image_Map>

once you've created the image_map, you'll want to scale it to correct
proportions, eg if the source is 1920x1080, the scale ought to read
'<1.92,1.08,1>'.

> The suggestion that I create each triangle at 0,0 and then translate/rotate them
> to the icosahedron would be just fine if i had those numbers. (I do not)

ok, I'll stop here 'coz confused, above you wrote "I have the XYZ coordinates
for the points".

if you do have those coords, create yr object in position (near origin, "image
is projected onto the object as though there were a slide projector somewhere in
the -z-direction"), then translate.  hth.

regards, jr.

[Molly-J] image_map to tilted and rotated triangle centere... [1476 days 20 hours and 40 minutes ago]

Mon, 28 Mar 2022 02:20:00 GMT

I am going mad trying to project image maps onto polygons that are not in the
x-y plane or plumb to the y axis. I have 20 equilateral triangles forming a
typical D20 shape (regular icosahedron). I have the XYZ coordinates for the
points so all I have to do is create each triangle using sets of the 32
vertices. BUT . . . .

I cannot work out how to project the 20 image_map pigments properly. Image_map
pigments only seem to work on polygons normal to the Z axis and left corner at
0,0 XY

The suggestion that I create each triangle at 0,0 and then translate/rotate them
to the icosahedron would be just fine if i had those numbers. (I do not)

There must exist another way, as the current limitation is ludicrously
un-useful. Everybody aplying pictures to polyhedra would have exactly the same
problem.
What am I missing?

Is it possible to translate the triangle by translating its individual points?
That I might be able to do, but I can't work out how.


The ultimate goal is a Dymaxion type world map on an Icosahedron.

[Alain Martel] Re: image map and batch render [1499 days 5 hours and 33 minutes ago]

Sat, 5 Mar 2022 17:27:14 GMT

Le 2022-03-05 Ã  04:27, kurtz le pirate a Ã©critÂ :
> On 04/03/2022 19:55, Bald Eagle wrote:
> 
>> If you name all of your files in sequential numerical order, you can use the
>> animation feature, and use the frame number or the clock value to choose the
>> right file.  Just concatenate everything into a string and use that for the
>> filename.
>>
> 
> As Bill say, animation feature is a key.
> 
> -> Name yours file sequential : File1.inc, File2.inc, ... File1500.inc
> -> In your SDL code, build the file name string :
>     #declare fileName = concat("File",str(frame_number,0,0),".inc");
> -> Include the file :
>     #include fileName
> -> Of corse, turn on animation and set
>     Initial_Frame=1 and Final_Frame=1500
> 
> 
>
<https://wiki.povray.org/content/Reference:Animation_Options#Internal_Animation_Loop>
> 
> 
> 
In this case, it's usually better to use constant file name length. So...
#declare fileName = concat("File",str(frame_number,-4,0),".inc");
The -4 means at least four digits and left padded with zeros.
The zero mean no decimal part.

File0001.inc, File0002.inc, ... File1500.inc

[kurtz le pirate] Re: image map and batch render [1499 days 13 hours and 33 minutes ago]

Sat, 5 Mar 2022 09:27:34 GMT

On 04/03/2022 19:55, Bald Eagle wrote:

> If you name all of your files in sequential numerical order, you can use the
> animation feature, and use the frame number or the clock value to choose the
> right file.  Just concatenate everything into a string and use that for the
> filename.
> 

As Bill say, animation feature is a key.

-> Name yours file sequential : File1.inc, File2.inc, ... File1500.inc
-> In your SDL code, build the file name string :
   #declare fileName = concat("File",str(frame_number,0,0),".inc");
-> Include the file :
   #include fileName
-> Of corse, turn on animation and set
   Initial_Frame=1 and Final_Frame=1500


<https://wiki.povray.org/content/Reference:Animation_Options#Internal_Animation_Loop>



-- 
Kurtz le pirate
Compagnie de la Banquise

[Bald Eagle] Re: image map and batch render [1500 days 4 hours ago]

Fri, 4 Mar 2022 19:00:00 GMT

"Peter.bates" <Pet### [at] livecoza> wrote:
> Platfor: in 10
> Version: 3.7
>
> Hi  all!
>
> I have 1500 stl files to convert to jpg images. I used stl2inc to create the
> files and renamed the objects inside the .inc definitions to the same, to make
> the povray script easier.
>
> 1) I am using a bmp image of a piece of wood (attached) to imagemap onto a block
> for the base of the scene (.pov also attached). This results in a
> blurry/stretched image - how can this be fixed?

Your image is 977x1526.
POV-Ray will import this and map it to a 1-POV-unit square.
So what you need to do is scale that texture to resize back to the right aspect
ratio.   (Just like jr said)

> 2) How can I run the same .pov scene file on each .inc file? My idea is: use
> python to create .pov files by changing the #define foo.inc line for each inc
> file, creating a batch of .pov files that can then be run in Windows batch. Is
> there a better way?

If you name all of your files in sequential numerical order, you can use the
animation feature, and use the frame number or the clock value to choose the
right file.  Just concatenate everything into a string and use that for the
filename.

- Bill

[jr] Re: image map and batch render [1500 days 6 hours and 55 minutes ago]

Fri, 4 Mar 2022 16:05:00 GMT

hi,

"Peter.bates" <Pet### [at] livecoza> wrote:
> Platfor: in 10
> Version: 3.7
>
> Hi  all!
>
> I have 1500 stl files to convert to jpg images. I used stl2inc to create the
> files and renamed the objects inside the .inc definitions to the same, to make
> the povray script easier.
>
> 1) I am using a bmp image of a piece of wood (attached) to imagemap onto a block
> for the base of the scene (.pov also attached). This results in a
> blurry/stretched image - how can this be fixed?

(guessing) make sure aspect ratio + scaling .. are in harmony.

> 2) How can I run the same .pov scene file on each .inc file? My idea is: use
> python to create .pov files by changing the #define foo.inc line for each inc
> file, creating a batch of .pov files that can then be run in Windows batch. Is
> there a better way?

you could use the command-line "constant" to supply (part of) a filename.
<https://wiki.povray.org/content/Reference:Scene_Parsing_Options>

(though you'll need to find the right combination of quotes + apostrophes around
the value(s).  sorry, not using MS Win)

regards, jr.

[Peter bates] image map and batch render [1500 days 8 hours and 25 minutes ago]

Fri, 4 Mar 2022 14:35:00 GMT

Platfor: in 10
Version: 3.7

Hi  all!

I have 1500 stl files to convert to jpg images. I used stl2inc to create the
files and renamed the objects inside the .inc definitions to the same, to make
the povray script easier.

1) I am using a bmp image of a piece of wood (attached) to imagemap onto a block
for the base of the scene (.pov also attached). This results in a
blurry/stretched image - how can this be fixed?

2) How can I run the same .pov scene file on each .inc file? My idea is: use
python to create .pov files by changing the #define foo.inc line for each inc
file, creating a batch of .pov files that can then be run in Windows batch. Is
there a better way?

Thanks!

[Dick Balaska] Re: Prime numbers [1535 days 2 hours and 25 minutes ago]

Fri, 28 Jan 2022 20:35:18 GMT

On 1/22/2022 1:25 PM, kurtz le pirate wrote:

Once you've determined a number is not prime, you can skip testing.

> // -----------------------------------------------------------
> // --- macro to test if a it is a prime numbers
> // -----------------------------------------------------------
> #macro IsPrime(n)
>   #local cnt = 0;
>   #local i=2;
>   #while(i<n)
>    #if(mod(n,i)=0)
>     #declare cnt=cnt+1;
       #break
>    #end
>    #declare i=i+1;
>   #end
>   (cnt=0)
> #end

[kurtz le pirate] Re: Prime numbers [1541 days 4 hours and 35 minutes ago]

Sat, 22 Jan 2022 18:25:21 GMT

On 13/01/2022 21:30, Cabesa wrote:
> Now, this is quite a simple request- but I ve been unable to do so myself and
> have no idea how to accomplish it.
> Let me explain:
> 
> I have a ".txt" file, with a random number. The idea is to debug a message that
> states whether said number is prime or not. Now,this should be quite an easy
> task, but i dont seem to wrap my head around it and dont know witch "ifs" or
> "whiles" to put so that the programme knows if the number meets with the
> condition.
> 
> Thanks in advance (for those that read this far)
> 

It's not the best way to do it, but it's done in 5mn ... ;)


// -----------------------------------------------------------
// --- unitary test
// -----------------------------------------------------------
#declare num = 98452;
#declare cnt = 0;
#declare i=2;
#while(i<num)
 #if (mod(num,i)=0)
  #declare cnt=cnt+1;
 #end
 #declare i=i+1;
#end
#debug concat(str(num,0,0)," is ")
#if(cnt !=0 )
 #debug "not a prime number\n"
#else
 #debug "a prime number\n"
#end
#debug "\n\n------------\n\n"



// -----------------------------------------------------------
// --- find prime numbers between 0 and ...
// -----------------------------------------------------------
#declare num=0;
#while(num<50)
 #declare cnt = 0;
 #declare i=2;
 #while( i < num)
  #if (mod(num,i)=0)
   #declare cnt=cnt+1;
  #end
  #declare i=i+1;
 #end
 #if(cnt =0 )
  #debug concat("prime number ",str(num,0,0),"\n")
 #end
 #declare num=num+1;
#end
#debug "\n\n------------\n\n"




// -----------------------------------------------------------
// --- macro to test if a it is a prime numbers
// -----------------------------------------------------------
#macro IsPrime(n)
 #local cnt = 0;
 #local i=2;
 #while(i<n)
  #if(mod(n,i)=0)
   #declare cnt=cnt+1;
  #end
  #declare i=i+1;
 #end
 (cnt=0)
#end



// -----------------------------------------------------------
// --- test a number using the macro
// -----------------------------------------------------------
#declare a = 51286;
#debug concat("Is ",str(a,0,0)," a prime number ? ")
#if(IsPrime(a))
  #debug "yes\n"
#else
  #debug "no\n"
#end

#declare a = 51287;
#debug concat("Is ",str(a,0,0)," a prime number ? ")
#if(IsPrime(a))
  #debug "yes\n"
#else
  #debug "no\n"
#end

#declare a = 51288;
#debug concat("Is ",str(a,0,0)," a prime number ? ")
#if(IsPrime(a))
  #debug "yes\n"
#else
  #debug "no\n"
#end
#debug "\n\n------------\n\n"






-- 
Kurtz le pirate
Compagnie de la Banquise

[Cabesa] Re: Prime numbers [1550 days 1 hour ago]

Thu, 13 Jan 2022 22:00:00 GMT

thanks, ill take a look

[Tor Olav Kristensen] Re: Prime numbers [1550 days 1 hour and 15 minutes ago]

Thu, 13 Jan 2022 21:45:00 GMT

"Cabesa" <adr### [at] gmailcom> wrote:
> Now, this is quite a simple request- but I ve been unable to do so myself and
> have no idea how to accomplish it.
> Let me explain:
>
> I have a ".txt" file, with a random number. The idea is to debug a message that
> states whether said number is prime or not. Now,this should be quite an easy
> task, but i dont seem to wrap my head around it and dont know witch "ifs" or
> "whiles" to put so that the programme knows if the number meets with the
> condition.
>
> Thanks in advance (for those that read this far)

Hi Cabesa

There are some "ifs" and "whiles" for you in the examples under "Simple
methods" on this page:

https://en.wikipedia.org/wiki/Primality_test

"i ** 2" and "n % (i + 2)" in Python can be written as "pow(i, 2)" and "mod(n, i
+ 2)" in POV-Ray's SDL.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Cabesa] Prime numbers [1550 days 2 hours and 25 minutes ago]

Thu, 13 Jan 2022 20:35:00 GMT

Now, this is quite a simple request- but I ve been unable to do so myself and
have no idea how to accomplish it.
Let me explain:

I have a ".txt" file, with a random number. The idea is to debug a message that
states whether said number is prime or not. Now,this should be quite an easy
task, but i dont seem to wrap my head around it and dont know witch "ifs" or
"whiles" to put so that the programme knows if the number meets with the
condition.

Thanks in advance (for those that read this far)

[Alain Martel] Re: Math expressions in text [1558 days 5 hours and 16 minutes ago]

Wed, 5 Jan 2022 17:44:17 GMT

Le 2022-01-04 Ã  15:15, Subrahmanyam Pattamatta a
Ã©critÂ :
> Hello,
> 
> I have recently started using POV-Ray for making illustrations/schematics for a
> material science research article. The figures came out really well. Thanks to
> POV-Ray developers.
> 
> I wonder if there is a way to insert mathematical expressions as text into the
> figure (example: say latex symbols $\alpha + \beta = 0$) directly into the scene
> file or do I have to render the image in POV-Ray, save it to .png and later cut
> and paste latex equations into the .png file ?
> 
> Thank you,
> Subrahmanyam Pattamatta
> Research Fellow
> University of Hong Kong
> 

You may use a text object. You can't directly use \alpha and \beta, but 
you can use the unicode code for those. Obviously, you need to chose a 
font where the Greek alphabet is defined.

You can also create an image file showing your equation and apply it to 
some object. Here, the simplest way is to have a box with an image_map 
as pigment using the image :

box{0, <1, 1, 0.0001> pigment{image_map{png "equation.png"}} scale<20, 
1, 1> translate Final_Location}

The image could be a jpeg or a gif if you want, just replace the
Â«pngÂ» 
with Â«jpegÂ» or Â«gifÂ».
Change the name of the file to whatever name you are using.
Place the image file in the same folder as your scene file.
The image is initially mapped from <0,0>to <1,1>.
Then, you scale it according to how wide it is compared to it's height.
Finally, you can translate to wherever you want it to show up.

If you use a png file, you can have an alpha channel to make the 
background transparent.

[Tor Olav Kristensen] Re: Math expressions in text [1558 days 17 hours ago]

Wed, 5 Jan 2022 06:00:00 GMT

"Subrahmanyam Pattamatta" <nomail@nomail> wrote:
> Hello,
>
> I have recently started using POV-Ray for making illustrations/schematics for a
> material science research article. The figures came out really well. Thanks to
> POV-Ray developers.
>
> I wonder if there is a way to insert mathematical expressions as text into the
> figure (example: say latex symbols $\alpha + \beta = 0$) directly into the scene
> file or do I have to render the image in POV-Ray, save it to .png and later cut
> and paste latex equations into the .png file ?

Hi Subrahmanyam

Have you considered rendering the mathematical expressions into high resolution
png-files with some other tool and then bringing them into the POV-Ray scenes by
UV-mapping the png-files onto objects ?

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

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

[Bald Eagle] Re: Math expressions in text [1558 days 23 hours and 35 minutes ago]

Tue, 4 Jan 2022 23:25:00 GMT

"Subrahmanyam Pattamatta" <nomail@nomail> wrote:

> I wonder if there is a way to insert mathematical expressions as text into the
> figure (example: say latex symbols $\alpha + \beta = 0$) directly into the scene
> file or do I have to render the image in POV-Ray, save it to .png and later cut
> and paste latex equations into the .png file ?

You can likely do anything you'd like, but as clipka would say, just keep in
mind that POV-Ray is a raytracer and not a word-processor or equation editor.

http://www.f-lohmueller.de/pov_tut/all_shapes/shapes604e.htm

So, just choose whatever font you want to use, and you can arrange your text and
symbols however you'd like. You may have to "draw" your own symbols using
cylinders, segments of tori, etc, and use scaling to get them to look right, but
it's doable.

You may also benefit from jr's tabulated macro to make tables and arrange the
terms of your equations that way.

https://news.povray.org/povray.text.scene-files/thread/%3Cweb.610402268669d715e0fed26cde94f1@news.povray.org%3E/

https://news.povray.org/povray.binaries.images/thread/%3C610444e7@news.povray.org%3E/

http://news.povray.org/povray.binaries.images/thread/%3Cweb.610564b1d66467d55e0fed26cde94f1%40news.povray.org%3E/

[Subrahmanyam Pattamatta] Math expressions in text [1559 days 2 hours and 40 minutes ago]

Tue, 4 Jan 2022 20:20:00 GMT

Hello,

I have recently started using POV-Ray for making illustrations/schematics for a
material science research article. The figures came out really well. Thanks to
POV-Ray developers.

I wonder if there is a way to insert mathematical expressions as text into the
figure (example: say latex symbols $\alpha + \beta = 0$) directly into the scene
file or do I have to render the image in POV-Ray, save it to .png and later cut
and paste latex equations into the .png file ?

Thank you,
Subrahmanyam Pattamatta
Research Fellow
University of Hong Kong

[Tor Olav Kristensen] Re: Round box [1559 days 2 hours and 45 minutes ago]

Tue, 4 Jan 2022 20:15:00 GMT

"Cabesa" <adr### [at] gmailcom> wrote:
> Ive been trying to use the round_box shape but i dont really understand how to.
> If someone is willing to explain the way the shapes and the "macro?" idrk what
> it is, id appreciate it a lot.

I suggest that you read these pages:

    "HowTo:Use macros and loops"
    https://wiki.povray.org/content/HowTo:Use_macros_and_loops

    "Reference:Shapes.inc"
    https://wiki.povray.org/content/Reference:Shapes.inc

    "2.2.2.8 User Defined Macros"
    https://www.povray.org/documentation/view/3.7.0/243/

    "2.7.12.1 shapes.inc"
    http://www.povray.org/documentation/view/3.7.1/468/

- and then you can try this:

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

global_settings { assumed_gamma 1.0 }

#include "colors.inc"
#include "shapes.inc" // For the Round_Box() macro

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare pA = <-2,  0, -1>;  // A corner
#declare pB = <+2, +1, +1>;  // The opposite corner
#declare EdgeAndcornerRadius = 0.25;
#declare UseMerge = false;

object {
    Round_Box(pA, pB, EdgeAndcornerRadius, UseMerge)
    texture {
        pigment { color DarkSlateBlue }
        normal {
            radial
            sine_wave
            frequency 30
            scale 0.25*<1, 1, 1>
        }
        finish { phong 0.5 }
    }
    rotate -35*y
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

background { color Gray30 + Cyan/5 }

light_source {
    100*<-5, 20, -10>
    color White
}

camera {
    location <0, 3, -5>
    look_at <0, 0, 0>
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

--
Tor Olav

[Alain Martel] Re: Round box [1559 days 7 hours and 20 minutes ago]

Tue, 4 Jan 2022 15:40:27 GMT

Le 2022-01-04 Ã  09:13, Cabesa a Ã©critÂ :
> Ive been trying to use the round_box shape but i dont really understand how to.
> If someone is willing to explain the way the shapes and the "macro?" idrk what
> it is, id appreciate it a lot.
> 

You use it pretty much as a regular box, but with the hard edges 
replaced with cylinders and spheres at the vertex. The faces are at the 
same position as for a regular box.

The first two parameters are two 3D vectors that define the opposite 
corners of the box in the exact same way as the two corners of the 
regular box primitive. Those points are actually outside the final shape.

The third one is the radius of the edges, or, the size of the rounded 
part. This is a single float value. If this value is to large, a warning 
will be issued, and the radius adjusted to the actual size. To large 
being more than half the smallest dimension of the box.
If you have this :
round_box( <2,1,1>, <-2,-1,-1>, 1, 0)
You end up with a cylinder capped by two half spheres.
Using those corners, ANY radius larger than 1 will result in the same 
final shape.

The last one determine whether an union or a merge is to be used. UNLESS 
your round_box is transparent or you are using SSLT, you should use the 
union option. So, set this to zero. Using the union option renders faster.

Normal box:
box{ Corner_One, Corner_Two texture{ Some_Texture} }
The equivalent round box :
object{round_box( Corner_One, Corner_Two, radius, 0) texture{ 
Some_Texture} }

The object wrapper is needed to add a texture and to allow some 
transform : rotation, scaling and translate.
The flat faces of the two objects are at the same location.
Those faces are connected using cylinders tangent with the adjacent faces.
Spheres tangent with the adjacent cylinders are used to fill the corners.

[Cabesa] Round box [1559 days 8 hours and 45 minutes ago]

Tue, 4 Jan 2022 14:15:00 GMT

Ive been trying to use the round_box shape but i dont really understand how to.
If someone is willing to explain the way the shapes and the "macro?" idrk what
it is, id appreciate it a lot.

[Bald Eagle] Re: Dark Regions and Reflections Removal [1584 days 18 hours and 50 minutes ago]

Fri, 10 Dec 2021 04:10:00 GMT

Scene file.

[Bald Eagle] Re: Dark Regions and Reflections Removal [1584 days 18 hours and 50 minutes ago]

Fri, 10 Dec 2021 04:10:00 GMT

Looks like the placement of the light_source was a major source of your
headaches.

I putzed around with this a bit more, and it's looking much better - hopefully
you can tweak things from here.

[Bald Eagle] Re: Dark Regions and Reflections Removal [1584 days 20 hours and 45 minutes ago]

Fri, 10 Dec 2021 02:15:00 GMT

"bubble_person" <nomail@nomail> wrote:

> included my code below as I can only attach a single file.

You can attach more than one file if you use a newsreader like Thunderbird.
You can also post your scene in the scene files area with a link to it here, or
just post twice - once with the render illustrating your problem, and again with
your scene file as an attachment.

> Can anyone help me troubleshoot this issue?

I haven't done a _lot_ with your file, but I just played around with
restructuring some things and see what was where.
Take a look through what I did - I have a #switch block to use a top-down view
with simple textures to get a clear look at your objects, and did some other
things with an array and a macro for your bubbles.
Just change the value of "Render" to "Setup" or "Scene" to see how that works.

I changed some textures and made all the merges unions trying to speed it up -
so you may need to change some of those back.

With the small amount of work I did - I'm thinking that you might need to take a
look at your geometry and make sure everything is sized properly and nests the
way you think it does.

With regard to the speckles, I think what you should try is just differencing
your bubbles away from the gel instead of adding them in as objects with a whole
material definition.   You only need an interior with an ior if it's different
than air.  Think of your bubbles not air bubbles of air - but of spherical
regions where the gel has been subtracted away or excluded.

You need a version number
assumed_gamma in global_settings

doesn't make too much sense to define variables if you're only using the values
once

I find it very interesting that you successfully instantiate objects without
using the object {} wrapper!  :O
..oO(This scene is never gonna render without an error the way it's written...)
And it DID!

> Thank you all for your support and insights!

These things can always be really tricky - sometimes for quite complex reasons,
but other times for the most ridiculously simple reasons that are hard to see.

I'm thinking that you should "build up" your geometry from the center outwards,
using thickness values rather than distinct radii.   It's simpler (in my mind)
to do it that way without error, and if you ever change a value, everything else
still works because it's already "parameterized".

So,
gel_radius
gel radius + epsilon
gel_radius + epsilon + tube_thickness
gel_radius + epsilon + tube_thickness + epsilon
gel_radius + epsilon + tube_thickness + epsilon + water_thickness

etc

[bubble person] Dark Regions and Reflections Removal [1585 days 10 hours and 30 minutes ago]

Thu, 9 Dec 2021 12:30:00 GMT

Hello Forum,

I have been beating my head against an issue in the rendering of scene.   I have
bubbles entrained in a gel, encased in a glass tube.  This is then surrounded by
water, and another clear cylinder containing the water.  I have an area light
backlighting this setup and a camera looking directly through the setup into my
backlight.

When I first rendered my setup, everything was looking good, and so I decided to
run it as an animation, rotating the bubbles around Y axis.  However, when I ran
the animation, the boundary between the glass and water appeared to be speckled,
which immediately made me think of an overlapping surface issue.  I addressed it
by adding an "epsilon" to the radius of my water cylinder's inner surface and
ran it again.  While the speckled surface issue was resolved, a large portion of
my cylinder is being rendered as a dark region, and this region will not go away
no matter what I do.

I have tried repositioning my light, resizing my light, playing with the epsilon
between the water and glass definition, increasing the max_trace_level, and with
the material characteristics of the glass.  In all cases, there seems to be a
new dark region that obscures the outer edges of my gel region.  I think this
may be some “reflective” property that is causing a dark region on the
surface
of the glass closest to the camera, as the dark region obscures bubbles within
the gel region.

I have included a before and after photo to illustrate the change.  I’ve
included my code below as I can only attach a single file.

Can anyone help me troubleshoot this issue?

Thank you all for your support and insights!

Sincerely,

Bubble_person


====================
Script Below
====================

//Files with predefined colors and textures
#include "colors.inc"
#include "glass.inc"
#include "stones.inc"

 global_settings { max_trace_level 50}

#declare epsilon         = .0001;

#declare light_loc_x   = 0;
#declare light_loc_y   = 0;
#declare light_loc_z   = 100;

#declare tube_base    =  -55;
#declare tube_height  = 92;
#declare tube_rinner  = 13;
#declare tube_router  = 16;
#declare tube_lip_width = 2;

#declare tube_rotation_x = 0;
#declare tube_rotation_y =  2*clock;
#declare tube_rotation_z = 0;

#declare water_router     = 25.4;
#declare plexi_router      = 31.75;

#declare gel_height         = 0.9*tube_height;

#declare bubble_r            = 0.8;
#declare bubble_ior         = 1.0;

//Place the camera
camera {
  location  <000,000,-500>    //Camera location
  look_at   <0,0,1>     //Where camera is pointing
  angle 15       //Angle of the view--increase to see more, decrease to see less
}

//Ambient light to "brighten up" darker pictures
global_settings { ambient_light White }

//Set a background color
background { color Black }


// Set up light source from box

#declare light_box = box{ <-80,-100,0>, <80,100,2>
        pigment{color White}
       } //end light box


light_source {
    <light_loc_x, light_loc_y,light_loc_z>
    color White
    area_light 160*x, 200*y 20, 20
    adaptive 1
    jitter
    looks_like { light_box }
  }

//=====================================================================================
// Creating bubbles that go into gel
//=====================================================================================


// Create Bubbles

#declare MatBubble =
material {
  texture {
    pigment {color rgbt<.99,.99,.99,0.98>}
    normal { bumps 0 scale 0.025 }
    finish { phong .001 }
  } // end of texture
  interior{
    ior           bubble_ior
    dispersion         1.01 // this simulates dispersion caused refraction
    dispersion_samples  7
    fade_power         1001     //(0=off)  (realistic: 1~2, >=1000 ->realistic
exponential attenuation function will be used!)
  } // end of interior
} // end of material


// Add Bubble Definitions Here:
#declare Bubble_5 =sphere{ <3.94,-7.554,-4.927>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_4 =sphere{ <-1.53,35.605,-2.926>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_3 =sphere{ <-1.271,40.873,2.981>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_2 =sphere{ <2.972,-36.206,-1.126>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_1 =sphere{ <8.863,-12.984,3.351>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)



union {

// Add Union here
  object {Bubble_5}
  object {Bubble_4}
  object {Bubble_3}
  object {Bubble_2}
  object {Bubble_1}

  rotate <tube_rotation_x,tube_rotation_y,tube_rotation_z>
}


//=====================================================================================
//Creating Glass Tube
//=====================================================================================


//create hollow cylinder

#declare GlassTube =
merge{
 difference{
  //Create single cylinder
  cylinder { <0,(tube_base-epsilon),0>, <0,tube_height,0>,   tube_router
     } // end cylinder

  cylinder { <0,(tube_base-2*epsilon),0>, <0,tube_height+epsilon,0>,
tube_rinner
     } // end cylinder
   }  // End difference (hollow cylinder)

  //create hollow half-sphere
  difference{
   difference{
    //Create single cylinder
    sphere { <0,0,0>,   tube_router } // end sphere
    sphere { <0,0,0>,   tube_rinner} // end sphere
     } // End difference (Hollow Sphere)
   box{ <-2* tube_router ,0,-2* tube_router >,
      < 2*tube_router , 2*tube_router ,2* tube_router >
     } // End Box

    translate<0,tube_base,0>
     }   // End Difference (Half-Sphere)

 // create Lip torus at top of tube
 torus {  (tube_router+ tube_rinner)/2, tube_lip_width
  translate <0,tube_height,0>
 } // End Torus (Tube Lip)


      material{
            texture {  pigment{ color rgbt<.99,.99,.99,0.99>}
                       normal { bumps 0 scale 0.025 }
                       finish { phong .99}
                     } // end of texture
            interior{  ior        1.56
               dispersion                1.0 // this simulates dispersion caused
refraction
               dispersion_samples   7
               fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                       caustics 0.0
                    } // end of interior
            } // end of material

 rotate<tube_rotation_x,tube_rotation_y,tube_rotation_z>

  } // End Merge (Full tube)

GlassTube

//=====================================================================================
// Creating Gel  to fill Glass Tube with voids for the bubbles
//=====================================================================================
// Creating gel to fill glass

#declare GelCyl =
 merge{
  sphere { <0,tube_base,0>,   tube_rinner-epsilon} // end sphere
  cylinder{<0,tube_base,0>, <0,gel_height,0>,   tube_rinner-epsilon}// end
cylinder
       material{
             texture {  pigment{ color rgbt<.99,.99,.99,0.98>}
                        normal { bumps 0 scale 0.025 }
                        finish { phong .001 }
                      } // end of texture
             interior{  ior        1.405
                dispersion                1.01  // this simulates dispersion
caused refraction
                dispersion_samples   7
                fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                        caustics 0.0
                     } // end of interior
             } // end of material


  } // end merge (gel matrix)

GelCyl

//=====================================================================================
// Creating Water Cylinder around tube
//=====================================================================================

#declare WaterCyl =
difference{
 cylinder{
  <0,tube_base-tube_router,0>,<0,tube_height*.8,0>, water_router} //End outer
cylinder
 merge{
  cylinder{<0,tube_base,0>, <0,tube_height+epsilon,0>, tube_router+epsilon} //
end cylinder for glass tube

  sphere{<0,tube_base,0>, tube_router+epsilon} // end sphere (tube bottom)
  } //end merge (glass tube inside of water


    material{
             texture {  pigment{ color rgbt<.99,.99,.99,0.98>}
                        normal { bumps 0 scale 0.025 }
                        finish { phong .001 }
                      } // end of texture
             interior{  ior        1.33
                dispersion                1.01 // this simulates dispersion
caused refraction
                dispersion_samples   7
                fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                        caustics 0.0
                     } // end of interior
             } // end of material
} // End difference of outer water tube

WaterCyl


//=====================================================================================
//Creating Plexiglass Cylinder holding water
//=====================================================================================
#declare PlexCyl =
difference{
 cylinder{<0,tube_base-tube_router,0>,<0,tube_height*.9,0>, plexi_router} //End
outer cylinder
 cylinder{<0,tube_base-tube_router-epsilon,0>,<0,tube_height*.9+epsilon,0>,
water_router+epsilon} //End outer cylinder

    material{
             texture {  pigment{ color rgbt<.99,.99,.99,0.98>}
                        normal { bumps 0 scale 0.025 }
                        finish { phong .001 }
                      } // end of texture
             interior{  ior        1.495
                dispersion                1.01 // this simulates dispersion
caused refraction
                dispersion_samples   7
                fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                        caustics 0.0
                     } // end of interior
             } // end of material

} // End difference of outer water tube


PlexCyl

[Kenneth] Re: Creating soft shadows [1590 days 5 hours and 5 minutes ago]

Sat, 4 Dec 2021 17:55:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> >
> > But that's odd behavior, and does not agree with the documentation about
> > 'adaptive': For my tests, I used a 'linear' light array of   1,33  which is
> > 'only' 33 lights (1*33). According to the docs,
> > "The number of rays never exceeds the values you specify for rows
> > and columns of points."
>
> It can't exceed the specified values in one direction. It's per
> direction, not total.
> If the number of elements for the two directions are not the same, then,
> the initial sampling can be different...
>

Thank you, Alain! That is a *very* useful and clear analysis of my 'adaptive'
results. I had a funny feeling that the 'linear' nature of my area_light was
responsible in some way.

For the OP:
My original code example was basically the result of trial-and-error, but I now
have a much clearer idea of how the parallel/linear combination works. I was
mainly confused about the point_at <...> value and what it does: I always
thought it was a vector direction, but it's actually a location in space.
The *combination* of the light's location and point_at is what determines the
parallel light's illumination direction. (The docs have always confused me about
this.) My light's 'area' is from <0,0,0> to <0,0,30>-- essentially a
one-dimensional 'line' from the origin out to z=30. (But the *center* of that is
at the origin, so it actually extends from -15*z to 15*z, before any
translations.) So I reset point_at to be <0,0,0> likewise, not z or -y, and the
resulting shadow direction is correct-- because the x-location is the same in
both cases.

A different example would be point_at <5,0,0>. But this would skew the shadow to
the right-- and look rather ugly and 'smudged'  as well--  because the light's
'area' is that line out from the origin at x=0, not x=5.

Anyway, here is a better code example. I flipped the text letters to be
horizontal. The result reminds me of an old-style movie title from the 1930's.

----------
#version 3.8; // or whatever
global_settings{assumed_gamma 1.0}
camera {
  orthographic
  location  <.35, 5, .1>
  look_at   <.35, 0, .1>
  right     x*image_width/image_height
  direction z
  angle 16
}

plane{y, 0
texture{
 pigment{rgb 1}
 finish{ambient .05 emission 0 diffuse .95}
 }
}

light_source{
<0, 0, 0>
color rgb 1.0
area_light
0*x  5*z
1, 33
adaptive 5
jitter
translate <0.0, 2.0, -2.5> // z is half of 'area' dimension
parallel
point_at <0, 0, 0>
rotate -30*y
}

text{
    ttf "timrom.ttf" "POV-Ray"
    .2, 0
    rotate 90*x
    scale <.25,1,.25>
    translate .2*y
texture{
 pigment{rgb .4*<0,1,1>}
 finish{ambient 1 emission 0 diffuse 0}
 }
rotate 20*y
}

[Alain Martel] Re: Creating soft shadows [1590 days 7 hours and 41 minutes ago]

Sat, 4 Dec 2021 15:18:44 GMT

Le 2021-12-03 Ã  16:16, Kenneth a Ã©critÂ :
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> For the two cylinders, adaptive 1, or maybe even adaptive 0, would
>> probably have been enough.
>> For the text object, it's not. You probably need to use adaptive 3 or
>> even 4 to get a correct result.
> 
> You're correct with both suggestions. And for the letters, I cranked up adaptive
> to 5(!), which continued to make the letter shadows even smoother... but with a
> slower render, of course.
> 
> But that's odd behavior, and does not agree with the documentation about
> 'adaptive': For my tests, I used a 'linear' light array of   1,33  which is
> 'only' 33 lights (1*31). According to the docs,
> "The number of rays never exceeds the values you specify for rows and columns of
> points."

It can't exceed the specified values in one direction. It's per 
direction, not total.
If the number of elements for the two directions are not the same, then, 
the initial sampling can be different.

> 
> So for 33 lights in my area_light, the maximum *useful* adaptive value should be
>         adaptive 2  (5X5=25 rays)

In your case, that's 1x5 rays when using adaptive 2. The number of 
samples in the U direction is limited to 1, while the number of samples 
in the V direction can reach up to 33.

> But the adaptive mechanism is definitely still working at values of 3 through 5;
> I did some visual 'difference' tests to confirm this-- and the render times get
> slower as well.
> 
> I am currently running POV-ray v3.8.0 beta 1 in Windows, so the way 'adaptive'
> works may have changed(?) at some point...or else there is something fundamental
> about the doc's description of 'adaptive' that I still don't understand.
> 
> 
> 
In your scene, the actual starting sampling are :
adaptive 0 : 1x2
adaptive 1 : 1x3
adaptive 2 : 1x5
adaptive 3 : 1x9
adaptive 4 : 1x17
adaptive 5 : 1x33

[Kenneth] Re: Creating soft shadows [1591 days 1 hour and 30 minutes ago]

Fri, 3 Dec 2021 21:30:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But that's odd behavior, and does not agree with the documentation about
> 'adaptive': For my tests, I used a 'linear' light array of   1,33  which is
> 'only' 33 lights (1*31).

Oops, (1*33), sorry.

[Kenneth] Re: Creating soft shadows [1591 days 1 hour and 40 minutes ago]

Fri, 3 Dec 2021 21:20:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
>
> For the two cylinders, adaptive 1, or maybe even adaptive 0, would
> probably have been enough.
> For the text object, it's not. You probably need to use adaptive 3 or
> even 4 to get a correct result.

You're correct with both suggestions. And for the letters, I cranked up adaptive
to 5(!), which continued to make the letter shadows even smoother... but with a
slower render, of course.

But that's odd behavior, and does not agree with the documentation about
'adaptive': For my tests, I used a 'linear' light array of   1,33  which is
'only' 33 lights (1*31). According to the docs,
"The number of rays never exceeds the values you specify for rows and columns of
points."

So for 33 lights in my area_light, the maximum *useful* adaptive value should be
       adaptive 2  (5X5=25 rays)
But the adaptive mechanism is definitely still working at values of 3 through 5;
I did some visual 'difference' tests to confirm this-- and the render times get
slower as well.

I am currently running POV-ray v3.8.0 beta 1 in Windows, so the way 'adaptive'
works may have changed(?) at some point...or else there is something fundamental
about the doc's description of 'adaptive' that I still don't understand.

[Alain Martel] Re: Area_light and Rendering Dark Regions after ... [1591 days 6 hours and 27 minutes ago]

Fri, 3 Dec 2021 16:32:46 GMT

Le 2021-12-03 Ã  07:39, bubble_person a Ã©critÂ :
> Hello Forum,
> 
> I recently posted about about trying to simulate bubbles in a tube and received
> a lot of great feedback on my scripting approach!  I've made changes to my
> previous setup to clean it up, but have two outstanding questions/issues.  The
> first is on the area_light function, and the second is an issue that I am having
> when rendering my new script.
> 
> 
> 1) Area_light:
> 
> In my last discussion, I received some great feedback on the area_light
> function, but I am still having some issues with it in concept.  In my script, I
> want to create a diffuse backlight for my scene.  I am trying to recreate the
> effect of having a bright light shining through transparent objects directly
> into my camera.  to do this, I am beginning by defining an area_light with the
> following characteristics:
> 

For that effect, you'd be better using the back lighting feature. It's a 
finish element. It use the definition for the diffuse component, but 
using TWO values. The first is the front diffuse value, and the second 
control the amount of light diffusely transmitted.
It works like this :
finish{ diffuse 0.1, 0.7 }

For what you want, the best way would be to have a polygon some distance 
in front of the light.

Another way using a box is to use the interior texture to give the 
inside of the box a totally transparent pigment.
box{Corner1, Corner2 texture{ Whatever_Texture_You_Want}
		interior_texture{ pigment { rgbt 1 }}
}

If you are using radiosity, then, the interior_texture is not needed, 
but you need to increase the recursion_limit by +1 over the value that 
you would otherwise use.

> PlexCyl
>

[Thomas de Groot] Re: Area_light and Rendering Dark Regions after ... [1591 days 9 hours and 27 minutes ago]

Fri, 3 Dec 2021 13:33:25 GMT

Op 3-12-2021 om 14:03 schreef bubble_person:
> 
> It must be a Friday because... 
> 

LOL, typically something that happens to all of us repeatedly. Welcome 
to the club! :-)

-- 
Thomas

[bubble person] Re: Area_light and Rendering Dark Regions after ... [1591 days 9 hours and 55 minutes ago]

Fri, 3 Dec 2021 13:05:00 GMT

"bubble_person" <nomail@nomail> wrote:
> Hello Forum,
>
> I recently posted about about trying to simulate bubbles in a tube and received
> a lot of great feedback on my scripting approach!  I've made changes to my
> previous setup to clean it up, but have two outstanding questions/issues.  The
> first is on the area_light function, and the second is an issue that I am having
> when rendering my new script.
> ...

Hello Forum,

It must be a Friday because the script I included has the definition:

tube_router-epsilon

instead of

tube_router+epsilon

I changed my script out of frustration to try to recreate my previous effects.
The issue I am experiencing happens when I have correctly defined the water's
inner surface as:

tube_router+epsilon

Sorry for the confusion on my part.

Sincerely,

Bubble_person

[bubble person] Re: Area_light and Rendering Dark Regions after ... [1591 days 10 hours and 5 minutes ago]

Fri, 3 Dec 2021 12:55:00 GMT

"bubble_person" <nomail@nomail> wrote:
> Hello Forum,
>
> I recently posted about about trying to simulate bubbles in a tube and received
> a lot of great feedback on my scripting approach!  I've made changes to my
> previous setup to clean it up, but have two outstanding questions/issues.  The
> first is on the area_light function, and the second is an issue that I am having
> when rendering my new script.
>...

Hello Forum,

I missed the reply from Alain in my previous post which gave a stellar
description of the area_light definition, and he has made it super clear to me.
Thanks Alain!

I am of course interested in how people would approach making a diffuse
backlight, and if my approach of using the looks_like{} function seems
appropriate.  Thanks again, everyone, for your support and help!

Sincerely,

Bubble_person

[bubble person] Re: Transparent Objects Become Black [1591 days 10 hours and 5 minutes ago]

Fri, 3 Dec 2021 12:55:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2021-12-01 à 08:58, bubble_person a écrit :
>
> > light_source {
> >      <0, 0,100>
> >      color White
> >      area_light <160, 0, 0>, <, 200, 0>, 100, 100
> >      adaptive 1
> >      jitter
> >    }
> >
> > When I do this, however, the background is all black, as I believe this only
> > produces rays from the defined area_light, but doesn't really simulate the
> > appearance of looking into a bright backlight.  To mimic realistic backlighting,
> > I can then use the command looks_like{ light_box } where I predefine a white
> > rectangle called "light_box."  My code then looks like this:
> >
> > #declare light_box = box{ <-80,-100,0>, <80,100,2>
> >          pigment{color White}
> >         } //end light box
> >
> > light_source {
> >      <0, 0,100>
> >      color White
> >      area_light <-10, -10, 0>, <10, 10, 0>, 100, 100// Not correct !
> >      adaptive 1
> >      jitter
> >      looks_like { light_box }
> >    }
> >
> > Doing this, I have defined an area_light parallel to the XY, stretched it over
> > my box dimensions, and translated that box/area_light +100 units in the
> > Z-direction.
> >
> > Is this correct?
> Not quite...
> >
> > Sincerely,
> >
> > bubble_person
> >
>
> First point : It is important to remember that light sources are never
> directly visible by the camera. They are ONLY places from where light
> emanate to illuminate the scene, they are not actual objects.
>
> In your example, one side of the area_light is parallel to a line going
> from the origin to a point at <-10, -10, 0>, and the other side is
> parallel to a line going from the origin to <10, 10, 0>.
> Those two lines are co-linear. This will cause soft shadows in only one
> direction. That direction is a diagonal.
>
> There is an obvious, for me, confusion about what is defined where.
>
> When defining a box, you use the two opposite corners. You effectively say :
> Here is a box with faces parallel to the orthogonal planes, and it's
> opposite corners are at those locations.
>
> When defining an area_light, you define the DIRECTION and length of each
> sides, NOT the location of the corners of the parallelogram covering the
> area_light. Here, you are effectively saying :
> Here is a parallelogram centred at the light's location with one side
> oriented this way and this long, and the other side oriented that way
> and that long.
>
> Normally, you want those to be orthogonal. In your case, they need to
> align to the X and Y axis. That mean that only one coordinate have to be
> non-zero and the other two have to be zero. The sign is not important,
> only the absolute value of the length.
>
> area_light 160*x, 200*y, 100, 100
> area_light -160*x, 200*y, 100, 100
> area_light 160*x, -200*y, 100, 100
> and
> area_light -160*x, -200*y, 100, 100
> all define exactly the same area_light.
>
> As you want the light to be parallel to the X-Y plane, it should be
> defined as :
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>          pigment{color White}
>    finish{emission 1}
>         } //end light box
>
> light_source {
>      <0, 0,100>
>      color White
>      area_light 160*x, 200*y, 65, 65
>      adaptive 0 // May be enough
>      jitter
>      looks_like { light_box }
>    }
>
> The smaller size is more than adequate. Because it use the adaptive
> mechanism, the performance is nearly identical.
> Just using adaptive 0 will enable the adaptive sampling. The value is
> not an on/off switch, but determine the minimum number of elements to
> start with.
>
> adaptive 0 start with just the four corners, a 2x2 array. (2^0 +1)
> adaptive 1 start with a 3x3 array. (2^1 +1)
> adaptive 2 start with a 5x5 array. (2^2 +1)
> adaptive 3 start with a 9x9 array. (2^3 +1)
> .
> .
> .
>
> That progression is also why your 100 by 100 array get increased to 129
> by 129, or 2^7 + 1.

Hello Alain,

Thank you so much for the in-depth description and example to illustrate the
concepts.  I see exactly what you mean, and I definitely got myself turned
around on it.  This makes total sense about the light source not being visible
by itself, and the coordinate system.  I think I got turned around on the online
diagrams of the area_light, and trying to figure out where the two defining
vectors were connected (as you said, an origin which is why I was doing wacky
things like making two co-linear vectors!).

As for the adaptive, this makes sense now and thank you for making this clear.
I just posted another question on my rendering that includes essentially this
same question.  I did not see your reply, and will go change the post if I can
because this has cleared up my questions.  Thank you again for all of your
support and insight!

Sincerely,

Bubble_person

[bubble person] Area_light and Rendering Dark Regions after Anim... [1591 days 10 hours and 20 minutes ago]

Fri, 3 Dec 2021 12:40:00 GMT

Hello Forum,

I recently posted about about trying to simulate bubbles in a tube and received
a lot of great feedback on my scripting approach!  I've made changes to my
previous setup to clean it up, but have two outstanding questions/issues.  The
first is on the area_light function, and the second is an issue that I am having
when rendering my new script.


1) Area_light:

In my last discussion, I received some great feedback on the area_light
function, but I am still having some issues with it in concept.  In my script, I
want to create a diffuse backlight for my scene.  I am trying to recreate the
effect of having a bright light shining through transparent objects directly
into my camera.  to do this, I am beginning by defining an area_light with the
following characteristics:

     - parallel to the X-Y-plane
     - centred on the Z-axis
     - with dimensions 160x200 (x,y)
     - I then want the center translated to position <0,0,100>
     - 100 x 100 lights array
     - white light

     Firstly, can somebody confirm that I have defined this correctly, below?

     light_source {
         <0, 0,100>
         color White
         area_light <-80, -100, 0>, <80, 100, 0>, 100, 100
         adaptive 1
         jitter
       }

Next, if I understand this correctly, I would not actually see my light source
shining like I would in real life, and instead need to create an object onto
which I put the area source if I want that realistic studio light panel look.
To do this, I have used the looks_like function, defining a white rectangular
box that will act as my light panel.  Can somebody confirm that this has been
implemented correctly?


     #declare light_box = box{ <-80,-100,0>, <80,100,2>
               pigment{color White}
            } //end light box

     light_source {
         <0, 0,100>
         color White
         area_light <-80, -100, 0>, <80, 100, 0>, 100, 100
         adaptive 1
         jitter
         looks_like { light_box }
       }

     Is what I'm trying to do make sense to create this diffuse, bright,
backlighting effect?
     If my area_light dimensions do not match the dimensions my defined
looks_like{} object, will the area light stretch to accommodate the defined
object?



2). Rendering Issue and the appearance of dark regions after animation
rendering:

My next question pertains to a rendering issue I have run into.  I reformatted
my previous script with the generous input of forum users.  Here I have defined
each region of my setup in a more efficient manner that I was perviously.  In my
attached file, I am simulating air bubbles trapped in a gel housed within a
glass tube.  Outside of this tube is a cylinder of water and then a cylinder of
plexiglass.

When I first rendered my setup, everything was looking good, and so I decided to
run it as an animation, rotating the bubbles around Y axis.  However, when I ran
the animation, the boundary between the glass and water appeared to be speckled,
which immediately made me think of an overlapping surface issue.  I addressed it
by adding an "epsilon" to the radius of my water cylinder's inner surface and
ran it again.  While the speckled surface issue was resolved, a large portion of
my cylinder is being rendered as a dark region, and this region will not go away
no matter what I do, and I cannot recreate the original bright region.  I also
tried turning off the fade and this did not help.

Can anyone help me troubleshoot this issue?

Thank you all for your support and insights!

Sincerely,

Bubble_person


* I have attached my code here, below, because I cannot figure out how to add a
photo and my script.  Sorry for the long post!

//Files with predefined colors and textures
#include "colors.inc"
#include "glass.inc"
#include "stones.inc"

 global_settings { max_trace_level 50}

#declare epsilon         = .0001;

#declare light_loc_x   = 0;
#declare light_loc_y   = 0;
#declare light_loc_z   = 90;

#declare tube_base    =  -55;
#declare tube_height  = 92;
#declare tube_rinner  = 13;
#declare tube_router  = 16;
#declare tube_lip_width = 2;

#declare tube_rotation_x = 0;
#declare tube_rotation_y =  2*clock;
#declare tube_rotation_z = 0;

#declare water_router     = 25.4;
#declare plexi_router      = 31.75;

#declare gel_height         = 0.9*tube_height;

#declare bubble_r            = 0.8;
#declare bubble_ior         = 1.0;

//Place the camera
camera {
  location  <000,000,-500>    //Camera location
  look_at   <0,0,1>     //Where camera is pointing
  angle 15       //Angle of the view--increase to see more, decrease to see less
}

//Ambient light to "brighten up" darker pictures
global_settings { ambient_light White }

//Set a background color
background { color Black }


// Set up light source from box

#declare light_box = box{ <-80,-100,0>, <80,100,2>
        pigment{color White}
       } //end light box


light_source {
    <light_loc_x, light_loc_y,light_loc_z>
    color White
    area_light <-80, -100, 0>, <80, 100, 0>, 100, 100
    adaptive 1
    jitter
    looks_like { light_box }
  }

//=====================================================================================
// Creating bubbles that go into gel
//=====================================================================================


// Create Bubbles

#declare MatBubble =
material {
  texture {
    pigment {color rgbt<.99,.99,.99,0.98>}
    normal { bumps 0 scale 0.025 }
    finish { phong .001 }
  } // end of texture
  interior{
    ior           bubble_ior
    dispersion         1.01 // this simulates dispersion caused refraction
    dispersion_samples  7
    fade_power         1001     //(0=off)  (realistic: 1~2, >=1000 ->realistic
exponential attenuation function will be used!)
  } // end of interior
} // end of material


// Add Bubble Definitions Here:
#declare Bubble_5 =sphere{ <3.94,-7.554,-4.927>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_4 =sphere{ <-1.53,35.605,-2.926>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_3 =sphere{ <-1.271,40.873,2.981>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_2 =sphere{ <2.972,-36.206,-1.126>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)
#declare Bubble_1 =sphere{ <8.863,-12.984,3.351>, (bubble_r)
       material{MatBubble}
   }  //end sphere (bubble)



union {

// Add Union here
  object {Bubble_5}
  object {Bubble_4}
  object {Bubble_3}
  object {Bubble_2}
  object {Bubble_1}

  rotate <tube_rotation_x,tube_rotation_y,tube_rotation_z>
}


//=====================================================================================
//Creating Glass Tube
//=====================================================================================


//create hollow cylinder

#declare GlassTube =
merge{
 difference{
  //Create single cylinder
  cylinder { <0,(tube_base-epsilon),0>, <0,tube_height,0>,   tube_router
     } // end cylinder

  cylinder { <0,(tube_base-2*epsilon),0>, <0,tube_height+epsilon,0>,
tube_rinner
     } // end cylinder
   }  // End difference (hollow cylinder)

  //create hollow half-sphere
  difference{
   difference{
    //Create single cylinder
    sphere { <0,0,0>,   tube_router } // end sphere
    sphere { <0,0,0>,   tube_rinner} // end sphere
     } // End difference (Hollow Sphere)
   box{ <-2* tube_router ,0,-2* tube_router >,
      < 2*tube_router , 2*tube_router ,2* tube_router >
     } // End Box

    translate<0,tube_base,0>
     }   // End Difference (Half-Sphere)

 // create Lip torus at top of tube
 torus {  (tube_router+ tube_rinner)/2, tube_lip_width
  translate <0,tube_height,0>
 } // End Torus (Tube Lip)


      material{
            texture {  pigment{ color rgbt<.99,.99,.99,0.99>}
                       normal { bumps 0 scale 0.025 }
                       finish { phong .99 }
                     } // end of texture
            interior{  ior        1.56
               dispersion                1.0 // this simulates dispersion caused
refraction
               dispersion_samples   7
               fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                       caustics 0.0
                    } // end of interior
            } // end of material

 rotate<tube_rotation_x,tube_rotation_y,tube_rotation_z>

  } // End Merge (Full tube)

GlassTube

//=====================================================================================
// Creating Gel  to fill Glass Tube with voids for the bubbles
//=====================================================================================
// Creating gel to fill glass

#declare GelCyl =
 merge{
  sphere { <0,tube_base,0>,   tube_rinner-epsilon} // end sphere
  cylinder{<0,tube_base,0>, <0,gel_height,0>,   tube_rinner-epsilon}// end
cylinder
       material{
             texture {  pigment{ color rgbt<.99,.99,.99,0.98>}
                        normal { bumps 0 scale 0.025 }
                        finish { phong .001 }
                      } // end of texture
             interior{  ior        1.405
                dispersion                1.0 // this simulates dispersion
caused refraction
                dispersion_samples   7
                fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                        caustics 0.0
                     } // end of interior
             } // end of material


  } // end merge (gel matrix)

GelCyl

//=====================================================================================
// Creating Water Cylinder around tube
//=====================================================================================

#declare WaterCyl =
difference{
 cylinder{
  <0,tube_base-tube_router,0>,<0,tube_height*.8,0>, water_router} //End outer
cylinder
 merge{
  cylinder{<0,tube_base,0>, <0,tube_height+epsilon,0>, tube_router-epsilon} //
end cylinder for glass tube

  sphere{<0,tube_base,0>, tube_router-epsilon} // end sphere (tube bottom)
  } //end merge (glass tube inside of water


    material{
             texture {  pigment{ color rgbt<.99,.99,.99,0.98>}
                        normal { bumps 0 scale 0.025 }
                        finish { phong .001 }
                      } // end of texture
             interior{  ior        1.33
                dispersion                1.0 // this simulates dispersion
caused refraction
                dispersion_samples   7
                fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                        caustics 0.0
                     } // end of interior
             } // end of material
} // End difference of outer water tube

WaterCyl


//=====================================================================================
//Creating Plexiglass Cylinder holding water
//=====================================================================================
#declare PlexCyl =
difference{
 cylinder{<0,tube_base-tube_router,0>,<0,tube_height*.9,0>, plexi_router} //End
outer cylinder
 cylinder{<0,tube_base-tube_router-epsilon,0>,<0,tube_height*.9+epsilon,0>,
water_router+epsilon} //End outer cylinder

    material{
             texture {  pigment{ color rgbt<.99,.99,.99,0.98>}
                        normal { bumps 0 scale 0.025 }
                        finish { phong .001 }
                      } // end of texture
             interior{  ior        1.495
                dispersion                1.0 // this simulates dispersion
caused refraction
                dispersion_samples   7
                fade_power           1001     //(0=off)  (realistic: 1~2, >=1000
->realistic exponential attenuation function will be used!
                        caustics 0.0
                     } // end of interior
             } // end of material

} // End difference of outer water tube


PlexCyl

[Alain Martel] Re: Creating soft shadows [1592 days 7 hours and 46 minutes ago]

Thu, 2 Dec 2021 15:13:57 GMT

Le 2021-12-02 Ã  03:30, Kenneth a Ã©critÂ :
> "TheRealMorris" <nomail@nomail> wrote:
>>
>> I've been playing around with some top-down scenes using an orthographic
>> camera and one of the things I've tried to achieve, are what I would
>> call "soft shadows"...
> 
> I arrived at something that looks like your example by using a "parallel linear
> area_light", which I had never tried before. I used a cylinder for the object,
> half-buried in the main plane (specifically so that there are no 'shadowed
> undercuts' between cylinder and plane-- which seems to improve the effect.) My
> renders are top-down too, using an orthographic camera.
> 
> I have not done a detailed analysis of *how* the area_light actually works in
> this situation-- but I think it is basically horizontal, hovering over the
> object, and only 'one-dimensional' in z (the 'linear' aspect of the light, like
> a long tube). The light's 'area' appears to be split more or less evenly behind
> the object and in front of it (-z and +z)-- but I'm not sure. In any case, that
> seems to be the key to getting this shadow effect.
> 
> The various values I used in the light are kind of extreme, but make the shadow
> smooth and with a smooth gradation. Play around with the light's z-dimension
> (and its z-translation) to see what happens; the thing to watch out for is the
> light casting a partial shadow of the cylinder in the opposite direction-- which
> should be avoided, of course!
> 
> I also tried this exact same set-up with a text{...} object-- which did not work
> very well. I suspect that the light's z-dimension and translation need to be
> changed, maybe radically.
> 
> -------
> #version 3.8; // or whatever
> global_settings{assumed_gamma 1.0}
> 
> camera {
>    orthographic
>    location  <.5, 5, .15>
>    look_at   <.5, 0, .151>
>    right     x*image_width/image_height
>    direction z
>    angle 17
> }
> 
> light_source {
>    <0,0,0>  // light's position (translated below)
>    color rgb 6.0
>    area_light
>    <0, 0, 0> <0, 0, 30> // lights spread out across this distance (x * z)
>    1, 33  // total number of lights in grid-- a 'linear' light
>    adaptive 2 // ?
>    jitter
>   // circular // No!
>   // orient // No!
>    translate <0, .75, -12.5>
>    parallel
>    point_at -y // <0,-1,0>; or +z?  (<0,0,1>) ?
> }
> 
> plane{y,0
> texture{
>   pigment{rgb 1}
>   finish{ambient 0 emission 0 diffuse .8}
>   }
> }
> 
> cylinder{0,1*x,.03  // half-buried in plane
> // OR...
> /*
> text{
>      ttf "timrom.ttf" "POV-Ray"
>      .2, 0
>      scale .2*<1,.17,1>
>      translate <0,0,0>
> */
> texture{
>   pigment{rgb .4*<0,1,1>}
>   finish{ambient 1 emission 0 diffuse 0}
>   }
> //rotate 30*y
> }
> 
For the two cylinders, adaptive 1, or maybe even adaptive 0, would 
probably have been enough.
For the text object, it's not. You probably need to use adaptive 3 or 
even 4 to get a correct result.

[Kenneth] Re: Creating soft shadows [1592 days 14 hours and 25 minutes ago]

Thu, 2 Dec 2021 08:35:00 GMT

"TheRealMorris" <nomail@nomail> wrote:
>
> I've been playing around with some top-down scenes using an orthographic
> camera and one of the things I've tried to achieve, are what I would
> call "soft shadows"...

I arrived at something that looks like your example by using a "parallel linear
area_light", which I had never tried before. I used a cylinder for the object,
half-buried in the main plane (specifically so that there are no 'shadowed
undercuts' between cylinder and plane-- which seems to improve the effect.) My
renders are top-down too, using an orthographic camera.

I have not done a detailed analysis of *how* the area_light actually works in
this situation-- but I think it is basically horizontal, hovering over the
object, and only 'one-dimensional' in z (the 'linear' aspect of the light, like
a long tube). The light's 'area' appears to be split more or less evenly behind
the object and in front of it (-z and +z)-- but I'm not sure. In any case, that
seems to be the key to getting this shadow effect.

The various values I used in the light are kind of extreme, but make the shadow
smooth and with a smooth gradation. Play around with the light's z-dimension
(and its z-translation) to see what happens; the thing to watch out for is the
light casting a partial shadow of the cylinder in the opposite direction-- which
should be avoided, of course!

I also tried this exact same set-up with a text{...} object-- which did not work
very well. I suspect that the light's z-dimension and translation need to be
changed, maybe radically.

-------
#version 3.8; // or whatever
global_settings{assumed_gamma 1.0}

camera {
  orthographic
  location  <.5, 5, .15>
  look_at   <.5, 0, .151>
  right     x*image_width/image_height
  direction z
  angle 17
}

light_source {
  <0,0,0>  // light's position (translated below)
  color rgb 6.0
  area_light
  <0, 0, 0> <0, 0, 30> // lights spread out across this distance (x * z)
  1, 33  // total number of lights in grid-- a 'linear' light
  adaptive 2 // ?
  jitter
 // circular // No!
 // orient // No!
  translate <0, .75, -12.5>
  parallel
  point_at -y // <0,-1,0>; or +z?  (<0,0,1>) ?
}

plane{y,0
texture{
 pigment{rgb 1}
 finish{ambient 0 emission 0 diffuse .8}
 }
}

cylinder{0,1*x,.03  // half-buried in plane
// OR...
/*
text{
    ttf "timrom.ttf" "POV-Ray"
    .2, 0
    scale .2*<1,.17,1>
    translate <0,0,0>
*/
texture{
 pigment{rgb .4*<0,1,1>}
 finish{ambient 1 emission 0 diffuse 0}
 }
//rotate 30*y
}

[Alain Martel] Re: Transparent Objects Become Black [1593 days 6 hours and 26 minutes ago]

Wed, 1 Dec 2021 16:34:06 GMT

Le 2021-12-01 Ã  08:58, bubble_person a Ã©critÂ :

> light_source {
>      <0, 0,100>
>      color White
>      area_light <160, 0, 0>, <, 200, 0>, 100, 100
>      adaptive 1
>      jitter
>    }
> 
> When I do this, however, the background is all black, as I believe this only
> produces rays from the defined area_light, but doesn't really simulate the
> appearance of looking into a bright backlight.  To mimic realistic backlighting,
> I can then use the command looks_like{ light_box } where I predefine a white
> rectangle called "light_box."  My code then looks like this:
> 
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>          pigment{color White}
>         } //end light box
> 
> light_source {
>      <0, 0,100>
>      color White
>      area_light <-10, -10, 0>, <10, 10, 0>, 100, 100// Not correct !
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }
> 
> Doing this, I have defined an area_light parallel to the XY, stretched it over
> my box dimensions, and translated that box/area_light +100 units in the
> Z-direction.
> 
> Is this correct?
Not quite...
> 
> Sincerely,
> 
> bubble_person
> 

First point : It is important to remember that light sources are never 
directly visible by the camera. They are ONLY places from where light 
emanate to illuminate the scene, they are not actual objects.

In your example, one side of the area_light is parallel to a line going 
from the origin to a point at <-10, -10, 0>, and the other side is 
parallel to a line going from the origin to <10, 10, 0>.
Those two lines are co-linear. This will cause soft shadows in only one 
direction. That direction is a diagonal.

There is an obvious, for me, confusion about what is defined where.

When defining a box, you use the two opposite corners. You effectively say :
Here is a box with faces parallel to the orthogonal planes, and it's 
opposite corners are at those locations.

When defining an area_light, you define the DIRECTION and length of each 
sides, NOT the location of the corners of the parallelogram covering the 
area_light. Here, you are effectively saying :
Here is a parallelogram centred at the light's location with one side 
oriented this way and this long, and the other side oriented that way 
and that long.

Normally, you want those to be orthogonal. In your case, they need to 
align to the X and Y axis. That mean that only one coordinate have to be 
non-zero and the other two have to be zero. The sign is not important, 
only the absolute value of the length.

area_light 160*x, 200*y, 100, 100
area_light -160*x, 200*y, 100, 100
area_light 160*x, -200*y, 100, 100
and
area_light -160*x, -200*y, 100, 100
all define exactly the same area_light.

As you want the light to be parallel to the X-Y plane, it should be 
defined as :
#declare light_box = box{ <-80,-100,0>, <80,100,2>
         pigment{color White}
   finish{emission 1}
        } //end light box

light_source {
     <0, 0,100>
     color White
     area_light 160*x, 200*y, 65, 65
     adaptive 0 // May be enough
     jitter
     looks_like { light_box }
   }

The smaller size is more than adequate. Because it use the adaptive 
mechanism, the performance is nearly identical.
Just using adaptive 0 will enable the adaptive sampling. The value is 
not an on/off switch, but determine the minimum number of elements to 
start with.

adaptive 0 start with just the four corners, a 2x2 array. (2^0 +1)
adaptive 1 start with a 3x3 array. (2^1 +1)
adaptive 2 start with a 5x5 array. (2^2 +1)
adaptive 3 start with a 9x9 array. (2^3 +1)
.
.
.

That progression is also why your 100 by 100 array get increased to 129 
by 129, or 2^7 + 1.

[bubble person] Re: Transparent Objects Become Black [1593 days 9 hours ago]

Wed, 1 Dec 2021 14:00:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2021-11-11 à 13:19, bubble_person a écrit :
> > Alain Martel <kua### [at] videotronca> wrote:
> >> Le 2021-11-11 à 08:06, bubble_person a écrit :
> >>> Hello Forum,
> >>>
> >>> I am relatively new to POV-RAY, but have a functional script .
> >>>
> >>> I am simulating air bubbles in a glass tube full of gel.  I am running into a
> >>> funny problem where, if I add too many bubbles to the script, they go from being
> >>> transparent and rendered correctly, to a completely opaque, black object through
> >>> which no light shines.
> >>>
> >>> Things that don't seem to work:
> >>>
> >>> 1) Increasing the  max_trace_level
> >>>
> >>> 2) I have tried to be sure that the inner surface of the gel is not in contact
> >>> with the air bubble by reducing the bubble radius by epsilon (.0001).  Oddly
> >>> enough, the script with up to 4 bubbles works only when the two surfaces are
> >>> coincident, and subtracting an epsilon value (.0001,.001,.01) causes the bubbles
> >>> to turn black, no matter the number.
> >>>
> >>> I would love your input on this issue as I am stumped.  I cannot figure out why
> >>> this renders without issue when I only have a certain number of objects defined.
> >>>
> >>>
> >>> The order of my file:
> >>>
> >>> In my scene, centered at the origin, I have bubbles, inside of gel, inside of a
> >>> glass tube, inside of water, inside of a plexiglass cylinder.
> >>>
> >>> My code
> >>>
> >>> 1) I define variables, set trace level, and place the camera
> >>>
> >>> 2) I create a distributed area light source on a rectangular box
> >>>
> >>> 3) I define the bubbles I want in the gel
> >>>
> >>> 4) I create the glass tube into which the gel will sit
> >>>
> >>> 5) I create the gel region with voids into which the bubbles sit.
> >>>
> >>> 6) I then add water around the glass tube, and then a plexiglass perimeter.
> >>>
> >>>
> >>>
> >>>
> >>
> >> The first thing that I would to would be to increase max_trace_level
> >> further still. It can go up to 255.
> >>
> >> Note : Your area_light is oblique. If you want it to be flat, then, it's
> >> size should be something like this :
> >> area_light 160*x 200*z 65 65
> >> adaptive 0 // start with zero, then, increase if needed
> >> Size of area_light adjusted to match the light_box dimensions.
> >>
> >> During testing, you should disable the area_light. It makes testing and
> >> debugging faster.
> >>
> >> The 100 by 100 get silently increased to 129 by 129 when adaptive is
> >> used. That increase DO NOT affect the rendering time.
> >>
> >> Using dispersion 1 is the same as not using dispersion. It must be
> >> slightly different than 1. Realistic values are usually in the 1.01 to
> >> 1.08. Values less than 1 result in inverted dispersion.
> >>
> >> You are using fade_power 1000 !? You should use 1 or 1001.
> >> Using 1000 may cause some issues.
> >
> > Hello Alain,
> >
> > Thank you so much for your reply and suggestions.  As you may have noticed, I am
> > still in the process of understanding the different features.
> >
> > In the case of max_trace_level, I have put this all the way up to the max as you
> > suggested, but this did not resolve the issue from my original script.  I'll
> > have to keep digging for a solution in that regard.
> >
> > For the area_light, I was certainly not clear on the pov-ray documentation and
> > examples.  From what I understand, I am creating a box (light box) that is
> > parallel with the xy-plan, onto which I'm stretching an array of 100x100 light
> > sources.  And as you stated, by adding the adaptive, feature, this gets
> > increased when running (Great thing to know!  I wasn't completely clear on what
> > happened in the background).
> >
> > I am, however, still confused on why the area_light would be tilted.  As you
> > mentioned, I want a light parallel to the xy plane, and thought that this was
> > the case.
> >
> > Given this example below, my understanding is that my light_box is a box that is
> > 160x200x2 units (x,y,z) and collared white.  I then locate my light_source at
> > <light_loc_x, light_loc_y,light_loc_z>.  I then use the area_light feature to
> > define two points <-10, -10, 10>, <10, 10, 10> from the origin to indicate the
> > vectors over which to stretch the light.
> >
> > #declare light_box = box{ <-80,-100,0>, <80,100,2>
> >          pigment{color White}
> >         } //end light box
> > light_source {
> >      <light_loc_x, light_loc_y,light_loc_z>
> >      color White
> >      area_light <-10, -10, 10>, <10, 10, 10>, 100, 100
> >      adaptive 1
> >      jitter
> >      looks_like { light_box }
> >    }
> >
> >
> The size vectors of an area_light define the 2D dimentions of the
> area_light. A line going from the origin to one of them will be parallel
> to the side of the area_light.
>
> Simple length are used for a light array with sides parallel to the axis.
> Two non-zero component are used for an array parallel to one of the
> major planes but rotated/sheared.
> Three non-zero components will define an array that is not parallel to
> any of the planes.
>
> Normally, we use simple lengts parameters, each in line with one of the
> axis.
>
> In the present example, the vectors are diagonal. They pass through the
> origin <0,0,0> and the defined points, or <-10, -10, 10> and <10, 10, 10>.
>
> It goes from <-10, -10, 10> to <0, 0, 0> to <10, 10, 10>.
> This is perpendicular to the X-Z plane, and at 45° from the X-Y plane.
>
> If you want an area_light parallel to the X-Z plane, then, the vectors
> need their Y components to be zero.
>
> light_source {
>      <light_loc_x, light_loc_y,light_loc_z>
>      color White
>      area_light <-10, 0, 10>, <10, 0, 10>, 100, 100
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }
> Defines an area_light parallel to the Z-X plane, rotated 45°.
>
> light_source {
>      <light_loc_x, light_loc_y,light_loc_z>
>      color White
>      area_light <-10, -10, 0>, <10, 10, 0>, 100, 100
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }
> Defines a LINEAR light array as the two vectors are colinear. It won't,
> but should, generate at least a warning.

Hello Alain,

Thank you again for all of your input and help.  I was unexpectedly out of my
project for a bit, but have implemented a number of changes of the code that
have resolved the issues of my bubbles being opaque.  I have also declared
objects and materials to simplify the code.

The last issue that I'm having is this topic of the area_light.  Your
explanation is much clearer than the documentation online, and I think I now
have it set in my scene correctly.  I just wanted to bounce this off of you as a
sanity check:

What I want is an area_light acting as a diffuse backlight shining through my
tube setup into my camera.  I want this area_light parallel to the XY plane
with dimensions 160x200, centered along the Z-axis, and translated +100 units in
the Z direction.

If I were only defining an area light without attaching it to an object it would
be defined as:

light_source {
    <0, 0,100>
    color White
    area_light <160, 0, 0>, <, 200, 0>, 100, 100
    adaptive 1
    jitter
  }

When I do this, however, the background is all black, as I believe this only
produces rays from the defined area_light, but doesn't really simulate the
appearance of looking into a bright backlight.  To mimic realistic backlighting,
I can then use the command looks_like{ light_box } where I predefine a white
rectangle called "light_box."  My code then looks like this:

#declare light_box = box{ <-80,-100,0>, <80,100,2>
        pigment{color White}
       } //end light box

light_source {
    <0, 0,100>
    color White
    area_light <-10, -10, 0>, <10, 10, 0>, 100, 100
    adaptive 1
    jitter
    looks_like { light_box }
  }

Doing this, I have defined an area_light parallel to the XY, stretched it over
my box dimensions, and translated that box/area_light +100 units in the
Z-direction.

Is this correct?

Sincerely,

bubble_person

[Thomas de Groot] Re: Trouble defining a visible light source [1595 days 15 hours and 46 minutes ago]

Mon, 29 Nov 2021 07:14:40 GMT

Op 28/11/2021 om 13:42 schreef TheRealMorris:

> Thank you, that's a useful tip. The problem is that the wiki isn't usually what
> comes up first when you do a google search but ok, I can work around that.
> 

Bookmark the address? ;-)

-- 
Thomas

[TheRealMorris] Re: Creating soft shadows [1596 days 1 hour and 35 minutes ago]

Sun, 28 Nov 2021 21:25:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "TheRealMorris" <nomail@nomail> wrote:
> > I've been playing around with some top-down scenes using an orthographic camera
> > and one of the things I've tried to achieve, are what I would call "soft
> > shadows". I've played around with multiple light sources, area lights, etc. but
> > no matter what I've done, my shadows look rather really hard; area lights seem
> > to help but the resulting shadow is devoid of any depth and just a bland shade
> > of gray with almost constant coloring.
>
> Without seeing your render, knowing the type and placement of objects in your
> scene, or knowing what your lighting, camera, and default block setting are,
> it's hard to really suggest anything useful.
> Maybe provide a small sample scene?
>
> > The effect I'm trying to achieve is something like the image attached.
>
> Is that - a cylinder or something?
> (It's hard for me to tell)
>
> I'd suggest that you use a sky_sphere to provide more overall ambient
> illumination, maybe an area light to create penumbral shadows, and depending on
> the exact effect you're trying to achieve, you might experiment with transmit,
> no_object, and no_shadow keywords to create an invisible surrogate object to
> filter the light rather than cast a hard shadow.

Thank you for your tips, I will experiment and get back to you on this. I hope
to be able to do so this week, but due to before-Christmas madness, it may have
to wait until the next weekend.

[Bald Eagle] Re: Creating soft shadows [1596 days 7 hours and 35 minutes ago]

Sun, 28 Nov 2021 15:25:00 GMT

"TheRealMorris" <nomail@nomail> wrote:
> I've been playing around with some top-down scenes using an orthographic camera
> and one of the things I've tried to achieve, are what I would call "soft
> shadows". I've played around with multiple light sources, area lights, etc. but
> no matter what I've done, my shadows look rather really hard; area lights seem
> to help but the resulting shadow is devoid of any depth and just a bland shade
> of gray with almost constant coloring.

Without seeing your render, knowing the type and placement of objects in your
scene, or knowing what your lighting, camera, and default block setting are,
it's hard to really suggest anything useful.
Maybe provide a small sample scene?

> The effect I'm trying to achieve is something like the image attached.

Is that - a cylinder or something?
(It's hard for me to tell)

I'd suggest that you use a sky_sphere to provide more overall ambient
illumination, maybe an area light to create penumbral shadows, and depending on
the exact effect you're trying to achieve, you might experiment with transmit,
no_object, and no_shadow keywords to create an invisible surrogate object to
filter the light rather than cast a hard shadow.

[TheRealMorris] Re: Trouble defining a visible light source [1596 days 10 hours and 15 minutes ago]

Sun, 28 Nov 2021 12:45:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 26/11/2021 om 00:03 schreef TheRealMorris:
> > =?utf-8?Q?Harald_J=C3=B6rg?= <haj### [at] posteode> wrote:
> >> TheRealMorris writes:
> >>
> >>> I'm using Povray 3.7.0.8 (which is the version coming straight from the Ubuntu
> >>> 21.10 archives) and I'm trying to define a visible light source. I found this in
> >>> the docs for povray 3.6 here:
> >>>
> >>> http://www.povray.org/documentation/view/3.6.2/137/
> >>>
>
> Tip: When using the POV-Ray documentation, always use the wiki version
> as that is the most up-to-date. Your document page can now be found here:
>
> https://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_1
>
> Personally, I most often start with:
>
> https://wiki.povray.org/content/Reference:Keywords
>
>
> --
> Thomas

Thank you, that's a useful tip. The problem is that the wiki isn't usually what
comes up first when you do a google search but ok, I can work around that.

[TheRealMorris] Creating soft shadows [1596 days 10 hours and 15 minutes ago]

Sun, 28 Nov 2021 12:45:00 GMT

I've been playing around with some top-down scenes using an orthographic camera
and one of the things I've tried to achieve, are what I would call "soft
shadows". I've played around with multiple light sources, area lights, etc. but
no matter what I've done, my shadows look rather really hard; area lights seem
to help but the resulting shadow is devoid of any depth and just a bland shade
of gray with almost constant coloring.

The effect I'm trying to achieve is something like the image attached.

Does anybody have any idea how such an effect could be achieved?

Thank you

[Alain Martel] Re: Trouble defining a visible light source [1598 days 4 hours and 50 minutes ago]

Fri, 26 Nov 2021 18:09:44 GMT

Le 2021-11-25 Ã  17:16, TheRealMorris a Ã©critÂ :
> Hi,
> 
> I'm using Povray 3.7.0.8 (which is the version coming straight from the Ubuntu
> 21.10 archives) and I'm trying to define a visible light source. I found this in
> the docs for povray 3.6 here:
> 
> http://www.povray.org/documentation/view/3.6.2/137/
> 
> So, just for a test I copy/pasted this into my scene:
> 
> 
> light_source
> { <0,0,0> color 1
>    looks_like
>    { sphere
>      { <0,0,0>,0.1
>        color { rgb 1 }
>        finish { ambient 1 }
>      }
>    }
>    translate <10,20,30>
> }
> 
> 
> But I get this error:
> 
> 
> File '/home/trm/light.pov' line 91: Parse Error: No matching } in 'sphere', {
> found instead Fatal error in parser: Cannot parse input.
> 
> Line 91 is the "color { rgb 1 }" one ...
> 
> 
> Did something change in the syntax in version 3.7 or is the example incorrect
> (or am I missing something basic)?
> 
> Thanks for any tips
> 
> 
> 
Replace Â«colorÂ» with Â«pigmentÂ».
Note : The keyword Â«colorÂ»/Â«colourÂ» is no
longer needed. It's a leftover 
from previous versions. Pre version 3.3.

Use this instead :

light_source
{ <10,20,30> rgb 1
   looks_like
   { sphere
     { <0,0,0>,0.1
       pigment { rgb 1 }
       finish { ambient 1 }
     }
   }
}

The coordinate of the looks_like is always relative to the light_source 
location.

[Thomas de Groot] Re: Trouble defining a visible light source [1598 days 15 hours and 30 minutes ago]

Fri, 26 Nov 2021 07:29:56 GMT

Op 26/11/2021 om 00:03 schreef TheRealMorris:
> =?utf-8?Q?Harald_J=C3=B6rg?= <haj### [at] posteode> wrote:
>> TheRealMorris writes:
>>
>>> I'm using Povray 3.7.0.8 (which is the version coming straight from the Ubuntu
>>> 21.10 archives) and I'm trying to define a visible light source. I found this in
>>> the docs for povray 3.6 here:
>>>
>>> http://www.povray.org/documentation/view/3.6.2/137/
>>>

Tip: When using the POV-Ray documentation, always use the wiki version 
as that is the most up-to-date. Your document page can now be found here:

https://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_1

Personally, I most often start with:

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


-- 
Thomas

[TheRealMorris] Re: Trouble defining a visible light source [1598 days 23 hours and 55 minutes ago]

Thu, 25 Nov 2021 23:05:00 GMT

=?utf-8?Q?Harald_J=C3=B6rg?= <haj### [at] posteode> wrote:
> TheRealMorris writes:
>
> > I'm using Povray 3.7.0.8 (which is the version coming straight from the Ubuntu
> > 21.10 archives) and I'm trying to define a visible light source. I found this in
> > the docs for povray 3.6 here:
> >
> > http://www.povray.org/documentation/view/3.6.2/137/
> >
> > So, just for a test I copy/pasted this into my scene:
> >
> >
> > light_source
> > { <0,0,0> color 1
> >   looks_like
> >   { sphere
> >     { <0,0,0>,0.1
> >       color { rgb 1 }
> >       finish { ambient 1 }
> >     }
> >   }
> >   translate <10,20,30>
> > }
> >
> >
> > But I get this error:
> >
> >
> > File '/home/trm/light.pov' line 91: Parse Error: No matching } in 'sphere', {
> > found instead Fatal error in parser: Cannot parse input.
> >
> > Line 91 is the "color { rgb 1 }" one ...
> >
> >
> > Did something change in the syntax in version 3.7 or is the example incorrect
> > (or am I missing something basic)?
>
> The syntax of POV-Ray apparently has changed, 'color' is no longer
> permitted outside a texture or pigment.  Replace
>
>     color { rgb 1 }
>
> with
>
>     pigment { color rgb 1 }
>
> and the scene should render.
> --
> Cheers,
> haj

Thank you, that solves the issue.

[Harald Jörg] Re: Trouble defining a visible light source [1599 days and 9 minutes ago]

Thu, 25 Nov 2021 22:51:41 GMT

TheRealMorris writes:

> I'm using Povray 3.7.0.8 (which is the version coming straight from the Ubuntu
> 21.10 archives) and I'm trying to define a visible light source. I found this in
> the docs for povray 3.6 here:
>
> http://www.povray.org/documentation/view/3.6.2/137/
>
> So, just for a test I copy/pasted this into my scene:
>
>
> light_source
> { <0,0,0> color 1
>   looks_like
>   { sphere
>     { <0,0,0>,0.1
>       color { rgb 1 }
>       finish { ambient 1 }
>     }
>   }
>   translate <10,20,30>
> }
>
>
> But I get this error:
>
>
> File '/home/trm/light.pov' line 91: Parse Error: No matching } in 'sphere', {
> found instead Fatal error in parser: Cannot parse input.
>
> Line 91 is the "color { rgb 1 }" one ...
>
>
> Did something change in the syntax in version 3.7 or is the example incorrect
> (or am I missing something basic)?

The syntax of POV-Ray apparently has changed, 'color' is no longer
permitted outside a texture or pigment.  Replace

    color { rgb 1 }

with

    pigment { color rgb 1 }

and the scene should render.
-- 
Cheers,
haj

[TheRealMorris] Trouble defining a visible light source [1599 days and 40 minutes ago]

Thu, 25 Nov 2021 22:20:00 GMT

Hi,

I'm using Povray 3.7.0.8 (which is the version coming straight from the Ubuntu
21.10 archives) and I'm trying to define a visible light source. I found this in
the docs for povray 3.6 here:

http://www.povray.org/documentation/view/3.6.2/137/

So, just for a test I copy/pasted this into my scene:


light_source
{ <0,0,0> color 1
  looks_like
  { sphere
    { <0,0,0>,0.1
      color { rgb 1 }
      finish { ambient 1 }
    }
  }
  translate <10,20,30>
}


But I get this error:


File '/home/trm/light.pov' line 91: Parse Error: No matching } in 'sphere', {
found instead Fatal error in parser: Cannot parse input.

Line 91 is the "color { rgb 1 }" one ...


Did something change in the syntax in version 3.7 or is the example incorrect
(or am I missing something basic)?

Thanks for any tips

[William F Pokorny] Re: Transparent Objects Become Black [1600 days 22 hours and 42 minutes ago]

Wed, 24 Nov 2021 00:18:27 GMT

On 11/23/21 4:33 PM, Kenneth wrote:
>> Also FWIW. In the most recent povr branch tarball there is a file called
>> albedoFresnelStory.txt in the doc directory with a great deal of finish
>> related detail - should anyone be interested...

> I would definitely like to read that. Could you post a link to it, here or
> elsewhere? I thought I had various links to your povr stuff, but can't find
> them. (They might be on my previous Win 7 machine, which is down at the moment.)
> I actually couldn't find any povr/Github reference on the web at all, even with
> a detailed Google search(!)

See:
http://news.povray.org/povray.binaries.programming/thread/%3C61781abc%40news.povray.org%3E/

or

Web Message: <61781abc@news.povray.org>


---
Thus far, the povr branch is published on the POV-Ray newsgroups as a 
linux/unix tarball a few times a year.

Bill P.

[Kenneth] Re: Transparent Objects Become Black [1601 days 1 hour and 25 minutes ago]

Tue, 23 Nov 2021 21:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> fresnel being on in a many v3.8 finish
> features will cause the negative negative ior values to be treated as
> positive ones. In other words, only the ior magnitude then matters.

Wow, that's...strange. I didn't know. Good detective work.
>
> Also FWIW. In the most recent povr branch tarball there is a file called
> albedoFresnelStory.txt in the doc directory with a great deal of finish
> related detail - should anyone be interested...

I would definitely like to read that. Could you post a link to it, here or
elsewhere? I thought I had various links to your povr stuff, but can't find
them. (They might be on my previous Win 7 machine, which is down at the moment.)
I actually couldn't find any povr/Github reference on the web at all, even with
a detailed Google search(!)

[Alain Martel] Re: Transparent Objects Become Black [1601 days 5 hours and 13 minutes ago]

Tue, 23 Nov 2021 17:46:53 GMT

Le 2021-11-22 Ã  19:52, m@b a Ã©critÂ :
> On 23/11/2021 3:45 am, Kenneth wrote:
>> "m@b" <sai### [at] googlemailcom> wrote:
>>>
>>> In this animation I cycle the ior of a glass sphere from 1.6 to zero and
>>> back:
>>>
>>> <https://youtu.be/gUzp0Bc6u1I>
>>>
>>
>> Nicely done!
>>
>> Are you sure that your sphere's ior goes to exactly 0.0? I am not 
>> seeing the
>> 'glitch' that I mentioned earlier, where ior 0.0 = ior 1.0. I suspect 
>> that your
>> animation code gets the ior *very close* to zero, but then cycles back.
>>
>>
>>
>>
> Yes - well spotted it goes down to 0.001 :-)
> 
That mean a substance where light travels at 1000 times the speed of light.

An ior of zero would mean light travelling at an infinite speed... In 
both directions at the same time.

[m@b] Re: Transparent Objects Become Black [1601 days 22 hours and 7 minutes ago]

Tue, 23 Nov 2021 00:52:48 GMT

On 23/11/2021 3:45 am, Kenneth wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
>>
>> In this animation I cycle the ior of a glass sphere from 1.6 to zero and
>> back:
>>
>> <https://youtu.be/gUzp0Bc6u1I>
>>
> 
> Nicely done!
> 
> Are you sure that your sphere's ior goes to exactly 0.0? I am not seeing the
> 'glitch' that I mentioned earlier, where ior 0.0 = ior 1.0. I suspect that your
> animation code gets the ior *very close* to zero, but then cycles back.
> 
> 
> 
> 
Yes - well spotted it goes down to 0.001 :-)

[Kenneth] Re: Transparent Objects Become Black [1602 days 3 hours and 10 minutes ago]

Mon, 22 Nov 2021 19:50:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
>
> In this animation I cycle the ior of a glass sphere from 1.6 to zero and
> back:
>
> <https://youtu.be/gUzp0Bc6u1I>
>

Nicely done!

Are you sure that your sphere's ior goes to exactly 0.0? I am not seeing the
'glitch' that I mentioned earlier, where ior 0.0 = ior 1.0. I suspect that your
animation code gets the ior *very close* to zero, but then cycles back.

[William F Pokorny] Re: Transparent Objects Become Black [1602 days 12 hours and 21 minutes ago]

Mon, 22 Nov 2021 10:38:49 GMT

On 11/21/21 4:11 PM, Kenneth wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> I've experienced with negative ior. That makes the surface behave as if
>> it had
>> finish{ reflection 1 }
>>
> 
> That's an interesting observation. With my own tests here, I was not sure a
> 'negative' ior was having any effect when lower than 0.5-- until I re-positioned
> the crystal and camera 'just so'. Then I could see at least my sphere inclusion
> subtly changing its appearance as the ior decreased. But as a practical matter,
> the more negative it goes, the less of a visual change there is.
> 

FWIW. The ior value ripples into many finish features and how it is used 
in any given feature depend upon additional finish settings and the 
version of POV-Ray - v3.7, v3.8 releases and the (v4.0 master branch) 
all differ somewhat. For example, fresnel being on in a many v3.8 finish 
features will cause the negative negative ior values to be treated as 
positive ones. In other words, only the ior magnitude then matters.

Also FWIW. In the most recent povr branch tarball there is a file called 
albedoFresnelStory.txt in the doc directory with a great deal of finish 
related detail - should anyone be interested. It was started as an 
attempt at albedo documentation I could understand and intended to be a 
wiki subject for the v3.8 release. As I dug, it grew and grew - and got 
more and more complicated. I changed the aim to be a newsgroup post at 
some point - but I've never posted it.

The file does represent my current understanding of the state of many 
finish features in v3.7/v3.8/v4.0. To a significant degree it explains 
why I'm playing with certain changes in my povr branch.

Anyhow...

Bill P.

[m@b] Re: Transparent Objects Become Black [1602 days 21 hours and 44 minutes ago]

Mon, 22 Nov 2021 01:16:02 GMT

On 22/11/2021 5:11 am, Kenneth wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>>
>> I've experienced with negative ior. That makes the surface behave as if
>> it had
>> finish{ reflection 1 }
>>
> 
> That's an interesting observation. With my own tests here, I was not sure a
> 'negative' ior was having any effect when lower than 0.5-- until I re-positioned
> the crystal and camera 'just so'. Then I could see at least my sphere inclusion
> subtly changing its appearance as the ior decreased. But as a practical matter,
> the more negative it goes, the less of a visual change there is.
> 


In this animation I cycle the ior of a glass sphere from 1.6 to zero and 
back:

<https://youtu.be/gUzp0Bc6u1I>

Probably not relevant :-)

[Kenneth] Re: Transparent Objects Become Black [1603 days 1 hour and 45 minutes ago]

Sun, 21 Nov 2021 21:15:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
>
> I've experienced with negative ior. That makes the surface behave as if
> it had
> finish{ reflection 1 }
>

That's an interesting observation. With my own tests here, I was not sure a
'negative' ior was having any effect when lower than 0.5-- until I re-positioned
the crystal and camera 'just so'. Then I could see at least my sphere inclusion
subtly changing its appearance as the ior decreased. But as a practical matter,
the more negative it goes, the less of a visual change there is.

[Alain Martel] Re: Transparent Objects Become Black [1605 days 4 hours and 30 minutes ago]

Fri, 19 Nov 2021 18:30:15 GMT

Le 2021-11-18 Ã  17:48, Kenneth a Ã©critÂ :
               inclusion ior: 1.2
> When they are the *same*, the inclusions do not show any 'additional' ior effect
> -- like an additional 0.2 for themselves, above the container's 1.2-- but just
> the overall ior of 1.2... as if the container and the inclusions are all "made
> from the same material" (whether as a union or a difference).  I guess that I
> should have expected this-- it seems obvious now-- although I originally thought
> that the inclusions would show 1.2 + 0.2 = 1.4.
> 
> BTW, I also discovered something interesting along the way:
> An ior of 0.0 is the same as ior 1.0. This has actually confused me in the
> past-- because 'negative' iors ( < 1.0 and even < 0.0) can be used for
> interesting effects, but there is this unexpected  'glitch' at exactly 0.0.
> 
> 

The refraction depends on the ratio of the iors on each sides of the 
surface. What you see is what is expected and observed in nature.

I've experienced with negative ior. That makes the surface behave as if 
it had
finish{ reflection 1 }

When you think about it, it makes sense. The ior is the ratio of the 
speed of light in a vacuum divided by the speed of light in a medium.
A negative ior demand a negative speed of light in that medium.

[Thomas de Groot] Re: Transparent Objects Become Black [1605 days 13 hours and 39 minutes ago]

Fri, 19 Nov 2021 09:21:03 GMT

I adapted the script to what I think is a comprehensive scene. I attach 
it here for everybody interested in fairly complex nested interiors. I 
am sure further improvements can be made, which I leave to you.

In p.b.i I post an image of this scene file.

-- 
Thomas

[Kenneth] Re: Transparent Objects Become Black [1606 days and 10 minutes ago]

Thu, 18 Nov 2021 22:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> You didn't say, but I suppose that the
> 'union' renders faster than the 'difference'. Additionally, using blobs
> as inclusions, especially if there are many of them, will speed up
> render time.

My current machine is so fast that I didn't even notice a difference in render
times! But I went back and noted the times: 2.067 sec for union, 2.138 sec for
difference. So yes, the union is faster. BTW, I have almost never experimented
with blobs(!); I need to do that. I still find it amazing that they render
faster in a 'difference' than even simple spheres do-- because I assume that
they are far more complex as math constructs.

BTW, I forgot to mention that my previous image post did not include media,
although I plan to experiment with that addition as well.

There is an interesting difference in how POV-ray treats media vs. ior regarding
embedded objects, which might be unexpected to a new user: Embedded objects with
different iors show the ior changes, whereas embedded media objects do NOT show
their different
                    media method...
                    intervals...
                    samples...
For media, the only values recognized for those settings are from the first
object 'surface' that the camera ray 'sees'-- which is the larger container
object. The inner-object values, if different, are ignored, and take on the
outer object values. It might be assumed that the ior and media 'mechanisms' --
both being interior{...} attributes-- would work the same way, but they don't.

> > [Kenneth wrote:]
> > I have not yet tested my scene to discover how the different iors
> > affect each other-- i.e., simple addition vs. multiplication of the
> > iors. That's difficult to tell, visually. I suspect that it's
> > just addition.

This situation is not quite what I originally thought, although it *is* simple
addition, in a different form:  From further tests, I see that the different
iors interact like this example:
              crystal ior (the container): 1.2
              inclusion ior: 1.2
When they are the *same*, the inclusions do not show any 'additional' ior effect
-- like an additional 0.2 for themselves, above the container's 1.2-- but just
the overall ior of 1.2... as if the container and the inclusions are all "made
from the same material" (whether as a union or a difference).  I guess that I
should have expected this-- it seems obvious now-- although I originally thought
that the inclusions would show 1.2 + 0.2 = 1.4.

BTW, I also discovered something interesting along the way:
An ior of 0.0 is the same as ior 1.0. This has actually confused me in the
past-- because 'negative' iors ( < 1.0 and even < 0.0) can be used for
interesting effects, but there is this unexpected  'glitch' at exactly 0.0.

[Kenneth] Re: Transparent Objects Become Black [1606 days and 30 minutes ago]

Thu, 18 Nov 2021 22:30:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2021-11-17 à 16:06, Kenneth a écrit :
> >
> > .. Of course, I am running into coincident-surface problems with all of
> > those slice recombinations... but I think that's a temporary problem, until
> > I figure out how best to re-position them.
>
> Try clipped_by to make your slices. That way, there will be no internal
> boundaries.

I didn't even think of clipped_by. Thanks, I'll give that a try.

[Alain Martel] Re: Transparent Objects Become Black [1606 days 5 hours and 32 minutes ago]

Thu, 18 Nov 2021 17:28:20 GMT

Le 2021-11-17 Ã  16:06, Kenneth a Ã©critÂ :

> -----
> BTW, this 'multiple-ior' effect gave me an idea-- which I am experimenting
> with-- about creating what looks like *variable* ior within an object, that
> changes along its length or depth, etc. The basic idea is to pre-slice the
> object into *many* very thin box sections, each with a slightly increasing ior
> value, then re-combine the slices to look like the original solid object. Of
> course, I am running into coincident-surface problems with all of those slice
> recombinations... but I think that's a temporary problem, until I figure out how
> best to re-position them. (Should they be separated by tiny 'air' gaps-- or
> should they be slightly embedded into each other?) Anyway, my experiments look
> promising so far, if a bit...odd ;-)
> 
> 

Try clipped_by to make your slices. That way, there will be no internal 
boundaries.

[Thomas de Groot] Re: Transparent Objects Become Black [1606 days 10 hours and 33 minutes ago]

Thu, 18 Nov 2021 12:27:27 GMT

Op 17-11-2021 om 22:06 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Kenneth, I have not tested it here, but are the 'voids' really
>> necessary? Is it not enough to just add the bubbles to the gel, as both
>> have different ior's and do not interact?
>>
> 
> Apparently, the visual result is exactly the same either way.
> 
> Here is my own "poor man's crystal", ha-- just an intersection of three rotated
> boxes. The inclusions are simple shapes. I rendered two versions, with the
> inclusions as a UNION with the crystal vs. being DIFFERENCED from it as voids. I
> see absolutely no visual change, although I was expecting them to look
> completely different. It seems that the ior 'effect' depends only on the
> *surfaces* that the camera ray sees, not really on any imagined interior
> substance of the inclusions.
> 
Yes, that confirms my guess. You didn't say, but I suppose that the 
'union' renders faster than the 'difference'. Additionally, using blobs 
as inclusions, especially if there are many of them, will speed up 
render time.

> I have not yet tested my scene to discover how the different iors affect each
> other-- i.e., simple addition vs. multiplication of the iors. That's difficult
> to tell, visually. I suspect that it's just addition.
> 
I am not sure. It looks like that - independent from ior - the used 
media inside container and inclusions are treated separately. In my 
experiments I do no see any cross-influence, addition or multiplication, 
of colors.

> -----
> BTW, this 'multiple-ior' effect gave me an idea-- which I am experimenting
> with-- about creating what looks like *variable* ior within an object, that
> changes along its length or depth, etc. The basic idea is to pre-slice the
> object into *many* very thin box sections, each with a slightly increasing ior
> value, then re-combine the slices to look like the original solid object. Of
> course, I am running into coincident-surface problems with all of those slice
> recombinations... but I think that's a temporary problem, until I figure out how
> best to re-position them. (Should they be separated by tiny 'air' gaps-- or
> should they be slightly embedded into each other?) Anyway, my experiments look
> promising so far, if a bit...odd ;-)
> 
I am interested to see the result.


@bubble_person: sorry if this discussion 'seems' to ignore you. This is 
not the intention nor the reality; Your original question generated a 
number of issues which we are not sure about, and I think everybody will 
benefit in the end.

-- 
Thomas

[Kenneth] Re: Transparent Objects Become Black [1607 days 1 hour and 50 minutes ago]

Wed, 17 Nov 2021 21:10:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Kenneth, I have not tested it here, but are the 'voids' really
> necessary? Is it not enough to just add the bubbles to the gel, as both
> have different ior's and do not interact?
>

Apparently, the visual result is exactly the same either way.

Here is my own "poor man's crystal", ha-- just an intersection of three rotated
boxes. The inclusions are simple shapes. I rendered two versions, with the
inclusions as a UNION with the crystal vs. being DIFFERENCED from it as voids. I
see absolutely no visual change, although I was expecting them to look
completely different. It seems that the ior 'effect' depends only on the
*surfaces* that the camera ray sees, not really on any imagined interior
substance of the inclusions.

I have not yet tested my scene to discover how the different iors affect each
other-- i.e., simple addition vs. multiplication of the iors. That's difficult
to tell, visually. I suspect that it's just addition.

-----
BTW, this 'multiple-ior' effect gave me an idea-- which I am experimenting
with-- about creating what looks like *variable* ior within an object, that
changes along its length or depth, etc. The basic idea is to pre-slice the
object into *many* very thin box sections, each with a slightly increasing ior
value, then re-combine the slices to look like the original solid object. Of
course, I am running into coincident-surface problems with all of those slice
recombinations... but I think that's a temporary problem, until I figure out how
best to re-position them. (Should they be separated by tiny 'air' gaps-- or
should they be slightly embedded into each other?) Anyway, my experiments look
promising so far, if a bit...odd ;-)

[Thomas de Groot] Re: Transparent Objects Become Black [1607 days 6 hours and 7 minutes ago]

Wed, 17 Nov 2021 16:53:12 GMT

Kenneth, I have not tested it here, but are the 'voids' really 
necessary? Is it not enough to just add the bubbles to the gel, as both 
have different ior's and do not interact?

See my recent test in p.b.i. with the crystal + huge inclusion.

-- 
Thomas

[Thomas de Groot] Re: Transparent Objects Become Black [1607 days 15 hours and 18 minutes ago]

Wed, 17 Nov 2021 07:42:35 GMT

Op 16/11/2021 om 20:57 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>> This brings the following question: What is the difference between
>> fade_power 2 and fade_power 1001, as both, in the docs/wiki, are
>> described as 'exponential'?
> 
> I did a search through old newsgroups too, and found a useful comment by Alain
> posted Dec 18 2017 (with my own comments in brackets, which I hope are correct):
> 
Hey! Thanks Kenneth! This does answer some questions indeed. I never 
paid much attention to the 'issue', and always mindlessly used the 1001 
value when necessary. The query from bubble_person made me wonder 
suddenly, however.

> "For a material [i.e., showing light attenuation inside a translucent object]
> you should use fade_power 1 or fade_power 1001 to get a more realistic result.
> Fade_power 2 is for light attenuation over a distance in empty space." [i.e., in
> POV-ray's 'air' or external space, not *inside* an object.]
> 
> So there is a difference in how and when fade_power is used, apparently.
> 
Good. This is an additional information of importance it seems. If 
confirmed by 'the powers that be', I would be grateful if this info 
could be added to the wiki and/or official documentation.

>>
>> Ive tells us: "note that this "fade_power 1001" statement is an old (and
>> really dirty as it lacks any logic) hack that is part of POV-Ray since
>> ages to turn realistic fade power calculation on."
>>
> 
> I saw that one too. :-) And here's a later comment by Clipka, dated Oct 27 2012:
> 
> "...realistic fading for interiors is exponential rather than
> linear; specify a fade_power value of 1000 or greater (1001 is often
> used, but it doesn't really matter), POV-Ray will then enable
> exponential fading."
> 
> It seems that fade_power 1001 has been used for quite a long time. It's in a
> section of code in a post by Ross on September 11 2003 entitled "glass objects".
> 
He he! I had not come across those two. I believe the comment by Clipka 
should also find its way, one way or another, to the documentation.

> Personally, I have not yet run a comparative test of values <1000 vs. 1000 vs.
> 1001 vs. some higher value, so I can't comment on the expected effects. It seems
> that a value of 1001 *or higher* turns on the 'exponential' fading, not
> specifically 1001. What that exponent *is*, I don't know; I guess it's derived
> by the in-built equation mentioned in the docs:
>              Attenuation = exp(-depth/fade_dist)
> 
Yes, I expect that is the case.

Thanks again for your sleuth work! :-)

-- 
Thomas

[Kenneth] Re: Transparent Objects Become Black [1608 days 3 hours ago]

Tue, 16 Nov 2021 20:00:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> This brings the following question: What is the difference between
> fade_power 2 and fade_power 1001, as both, in the docs/wiki, are
> described as 'exponential'?

I did a search through old newsgroups too, and found a useful comment by Alain
posted Dec 18 2017 (with my own comments in brackets, which I hope are correct):

"For a material [i.e., showing light attenuation inside a translucent object]
you should use fade_power 1 or fade_power 1001 to get a more realistic result.
Fade_power 2 is for light attenuation over a distance in empty space." [i.e., in
POV-ray's 'air' or external space, not *inside* an object.]

So there is a difference in how and when fade_power is used, apparently.

>
> Ive tells us: "note that this "fade_power 1001" statement is an old (and
> really dirty as it lacks any logic) hack that is part of POV-Ray since
> ages to turn realistic fade power calculation on."
>

I saw that one too. :-) And here's a later comment by Clipka, dated Oct 27 2012:

"...realistic fading for interiors is exponential rather than
linear; specify a fade_power value of 1000 or greater (1001 is often
used, but it doesn't really matter), POV-Ray will then enable
exponential fading."

It seems that fade_power 1001 has been used for quite a long time. It's in a
section of code in a post by Ross on September 11 2003 entitled "glass objects".

Personally, I have not yet run a comparative test of values <1000 vs. 1000 vs.
1001 vs. some higher value, so I can't comment on the expected effects. It seems
that a value of 1001 *or higher* turns on the 'exponential' fading, not
specifically 1001. What that exponent *is*, I don't know; I guess it's derived
by the in-built equation mentioned in the docs:
            Attenuation = exp(-depth/fade_dist)

??

[Thomas de Groot] Re: Transparent Objects Become Black [1608 days 10 hours and 2 minutes ago]

Tue, 16 Nov 2021 12:57:47 GMT

Op 16-11-2021 om 11:52 schreef Mr:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 11-11-2021 om 19:19 schreef bubble_person:
>>> Finally, with the fade_power, how is 1000 bad, but 1 or 1001 good?  I did a
>>> little copy-pasting of this part from an example, so I had not really asked
>>> myself what realistic values should be.
>>>
>> Alain is right about the fade_power of 1001. However, when I wanted to
>> find again the location of this in the wiki pages to help your
>> understanding of it - surprisingly - I was unable to find it! I am sure
>> it was there, somewhere, in the documentation...
>>
>> --
>> Thomas
> 
> Generally, when this occurs, the bit of information, is rather in release logs
> instead of doc, if you do find it in one or the other, please share, so that we
> can update or ignore. Meanwhile, I added some of Alain's guidelines to
> dispersion page in the wiki which are developing a bit further than current doc,
> so if a native speaker wants to restyle, do not hesitate and add your
> improvements in the page's discussion:
> https://wiki.povray.org/content/Reference:Interior#Dispersion
> 
I am not sure. In the 'Attenuation' section of 'Dispersion & Caustics', 
there is that mention about "If you set fade_power in the interior of an 
object at 1000 or above, a realistic exponential attenuation function 
will be used". I guess that the '1001' value comes from there.

This brings the following question: What is the difference between 
fade_power 2 and fade_power 1001, as both, in the docs/wiki, are 
described as 'exponential'?

Finally, in:
https://news.povray.org/povray.binaries.images/thread/%3C4f2654d6%241%40news.povray.org%3E/

Ive tells us: "note that this "fade_power 1001" statement is an old (and 
really dirty as it lacks any logic) hack that is part of POV-Ray since 
ages to turn realistic fade power calculation on."

Food for thoughts?

-- 
Thomas

[Mr] Re: Transparent Objects Become Black [1608 days 12 hours and 5 minutes ago]

Tue, 16 Nov 2021 10:55:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 11-11-2021 om 19:19 schreef bubble_person:
> > Finally, with the fade_power, how is 1000 bad, but 1 or 1001 good?  I did a
> > little copy-pasting of this part from an example, so I had not really asked
> > myself what realistic values should be.
> >
> Alain is right about the fade_power of 1001. However, when I wanted to
> find again the location of this in the wiki pages to help your
> understanding of it - surprisingly - I was unable to find it! I am sure
> it was there, somewhere, in the documentation...
>
> --
> Thomas

Generally, when this occurs, the bit of information, is rather in release logs
instead of doc, if you do find it in one or the other, please share, so that we
can update or ignore. Meanwhile, I added some of Alain's guidelines to
dispersion page in the wiki which are developing a bit further than current doc,
so if a native speaker wants to restyle, do not hesitate and add your
improvements in the page's discussion:
https://wiki.povray.org/content/Reference:Interior#Dispersion

Thanks for your patience

[Vasconcelos] Re: Change component color [1609 days 15 hours and 50 minutes ago]

Mon, 15 Nov 2021 07:10:00 GMT

"m@b" <sai### [at] googlemailcom> wrote:
> On 14/11/2021 11:42 am, Vasconcelos wrote:
> > Hi , I 'm a beginner in POV Ray , could you help me ?
> > I did a render of an electronic board and I would like to change the color
> > of a capacitor, I checked the file "e3d_cap.inc", I made several changes, but I
> > am not able to change the color of the capacitor body. In fact, I can even
> > change the color, but the component's polarity marking disappears.
> > Help !!
>
>
>  > pigment{image_map{png "tex_elko.png"}scale tex_scale  }
>
>
>
> The file "tex_elko.png" is an image, the image is mapped onto a cylinder
> by POV-Ray.
>
> You can edit the image using any graphics programme such as Paint on
> windows.

Thank you.

[m@b] Re: Change component color [1610 days 15 hours and 13 minutes ago]

Sun, 14 Nov 2021 07:47:18 GMT

On 14/11/2021 11:42 am, Vasconcelos wrote:
> Hi , I 'm a beginner in POV Ray , could you help me ?
> I did a render of an electronic board and I would like to change the color
> of a capacitor, I checked the file "e3d_cap.inc", I made several changes, but I
> am not able to change the color of the capacitor body. In fact, I can even
> change the color, but the component's polarity marking disappears.
> Help !!


 > pigment{image_map{png "tex_elko.png"}scale tex_scale  }



The file "tex_elko.png" is an image, the image is mapped onto a cylinder 
by POV-Ray.

You can edit the image using any graphics programme such as Paint on 
windows.

[Vasconcelos] Change component color [1610 days 19 hours and 15 minutes ago]

Sun, 14 Nov 2021 03:45:00 GMT

Hi , I 'm a beginner in POV Ray , could you help me ?
I did a render of an electronic board and I would like to change the color
of a capacitor, I checked the file "e3d_cap.inc", I made several changes, but I
am not able to change the color of the capacitor body. In fact, I can even
change the color, but the component's polarity marking disappears.
Help !!


union{
    //Elko KÃ¶rper
    difference{
        union{

            cylinder{<0,0.5,0><0,hig-0.5,0>dia }


            //Elko Rundung oben
            torus{dia-0.5,0.5 translate<0,hig-0.5,0> }

            difference{

                cylinder{<0,hig-0.5,0><0,hig,0>dia-0.5 }

                cylinder{<0,hig-0.5,0><0,hig+0.1,0>dia*0.8*pow(dia/16,0.11)}

            }
            //Elko Rundung unten
            torus{dia-0.5,0.5 translate<0,0.5,0>}
        }
        //Aussparung unten
        torus{dia+0.85,1 translate<0,2.5,0>}

        //Textur fÃ¼r Minusmarkierung
        //pigment{image_map{png "tex_elko.png"}scale tex_scale} => AQUI ERA O
TEXTO ORIGINAL/ ALTERAÇÃO DA COR DO CAPACITOR


        pigment{image_map{png "tex_elko.png"}scale tex_scale  }


        finish{reflection { 0.03, .1}   phong 0.4 crand 0.05 ambient (0.1 *
global_ambient_mul)}



    }

    //Abdeckung oben
    difference{

        cylinder{<0,hig-0.5,0><0,hig-0.1,0>dia*0.8*pow(dia/16,0.11)}
        box{<0,hig-0.35,-0.1><dia,hig,0.1>}
        box{<0,hig-0.35,-0.1><dia,hig,0.1> rotate<0,120,0>}
        box{<0,hig-0.35,-0.1><dia,hig,0.1> rotate<0,240,0>}

        texture{col_silver}

    }

    //Abdeckung unten
    cylinder{<0,0.2,0><0,0.5,0>dia-0.5 pigment{Black}}
    union{
        #if(pin_short=off)
            cylinder{<0,0,0><0,-14.5,0>dia_b translate<dis/2,0,0>}    //Beinchen
rechts
            cylinder{<0,0,0><0,-17.5,0>dia_b translate<-dis/2,0,0>}   //Beinchen
links
        #else
            cylinder{<0,0,0><0,-1*(pcb_height+pin_length)-0.2,0>dia_b
translate<dis/2,0,0>}    //Beinchen rechts
            cylinder{<0,0,0><0,-1*(pcb_height+pin_length)-0.2,0>dia_b
translate<-dis/2,0,0>}   //Beinchen links
        #end
        texture{e3d_tex_silver}

    }

    //Beschriftung
    intersection{
        cylinder{<0,0,0><0,hig,0>dia}
        text {ttf besch_font value 0.2, 0 scale val_size rotate<0,0,90>
translate<0,0,-dia>}
        rotate<0,0,180>
        rotate<0,10,0>
        translate<0,hig-val_size,-0.001>
        pigment {rgb<0.4,0.6,1>}


    }
    intersection{
        cylinder{<0,0,0><0,hig,0>dia }
        text {ttf besch_font value 0.2, 0 scale val_size rotate<0,0,90>
translate<0,0,-dia>}
        rotate<0,0,180>
        rotate<0,100,0>
        translate<-0.001,hig-val_size,0>
        pigment {rgb<0.4,0.6,1>}

    }
    intersection{
        cylinder{<0,0,0><0,hig,0>dia }
        text {ttf besch_font value 0.2, 0 scale val_size rotate<0,0,90>
translate<0,0,-dia>}
        rotate<0,0,180>
        rotate<0,190,0>
        translate<0,hig-val_size,0.001>
        pigment {rgb<0.4,0.6,1>}
    }
    finish{F_MetalE ambient (0.1 * global_ambient_mul)}
    translate<0,0.2,0>


}
#end

[Vasconcelos] Change component color [1610 days 19 hours and 25 minutes ago]

Sun, 14 Nov 2021 03:35:00 GMT

Hi , I 'm a beginner in POV Ray , could you help me ?
I did a redereização of an electronic board and I would like to change the
color
of a capacitor, I checked the file "e3d_cap.inc", I made several changes, but I
am not able to change the color of the capacitor body. In fact, I can even
change the color, but the component's polarity marking disappears.
Help !!

[Thomas de Groot] Re: Transparent Objects Become Black [1611 days 9 hours and 32 minutes ago]

Sat, 13 Nov 2021 13:27:46 GMT

Op 11-11-2021 om 19:19 schreef bubble_person:
> Finally, with the fade_power, how is 1000 bad, but 1 or 1001 good?  I did a
> little copy-pasting of this part from an example, so I had not really asked
> myself what realistic values should be.
> 
Alain is right about the fade_power of 1001. However, when I wanted to 
find again the location of this in the wiki pages to help your 
understanding of it - surprisingly - I was unable to find it! I am sure 
it was there, somewhere, in the documentation...

-- 
Thomas

[Alain Martel] Re: Transparent Objects Become Black [1612 days 4 hours and 20 minutes ago]

Fri, 12 Nov 2021 18:40:12 GMT

Le 2021-11-12 Ã  12:19, Kenneth a Ã©critÂ :

> To put it very simply, POV-Ray's default texture{...} has ALL of the many
> possible attributes included in it, behind-the-scenes-- but they are set up so
> that you see a simple (bland!) pigment{...}, finish{...},  interior{...} etc.
> For older versions, the pigment color is opaque black; for newer versions, it's
> opaque white (and I'm not exactly sure when that change occurred-- possibly with
> v3.7?).  Those are rgbft <0,0,0,0,0> *or* rgbft <1,1,1,0,0>.
> The change occurred between 3.7 and 3.8.

[Alain Martel] Re: Transparent Objects Become Black [1612 days 4 hours and 26 minutes ago]

Fri, 12 Nov 2021 18:34:33 GMT

Le 2021-11-11 Ã  13:19, bubble_person a Ã©critÂ :
> Alain Martel <kua### [at] videotronca> wrote:
>> Le 2021-11-11 Ã  08:06, bubble_person a Ã©critÂ :
>>> Hello Forum,
>>>
>>> I am relatively new to POV-RAY, but have a functional script .
>>>
>>> I am simulating air bubbles in a glass tube full of gel.  I am running into a
>>> funny problem where, if I add too many bubbles to the script, they go from being
>>> transparent and rendered correctly, to a completely opaque, black object through
>>> which no light shines.
>>>
>>> Things that don't seem to work:
>>>
>>> 1) Increasing the  max_trace_level
>>>
>>> 2) I have tried to be sure that the inner surface of the gel is not in contact
>>> with the air bubble by reducing the bubble radius by epsilon (.0001).  Oddly
>>> enough, the script with up to 4 bubbles works only when the two surfaces are
>>> coincident, and subtracting an epsilon value (.0001,.001,.01) causes the bubbles
>>> to turn black, no matter the number.
>>>
>>> I would love your input on this issue as I am stumped.  I cannot figure out why
>>> this renders without issue when I only have a certain number of objects defined.
>>>
>>>
>>> The order of my file:
>>>
>>> In my scene, centered at the origin, I have bubbles, inside of gel, inside of a
>>> glass tube, inside of water, inside of a plexiglass cylinder.
>>>
>>> My code
>>>
>>> 1) I define variables, set trace level, and place the camera
>>>
>>> 2) I create a distributed area light source on a rectangular box
>>>
>>> 3) I define the bubbles I want in the gel
>>>
>>> 4) I create the glass tube into which the gel will sit
>>>
>>> 5) I create the gel region with voids into which the bubbles sit.
>>>
>>> 6) I then add water around the glass tube, and then a plexiglass perimeter.
>>>
>>>
>>>
>>>
>>
>> The first thing that I would to would be to increase max_trace_level
>> further still. It can go up to 255.
>>
>> Note : Your area_light is oblique. If you want it to be flat, then, it's
>> size should be something like this :
>> area_light 160*x 200*z 65 65
>> adaptive 0 // start with zero, then, increase if needed
>> Size of area_light adjusted to match the light_box dimensions.
>>
>> During testing, you should disable the area_light. It makes testing and
>> debugging faster.
>>
>> The 100 by 100 get silently increased to 129 by 129 when adaptive is
>> used. That increase DO NOT affect the rendering time.
>>
>> Using dispersion 1 is the same as not using dispersion. It must be
>> slightly different than 1. Realistic values are usually in the 1.01 to
>> 1.08. Values less than 1 result in inverted dispersion.
>>
>> You are using fade_power 1000 !? You should use 1 or 1001.
>> Using 1000 may cause some issues.
> 
> Hello Alain,
> 
> Thank you so much for your reply and suggestions.  As you may have noticed, I am
> still in the process of understanding the different features.
> 
> In the case of max_trace_level, I have put this all the way up to the max as you
> suggested, but this did not resolve the issue from my original script.  I'll
> have to keep digging for a solution in that regard.
> 
> For the area_light, I was certainly not clear on the pov-ray documentation and
> examples.  From what I understand, I am creating a box (light box) that is
> parallel with the xy-plan, onto which I'm stretching an array of 100x100 light
> sources.  And as you stated, by adding the adaptive, feature, this gets
> increased when running (Great thing to know!  I wasn't completely clear on what
> happened in the background).
> 
> I am, however, still confused on why the area_light would be tilted.  As you
> mentioned, I want a light parallel to the xy plane, and thought that this was
> the case.
> 
> Given this example below, my understanding is that my light_box is a box that is
> 160x200x2 units (x,y,z) and collared white.  I then locate my light_source at
> <light_loc_x, light_loc_y,light_loc_z>.  I then use the area_light feature to
> define two points <-10, -10, 10>, <10, 10, 10> from the origin to indicate the
> vectors over which to stretch the light.
> 
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>          pigment{color White}
>         } //end light box
> light_source {
>      <light_loc_x, light_loc_y,light_loc_z>
>      color White
>      area_light <-10, -10, 10>, <10, 10, 10>, 100, 100
>      adaptive 1
>      jitter
>      looks_like { light_box }
>    }
> 
> 
The size vectors of an area_light define the 2D dimentions of the 
area_light. A line going from the origin to one of them will be parallel 
to the side of the area_light.

Simple length are used for a light array with sides parallel to the axis.
Two non-zero component are used for an array parallel to one of the 
major planes but rotated/sheared.
Three non-zero components will define an array that is not parallel to 
any of the planes.

Normally, we use simple lengts parameters, each in line with one of the 
axis.

In the present example, the vectors are diagonal. They pass through the 
origin <0,0,0> and the defined points, or <-10, -10, 10> and <10, 10, 10>.

It goes from <-10, -10, 10> to <0, 0, 0> to <10, 10, 10>.
This is perpendicular to the X-Z plane, and at 45Â° from the X-Y plane.

If you want an area_light parallel to the X-Z plane, then, the vectors 
need their Y components to be zero.

light_source {
     <light_loc_x, light_loc_y,light_loc_z>
     color White
     area_light <-10, 0, 10>, <10, 0, 10>, 100, 100
     adaptive 1
     jitter
     looks_like { light_box }
   }
Defines an area_light parallel to the Z-X plane, rotated 45Â°.

light_source {
     <light_loc_x, light_loc_y,light_loc_z>
     color White
     area_light <-10, -10, 0>, <10, 10, 0>, 100, 100
     adaptive 1
     jitter
     looks_like { light_box }
   }
Defines a LINEAR light array as the two vectors are colinear. It won't, 
but should, generate at least a warning.

[Kenneth] Re: Transparent Objects Become Black [1612 days 5 hours and 35 minutes ago]

Fri, 12 Nov 2021 17:25:00 GMT

"bubble_person" <nomail@nomail> wrote:
>
>
> Hello Kenneth,
>
> Thank you for all of your sleuthing and the stripped-down example...This
> gives me some good footing to streamline my POV-RAY scripting.
>

Glad to help. There are many forum users here who can give you good advice, so
don't hesitate to ask even the most basic questions.

By the way: The 'default' attributes and values for a texture{...} are not
easily found in the documentation, and they're not all in one place for easy
look-up as far as I know. And some have changed over time, depending on which
version of POV-ray you are running.

To put it very simply, POV-Ray's default texture{...} has ALL of the many
possible attributes included in it, behind-the-scenes-- but they are set up so
that you see a simple (bland!) pigment{...}, finish{...},  interior{...} etc.
For older versions, the pigment color is opaque black; for newer versions, it's
opaque white (and I'm not exactly sure when that change occurred-- possibly with
v3.7?).  Those are rgbft <0,0,0,0,0> *or* rgbft <1,1,1,0,0>.

So when you manually specify a specific texture{...} for an object, whatever
attributes and values you include there simply override the built-in 'default'
values-- but any remaining non-specified attributes are still there, at their
defaults. That's why you can specify an object with NO manually-attached
texture{...} yet still see the object in your scene.

Also, take a look at the #default{...} keyword in the docs; it's an easy and
time-saving way of setting up any texture attribute OR full texture near the
beginning of a scene file, which is then used for *every* object in your scene
(and you can then override any of the attributes on a per-object basis, as
needed.) Less typing drudgery!  ;-)

[jr] Re: Transparent Objects Become Black [1612 days 9 hours and 50 minutes ago]

Fri, 12 Nov 2021 13:10:00 GMT

hi,

"bubble_person" <nomail@nomail> wrote:
> ...
> Hello Jr.,
> ...

good to see (from yr reply to Kenneth) that "you're sorted" :-).  re voids,
there's also the 'hollow' keyword, which may be of use.
<https://wiki.povray.org/content/Reference:Hollow_Object_Modifier>


regards, jr.

[bubble person] Re: Transparent Objects Become Black [1612 days 13 hours and 55 minutes ago]

Fri, 12 Nov 2021 09:05:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > ... So in effect, your original five sphere definitions are not even being
> > used; and the ones you did use are simply opaque.
>
> Correction: In your scene, both sets of spheres ARE being rendered at the same
> time... by mistake of course...and they exactly overlap, which is probably why
> you (and I!) were seeing odd results during various experiments. When multiple
> objects occupy the same exact space, POV-ray's built-in precision with its
> calculations can sometimes show one object or the other, or else 'coincident
> surface' speckles or other oddities.

Hello Kenneth,

Thank you for all of your sleuthing and the stripped-down example.  This has
really cleared up a fundamental misunderstanding that I was having about
inserting objects.  I was under the impression that the spheres defined in the
difference{} function were only there to carve out holes.  I didn't realise I
could actually define material properties for those voids.  That's the reason I
defined the bubbles twice, thinking I had to scoop out the region, and then fill
it with a bubble with the desired material properties.  It makes a lot of sense
that I was getting funny results with the doubly-defined bubbles occupying the
same space!

I also appreciate the example of the object definitions. As you can see with my
long-winded scripting, I was pushing my basic knowledge of the program as far as
I could without adding the hierarchical structures that would make it elegant.
haha!  This gives me some good footing to streamline my POV-RAY scripting.

I'll keep everyone updated as I try to make the script cleaner using your
examples and the input of others in the post.

Sincerely,

bubble_person

[Bald Eagle] Re: Transparent Objects Become Black [1612 days 22 hours and 50 minutes ago]

Fri, 12 Nov 2021 00:10:00 GMT

"bubble_person" <nomail@nomail> wrote:
> Alain Martel <kua### [at] videotronca> wrote:

> > Note : Your area_light is oblique. If you want it to be flat, then, it's
> > size should be something like this :
> > area_light 160*x 200*z 65 65

> For the area_light, I was certainly not clear on the pov-ray documentation and
> examples.  From what I understand, I am creating a box (light box) that is
> parallel with the xy-plan, onto which I'm stretching an array of 100x100 light
> sources.

>
> I am, however, still confused on why the area_light would be tilted.  As you
> mentioned, I want a light parallel to the xy plane, and thought that this was
> the case.

I'm confused also.  I'm not entirely certain that using looks_like will tilt the
area light array.  (I'm not sure of the top of my head how to accurately
visualize the actual area light.)

> Given this example below, my understanding is that my light_box is a box that is
> 160x200x2 units (x,y,z) and collared white.  I then locate my light_source at
> <light_loc_x, light_loc_y,light_loc_z>.  I then use the area_light feature to
> define two points <-10, -10, 10>, <10, 10, 10> from the origin to indicate the
> vectors over which to stretch the light.
>
> #declare light_box = box{ <-80,-100,0>, <80,100,2>
>         pigment{color White}
>        } //end light box
> light_source {
>     <light_loc_x, light_loc_y,light_loc_z>
>     color White
>     area_light <-10, -10, 10>, <10, 10, 10>, 100, 100
>     adaptive 1
>     jitter
>     looks_like { light_box }
>   }

So, a few things, in no particular order or importance:

It's ... weird to be that you're making a box of one size and an area light of
another.  Use the same dimensions.

Also kinda clunky that you're defining location x, y, and z separately, when you
could just declare a vector.

Is your light box visible in the scene? (I can't see it)  If not, can you just
use  a light source without the looks_like attribute?

Just in case you didn't know, when x, y, and z are used outside of function {}
equation definitions, they refer to vectors  (<1, 0, 0>, etc.)
So you can do something like 10*x to get <10, 0, 0>

Also, we have a weird thing in POV-Ray called automatic vector promotion.  They
way it works is, say you are making your light box, and you need two 3D vectors.
 If you are making a unit cube centered at the origin, you can do something
like:
box {-0.5, 0.5}, and the automatic vector promotion will promote --- expand ---
the scalar quantities into the 3D vectors that POV-Ray's parser is expecting for
those parameters.
So what you'd wind up with is the equivalent of:
box {<-0.5, -0.5, -0.5>, <0.5, 0.5, 0.5>}

This can be convenient for certain things, and a real PITA with others (rgbft
color vectors)

I noticed that Kenneth tracked down your core issue - and you may want to try
modeling individual components separately, one by one, in a standalone scene so
that you can see exactly what is going on.  That would have shown you that your
spheres have the default texture, not the one you _thought_ you were using.

You're making a tube filled with stuff that will be in some rotated position.
Rather than rotating every individual component to line up with a rotated tube,
model your tube around the origin, place everything inside it, and then rotate
the whole union {} of everything all at once.

To save a million lines of code, declare your material, ONCE, and then use that
declared material name.

To save even more internal gymnastics, write a loop to make all of your spheres
inside of a union, and then apply that material to the entire union of spheres,
not to each individual sphere.

Think in a hierarchies and flowcharts.

Busy here doing other things and juggling crises, but looking forward to seeing
your progress and answering any questions when time allows.  :)

- Bill

[Kenneth] Re: Transparent Objects Become Black [1613 days 4 hours and 25 minutes ago]

Thu, 11 Nov 2021 18:35:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> ... So in effect, your original five sphere definitions are not even being
> used; and the ones you did use are simply opaque.

Correction: In your scene, both sets of spheres ARE being rendered at the same
time... by mistake of course...and they exactly overlap, which is probably why
you (and I!) were seeing odd results during various experiments. When multiple
objects occupy the same exact space, POV-ray's built-in precision with its
calculations can sometimes show one object or the other, or else 'coincident
surface' speckles or other oddities.

[bubble person] Re: Transparent Objects Become Black [1613 days 4 hours and 40 minutes ago]

Thu, 11 Nov 2021 18:20:00 GMT

Alain Martel <kua### [at] videotronca> wrote:
> Le 2021-11-11 à 08:06, bubble_person a écrit :
> > Hello Forum,
> >
> > I am relatively new to POV-RAY, but have a functional script .
> >
> > I am simulating air bubbles in a glass tube full of gel.  I am running into a
> > funny problem where, if I add too many bubbles to the script, they go from being
> > transparent and rendered correctly, to a completely opaque, black object through
> > which no light shines.
> >
> > Things that don't seem to work:
> >
> > 1) Increasing the  max_trace_level
> >
> > 2) I have tried to be sure that the inner surface of the gel is not in contact
> > with the air bubble by reducing the bubble radius by epsilon (.0001).  Oddly
> > enough, the script with up to 4 bubbles works only when the two surfaces are
> > coincident, and subtracting an epsilon value (.0001,.001,.01) causes the bubbles
> > to turn black, no matter the number.
> >
> > I would love your input on this issue as I am stumped.  I cannot figure out why
> > this renders without issue when I only have a certain number of objects defined.
> >
> >
> > The order of my file:
> >
> > In my scene, centered at the origin, I have bubbles, inside of gel, inside of a
> > glass tube, inside of water, inside of a plexiglass cylinder.
> >
> > My code
> >
> > 1) I define variables, set trace level, and place the camera
> >
> > 2) I create a distributed area light source on a rectangular box
> >
> > 3) I define the bubbles I want in the gel
> >
> > 4) I create the glass tube into which the gel will sit
> >
> > 5) I create the gel region with voids into which the bubbles sit.
> >
> > 6) I then add water around the glass tube, and then a plexiglass perimeter.
> >
> >
> >
> >
>
> The first thing that I would to would be to increase max_trace_level
> further still. It can go up to 255.
>
> Note : Your area_light is oblique. If you want it to be flat, then, it's
> size should be something like this :
> area_light 160*x 200*z 65 65
> adaptive 0 // start with zero, then, increase if needed
> Size of area_light adjusted to match the light_box dimensions.
>
> During testing, you should disable the area_light. It makes testing and
> debugging faster.
>
> The 100 by 100 get silently increased to 129 by 129 when adaptive is
> used. That increase DO NOT affect the rendering time.
>
> Using dispersion 1 is the same as not using dispersion. It must be
> slightly different than 1. Realistic values are usually in the 1.01 to
> 1.08. Values less than 1 result in inverted dispersion.
>
> You are using fade_power 1000 !? You should use 1 or 1001.
> Using 1000 may cause some issues.

Hello Alain,

Thank you so much for your reply and suggestions.  As you may have noticed, I am
still in the process of understanding the different features.

In the case of max_trace_level, I have put this all the way up to the max as you
suggested, but this did not resolve the issue from my original script.  I'll
have to keep digging for a solution in that regard.

For the area_light, I was certainly not clear on the pov-ray documentation and
examples.  From what I understand, I am creating a box (light box) that is
parallel with the xy-plan, onto which I'm stretching an array of 100x100 light
sources.  And as you stated, by adding the adaptive, feature, this gets
increased when running (Great thing to know!  I wasn't completely clear on what
happened in the background).

I am, however, still confused on why the area_light would be tilted.  As you
mentioned, I want a light parallel to the xy plane, and thought that this was
the case.

Given this example below, my understanding is that my light_box is a box that is
160x200x2 units (x,y,z) and collared white.  I then locate my light_source at
<light_loc_x, light_loc_y,light_loc_z>.  I then use the area_light feature to
define two points <-10, -10, 10>, <10, 10, 10> from the origin to indicate the
vectors over which to stretch the light.

#declare light_box = box{ <-80,-100,0>, <80,100,2>
        pigment{color White}
       } //end light box
light_source {
    <light_loc_x, light_loc_y,light_loc_z>
    color White
    area_light <-10, -10, 10>, <10, 10, 10>, 100, 100
    adaptive 1
    jitter
    looks_like { light_box }
  }

As I look closely at this and my response, I'm very much confused about the
area_light.

Given my example above, how would you define an area light parallel to the
xy-plane that is, say, + 80 units in the Z-direction, and fits to the dimensions
of the light_box that I defined?  I've missed something important in the
documentation.

Finally, with the fade_power, how is 1000 bad, but 1 or 1001 good?  I did a
little copy-pasting of this part from an example, so I had not really asked
myself what realistic values should be.

Thank you again for all of your comments and insights.  I've got more digging to
do!

[Kenneth] Re: Transparent Objects Become Black [1613 days 5 hours and 5 minutes ago]

Thu, 11 Nov 2021 17:55:00 GMT

Hi! Welcome to the forum.

Your sphere voids are not really 'black' but opaque (like silhouettes) due to
your light's position.

After stripping-out everything that was non-essential in your code, I
narrowed-down the problem to your 'gel' object and its differenced spheres (the
'voids'). It was only then that I realized that the problem is really with the
spheres themselves: In your code section "Add Bubble Definitions here", you need
to #declare those individual objects, then use *those* definitions in your gel
object. The sphere objects you actually used in your gel object are 'redefined'
there and have 'default' textures (which have no transparency.) So in effect,
your original five sphere definitions are not even being used; and the ones you
did use are simply opaque.

I've included my stripped-down scene to give you a better idea of what is
required, code-wise. I hope this helps you to understand the idea of #declaring
objects beforehand. Of course, it's not always necessary; you could have written
your five complete sphere definitions IN the gel object instead, without using
#declares.


[Some notes: In your own code, you used  ambient_light White. Nothing wrong with
that, but in case you don't know, ambient_light is just a *multiplier* for the
finish(ambient...} values in a scene. So here, you are simply multiplying your
ambient values by <1,1,1>, which is the White color.  Also, it looks like you
have a redundant or extra use of rotate <...> for your sphere voids. You should
eliminate one set of those, unless it's for some purpose.]

--- simplified code ---
#version 3.8;
global_settings{assumed_gamma 1.0 max_trace_level 50}

background{rgb <.1,.05,.05>}

#include "colors.inc"

#default{finish{ambient 0 emission 0 diffuse .9}}

#declare epsilon       = .0001;
#declare light_loc_x   = 0;
#declare light_loc_y   = 0;
#declare light_loc_z   = 90;

#declare tube_base    =  -55;
#declare tube_height  = 92;
#declare tube_rinner  = 13;

#declare gel_height   = 0.9*tube_height;
#declare bubble_r     = 0.8;

// [additional camera]
camera {
  perspective
  location  <-40, 19, -5>
  look_at   <0, 19,  0>
  right     x*image_width/image_height
 // rotate -180*clock*y
}

light_source {
<light_loc_x, light_loc_y,light_loc_z>
color White
  }

//———————————————————————————————————————————————————
// Creating bubbles that go into voids of gel
//———————————————————————————————————————————————————

// Add Bubble Definitions Here:

#declare SPH_1 =
sphere{ <4.708,7.784,4.171>, (bubble_r)
 texture {
  pigment{ color rgbt<.99,.99,.99,0.9>}
            finish { phong .001 }
              }
}

#declare SPH_2 =
sphere{ <1.862,29.796,-6.023>, (bubble_r)
 texture {
  pigment{ color rgbt<.99,.99,.99,0.9>}
  finish { phong .001 }
    }
}

#declare SPH_3 =
sphere{ <-7.205,20.129,-3.448>, (bubble_r)
 texture {
  pigment{ color rgbt<.99,.99,.99,0.9>}
  finish { phong .001 }
    } // end of texture
}

#declare SPH_4 =
sphere{ <1.424,17.806,-9.772>, (bubble_r)
 texture {
  pigment{ color rgbt<.99,.99,.99,0.9>}
  finish { phong .001 }
    } // end of texture
}

#declare SPH_5 =
sphere{ <-5.249,17.494,-3.139>, (bubble_r)
 texture {
  pigment{ color rgbt<.99,.99,.99,0.9>}
  finish { phong .001 }
    } // end of texture
}

// --- Creating gel and the bubble voids ---

difference{
 merge{
  sphere { <0,tube_base,0>, tube_rinner-epsilon}
  cylinder{<0,tube_base,0>, <0,gel_height,0>,
                                tube_rinner-epsilon}
   texture { pigment{ color rgbt<.99,.99,.99,0.9>}
   finish { phong .001 }
                      } // end of texture
  } // end merge (gel matrix)

// subtract Bubble Voids Here:

 object{SPH_1}  // bubble
 object{SPH_2}  // bubble
 object{SPH_3}  // bubble
 object{SPH_4}  // bubble
 object{SPH_5}  // bubble

 } // End difference for bubbles

[bubble person] Re: Transparent Objects Become Black [1613 days 5 hours and 35 minutes ago]

Thu, 11 Nov 2021 17:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "bubble_person" <nomail@nomail> wrote:
> > Hello Forum,
> >
> > I am relatively new to POV-RAY, but have a functional script .
> >
> > I am simulating air bubbles in a glass tube full of gel.  I am running into a
> > funny problem where, if I add too many bubbles to the script, they go from being
> > transparent and rendered correctly, to a completely opaque, black object through
> > which no light shines.
>
> not sure if it will help, or is even related to "the issue", but if I change the
> "bubble_r" to "(bubble_r - epsilon)" in the five spheres following comment "Add
> Bubble Voids here", they're visible.
>
> quick comment re "new to POV-Ray".  you have five identical (apart from
> location) spheres.  have a look at macros, they're ideal in such a situation.
> <https://wiki.povray.org/content/Reference:User_Defined_Macros#The_macro_Directive>
>
>
> regards, jr.

Hello Jr.,

Thank you for the response, and I appreciate your pointer to the Macros.  I'll
be taking a deeper look at this.

I tried what you suggested, and for my script, it causes the bubble surface to
be shiny (I can see reflection on the perimeter of the bubble), but it seems
like the center of the bubble remains black, unrendered, or something like that.
 Light is certainly not going through it.

In previous cases, light refracts through the center of the bubbles, so the fact
that the center is still dark tells me that I'm still encountering an issue.

One other idea that I had was using the "clipped_by{}" function when defining
the voids.  I reordered the merge{} definition for the gel and the used the
clipped_by{} function to subtract out the bubble voids.

I did this and the centers seem to have reappeared for all the bubbles.  The
light is refracting through the bubbles which is good, but I'm worried that I
might be missing a subtlety about how the "difference{}" and "clipped_by{}"
functions work.  I'm not sure why this has worked, and it's worrying me when my
goal is to simulate realistic refraction through this volume.

[Alain Martel] Re: Transparent Objects Become Black [1613 days 5 hours and 51 minutes ago]

Thu, 11 Nov 2021 17:08:51 GMT

Le 2021-11-11 Ã  08:06, bubble_person a Ã©critÂ :
> Hello Forum,
> 
> I am relatively new to POV-RAY, but have a functional script .
> 
> I am simulating air bubbles in a glass tube full of gel.  I am running into a
> funny problem where, if I add too many bubbles to the script, they go from being
> transparent and rendered correctly, to a completely opaque, black object through
> which no light shines.
> 
> Things that don't seem to work:
> 
> 1) Increasing the  max_trace_level
> 
> 2) I have tried to be sure that the inner surface of the gel is not in contact
> with the air bubble by reducing the bubble radius by epsilon (.0001).  Oddly
> enough, the script with up to 4 bubbles works only when the two surfaces are
> coincident, and subtracting an epsilon value (.0001,.001,.01) causes the bubbles
> to turn black, no matter the number.
> 
> I would love your input on this issue as I am stumped.  I cannot figure out why
> this renders without issue when I only have a certain number of objects defined.
> 
> 
> The order of my file:
> 
> In my scene, centered at the origin, I have bubbles, inside of gel, inside of a
> glass tube, inside of water, inside of a plexiglass cylinder.
> 
> My code
> 
> 1) I define variables, set trace level, and place the camera
> 
> 2) I create a distributed area light source on a rectangular box
> 
> 3) I define the bubbles I want in the gel
> 
> 4) I create the glass tube into which the gel will sit
> 
> 5) I create the gel region with voids into which the bubbles sit.
> 
> 6) I then add water around the glass tube, and then a plexiglass perimeter.
> 
> 
> 
> 

The first thing that I would to would be to increase max_trace_level 
further still. It can go up to 255.

Note : Your area_light is oblique. If you want it to be flat, then, it's 
size should be something like this :
area_light 160*x 200*z 65 65
adaptive 0 // start with zero, then, increase if needed
Size of area_light adjusted to match the light_box dimensions.

During testing, you should disable the area_light. It makes testing and 
debugging faster.

The 100 by 100 get silently increased to 129 by 129 when adaptive is 
used. That increase DO NOT affect the rendering time.

Using dispersion 1 is the same as not using dispersion. It must be 
slightly different than 1. Realistic values are usually in the 1.01 to 
1.08. Values less than 1 result in inverted dispersion.

You are using fade_power 1000 !? You should use 1 or 1001.
Using 1000 may cause some issues.

[jr] Re: Transparent Objects Become Black [1613 days 7 hours and 40 minutes ago]

Thu, 11 Nov 2021 15:20:00 GMT

hi,

"bubble_person" <nomail@nomail> wrote:
> Hello Forum,
>
> I am relatively new to POV-RAY, but have a functional script .
>
> I am simulating air bubbles in a glass tube full of gel.  I am running into a
> funny problem where, if I add too many bubbles to the script, they go from being
> transparent and rendered correctly, to a completely opaque, black object through
> which no light shines.

not sure if it will help, or is even related to "the issue", but if I change the
"bubble_r" to "(bubble_r - epsilon)" in the five spheres following comment "Add
Bubble Voids here", they're visible.

quick comment re "new to POV-Ray".  you have five identical (apart from
location) spheres.  have a look at macros, they're ideal in such a situation.
<https://wiki.povray.org/content/Reference:User_Defined_Macros#The_macro_Directive>

regards, jr.

[bubble person] Transparent Objects Become Black [1613 days 9 hours and 50 minutes ago]

Thu, 11 Nov 2021 13:10:00 GMT

Hello Forum,

I am relatively new to POV-RAY, but have a functional script .

I am simulating air bubbles in a glass tube full of gel.  I am running into a
funny problem where, if I add too many bubbles to the script, they go from being
transparent and rendered correctly, to a completely opaque, black object through
which no light shines.

Things that don't seem to work:

1) Increasing the  max_trace_level

2) I have tried to be sure that the inner surface of the gel is not in contact
with the air bubble by reducing the bubble radius by epsilon (.0001).  Oddly
enough, the script with up to 4 bubbles works only when the two surfaces are
coincident, and subtracting an epsilon value (.0001,.001,.01) causes the bubbles
to turn black, no matter the number.

I would love your input on this issue as I am stumped.  I cannot figure out why
this renders without issue when I only have a certain number of objects defined.


The order of my file:

In my scene, centered at the origin, I have bubbles, inside of gel, inside of a
glass tube, inside of water, inside of a plexiglass cylinder.

My code

1) I define variables, set trace level, and place the camera

2) I create a distributed area light source on a rectangular box

3) I define the bubbles I want in the gel

4) I create the glass tube into which the gel will sit

5) I create the gel region with voids into which the bubbles sit.

6) I then add water around the glass tube, and then a plexiglass perimeter.

[BayashiPascal] Re: driving scene simulation examples [1692 days 10 hours and 30 minutes ago]

Tue, 24 Aug 2021 12:30:00 GMT

I don't know of an equivalent to Kitti made with POV-Ray. That would be an
impressive amount of work ! But if you think of using POV-Ray to generate
datasets with automatic annotation for AI training, you may be interested in
this work of mine:
https://github.com/BayashiPascal/SDSIA

Pascal

"ynjiun" <nomail@nomail> wrote:
> Hi,
>
> I hope I am in the right place to post this question:
>
> I am looking for generating driving scene for AI training. Is there an example
> driving scene .pov file? or repository that contains examples that I can begin
> to learn how to create my own driving scene?
>
> Thank you very much for your help.
>
> -Ynjiun

[William F Pokorny] Re: driving scene simulation examples [1693 days 11 hours and 17 minutes ago]

Mon, 23 Aug 2021 11:42:48 GMT

On 8/22/21 5:55 PM, ynjiun wrote:
> Hi,
> 
> I hope I am in the right place to post this question:
> 
> I am looking for generating driving scene for AI training. Is there an example
> driving scene .pov file? or repository that contains examples that I can begin
> to learn how to create my own driving scene?
> 
> Thank you very much for your help.
> 
> -Ynjiun
> 

I'm not aware of any driving related standard shipped scene or animation.

If talking about still scenes you might find pre-packaged scenes on the 
old irtc site. Hmm... Is it back up after the server crash? Yes! See: 
http://www.irtc.org/

As for animations.

In addition to Bald Eagle's pointer you might look at work done by Jaime 
Vives Piqueres some years back. https://www.youtube.com/watch?v=QnBYP4LF7Ww

He hasn't been active with POV-Ray in the last couple years as far as I 
know, but he's got a POV-Ray web site at: http://www.ignorancia.org/

I couldn't immediately turn up sample scenes there for his driving car 
animation work, but there is contact information on the site.

I think he did a fair bit of work taking road racing data from some game 
and turning it into POV-Ray scenes and animations too, but there the 
details in my mind are foggier still.

The site http://www.oyonale.com is worth checking out too at for models 
and such.

Bill P.

[ynjiun] driving scene simulation examples [1694 days 1 hour ago]

Sun, 22 Aug 2021 22:00:00 GMT

Hi,

I hope I am in the right place to post this question:

I am looking for generating driving scene for AI training. Is there an example
driving scene .pov file? or repository that contains examples that I can begin
to learn how to create my own driving scene?

Thank you very much for your help.

-Ynjiun

[Thomas de Groot] Re: Finding extents of an object [1761 days 7 hours and 56 minutes ago]

Wed, 16 Jun 2021 15:04:06 GMT

Op 16-6-2021 om 15:51 schreef Alain Martel:
> I know that, but, in many cases, it's good enough.
> In the present case, it may be just what is needed. It will always 
> ensure that the whole object is visible, even if the use of the image's 
> real estate may not be optimal.
> 
> Also, the solution proposed ensure that the object do not extend beyond 
> the camera.

Absolutely.

Thanks Alain! I was just in need of something like this for the 
granite_21 macro, and you took away the need to write my own macro. ;-)

I changed your code into a macro which I include here. Herbert might 
want to use it.

-- 
Thomas

[Alain Martel] Re: Finding extents of an object [1761 days 9 hours and 9 minutes ago]

Wed, 16 Jun 2021 13:51:26 GMT

Le 2021-06-16 Ã  05:16, clipka a Ã©critÂ :
> Am 15.06.2021 um 22:27 schrieb Alain Martel:
> 
>> You can use max_extent(Object) and min_extent(Object) to relocate and 
>> scale your objects correctly.
>> Those return the far, top right and close bottom left of the bounding 
>> box of Object.
> 
> Just for the records: It is worthy to note that the bounding box of an 
> object is not necessarily a perfect fit; depending on the type of object 
> and how it has been rotated, it might be noticeably larger.
> 
> The reason is that the bounding boxes' primary purpose is to be used 
> internally during render to speed up calculations, but for that purpose 
> they don't need to be perfect, as long as they contian the entire object.

I know that, but, in many cases, it's good enough.
In the present case, it may be just what is needed. It will always 
ensure that the whole object is visible, even if the use of the image's 
real estate may not be optimal.

Also, the solution proposed ensure that the object do not extend beyond 
the camera.

[Bald Eagle] Re: Finding extents of an object [1761 days 12 hours and 20 minutes ago]

Wed, 16 Jun 2021 10:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> Just for the records: It is worthy to note that the bounding box of an
> object is not necessarily a perfect fit; depending on the type of object
> and how it has been rotated, it might be noticeably larger.

Right-o.  Always good to have that datum repeated as a refresher lest it bite
the unsuspecting.

That actually gave rise to a fair bit of exploration and learning:

http://news.povray.org/povray.general/thread/%3C5ef59918%241%40news.povray.org%3E/

http://news.povray.org/povray.text.scene-files/thread/%3Cweb.5db5b0ff51c96acafeeb22ff0%40news.povray.org%3E/

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5dc8a318adf09f614eec112d0%40news.povray.org%3E/?ttop=432391
&toff=100

http://news.povray.org/povray.text.scene-files/thread/%3Cweb.5dc33544f7b9a3affeeb22ff0%40news.povray.org%3E/


and finally:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.6067c66d2a07e751f9dae3025979125%40news.povray.org%3E/

[clipka] Re: Finding extents of an object [1761 days 13 hours and 44 minutes ago]

Wed, 16 Jun 2021 09:16:05 GMT

Am 15.06.2021 um 22:27 schrieb Alain Martel:

> You can use max_extent(Object) and min_extent(Object) to relocate and 
> scale your objects correctly.
> Those return the far, top right and close bottom left of the bounding 
> box of Object.

Just for the records: It is worthy to note that the bounding box of an 
object is not necessarily a perfect fit; depending on the type of object 
and how it has been rotated, it might be noticeably larger.

The reason is that the bounding boxes' primary purpose is to be used 
internally during render to speed up calculations, but for that purpose 
they don't need to be perfect, as long as they contian the entire object.

[Alain Martel] Re: Finding extents of an object [1762 days 2 hours and 33 minutes ago]

Tue, 15 Jun 2021 20:27:12 GMT

Le 2021-06-15 Ã  13:14, Herbert Pflaum a Ã©critÂ :
> Hi there,
> 
> I would like to render an object using POV-Ray and it works nicely for
> the most part. The issue is that I have varying objects that I'm
> rendering (the POV-Ray source is generated) and they are varying in
> their position and size. I always view them in orthographic projection
> from a 45Â° angle (i.e., object at 0,0,0 camera at 10,10,10 look_at
0,0,0).
> 
> This works fairly well but I would like the rendering output to be so
> that the object is not clipped but also takes up most of the screen real
> estate. I do this currently by manually varying the "angle" operator
> (i.e., for small objects, small angle and for large objects a large angle).
> 
> I want this do be done automatically but I don't know where to start.
> Any hints on how to achieve this?
> 
> Thanks,
> Herbert
> 

You can use max_extent(Object) and min_extent(Object) to relocate and 
scale your objects correctly.
Those return the far, top right and close bottom left of the bounding 
box of Object.

The way to use that is as follow (steps as comment so that you can 
copy/paste in your scene :

// 1) #declare your object.
#declare Object = { your object's definition/construction }

// 2) Find it's bounds :
#declare TopRight = max_extent(Object);
#declare BottomLeft = min_extent(Object);

// 3) Find the centre of the object :
#declare ObjCentre = (TopRight + BottomLeft ) /2;

// 4) Place your object at the origin :
#declare Object = object{Object translate -ObjCentre }

// 5) Optionally, you can scale it to fit and prevent clipping :
#declare Extent = max(TopRight.x, TopRight.y, TopRight.z);
// Find the largest dimension

#declare DimFactor = 9.9;
// Standardize the dimention :
#declare Object = object{Object scale 9.9/Extent}

// This effectively scale your object down to a size of 1 unit, then
// up by a factor of 9.9, keeping it's proportions intact
// and providing a small margin

// 6) Finally, place it in your scene :
Object

The value of Â«DimFactorÂ» may need to be adjusted to have your
best fit.

[Bald Eagle] Re: Finding extents of an object [1762 days 5 hours and 15 minutes ago]

Tue, 15 Jun 2021 17:45:00 GMT

Herbert Pflaum <nospam@invalid> wrote:
> Hi there,
>
> I would like to render an object using POV-Ray and it works nicely for
> the most part. The issue is that I have varying objects that I'm
> rendering (the POV-Ray source is generated) and they are varying in
> their position and size. I always view them in orthographic projection
> from a 45° angle (i.e., object at 0,0,0 camera at 10,10,10 look_at 0,0,0).

Well, the orthographic projection makes it easy.
http://news.povray.org/58475e0a%241%40news.povray.org

So what I would do is define your object at the origin, and put your camera at
z=10, then rotate your object -y*45 and -x*45 to simulate the way it will look
with the camera in the proper location.   That will give you an axis-aligned
bounding box which will tell you how many pov-units wide and high it is in that
orientation.

Then you can either use the scene as it is and calculate an appropriate "zoom"
value, or undo the rotations and then move your camera to xyz*10

make sense?

You may have to perform additional adjustments using a translation if your
objects are not symmetrical and centered on the origin.

> This works fairly well but I would like the rendering output to be so
> that the object is not clipped but also takes up most of the screen real
> estate. I do this currently by manually varying the "angle" operator
> (i.e., for small objects, small angle and for large objects a large angle).
>
> I want this do be done automatically but I don't know where to start.
> Any hints on how to achieve this?

Just in case you're interested, there was a thread on doing this with the
perspective camera as well:

http://news.povray.org/povray.binaries.images/thread/%3C5d95e6c3%241%40news.povray.org%3E/

-Bill

[Herbert Pflaum] Finding extents of an object [1762 days 5 hours and 46 minutes ago]

Tue, 15 Jun 2021 17:14:40 GMT

Hi there,

I would like to render an object using POV-Ray and it works nicely for
the most part. The issue is that I have varying objects that I'm
rendering (the POV-Ray source is generated) and they are varying in
their position and size. I always view them in orthographic projection
from a 45Â° angle (i.e., object at 0,0,0 camera at 10,10,10 look_at 0,0,0).

This works fairly well but I would like the rendering output to be so
that the object is not clipped but also takes up most of the screen real
estate. I do this currently by manually varying the "angle" operator
(i.e., for small objects, small angle and for large objects a large angle).

I want this do be done automatically but I don't know where to start.
Any hints on how to achieve this?

Thanks,
Herbert

[clipka] Re: sphere proportions [1774 days 2 hours and 30 minutes ago]

Thu, 3 Jun 2021 20:29:46 GMT

Am 02.06.2021 um 15:47 schrieb clipka:

> (ramblerambleramble)

Oh, and one thing I forgot to mention entirely:

If you're using POV-Ray v3.8 or higher, and start you scene with

#version 3.8;

(as you should), then your sphere should automagically be round 
regardless of image size, even without messing with `right` and/or `up`.

At least that's what I had written in `changes.txt` some glorious day, 
so it must be true. Totally forgot that I implemented that.

[clipka] Re: sphere proportions [1774 days 4 hours and 23 minutes ago]

Thu, 3 Jun 2021 18:36:54 GMT

Am 03.06.2021 um 15:38 schrieb Alain Martel:

> Yes... but, most modern monitors have exactly a 16:9 aspect ratio.
> The ubiquitous 1920x1080 is 16:9.

Most, but not all.

Two 1920x1200 displays here. (And a third one tucked away in a box.)

In general, displays targeted at end-users are pretty much all 16:9; 
those targeted at people who do actual work with them come at 16:10 
surprisingly(?) frequently.

In their office range of displays, Eizo for instance currently offers 
more displays @ 1920x1200 than @ 1920x1080 (10 vs. 8).

In their photo/video editing range of displays, they don't even offer 
1920x1080; in that ballpark, 1920x1200 is the only thing they offer. (At 
higher resolution, they're tending towards 16:9 though, too, or even 17:9.)

[Alain Martel] Re: sphere proportions [1774 days 9 hours and 22 minutes ago]

Thu, 3 Jun 2021 13:38:36 GMT

Le 2021-06-01 à 18:45, Mike Horvath a écrit :
> On 6/1/2021 6:34 PM, Psnarf wrote:
>>  From Section 2.3.1.1.6:
>> Most computer video modes and graphics printers use perfectly square 
>> pixels.
>> Note: 640/480 = 4/3 so the ratio is proper for this square pixel mode.
>> Non-square pixels: IBM VGA mode 320x200
>>
>> It may be some time before the default aspect ratio changes to 1080p, 
>> 1.777.
>>
>>
> 
> I prefer 16:10. I hear 3:2 is very nice too. 16:9 is only good for 
> movies IMO. Should not be used for work displays.
> 
> 
> Mike

Yes... but, most modern monitors have exactly a 16:9 aspect ratio.
The ubiquitous 1920x1080 is 16:9.

[Thomas de Groot] Re: sphere proportions [1774 days 16 hours and 19 minutes ago]

Thu, 3 Jun 2021 06:41:23 GMT

Op 02/06/2021 om 22:01 schreef clipka:
> Am 02.06.2021 um 00:45 schrieb Mike Horvath:
> 
>> I prefer 16:10. I hear 3:2 is very nice too. 16:9 is only good for 
>> movies IMO. Should not be used for work displays.
> 
> Hear, hear!

Indeed. Good suggestions.

-- 
Thomas

[clipka] Re: sphere proportions [1775 days 2 hours and 59 minutes ago]

Wed, 2 Jun 2021 20:01:13 GMT

Am 02.06.2021 um 00:45 schrieb Mike Horvath:

> I prefer 16:10. I hear 3:2 is very nice too. 16:9 is only good for 
> movies IMO. Should not be used for work displays.

Hear, hear!

[clipka] Re: sphere proportions [1775 days 9 hours and 12 minutes ago]

Wed, 2 Jun 2021 13:47:51 GMT

Am 01.06.2021 um 19:37 schrieb Psnarf:

> Why does the radius of the sphere change if the render window is not 1:1.333?

For some background information:

POV-Ray's historic roots date back as far as 30 years. The earliest 
pieces of code were developed for the Commodore Amiga series of computers.

When the earlier versions of the current scene description language were 
designed, square pixels were still a novelty, while screen aspect ratio 
was pretty much standardized: Virtually all personal computers of that 
era used standard PAL or NTSC analog TV sets as a displays, which had a 
designed aspect ratio of 4:3, and even computers that came with their 
own display followed that convention. (It was customary to have a small 
border around the image, so that the edges of the image wouldn't be 
hidden in the somewhat rounded corners of the TV set, but that usually 
didn't affect the aspect ratio too much.)

When it came to pixel resolution though, those early systems had a wide 
variety of standards: 320x200 was quite common, especially in NTSC 
dominated regions (note the 8:5 = 16:10 aspect ratio!), but the pixels 
would have been slightly taller than wide; 320x240 (genuine 4:3) was 
occasionally seen in computers specifically targeted at PAL-dominated 
regions, but e.g. the Amiga 500 in PAL mode would have used 320x256 
(5:4), using slightly squashed pixels.

And then there were those computers that used different modes to get 
more colours out of the same amount of video buffer memory (and memory 
read timing) at the cost of horizontal resolution, or vice versa, giving 
image resolutions as odd as e.g. 160x200 (4:5) or 640x200 (16:5). Not 
anywhere close to square pixels there.


TL;DR: Back in those days, it was anything but a given that the "storage 
aspect ratio" (the aspect ratio in pixels) of an image would match the 
"display aspect ratio" (the aspect ratio in cm or inch as displayed on 
screen), because pixels were rarely square back then.


That still holds true in some professional applications, e.g. HDV or 
DVCPRO HD - though the details of those formats tend to rarely be 
exposed to end users anymore.

Also, POV-Ray allows to render formats where the display aspect ratio is 
fixed in some other ways while the storage aspect ratio could be adapted 
depending on requirements; e.g. 360 degrees panoramic images (the 
standard 2:1 ratio there is sub-optimal unless your main focus of 
interest is near the "equator").

[Bald Eagle] Re: sphere proportions [1776 days ago]

Tue, 1 Jun 2021 23:00:00 GMT

Yeah, but the exact syntax of those commands is more like:

camera {
 location <0, 0, -3>
 look_at <0, 0, 0>
 right x*image_width/image_height
}

Dunno which version you're landing on, but the most up-to-date documentation
will be at:
https://wiki.povray.org/content/Main_Page

I don't know if this will help or not, but consider this:

There is no sphere.
Likewise, there is no camera, no light - none of it exists.
It's all just one big mathematical simulation whose whole goal is to do one
thing - figure out what color to make that pixel at the current <x, y> location.
(Not on the screen, mind you - in a FILE - a big wad of 0's and 1's that might
have visual meaning when properly processed and displayed on your monitor.

http://www.rene-magritte.com/this-is-not-an-apple/
https://conceptually.org/concepts/the-map-is-not-the-territory

As such, you have no space, and no reference by which to establish an objective
unit of measure.  And so at some point you have to boot-strap things and impose
one "arbitrarily".
And that is done by the standard method of taking the image dimensions and
making it one unit high and one unit wide in the z=1 plane for the default
camera.
(you don't even have to declare a camera if you use the default and know that
it's at the origin and looking at <0, 0, 1>)
But now you have to take the number of pixels into account, and - adjust - for
that.

Take a piece of regular letter/A4 paper and divide it into 10 units long and 10
units wide - you get rectangles.   It gets farther off if you use 8.5 x 14.
So if you were going to use sin and cos to calculate the positions of points
around the circle, and you just graphed it as is - it would _look_ like an
ellipse because your basis vectors are unequal.  So instead of applying a
correction to every bloody thing that you do, you could just view the paper
through a lens that scrunched the paper in one dimension, altering the visual
perception of the graph such that it now properly _looks_ like a circle.

And that's the all the "camera" is in POV-Ray, a mathematical "lens" that maps
the raw mathematical result onto a different "space".

And truly, unless you have some specific need for knowing HOW it all works
(believe me, I understand), then just don't worry about it and plug-and-chug.


https://www.youtube.com/watch?v=uAXtO5dMqEI

[Mike Horvath] Re: sphere proportions [1776 days and 14 minutes ago]

Tue, 1 Jun 2021 22:45:48 GMT

On 6/1/2021 6:34 PM, Psnarf wrote:
>  From Section 2.3.1.1.6:
> Most computer video modes and graphics printers use perfectly square pixels.
> Note: 640/480 = 4/3 so the ratio is proper for this square pixel mode.
> Non-square pixels: IBM VGA mode 320x200
> 
> It may be some time before the default aspect ratio changes to 1080p, 1.777.
> 
> 

I prefer 16:10. I hear 3:2 is very nice too. 16:9 is only good for 
movies IMO. Should not be used for work displays.


Mike

[Alain Martel] Re: sphere proportions [1776 days and 15 minutes ago]

Tue, 1 Jun 2021 22:45:08 GMT

Le 2021-06-01 à 18:22, Psnarf a écrit :
> Hunted down section 1.4.2.4 in the manual.
> camera
> { right x*ImageWidth/ImageHeight
>    (other camera settings...)
> }
> 
> 
It's image_width/image_height, no capital and with an underscore.

camera
{ right x*image_width/image_height
   (other camera settings...)
}

It can also be set using the up vector as follow :
camera
{ up y*image_height/image_width
   right x
   (other camera settings...)
}

Yes. That structure will ensure that the camera will always respect the 
aspect ratio of the generated image.

image_width and image_height are internal, reserved variables that 
contain the actual dimensions of the rendered image.

[Psnarf] Re: sphere proportions [1776 days and 25 minutes ago]

Tue, 1 Jun 2021 22:35:00 GMT

From Section 2.3.1.1.6:
Most computer video modes and graphics printers use perfectly square pixels.
Note: 640/480 = 4/3 so the ratio is proper for this square pixel mode.
Non-square pixels: IBM VGA mode 320x200

It may be some time before the default aspect ratio changes to 1080p, 1.777.

[Psnarf] Re: sphere proportions [1776 days and 35 minutes ago]

Tue, 1 Jun 2021 22:25:00 GMT

Hunted down section 1.4.2.4 in the manual.
camera
{ right x*ImageWidth/ImageHeight
  (other camera settings...)
}

[jr] Re: sphere proportions [1776 days 1 hour ago]

Tue, 1 Jun 2021 22:00:00 GMT

hi,

"Psnarf" <nomail@nomail> wrote:
> ... I still don't see the
> connection between the rendered object in 3d space and the +W +H switches to the
povray command.

the width + height were used to ensure the ratio matches that specified in the
camera; any size will do as long as you have the aspect ratio be the same for
both camera _and_ image.  ;-)

regards, jr.

[Psnarf] Re: sphere proportions [1776 days 1 hour and 10 minutes ago]

Tue, 1 Jun 2021 21:50:00 GMT

I did not know the default aspect ratio was 4/3, or 1.333. I still don't see the
connection between the rendered object in 3d space and the +W +H switches to the
povray command. A ball should look the same no matter the size of the rendered
image. If the aspect ratio of the povray scene is different than the dimensions
of the rendered scene, should not the borders be extended, leaving a 4/3 box in
the center of the final image? I'm looking for a keep-aspect-ratio switch.

[Bald Eagle] Re: sphere proportions [1776 days 2 hours and 5 minutes ago]

Tue, 1 Jun 2021 20:55:00 GMT

"Psnarf" <nomail@nomail> wrote:
> The code for demo.pov:
>
> #include "colors.inc"    // The include files contain
> #include "stones.inc"    // pre-defined scene elements
>
> camera {
>     location <0, 2, -3>
>     look_at  <0, 1,  2>
> }
>
> sphere {
>     <0, 1, 2>, 2
>     texture {
>         pigment { color Yellow }
>     }
> }
>
> light_source { <2, 4, -3> color White}
>
> -=-=-=-=-=-=-=-=-
> Why does the radius of the sphere change if the render window is not 1:1.333?
> A ratio of 1:1.777 (16/9) produces the attached image.

I don't think it's the "render window", but rather the camera configuration
which is the controlling factor.  In the same way that you can scale the sphere,
you can scale the camera.  Depending on the aspect ratio of the image, you're
going to need to compensate for that in some way - the easiest being the camera.

If you look at the diagram of the camera, you get a "viewport" with "uv
coordinates" of the image going from -0.5 to 0.5 both vertically and
horizontally, or one unit in each orthogonal direction.  If those are not
equally subdivided into the same number of pixels per unit, then when you try to
draw a circle, you get an ellipse.   When you try to draw a square, you get a
rectangle.  So when the image aspect tries to "pull" in one direction, you
"squash" it the same relative amount in the other so that it all balances out.

Believe, me, we've covered this very topic from a variety of angles, and if
you're intensely interested, I can point you to a number of threads, and you can
try to do some experiments of your own to demonstrate to yourself how it all
works.

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5bb3646e813dde7ac437ac910%40news.povray.org%3E/

http://news.povray.org/povray.binaries.images/thread/%3Cweb.587ce3fc782d1af2c437ac910%40news.povray.org%3E/?ttop=418740
&toff=50&mtop=415328

While not "POV-Ray", I personally find it instructive to learn how people code
pixel shaders from scratch, which gives me a lot of easily-accessible insight
into how things like cameras, light, shadows, transform matrices, pattern
functions, mathematical object primitives, and CSG operations work "under the
hood".

https://www.youtube.com/watch?v=dKA5ZVALOhs
https://www.youtube.com/watch?v=PBxuVlp7nuM

https://iquilezles.org/www/articles/frustum/frustum.htm

[jr] Re: sphere proportions [1776 days 5 hours ago]

Tue, 1 Jun 2021 18:00:00 GMT

hi,

"Psnarf" <nomail@nomail> wrote:
> The code for demo.pov:
>
> #include "colors.inc"    // The include files contain
> #include "stones.inc"    // pre-defined scene elements
>
> camera {
>     location <0, 2, -3>
>     look_at  <0, 1,  2>
> }
>
> sphere {
>     <0, 1, 2>, 2
>     texture {
>         pigment { color Yellow }
>     }
> }
>
> light_source { <2, 4, -3> color White}
>
> -=-=-=-=-=-=-=-=-
> Why does the radius of the sphere change if the render window is not 1:1.333?
> A ratio of 1:1.777 (16/9) produces the attached image.

when I cut'n'paste the above in a file and render it all defaults (here 4/3, ie
960x720), the sphere's round.  if I insert 'right x * (16/9)' in the camera, and
render with '+w960 +h540', the sphere's round.

if you do not want to modify the camera, you'll have to stick with the (default)
4/3 aspect to see the shape you expect.

regards, jr.

[Psnarf] Re: sphere proportions [1776 days 5 hours and 20 minutes ago]

Tue, 1 Jun 2021 17:40:00 GMT

The code for demo.pov:

#include "colors.inc"    // The include files contain
#include "stones.inc"    // pre-defined scene elements

camera {
    location <0, 2, -3>
    look_at  <0, 1,  2>
}

sphere {
    <0, 1, 2>, 2
    texture {
        pigment { color Yellow }
    }
}

light_source { <2, 4, -3> color White}

-=-=-=-=-=-=-=-=-
Why does the radius of the sphere change if the render window is not 1:1.333?
A ratio of 1:1.777 (16/9) produces the attached image.

[Psnarf] Re: sphere proportions [1776 days 5 hours and 25 minutes ago]

Tue, 1 Jun 2021 17:35:00 GMT

> x*image_width/image_height = <image_width/image_height, 0, 0>
> "x" is a reserved keyword, shorthand for the cardinal x basis vector, <1, 0, 0>.

That seems intuitive. Thanks for the tip!

Obquote:
  "Ad hoc, ad hoc,
  And quid pro quo.
  So little time,
  And so much to know." -J. Hillary Boob, Phud.

[Bald Eagle] Re: sphere proportions [1777 days 4 hours and 35 minutes ago]

Mon, 31 May 2021 18:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...> personally I like to use an aspect ratio (eg "right * (16/9)"), because
>
> sheesh..  should read "right x * (16/9)".  sorry.

Yes,  and a lot of us are lazy and very naughty and use:

right x*image_width/image_height

https://wiki.povray.org/content/Knowledgebase:Language_Questions_and_Tips#Topic_19

It's worth pointing out at this early stage that "x" is a reserved keyword,
shorthand for the cardinal x basis vector, <1, 0, 0>.

So after multiplying, you get: <image_width/image_height, 0, 0>

Maybe this will help explain better, or help to further confuse you...  :D

http://news.povray.org/povray.binaries.images/thread/%3Cweb.5d881ea3763463c54eec112d0%40news.povray.org%3E/?ttop=430067
&toff=50

[jr] Re: sphere proportions [1777 days 4 hours and 55 minutes ago]

Mon, 31 May 2021 18:05:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...> personally I like to use an aspect ratio (eg "right * (16/9)"), because

sheesh..  should read "right x * (16/9)".  sorry.


regards, jr.

[jr] Re: sphere proportions [1777 days 5 hours ago]

Mon, 31 May 2021 18:00:00 GMT

hi,

"Psnarf" <nomail@nomail> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ....
> Thank you, jr. I am a noob, running the demo.pov from the tutorial. I haven't
> come to the camera, yet. As the poet Frost might say, I have miles to go before
> I can create anything worthy of the top-100.

you're welcome.  hope you will find "povving" a pleasant hobby.  re camera,
personally I like to use an aspect ratio (eg "right * (16/9)"), because it's
readable.

regards, jr.

[Psnarf] Re: sphere proportions [1777 days 5 hours and 35 minutes ago]

Mon, 31 May 2021 17:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
....
> depends on the 'right' vector of your camera.
> <https://wiki.povray.org/content/Reference:Camera#Index_Entry_right_camera>
>
>
> regards, jr.

Thank you, jr. I am a noob, running the demo.pov from the tutorial. I haven't
come to the camera, yet. As the poet Frost might say, I have miles to go before
I can create anything worthy of the top-100.

[jr] Re: sphere proportions [1777 days 6 hours and 20 minutes ago]

Mon, 31 May 2021 16:40:00 GMT

hi,

"Psnarf" <nomail@nomail> wrote:
> In a square window,
> sphere {
>     <0, 1, 2>, 2
>     texture {
>         pigment { color Yellow }
>     }
> }
> produces an ellipsoid, the vertical radius is larger than the horizontal radius:
> `povray -Idemo.pov +V +W400 +H400`
>
> Apparently, the window proportion must be 1:1.33 in order to produce a sphere
> with a fixed radius. Should not sphere appear circular no matter what the window
> proportions in the render command?

depends on the 'right' vector of your camera.
<https://wiki.povray.org/content/Reference:Camera#Index_Entry_right_camera>


regards, jr.

[Psnarf] Re: sphere proportions [1777 days 6 hours and 25 minutes ago]

Mon, 31 May 2021 16:35:00 GMT

> the window proportion must be 1:1.33
....such as 640x480 or 520x390

[Psnarf] sphere proportions [1777 days 6 hours and 30 minutes ago]

Mon, 31 May 2021 16:30:00 GMT

In a square window,
sphere {
    <0, 1, 2>, 2
    texture {
        pigment { color Yellow }
    }
}
produces an ellipsoid, the vertical radius is larger than the horizontal radius:
`povray -Idemo.pov +V +W400 +H400`

Apparently, the window proportion must be 1:1.33 in order to produce a sphere
with a fixed radius. Should not sphere appear circular no matter what the window
proportions in the render command?

[William F Pokorny] Re: Ignorance rules! [1781 days 12 hours and 56 minutes ago]

Thu, 27 May 2021 10:04:42 GMT

On 5/26/21 9:23 PM, clipka wrote:
> Am 23.06.2020 um 19:25 schrieb Cousin Ricky:
>> On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
> ...
>>> We have the convention today users should not declare IDs with lower 
>>> case characters because such things might become, or might already 
>>> be, SDL keywords. What I'm thinking about for povr is adding checking 
>>> such that users cannot declare/local a name with only (lower case 
>>> ascii, _) characters. #declare _a =... would be a parsing error.
>>>
>>> With this in place, I think it would then be the case we could always 
>>> use something like _<lowercase_parm> for all our parameters without 
>>> worry of collisions. The _ leading character would never be part of a 
>>> keyword.
>>>
>>> Am I missing something with this planned approach?
> 
> Been there. Done that.
> Curesed a lot.
> 
>> I suppose it could work.Â  It could potentially break old scenes, but I 
>> don't suppose many such scenes exist.Â  None of the stock include files 
>> have any such names that I can find.
> 
> Look harder.
> `functions.inc` is what made me put the idea on the back burner.

Yes, there's that and more for complications. I've had some success with 
it and it's how I've been running day to day for near a year now(1). 
Twiddle with the hacked in code now and again as I pick up some detail - 
recently performance impacts doing millions of calls to macros. Made it 
better, but, thinking now even when compiled in there should perhaps be 
a run time switch - but given how our macros work even simple that would 
be seen performance wise in the worst cases.

Today, I'd say it'll stay in as a configure option for sure, but we'll see.

Bill P.

(1) - It lines up with my coding style/aim where it won't with all.

[William F Pokorny] Re: Ignorance rules! [1781 days 13 hours and 3 minutes ago]

Thu, 27 May 2021 09:57:26 GMT

On 5/26/21 10:58 PM, clipka wrote:
> Can you help me out which pull request of yours that would have been, 
> for which I suggested the use of PRECISE_FLOAT?

Related to selective use of long doubles where the hardware supports 
80/96 bits or more.

There is today no value to you or the POV-Ray code mainstream to dig 
into this. It's my code base stuck with something once thought might be 
of value which - knowing what I know today - isn't. It doesn't hurt 
anything other than my code's esthetics to have it sitting in there. It 
just bugs me that it is there.

Bill P.

[clipka] Re: Ignorance rules! [1781 days 20 hours and 1 minute ago]

Thu, 27 May 2021 02:58:47 GMT

Am 24.06.2020 um 19:53 schrieb William F Pokorny:

> (4) - And, yep. I don't like the DBL, SNGL in our source code since 
> v1.0. Or the PRECISE_FLOAT Christoph asked me to add to a pull request 
> years back which then never got adopted. PRECISE_FLOAT now needs to be 
> yanked at some point from povr and I'd like to drop DBL and SNGL too.

I'm trying to jog my memory here to recall what that PRECISE_FLOAT was 
all about, but for the love of it I can't find no reference to it, 
except mentions by you yourself: One in 2019-02-17 in povray.beta-test 
where you posted a snippet apparently from a custom 
`polynomialsolver.cpp` where it appears in a comment, and one in a pull 
request from LeForgeron, titled "fix for FS324, regression on triangle" 
(pull request #358), where you mentioned "the new PRECISE_FLOAT compile 
hook" on 2019-06-06.

Can you help me out which pull request of yours that would have been, 
for which I suggested the use of PRECISE_FLOAT?

The Interwebkraken knows nothing else about it, GitHub can't seem to dig 
it up, and even in all my dozen unpublished half-finished branches that 
spun off at different times in history and still reside on my computer, 
none of them seems to contain the character sequence "PRECISE_FLOAT".


Is there a publicly accessible repo for your povr branch? Seeing where 
you're using the thing might bring my memory back up to speed.

[clipka] Re: Ignorance rules! [1781 days 21 hours and 37 minutes ago]

Thu, 27 May 2021 01:23:06 GMT

Am 23.06.2020 um 19:25 schrieb Cousin Ricky:
> On 2020-06-23 7:28 AM (-4), William F Pokorny wrote:
...
>> We have the convention today users should not declare IDs with lower 
>> case characters because such things might become, or might already be, 
>> SDL keywords. What I'm thinking about for povr is adding checking such 
>> that users cannot declare/local a name with only (lower case ascii, _) 
>> characters. #declare _a =... would be a parsing error.
>>
>> With this in place, I think it would then be the case we could always 
>> use something like _<lowercase_parm> for all our parameters without 
>> worry of collisions. The _ leading character would never be part of a 
>> keyword.
>>
>> Am I missing something with this planned approach?

Been there. Done that.
Curesed a lot.

> I suppose it could work.Â  It could potentially break old scenes, but I 
> don't suppose many such scenes exist.Â  None of the stock include files 
> have any such names that I can find.

Look harder.
`functions.inc` is what made me put the idea on the back burner.

[Cousin Ricky] Re: How to locate/light this airplane skeleton? [1797 days 18 hours and 2 minutes ago]

Tue, 11 May 2021 04:57:52 GMT

On 2021-05-09 11:01 PM (-4), coltson wrote:
> Hello. I got the code to render the skeleton of an airplane. However, its only
> the airplane's skeleton code, no "scene" code is there, so I cannot send povray
> ro render it and see the results. So I used the menu and inserted two default
> point light (changed one of them a bit) and "A typical camera".
> 
> However, the end result is nearly black, and nothing from the skeleton can be
> seen:

Moving the lights and camera, or setting emission on the texture will
not help in this case (sorry, Bill).  Only creating an environment will
reveal the problem.

1. First declare the airplane, so its dimensions can be read.

2. Place the airplane in the scene.

3. Create a ground plane, using the airplane's dimensions as a guide.

4. Add a background.

----------[BEGIN CODE EXCERPT]----------
#declare Airplane =
object { Body(R1, R2, R3, R4, R5)
        texture {
                pigment {
                        color_map {      // color map
                                [0.1 color red 1]
                                [0.5 color rgbf 1]
                        }
                }
                finish {diffuse 0.9 phong 1}
        }
}
object { Airplane }
plane
{ y, min_extent (Airplane).y
  pigment { rgb 0.5 }
}
background { rgb <0.3, 0.5, 0.7> }
-----------[END CODE EXCERPT]-----------

As it turns out, your current camera shows enough of the airplane to
give you an idea of how to adjust it.

As you can see, the airplane really is black.  The reason is that the
pigment has no pattern on which to apply the color map.  The pigment
needs a pattern, such as gradient, marble, or wood.

You should have gotten a parse warning "Pigment type unspecified or not
1st item" or "No pigment type given" in the message window.